[Freeipa-users] DNS reverse zone is not managed by this server
Martin Basti
mbasti at redhat.com
Tue Dec 27 16:15:14 UTC 2016
Great, you are welcome :)
On 27.12.2016 13:41, Maciej Drobniuch wrote:
> 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 <mailto: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.INSOA
>
> ;; ANSWER SECTION:
> 0.0.10.in-addr.arpa.86400INSOAfreeipa1.cs.int
> <http://freeipa1.cs.int>. hostmaster.cs.int
> <http://hostmaster.cs.int>. 1482653944 3600 900 1209600 3600
>
> ;; AUTHORITY SECTION:
> 0.0.10.in-addr.arpa.86400INNSfreeipa1.cs.int <http://freeipa1.cs.int>.
> 0.0.10.in-addr.arpa.86400INNSfreeipa2.cs.int <http://freeipa2.cs.int>.
> 0.0.10.in-addr.arpa.86400INNSkrkfreeipa.cs.int
> <http://krkfreeipa.cs.int>.
>
> ;; ADDITIONAL SECTION:
> freeipa1.cs.int <http://freeipa1.cs.int>.1200INA10.0.0.200
> freeipa2.cs.int <http://freeipa2.cs.int>.1200INA10.0.1.200
> krkfreeipa.cs.int <http://krkfreeipa.cs.int>.1200INA10.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
> <mailto: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 <http://a.rrset.name>'
>> 0.0.10.in-addr.arpa.
>>
>> On Tue, Dec 27, 2016 at 1:09 PM, Martin Basti
>> <mbasti at redhat.com <mailto: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.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 <http://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
>>
>>
>>
>>
>> --
>> 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/c3c99a59/attachment.htm>
More information about the Freeipa-users
mailing list