# 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>> 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 <[email protected]> >>>>> 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
-- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
