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

Re: Does this IP have reverse DNS?

Expand Messages
  • John Peach
    On Mon, 04 Mar 2013 12:06:20 -0600 ... dig +trace 212.0.171.63.in-addr.arpa ; DiG 9.8.1-P1 +trace 212.0.171.63.in-addr.arpa ;; global options: +cmd
    Message 1 of 16 , Mar 4, 2013
    • 0 Attachment
      On Mon, 04 Mar 2013 12:06:20 -0600
      Blake Hudson <blake@...> 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
      > 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?

      dig +trace 212.0.171.63.in-addr.arpa

      ; <<>> DiG 9.8.1-P1 <<>> +trace 212.0.171.63.in-addr.arpa
      ;; global options: +cmd
      . 107196 IN NS c.root-servers.net.
      . 107196 IN NS j.root-servers.net.
      . 107196 IN NS h.root-servers.net.
      . 107196 IN NS b.root-servers.net.
      . 107196 IN NS e.root-servers.net.
      . 107196 IN NS d.root-servers.net.
      . 107196 IN NS a.root-servers.net.
      . 107196 IN NS k.root-servers.net.
      . 107196 IN NS f.root-servers.net.
      . 107196 IN NS m.root-servers.net.
      . 107196 IN NS l.root-servers.net.
      . 107196 IN NS g.root-servers.net.
      . 107196 IN NS i.root-servers.net.
      ;; Received 436 bytes from 192.168.1.2#53(192.168.1.2) in 29 ms

      in-addr.arpa. 172800 IN NS e.in-addr-servers.arpa.
      in-addr.arpa. 172800 IN NS a.in-addr-servers.arpa.
      in-addr.arpa. 172800 IN NS b.in-addr-servers.arpa.
      in-addr.arpa. 172800 IN NS f.in-addr-servers.arpa.
      in-addr.arpa. 172800 IN NS c.in-addr-servers.arpa.
      in-addr.arpa. 172800 IN NS d.in-addr-servers.arpa.
      ;; Received 419 bytes from 192.228.79.201#53(192.228.79.201) in 94 ms

      63.in-addr.arpa. 86400 IN NS t.arin.net.
      63.in-addr.arpa. 86400 IN NS z.arin.net.
      63.in-addr.arpa. 86400 IN NS u.arin.net.
      63.in-addr.arpa. 86400 IN NS w.arin.net.
      63.in-addr.arpa. 86400 IN NS r.arin.net.
      63.in-addr.arpa. 86400 IN NS y.arin.net.
      63.in-addr.arpa. 86400 IN NS x.arin.net.
      63.in-addr.arpa. 86400 IN NS v.arin.net.
      ;; Received 179 bytes from 199.212.0.73#53(199.212.0.73) in 20 ms

      171.63.in-addr.arpa. 86400 IN NS NS3-AUTH.SPRINTLINK.NET.
      171.63.in-addr.arpa. 86400 IN NS NS2-AUTH.SPRINTLINK.NET.
      171.63.in-addr.arpa. 86400 IN NS NS1-AUTH.SPRINTLINK.NET.
      ;; Received 126 bytes from 199.212.0.63#53(199.212.0.63) in 18 ms

      212.0.171.63.in-addr.arpa. 86400 IN CNAME
      63.171.0.212.cust.lkq.sprintlink.net. 171.63.in-addr.arpa. 86400
      IN NS ns1-auth.sprintlink.net. 171.63.in-addr.arpa.
      86400 IN NS ns2-auth.sprintlink.net.
      171.63.in-addr.arpa. 86400 IN NS
      ns3-auth.sprintlink.net. ;; Received 162 bytes from
      144.228.255.10#53(144.228.255.10) in 35 ms

      >
      > --Blake*
      >
      >
      >
      >
      > *
    • 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? -- #
      Message 2 of 16 , Mar 4, 2013
      • 0 Attachment
        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 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?
        >>
        >> --Blake*
        >>
        >>
        >>
        >>
        >> *
        > 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.
        >
        > --
        > KSB


        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

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

        --
      • Robert Schetterer
        ... yeah ,my dns cache didnt resolved it had to be reloaded Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64
        Message 3 of 16 , Mar 4, 2013
        • 0 Attachment
          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

          --
          [*] 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
        • Pau Amma
          ... 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
          Message 4 of 16 , Mar 4, 2013
          • 0 Attachment
            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
          • 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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.