[Freeipa-users] DNS reverse zone is not managed by this server
Martin Basti
mbasti at redhat.com
Tue Dec 27 11:24:12 UTC 2016
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20161227/cf8c6e09/attachment.htm>
More information about the Freeipa-users
mailing list