Loading ...
Sorry, an error occurred while loading the content.

Re: Does this IP have reverse DNS?

Expand Messages
  • Blake Hudson
    ... The CNAME returned by sprintlink is 63.171.0.212.cust.lkq.sprintlink.net. You did a query for mail1.lkqcorp.com...
    Message 1 of 16 , Mar 4, 2013
    • 0 Attachment
      Pau Amma wrote the following on 3/4/2013 12:40 PM:
      > On Mon, March 4, 2013 6:31 pm, Blake Hudson wrote:
      >> OK, so we ask for a PTR on 212.0.171.63.in-addr.arpa and instead receive
      >> a CNAME (with additional). Did anyone notice that the CNAME does not
      >> resolve?
      > Does for me. *shrug*
      >
      > $ dig +noall +question +answer -x 63.171.0.212
      > ;212.0.171.63.in-addr.arpa. IN PTR
      > 212.0.171.63.in-addr.arpa. 86085
      > IN CNAME 63.171.0.212.cust.lkq.sprintlink.net.
      > 63.171.0.212.cust.lkq.sprintlink.net. 21285 IN PTR mail1.lkqcorp.com.
      > $ dig +noall +question +answer mail1.lkqcorp.com
      > ;mail1.lkqcorp.com. IN A
      > mail1.lkqcorp.com. 7653 IN A 63.171.0.212
      >
      >
      The CNAME returned by sprintlink is
      63.171.0.212.cust.lkq.sprintlink.net. You did a query for
      mail1.lkqcorp.com...
    • Blake Hudson
      ... Robert, you show the same problem as me (different version of bind 9.8.x). Seems to be a bind 9.8 specific behavior to return SERVFAIL on this lookup.
      Message 2 of 16 , Mar 4, 2013
      • 0 Attachment
        Robert Schetterer wrote the following on 3/4/2013 12:37 PM:
        > Am 04.03.2013 19:31, schrieb Blake Hudson:
        >> OK, so we ask for a PTR on 212.0.171.63.in-addr.arpa and instead receive
        >> a CNAME (with additional). Did anyone notice that the CNAME does not
        >> resolve?
        > yeah ,my dns cache didnt resolved it
        > had to be reloaded
        >
        >
        > Best Regards
        > MfG Robert Schetterer
        >
        Robert, you show the same problem as me (different version of bind
        9.8.x). Seems to be a bind 9.8 specific behavior to return SERVFAIL on
        this lookup. FWIW, Bind 9.2.x uses the additional info in the first
        query results without performing any lookup/validation on the CNAME
        (63.171.0.212.cust.lkq.sprintlink.net).

        flushing cache or restarting bind does not resolve the issue. Unless you
        can show me otherwise...
      • /dev/rob0
        ... See RFC 2317. ... It s fine. As to why your named is returning SERVFAIL, that is another issue. Obviously a SERVFAIL will prevent it from being resolved. I
        Message 3 of 16 , Mar 4, 2013
        • 0 Attachment
          On Mon, Mar 04, 2013 at 12:31:08PM -0600, Blake Hudson wrote:
          > KSB wrote the following on 3/4/2013 12:13 PM:
          > >On 2013.03.04. 20:06, Blake Hudson wrote:
          > >>Just hoping to get a consensus on this. Postfix is stating that a
          > >>host (in fact several hosts from the same ISP) does not have
          > >>rDNS, because our DNS (Bind 9.8) returns SERVFAIL when looking up
          > >>a PTR record for it. The IP in question is 63.171.0.212. From my

          See RFC 2317.

          > >>perspective, this IP does not have a PTR record and as such does
          > >>not have proper rDNS. Other tools (including older versions of
          > >>bind) might say otherwise; What do you say?
          > >>*
          > >Seems very, very strage... but probably this is allowed, anybody knows?
          > >
          > >;; QUESTION SECTION:
          > >;212.0.171.63.in-addr.arpa. IN PTR
          > >
          > >;; ANSWER SECTION:
          > >212.0.171.63.in-addr.arpa. 86400 IN CNAME
          > >63.171.0.212.cust.lkq.sprintlink.net.
          > >63.171.0.212.cust.lkq.sprintlink.net. 86400 IN PTR mail1.lkqcorp.com.

          It's fine. As to why your named is returning SERVFAIL, that is
          another issue. Obviously a SERVFAIL will prevent it from being
          resolved. I get the SERVFAIL as well:

          Mar 4 12:51:36 chestnut named[1811]: error (chase DS servers)
          resolving 'cust.lkq.sprintlink.net/DS/IN': 144.228.254.10#53
          Mar 4 12:51:36 chestnut named[1811]: error (insecurity proof failed)
          resolving 'lkq.sprintlink.net/NS/IN': 144.228.255.10#53
          Mar 4 12:51:36 chestnut named[1811]: error (insecurity proof failed)
          resolving 'lkq.sprintlink.net/NS/IN': 206.228.179.10#53
          Mar 4 12:51:36 chestnut named[1811]: error (insecurity proof failed)
          resolving 'lkq.sprintlink.net/NS/IN': 144.228.254.10#53
          Mar 4 12:51:36 chestnut named[1811]: error (no valid DS) resolving
          '63.171.0.212.cust.lkq.sprintlink.net/PTR/IN': 144.228.254.10#53

          This is a problem with the DNSSEC signing.

          > OK, so we ask for a PTR on 212.0.171.63.in-addr.arpa and instead
          > receive a CNAME (with additional). Did anyone notice that the CNAME
          > does not resolve?
          >
          > --
          >
          > # dig @... 63.171.0.212.cust.lkq.sprintlink.net

          You're doing a default query type, for "A".

          > ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.4 <<>>
          > @... 63.171.0.212.cust.lkq.sprintlink.net
          > ; (2 servers found)
          > ;; global options: +cmd
          > ;; Got answer:
          > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7207

          NOERROR means that the name exists, but there is no data of the
          requested type, A. It's wrong to assume that all names in the DNS
          should have A records.

          > ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
          > ;; WARNING: recursion requested but not available
          >
          > ;; QUESTION SECTION:
          > ;63.171.0.212.cust.lkq.sprintlink.net. IN A
          >
          > ;; AUTHORITY SECTION:
          > cust.lkq.sprintlink.net. 7200 IN SOA ns1-auth.sprintlink.net.
          > dns-admin.sprint.net. 2010080301 43200 3600 2419200 7200
          >
          > ;; Query time: 50 msec
          > ;; SERVER: 206.228.179.10#53(206.228.179.10)
          > ;; WHEN: Mon Mar 4 12:04:25 2013
          > ;; MSG SIZE rcvd: 116
          >
          > --

          --
          http://rob0.nodns4.us/ -- system administration and consulting
          Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
        • Reindl Harald
          ... that a CNAME here is very strange and this setup is not sane [harry@srv-rhsoft:~]$ nslookup 63.171.0.212 Server: 127.0.0.1 Address:
          Message 4 of 16 , Mar 4, 2013
          • 0 Attachment
            Am 04.03.2013 19:06, schrieb Blake Hudson:
            > Just hoping to get a consensus on this. Postfix is stating that a host (in fact several hosts from the same ISP)
            > does not have rDNS, because our DNS (Bind 9.8) returns SERVFAIL when looking up a PTR record for it. The IP in
            > question is 63.171.0.212. From my perspective, this IP does not have a PTR record and as such does not have proper
            > rDNS. Other tools (including older versions of bind) might say otherwise; What do you say?

            that a CNAME here is very strange and this setup is not sane

            [harry@srv-rhsoft:~]$ nslookup 63.171.0.212
            Server: 127.0.0.1
            Address: 127.0.0.1#53

            Non-authoritative answer:
            212.0.171.63.in-addr.arpa canonical name = 63.171.0.212.cust.lkq.sprintlink.net.
            63.171.0.212.cust.lkq.sprintlink.net name = mail1.lkqcorp.com.
          • Robert Schetterer
            ... its by dnssec-validation auto in BIND 9.8.1-P1 /usr/sbin/named -v BIND 9.8.1-P1 dig @localhost -x 63.171.0.212 ; DiG 9.8.1-P1 @localhost -x
            Message 5 of 16 , Mar 4, 2013
            • 0 Attachment
              Am 04.03.2013 19:46, schrieb Blake Hudson:
              >
              > Robert Schetterer wrote the following on 3/4/2013 12:37 PM:
              >> Am 04.03.2013 19:31, schrieb Blake Hudson:
              >>> OK, so we ask for a PTR on 212.0.171.63.in-addr.arpa and instead receive
              >>> a CNAME (with additional). Did anyone notice that the CNAME does not
              >>> resolve?
              >> yeah ,my dns cache didnt resolved it
              >> had to be reloaded
              >>
              >>
              >> Best Regards
              >> MfG Robert Schetterer
              >>
              > Robert, you show the same problem as me (different version of bind
              > 9.8.x). Seems to be a bind 9.8 specific behavior to return SERVFAIL on
              > this lookup. FWIW, Bind 9.2.x uses the additional info in the first
              > query results without performing any lookup/validation on the CNAME
              > (63.171.0.212.cust.lkq.sprintlink.net).
              >
              > flushing cache or restarting bind does not resolve the issue. Unless you
              > can show me otherwise...

              its by dnssec-validation auto in BIND 9.8.1-P1

              /usr/sbin/named -v
              BIND 9.8.1-P1

              dig @localhost -x 63.171.0.212

              ; <<>> DiG 9.8.1-P1 <<>> @localhost -x 63.171.0.212
              ; (1 server found)
              ;; global options: +cmd
              ;; Got answer:
              ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38497
              ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

              ;; QUESTION SECTION:
              ;212.0.171.63.in-addr.arpa. IN PTR

              ;; Query time: 3462 msec
              ;; SERVER: 127.0.0.1#53(127.0.0.1)
              ;; WHEN: Mon Mar 4 20:01:51 2013
              ;; MSG SIZE rcvd: 43


              deconfigure or comment out

              dnssec-validation auto


              etc/init.d/bind9 restart
              * Stopping domain name service... bind9

              waiting for pid 28122 to die


              [ OK ]
              * Starting domain name service... bind9

              [ OK ]
              root@newlinux:~# dig @localhost -x 63.171.0.212

              ; <<>> DiG 9.8.1-P1 <<>> @localhost -x 63.171.0.212
              ; (1 server found)
              ;; global options: +cmd
              ;; Got answer:
              ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47133
              ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 6

              ;; QUESTION SECTION:
              ;212.0.171.63.in-addr.arpa. IN PTR

              ;; ANSWER SECTION:
              212.0.171.63.in-addr.arpa. 86400 IN CNAME
              63.171.0.212.cust.lkq.sprintlink.net.
              63.171.0.212.cust.lkq.sprintlink.net. 86400 IN PTR mail1.lkqcorp.com.

              ;; AUTHORITY SECTION:
              cust.lkq.sprintlink.net. 86400 IN NS ns1-auth.sprintlink.net.
              cust.lkq.sprintlink.net. 86400 IN NS ns3-auth.sprintlink.net.
              cust.lkq.sprintlink.net. 86400 IN NS ns2-auth.sprintlink.net.

              ;; ADDITIONAL SECTION:
              ns1-auth.sprintlink.net. 86399 IN A 206.228.179.10
              ns1-auth.sprintlink.net. 86399 IN AAAA 2600::a1
              ns2-auth.sprintlink.net. 86399 IN A 144.228.254.10
              ns2-auth.sprintlink.net. 86399 IN AAAA 2600::a2
              ns3-auth.sprintlink.net. 86399 IN A 144.228.255.10
              ns3-auth.sprintlink.net. 86399 IN AAAA 2600::a3


              compared

              /usr/sbin/named -v
              BIND 9.7.6-P4

              dig @localhost -x 63.171.0.212

              ; <<>> DiG 9.7.6-P4 <<>> @localhost -x 63.171.0.212
              ; (1 server found)
              ;; global options: +cmd
              ;; Got answer:
              ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26972
              ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 6

              ;; QUESTION SECTION:
              ;212.0.171.63.in-addr.arpa. IN PTR

              ;; ANSWER SECTION:
              212.0.171.63.in-addr.arpa. 85099 IN CNAME
              63.171.0.212.cust.lkq.sprintlink.net.
              63.171.0.212.cust.lkq.sprintlink.net. 85099 IN PTR mail1.lkqcorp.com.


              try post bind list for details


              Best Regards
              MfG Robert Schetterer

              --
              [*] sys4 AG

              http://sys4.de, +49 (89) 30 90 46 64
              Franziskanerstraße 15, 81669 München

              Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
              Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
              Aufsichtsratsvorsitzender: Joerg Heidrich
            • Blake Hudson
              ... Awesome answer. Thanks for your expertise! I had been reading RFC 1035 and was simply unsure of what, exactly, was allowed and what was not - Sometimes
              Message 6 of 16 , Mar 4, 2013
              • 0 Attachment
                /dev/rob0 wrote the following on 3/4/2013 12:56 PM:
                > On Mon, Mar 04, 2013 at 12:31:08PM -0600, Blake Hudson wrote:
                >> KSB wrote the following on 3/4/2013 12:13 PM:
                >>> On 2013.03.04. 20:06, Blake Hudson wrote:
                >>>> Just hoping to get a consensus on this. Postfix is stating that a
                >>>> host (in fact several hosts from the same ISP) does not have
                >>>> rDNS, because our DNS (Bind 9.8) returns SERVFAIL when looking up
                >>>> a PTR record for it. The IP in question is 63.171.0.212. From my
                > See RFC 2317.
                >
                >>>> perspective, this IP does not have a PTR record and as such does
                >>>> not have proper rDNS. Other tools (including older versions of
                >>>> bind) might say otherwise; What do you say?
                >>>> *
                >>> Seems very, very strage... but probably this is allowed, anybody knows?
                >>>
                >>> ;; QUESTION SECTION:
                >>> ;212.0.171.63.in-addr.arpa. IN PTR
                >>>
                >>> ;; ANSWER SECTION:
                >>> 212.0.171.63.in-addr.arpa. 86400 IN CNAME
                >>> 63.171.0.212.cust.lkq.sprintlink.net.
                >>> 63.171.0.212.cust.lkq.sprintlink.net. 86400 IN PTR mail1.lkqcorp.com.
                > It's fine. As to why your named is returning SERVFAIL, that is
                > another issue. Obviously a SERVFAIL will prevent it from being
                > resolved. I get the SERVFAIL as well:
                >
                > Mar 4 12:51:36 chestnut named[1811]: error (chase DS servers)
                > resolving 'cust.lkq.sprintlink.net/DS/IN': 144.228.254.10#53
                > Mar 4 12:51:36 chestnut named[1811]: error (insecurity proof failed)
                > resolving 'lkq.sprintlink.net/NS/IN': 144.228.255.10#53
                > Mar 4 12:51:36 chestnut named[1811]: error (insecurity proof failed)
                > resolving 'lkq.sprintlink.net/NS/IN': 206.228.179.10#53
                > Mar 4 12:51:36 chestnut named[1811]: error (insecurity proof failed)
                > resolving 'lkq.sprintlink.net/NS/IN': 144.228.254.10#53
                > Mar 4 12:51:36 chestnut named[1811]: error (no valid DS) resolving
                > '63.171.0.212.cust.lkq.sprintlink.net/PTR/IN': 144.228.254.10#53
                >
                > This is a problem with the DNSSEC signing.
                >
                >> OK, so we ask for a PTR on 212.0.171.63.in-addr.arpa and instead
                >> receive a CNAME (with additional). Did anyone notice that the CNAME
                >> does not resolve?
                >>
                >> --
                >>
                >> # dig @... 63.171.0.212.cust.lkq.sprintlink.net
                > You're doing a default query type, for "A".
                >
                >> ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.4 <<>>
                >> @... 63.171.0.212.cust.lkq.sprintlink.net
                >> ; (2 servers found)
                >> ;; global options: +cmd
                >> ;; Got answer:
                >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7207
                > NOERROR means that the name exists, but there is no data of the
                > requested type, A. It's wrong to assume that all names in the DNS
                > should have A records.
                >
                >> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
                >> ;; WARNING: recursion requested but not available
                >>
                >> ;; QUESTION SECTION:
                >> ;63.171.0.212.cust.lkq.sprintlink.net. IN A
                >>
                >> ;; AUTHORITY SECTION:
                >> cust.lkq.sprintlink.net. 7200 IN SOA ns1-auth.sprintlink.net.
                >> dns-admin.sprint.net. 2010080301 43200 3600 2419200 7200
                >>
                >> ;; Query time: 50 msec
                >> ;; SERVER: 206.228.179.10#53(206.228.179.10)
                >> ;; WHEN: Mon Mar 4 12:04:25 2013
                >> ;; MSG SIZE rcvd: 116
                >>
                >> --


                Awesome answer. Thanks for your expertise!

                I had been reading RFC 1035 and was simply unsure of what, exactly, was
                allowed and what was not - Sometimes RFCs allow for interpretation
                differences between readers. I'll need to read 2317 again.

                You're absolutely correct about it being wrong to assume that all
                records are A. Maybe I am complacent in my expectation that I can ask
                for an A record and receive a CNAME in return, but what else would/could
                one expect - isn't this the behavior of CNAMEs? If I perform the
                following query I do get an answer in return:

                --
                # dig @... ANY 63.171.0.212.cust.lkq.sprintlink.net

                ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.6 <<>>
                @... ANY 63.171.0.212.cust.lkq.sprintlink.net
                ; (2 servers found)
                ;; global options: +cmd
                ;; Got answer:
                ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8377
                ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 0
                ;; WARNING: recursion requested but not available

                ;; QUESTION SECTION:
                ;63.171.0.212.cust.lkq.sprintlink.net. IN ANY

                ;; ANSWER SECTION:
                63.171.0.212.cust.lkq.sprintlink.net. 86400 IN PTR mail1.lkqcorp.com.

                ;; AUTHORITY SECTION:
                cust.lkq.sprintlink.net. 86400 IN NS ns1-auth.sprintlink.net.
                cust.lkq.sprintlink.net. 86400 IN NS ns2-auth.sprintlink.net.
                cust.lkq.sprintlink.net. 86400 IN NS ns3-auth.sprintlink.net.

                ;; Query time: 48 msec
                ;; SERVER: 206.228.179.10#53(206.228.179.10)
                ;; WHEN: Mon Mar 4 13:08:25 2013
                ;; MSG SIZE rcvd: 154
                --

                I still am unsure if it's valid to ask for a PTR record and receive a
                CNAME in return. If it is, I assume that CNAME needs to lead to a valid
                PTR record at some point.

                Thanks for pointing out the DNSSEC error. I was focusing on the unusual
                PTR setup (in my experience) and didn't even consider DNSSEC. Looks like
                Sprint has a DNS issue to resolve.

                Thanks,
                --Blake
              • /dev/rob0
                ... The way it works: when you query for any type and get a CNAME, the resolver (dig in this case) looks up that type record for the CNAME target. ... Yes,
                Message 7 of 16 , Mar 4, 2013
                • 0 Attachment
                  On Mon, Mar 04, 2013 at 01:22:39PM -0600, Blake Hudson wrote:
                  > I still am unsure if it's valid to ask for a PTR record and receive
                  > a CNAME in return. If it is, I assume that CNAME needs to lead to a
                  > valid PTR record at some point.

                  The way it works: when you query for any type and get a CNAME, the
                  resolver (dig in this case) looks up that type record for the CNAME
                  target.

                  > Thanks for pointing out the DNSSEC error. I was focusing on the
                  > unusual PTR setup (in my experience) and didn't even consider
                  > DNSSEC. Looks like Sprint has a DNS issue to resolve.

                  Yes, this would all be fine if the DNSSEC was right, or with the
                  "workaround" as proposed upthread, to disable DNSSEC checking in your
                  named. (I would not recommend that, but indeed, it's a possible way
                  to shift the error from Sprint to yourself.)
                  --
                  http://rob0.nodns4.us/ -- system administration and consulting
                  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
                • Blake Hudson
                  ... # dig @8.8.8.8 PTR 63.171.0.212.cust.lkq.sprintlink.net +dnssec ; DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.6 @8.8.8.8 PTR
                  Message 8 of 16 , Mar 4, 2013
                  • 0 Attachment
                    Robert Schetterer wrote the following on 3/4/2013 1:08 PM:
                    > Am 04.03.2013 19:46, schrieb Blake Hudson:
                    >> Robert Schetterer wrote the following on 3/4/2013 12:37 PM:
                    >>> Am 04.03.2013 19:31, schrieb Blake Hudson:
                    >>>> OK, so we ask for a PTR on 212.0.171.63.in-addr.arpa and instead receive
                    >>>> a CNAME (with additional). Did anyone notice that the CNAME does not
                    >>>> resolve?
                    >>> yeah ,my dns cache didnt resolved it
                    >>> had to be reloaded
                    >>>
                    >>>
                    >>> Best Regards
                    >>> MfG Robert Schetterer
                    >>>
                    >> Robert, you show the same problem as me (different version of bind
                    >> 9.8.x). Seems to be a bind 9.8 specific behavior to return SERVFAIL on
                    >> this lookup. FWIW, Bind 9.2.x uses the additional info in the first
                    >> query results without performing any lookup/validation on the CNAME
                    >> (63.171.0.212.cust.lkq.sprintlink.net).
                    >>
                    >> flushing cache or restarting bind does not resolve the issue. Unless you
                    >> can show me otherwise...
                    > its by dnssec-validation auto in BIND 9.8.1-P1
                    >
                    > /usr/sbin/named -v
                    > BIND 9.8.1-P1
                    >
                    > dig @localhost -x 63.171.0.212
                    >
                    > ; <<>> DiG 9.8.1-P1 <<>> @localhost -x 63.171.0.212
                    > ; (1 server found)
                    > ;; global options: +cmd
                    > ;; Got answer:
                    > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38497
                    > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
                    >
                    > ;; QUESTION SECTION:
                    > ;212.0.171.63.in-addr.arpa. IN PTR
                    >
                    > ;; Query time: 3462 msec
                    > ;; SERVER: 127.0.0.1#53(127.0.0.1)
                    > ;; WHEN: Mon Mar 4 20:01:51 2013
                    > ;; MSG SIZE rcvd: 43
                    >
                    >
                    > deconfigure or comment out
                    >
                    > dnssec-validation auto
                    >
                    >
                    > etc/init.d/bind9 restart
                    > * Stopping domain name service... bind9
                    >
                    > waiting for pid 28122 to die
                    >
                    >
                    > [ OK ]
                    > * Starting domain name service... bind9
                    >
                    > [ OK ]
                    > root@newlinux:~# dig @localhost -x 63.171.0.212
                    >
                    > ; <<>> DiG 9.8.1-P1 <<>> @localhost -x 63.171.0.212
                    > ; (1 server found)
                    > ;; global options: +cmd
                    > ;; Got answer:
                    > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47133
                    > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 6
                    >
                    > ;; QUESTION SECTION:
                    > ;212.0.171.63.in-addr.arpa. IN PTR
                    >
                    > ;; ANSWER SECTION:
                    > 212.0.171.63.in-addr.arpa. 86400 IN CNAME
                    > 63.171.0.212.cust.lkq.sprintlink.net.
                    > 63.171.0.212.cust.lkq.sprintlink.net. 86400 IN PTR mail1.lkqcorp.com.
                    >
                    > ;; AUTHORITY SECTION:
                    > cust.lkq.sprintlink.net. 86400 IN NS ns1-auth.sprintlink.net.
                    > cust.lkq.sprintlink.net. 86400 IN NS ns3-auth.sprintlink.net.
                    > cust.lkq.sprintlink.net. 86400 IN NS ns2-auth.sprintlink.net.
                    >
                    > ;; ADDITIONAL SECTION:
                    > ns1-auth.sprintlink.net. 86399 IN A 206.228.179.10
                    > ns1-auth.sprintlink.net. 86399 IN AAAA 2600::a1
                    > ns2-auth.sprintlink.net. 86399 IN A 144.228.254.10
                    > ns2-auth.sprintlink.net. 86399 IN AAAA 2600::a2
                    > ns3-auth.sprintlink.net. 86399 IN A 144.228.255.10
                    > ns3-auth.sprintlink.net. 86399 IN AAAA 2600::a3
                    >
                    >
                    > compared
                    >
                    > /usr/sbin/named -v
                    > BIND 9.7.6-P4
                    >
                    > dig @localhost -x 63.171.0.212
                    >
                    > ; <<>> DiG 9.7.6-P4 <<>> @localhost -x 63.171.0.212
                    > ; (1 server found)
                    > ;; global options: +cmd
                    > ;; Got answer:
                    > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26972
                    > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 6
                    >
                    > ;; QUESTION SECTION:
                    > ;212.0.171.63.in-addr.arpa. IN PTR
                    >
                    > ;; ANSWER SECTION:
                    > 212.0.171.63.in-addr.arpa. 85099 IN CNAME
                    > 63.171.0.212.cust.lkq.sprintlink.net.
                    > 63.171.0.212.cust.lkq.sprintlink.net. 85099 IN PTR mail1.lkqcorp.com.
                    >
                    >
                    > try post bind list for details
                    >
                    >
                    > Best Regards
                    > MfG Robert Schetterer
                    >
                    # dig @8.8.8.8 PTR 63.171.0.212.cust.lkq.sprintlink.net +dnssec

                    ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.6 <<>> @8.8.8.8 PTR
                    63.171.0.212.cust.lkq.sprintlink.net +dnssec
                    ; (1 server found)
                    ;; global options: +cmd
                    ;; Got answer:
                    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 27767
                    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

                    ;; OPT PSEUDOSECTION:
                    ; EDNS: version: 0, flags: do; udp: 512
                    ;; QUESTION SECTION:
                    ;63.171.0.212.cust.lkq.sprintlink.net. IN PTR

                    ;; Query time: 441 msec
                    ;; SERVER: 8.8.8.8#53(8.8.8.8)
                    ;; WHEN: Mon Mar 4 13:44:03 2013
                    ;; MSG SIZE rcvd: 65



                    # dig @8.8.8.8 PTR 63.171.0.212.cust.lkq.sprintlink.net +nodnssec

                    ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.6 <<>> @8.8.8.8 PTR
                    63.171.0.212.cust.lkq.sprintlink.net +nodnssec
                    ; (1 server found)
                    ;; global options: +cmd
                    ;; Got answer:
                    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14054
                    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

                    ;; QUESTION SECTION:
                    ;63.171.0.212.cust.lkq.sprintlink.net. IN PTR

                    ;; ANSWER SECTION:
                    63.171.0.212.cust.lkq.sprintlink.net. 390 IN PTR mail1.lkqcorp.com.

                    ;; Query time: 19 msec
                    ;; SERVER: 8.8.8.8#53(8.8.8.8)
                    ;; WHEN: Mon Mar 4 13:44:09 2013
                    ;; MSG SIZE rcvd: 85


                    If Sprint has setup DNSSEC on their zones incorrectly, I would rather
                    they resolve the issue they've created rather than turning of DNSSEC
                    validation on my server (which I've intentionally enabled). I don't
                    think posting to the bind list or any other action on my part is
                    necessary at this point. Thanks for the recommendations and the pointer,
                    as well as another set of eyes; It was helpful to have a point of
                    reference from multiple people running different software in different
                    configurations.
                  • Bill Cole
                    ... No. A CNAME record provides the canonical name that should be used instead of the name originally queried. It applies to all record types, so in the event
                    Message 9 of 16 , Mar 4, 2013
                    • 0 Attachment
                      On 4 Mar 2013, at 14:22, Blake Hudson wrote:

                      > Maybe I am complacent in my expectation that I can ask for an A record
                      > and receive a CNAME in return, but what else would/could one expect -
                      > isn't this the behavior of CNAMEs?

                      No. A CNAME record provides the canonical name that should be used
                      instead of the name originally queried. It applies to all record types,
                      so in the event that a query returns a CNAME record without additional
                      records with the canonical name as the label and the requested record
                      type, the next step for the originator of the query is to make a query
                      for the same record type using the canonical name as the label instead
                      of the original name. If a CNAME record exists for a particular name, it
                      is used as the answer to queries for any record type at that name other
                      than NSEC and RRSIG.
                    Your message has been successfully submitted and would be delivered to recipients shortly.