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

Re: Does this IP have reverse DNS?

Expand Messages
  • Robert Moskowitz
    ... host 63.171.0.212 212.0.171.63.in-addr.arpa is an alias for 63.171.0.212.cust.lkq.sprintlink.net. 63.171.0.212.cust.lkq.sprintlink.net domain name pointer
    Message 1 of 16 , Mar 4, 2013
    • 0 Attachment

      On 03/04/2013 01:06 PM, 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?


      host 63.171.0.212
      212.0.171.63.in-addr.arpa is an alias for 63.171.0.212.cust.lkq.sprintlink.net.
      63.171.0.212.cust.lkq.sprintlink.net domain name pointer mail1.lkqcorp.com.



    • KSB
      ... Seems very, very strage... but probably this is allowed, anybody knows? ;; QUESTION SECTION: ;212.0.171.63.in-addr.arpa. IN PTR ;; ANSWER SECTION:
      Message 2 of 16 , Mar 4, 2013
      • 0 Attachment
        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
      • 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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.