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

Re: Does this IP have reverse DNS?

Expand Messages
  • 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 1 of 16 , Mar 4 10:46 AM
    • 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 2 of 16 , Mar 4 10:56 AM
      • 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 3 of 16 , Mar 4 10:59 AM
        • 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 4 of 16 , Mar 4 11:08 AM
          • 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 5 of 16 , Mar 4 11:22 AM
            • 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 6 of 16 , Mar 4 11:37 AM
              • 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 7 of 16 , Mar 4 11:53 AM
                • 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 8 of 16 , Mar 4 4:37 PM
                  • 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.