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 <mba...@redhat.com <mailto:mba...@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 <mba...@redhat.com
    <mailto:mba...@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
        <mba...@redhat.com <mailto:mba...@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
            <mba...@redhat.com <mailto:mba...@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
                <mba...@redhat.com <mailto:mba...@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

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

Reply via email to