[Freeipa-users] DNS reverse zone is not managed by this server
Maciej Drobniuch
md at collective-sense.com
Tue Dec 27 12:41:59 UTC 2016
Martin,
Your troubleshooting style put me on the right track.
The alternative DNS servers had Ipv6 AAAA records that did not resolv
properly.
After deleting those records adding A records (with reverse PTR check) and
adding host works fine. The PTR record is created in the GUI and works fine.
Thank you very much for your time and help with this!
Cheers!
M.
On Tue, Dec 27, 2016 at 1:35 PM, Maciej Drobniuch <md at collective-sense.com>
wrote:
> # dig soa 0.0.10.in-addr.arpa.
>
> ; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> soa 0.0.10.in-addr.arpa.
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60690
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 8
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;0.0.10.in-addr.arpa. IN SOA
>
> ;; ANSWER SECTION:
> 0.0.10.in-addr.arpa. 86400 IN SOA freeipa1.cs.int. hostmaster.cs.int.
> 1482653944 3600 900 1209600 3600
>
> ;; AUTHORITY SECTION:
> 0.0.10.in-addr.arpa. 86400 IN NS freeipa1.cs.int.
> 0.0.10.in-addr.arpa. 86400 IN NS freeipa2.cs.int.
> 0.0.10.in-addr.arpa. 86400 IN NS krkfreeipa.cs.int.
>
> ;; ADDITIONAL SECTION:
> freeipa1.cs.int. 1200 IN A 10.0.0.200
> freeipa2.cs.int. 1200 IN A 10.0.1.200
> krkfreeipa.cs.int. 1200 IN A 10.0.2.6
>
> ;; Query time: 15 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: wto gru 27 07:33:41 EST 2016
> ;; MSG SIZE rcvd: 333
>
>
> On Tue, Dec 27, 2016 at 1:28 PM, Martin Basti <mbasti at redhat.com> wrote:
>
>> I just noticed previously you sent wrong dig, I need
>>
>> dig 0.0.10.in-addr.arpa. SOA instead of the A rtype
>>
>>
>>
>>
>> On 27.12.2016 13:21, Maciej Drobniuch wrote:
>>
>> # python -c 'from dns import resolver; a = resolver.query("0.0.10.in-addr.arpa.",
>> "SOA", "IN"); print a.rrset.name'
>> 0.0.10.in-addr.arpa.
>>
>> On Tue, Dec 27, 2016 at 1:09 PM, Martin Basti <mbasti at redhat.com> wrote:
>>
>>>
>>>
>>> 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. 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
>>>
>>>
>>> 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>
>>> 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
>>>
>>>
>>>
>>
>>
>> --
>> 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
Collective-Sense,LLC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20161227/d6ffdd25/attachment.htm>
More information about the Freeipa-users
mailing list