[Freeipa-users] DNS reverse zone is not managed by this server
Martin Basti
mbasti at redhat.com
Tue Dec 27 12:09:55 UTC 2016
On 27.12.2016 13:04, Maciej Drobniuch wrote:
> $ 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.INA
>
> ;; AUTHORITY SECTION:
> 0.0.10.in-addr.arpa.3600INSOAfreeipa1.cs.int <http://freeipa1.cs.int>.
> hostmaster.cs.int <http://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
>
>
Hmm, this query doesn't contain ANSWER section, that may be reason why
python-dns failed.
could you check with:
python -c 'from dns import resolver; a =
resolver.query("0.0.10.in-addr.arpa.", "SOA", "IN"); print a.rrset.name'
> On Tue, Dec 27, 2016 at 12:24 PM, Martin Basti <mbasti at redhat.com
> <mailto: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
>> <mailto: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 <mailto: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.INPTR
>>>
>>> ;; ANSWER SECTION:
>>> 165.0.0.10.in-addr.arpa. 1200INPTRprdfrmprb01.cs.int
>>> <http://prdfrmprb01.cs.int>.
>>>
>>> ;; AUTHORITY SECTION:
>>> 1.0.10.in-addr.arpa.86400INNSfreeipa1.cs.int
>>> <http://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 <http://freeipa1.cs.int>.1200INA10.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 <mailto: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/4a72af09/attachment.htm>
More information about the Freeipa-users
mailing list