# 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
-- 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
