[Freeipa-users] DNS reverse zone is not managed by this server

Tue Dec 27 12:04:17 UTC 2016

$ dig 0.0.10.in-addr.arpa

; <<>> DiG 9.10.3-P4-Ubuntu <<>> 0.0.10.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14232
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;0.0.10.in-addr.arpa. IN A

;; AUTHORITY SECTION:
0.0.10.in-addr.arpa. 3600 IN SOA freeipa1.cs.int. hostmaster.cs.int.
1482653944 3600 900 1209600 3600

;; Query time: 197 msec
;; SERVER: 10.0.0.200#53(10.0.0.200)
;; WHEN: Tue Dec 27 13:02:24 CET 2016
;; MSG SIZE  rcvd: 111

On Tue, Dec 27, 2016 at 12:24 PM, Martin Basti <mbasti at redhat.com> wrote:

>
>
> On 27.12.2016 12:07, Maciej Drobniuch wrote:
>
> Hi Martin!
>
> Thank you for your time!
>
> On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti <mbasti at redhat.com> wrote:
>
>>
>>
>> On 22.12.2016 10:57, Maciej Drobniuch wrote:
>>
>> Hi Martin
>>
>> Appreciate your help!
>>
>> On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti <mbasti at redhat.com> wrote:
>>
>>>
>>>
>>> On 22.12.2016 09:37, Maciej Drobniuch wrote:
>>>
>>> Hi Martin
>>>
>>> Thank you for reply.
>>>
>>> 1. The dig is returning proper PTR record. I've added it manually to the
>>> zone and it's working.
>>>
>>>
>>> I was asking for SOA and zone name, IMO there is nothing secret about
>>> reverse zone name from private address space
>>>
>>> what returns this command on server?
>>> python -c 'import netaddr; from dns import resolver; ip =
>>> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn;
>>> print resolver.zone_for_name(revn)'
>>>
>>>
>>> # python -c 'import netaddr; from dns import resolver; ip =
>> netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn;
>> print resolver.zone_for_name(revn)'
>> 165.0.0.10.in-addr.arpa.
>> in-addr.arpa.
>>
>>
>> It looks that python-dns failed to find proper zone, what is supposed to
>> be authoritative zone for that record in your system?
>> How do your reverse zones look?
>>
> I have the reverse zone added.
> 0.0.10.in-addr.arpa.
>
> Do you know maybe how python/ipa is determining what's the dns server for
> the internal zone?
> As far I understood this is not a "access rights issue". It's a DNS PTR
> resolution problem with python(ipa's using python) ?
>
>
> It doesn't care about resolver, python-dns is checking SOA records, it
> removes labels from left and tries to find best match zone
>
> what returns dig 0.0.10.in-addr.arpa.  SOA ?
>
>
>
>
>>
>>
>>
>> 2. The problem exists while adding host entries or A records with "create
>>> reverse" option.
>>>
>>> That's why I asked to run dig, the code uses DNS system to determine
>>> zone.
>>>
>>> 3. If I'll bind a host with ipa-client-install the PTR record gets
>>> created in the reverse zone and it works
>>>
>>> Ok
>>>
>> Manually creating the PTR record works fine as well.
>>
>>>
>>>
>>> 4. The resolv.conf file has only the IPA server IP addres/localhost
>>> added.
>>>
>>>
>>> Have you changed it recently?
>>>
>> Yes, it pointed to outside 8.8.8.8, so the OS did not see the local
>> reverse zone.
>> Now it's pointing to localhost. And I get dig the PTRs. (I've manually
>> created the ptr)
>>
>> # dig -x 10.0.0.165
>>
>> ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> -x 10.0.0.165
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35592
>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
>>
>> ;; OPT PSEUDOSECTION:
>> ; E: version: 0, flags:; udp: 4096
>> ;; QUESTION SECTION:
>> ;165.0.0.10.in-addr.arpa. IN PTR
>>
>> ;; ANSWER SECTION:
>> 165.0.0.10.in-addr.arpa. 1200 IN PTR prdfrmprb01.cs.int.
>>
>> ;; AUTHORITY SECTION:
>> 1.0.10.in-addr.arpa. 86400 IN NS freeipa1.cs.int.
>>
>>
>> This authority section looks suspicious, I would expect something like
>> 0.0.10.in-addr.arpa.
>>
>> Back to question about your reverse zones.
>>
> I've intentionally hid our internal ip space, sorry, good catch my finger
> has slipped :).
>
>
> So is the 0.0.10.in-addr.arpa. an authoritative zone? Or what dig returned
> in authority section.
>
>
>
>>
>> ;; ADDITIONAL SECTION:
>> freeipa1.cs.int. 1200 IN A 10.0.0.200
>>
>> ;; Query time: 3 msec
>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>> ;; WHEN: czw gru 22 04:51:23 EST 2016
>> ;; MSG SIZE  rcvd: 124
>>
>>>
>>>
>>> Martin
>>>
>>>
>>>
>>> Cheers!
>>> M.
>>>
>>> On Wed, Dec 21, 2016 at 5:43 PM, Martin Basti <mbasti at redhat.com> wrote:
>>>
>>>> Hello all :)
>>>>
>>>> On 20.12.2016 01:33, Maciej Drobniuch wrote:
>>>>
>>>> Hi All!
>>>>
>>>> I get the following message while adding a new hostname.
>>>>
>>>> "The host was added but the DNS update failed with: DNS reverse zone
>>>> in-addr.arpa. for IP address 10.0.0.165 is not managed by this server"
>>>>
>>>>
>>>> IPA failed to get correct reverse zone, can you try dig -x 10.0.0.165
>>>> what will be in SOA answer?
>>>>
>>>> What is the name of reverse zone you have on IPA DNS server?
>>>>
>>>>
>>>> Martin
>>>>
>>>>
>>>> The reverse zone is configured and working.
>>>> When I am manually adding the PTR record to the reverse zone - all OK
>>>>
>>>> While adding a new host,  the A record is being created but the PTR
>>>> fails with the message above.
>>>>
>>>> Reinstalling centos+IPA worked once but I had to reinstall again
>>>> because of problems with kerberos(probably dependencies).
>>>>
>>>> Not sure what is the root cause of the issue.
>>>>
>>>> VERSION: 4.4.0, API_VERSION: 2.213
>>>>
>>>> CENTOS7 Linux freeipa1 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42
>>>> UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>>>>
>>>> Any help appreciated!
>>>> --
>>>> Best regards
>>>>
>>>> Maciej Drobniuch
>>>> Network Security Engineer
>>>> Collective-sense LLC
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Best regards
>>>
>>> Maciej Drobniuch
>>> Network Security Engineer
>>> Collective-sense LLC
>>>
>>>
>>>
>>
>>
>> --
>> Best regards
>>
>> Maciej Drobniuch
>> Network Security Engineer
>> 2410 Camino Ramon, Suite 129
>> San Ramon, CA 94583
>>
>>
>>
> Happy new year!
>
> --
> Best regards
>
> Maciej Drobniuch
> Network Security Engineer
> Collective-Sense,LLC
>
>
>

-- 
Best regards

Maciej Drobniuch
Network Security Engineer
Collective-Sense,LLC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20161227/8e39d165/attachment.htm>