/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 @ns1-auth.sprintlink.net 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 <<>>
@ns1-auth.sprintlink.net 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 @ns1-auth.sprintlink.net ANY 63.171.0.212.cust.lkq.sprintlink.net
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.6 <<>>
@ns1-auth.sprintlink.net 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
