[svlug] DNS lookup failures

[Rick Moen]

Quoting Robert Freiberger (rfreiberger at gmail.com):

> Something helpful I find is using the DNSstuff.com traversal tool.
> http://www.dnsstuff.com/tools

Robert, is there an applicable tool on that site that's still available
for free-of-charge use by the general public?  (If you haven't used it
in a few years, things have changed a bit.)  I used to use DNSstuff's
'dnsreport' analytical service quite happily.  A demo of that tool can
still be used on a half-dozen example sites here:

http://www.dnsstuff.com/products/dnsreport
E.g., 
http://www.dnsstuff.com/tools/dnsreportsmpl/?domain=sun.com

To my knowledge, they put all of their tools behind a pay wall starting
in 2008.  

A year or two before that, I had an e-mail conversation with the guy who
writes the tools, a very nice fellow in Austin.  I told him I really
admired the dnsreport script, and asked politely if he had any plans to
open-source it.  He brushed off my query in a way that said 'Heck no'
between the lines, so I of course dropped it.

It turns out, if you study delegation of domain authority and use of the
'dig' and 'telnet' utilities, you can do absolutely everything that
DNSstuff's 'dnsreport' does, using just dig & telnet -- albeit it won't
be as pretty or self-documenting.  Pro bono publico, I'm going to try to
replicate _everything_ the dnsreport says about sun.com, just using
standard tools.

1.  PARENT ZONE ISSUES:

o  Does direct parent zone exist?

Didn't even bother to test.  Zone .com. exists.

o  What are the domain's NS records at the parert's nameservers?

First, what are com.'s nameservers?

 dig -t ns com. +short
f.gtld-servers.net.
c.gtld-servers.net.
i.gtld-servers.net.
h.gtld-servers.net.
k.gtld-servers.net.
j.gtld-servers.net.
l.gtld-servers.net.
d.gtld-servers.net.
b.gtld-servers.net.
g.gtld-servers.net.
e.gtld-servers.net.
a.gtld-servers.net.
m.gtld-servers.net.
$

Next, what does one of com.'s nameservers have in its zonefile
as NS records for sun.com.?

$ dig -t ns sun.com. @i.gtld-servers.net. 
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45755
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; AUTHORITY SECTION:
sun.com.		172800	IN	NS	ns8.sun.com.
sun.com.		172800	IN	NS	ns2.sun.com.
sun.com.		172800	IN	NS	ns1.sun.com.
sun.com.		172800	IN	NS	ns3.sun.com.

;; ADDITIONAL SECTION:
ns8.sun.com.		172800	IN	A	192.18.43.12
ns2.sun.com.		172800	IN	A	192.18.99.5
ns1.sun.com.		172800	IN	A	192.18.128.11
ns3.sun.com.		172800	IN	A	192.18.4.206
$

o  Do the parent zones's nameservers have the domain's namservers
listed?

Yes.  See above.

o   Do the parent zones's nameservers have glue records for the domain's
nameservers?

Yes.  Those are the 'A' records in the 'Additional Section'.


2.  IN-DOMAIN 'NS' ISSUES:

o  What are the NS records at the domain's nameservers?

 $ dig -t ns sun.com. @ns8.sun.com. 
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23859
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; ANSWER SECTION:
sun.com.		900	IN	NS	ns8.sun.com.
sun.com.		900	IN	NS	ns1.sun.com.
sun.com.		900	IN	NS	ns2.sun.com.
sun.com.		900	IN	NS	ns3.sun.com.

;; ADDITIONAL SECTION:
ns1.sun.com.		900	IN	A	192.18.128.11
ns2.sun.com.		900	IN	A	192.18.99.5
ns3.sun.com.		300	IN	A	192.18.43.12
ns8.sun.com.		900	IN	A	192.18.43.12

o  Are the domain's nameservers 'open' nameservers?  (It's a little
unclear whether dnsreport's term 'open' in this context means willing to 
do recursive service for anyone, being willing to supply zone transfers
to anyone, or  both, so let's check both:)

 dig linuxmafia.com @ns1.sun.com.
 dig linuxmafia.com @ns2.sun.com.
 dig linuxmafia.com @ns3.sun.com.
 dig linuxmafia.com @ns8.sun.com.

All return status: REFUSED, which is a good thing (not offering public
recursive service).

 dig -t axfr sun.com. @ns1.sun.com.
 dig -t axfr sun.com. @ns2.sun.com.
 dig -t axfr sun.com. @ns3.sun.com.
 dig -t axfr sun.com. @ns8.sun.com.

All return conection timeouts (not offering public zone transfers).

o  Are there mismatched glue records?

FAIL.  

The 'A' records for the nameservers returned by the parent com. zone's 
nameservers differ from those returned by the in-zone sun.com
nameservers.  This is a very bad thing.  (See above for the IP address
details, which apply to all four nameservers.)

o  Are the 'NS' records returned by all of te in-zone nameservers
identical?

 dig -t ns sun.com. @ns1.sun.com. 
 dig -t ns sun.com. @ns2.sun.com. 
 dig -t ns sun.com. @ns3.sun.com. 
 dig -t ns sun.com. @ns8.sun.com. 

All return the same 'NS' and 'A' results.

o  Are there 'A' records returned in-zone for all nameservers?

Yes, see above.

o  Do all NS entries listed in the parent zone (i.e., the authoritative
servers) respond?

FAIL.  The fourth one doesn't respond.

$ dig -t soa sun.com. @192.18.43.12 +short
ns1.sun.com. hostmaster.sun.com. 2011101403 3600 1200 1038800 900
$ dig -t soa sun.com. @192.18.99.5 +short
ns1.sun.com. hostmaster.sun.com. 2011101403 3600 1200 1038800 900
$ dig -t soa sun.com. @192.18.128.11 +short
ns1.sun.com. hostmaster.sun.com. 2011101403 3600 1200 1038800 900
$ dig -t soa sun.com. @192.18.4.206 +short
;; connection timed out; no servers could be reached
$

o  Do all the 'NS' record contents in-zone have valid contents, i.e., no 
IPs or partial domain names?

Sure.   See above.

o  Is your quantity of nameservers in the recommended range (3 to 7;
see RFC-2182 section 5)?

Yes.  Four is fine.

o  Are there any 'lame' nameservers, i.e., ones listed in-zone but not
listed at the parent zone and thus deprived of authority?

No.  See above.

o  Are there any 'missing' aka 'stealth' nameservers, i.e., ones listed
at the parent zone but not in-zone?

No.  See above.

o  Are all nameservers listed as 'NS' entries at the parent zone also
listed as 'NS' lines in-zone?

Yes.  See above.

o  Are there any CNAME records for the unqualified domain (sun.com.),
which is barred by RFC1912 2.4 and RFC2181 10.3 if NS or any other
records are present?

 $ dig -t cname sun.com. @ns1.sun.com.       
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5479
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; AUTHORITY SECTION:
sun.com.		900	IN	SOA	ns1.sun.com.
hostmaster.sun.com. 2011101403 3600 1200 1038800 900
 $

No, didn't make that error.

o  Are there any CNAMEs for the names listed in NS records (barred by
RFC1912 2.4 and RFC2181 10.3)?

 $ dig -t cname ns1.sun.com. @ns1.sun.com.
 $ dig -t cname ns2.sun.com. @ns1.sun.com.
 $ dig -t cname ns3.sun.com. @ns1.sun.com.
 $ dig -t cname ns8.sun.com. @ns1.sun.com.

Nope.  All respond status: NOERROR and ANSWER: 0.

o  Are all nameservers on different class C aka /24 netblocks?  
(RFC2182 3.1 has recommendations.)

Yes, they are.  See above.

o  Are all of the NS entries on public IPs?

Yes.  See above.

o  Do all of the NS hosts permit TCP-type connections?  (Accidentally
firewalling off TCP can create hard-to-diagnose problems.  DNSstuff
warns that use of anycast can create false positives on this test.)

FAIL.

 $ dig sun.com. @ns1.sun.com. +tcp
 $ dig sun.com. @ns2.sun.com. +tcp
 $ dig sun.com. @ns3.sun.com. +tcp
 $ dig sun.com. @ns8.sun.com. +tcp

All of them fail -- but this is almost certainly just an anycast effect.

o  What are the versions reported by nameservers?

The DNSstuff people say 'For security reasons, this test is restricted
to customers', but we need not observe any such restrictions.

 $ dig -t txt -c chaos version.bind @ns1.sun.com.
 $ dig -t txt -c chaos version.bind @ns2.sun.com.
 $ dig -t txt -c chaos version.bind @ns3.sun.com.
 $ dig -t txt -c chaos version.bind @ns8.sun.com.

All of them return 'status: REFUSED', which is good.  Compare my own
nameserver's response to that question:

dig -t txt -c chaos version.bind @ns1.linuxmafia.com. +short
"Shirley, you're joking"
$

;->

o  Do any of your DNS servers return any stealth NS records in non-NS
requests? 

I don't think so.  I did a spot-check of obvious queries.

o  Do all of your nameservers return the same S/N value, which is field
#3 in the SOA record (and thus are to a first approximation verified to
be serving up the same version of the zone data)?

 $ dig -t soa sun.com. @ns1.sun.com. +short | awk '{print $3}'
 $ dig -t soa sun.com. @ns2.sun.com. +short | awk '{print $3}'
 $ dig -t soa sun.com. @ns3.sun.com. +short | awk '{print $3}'
 $ dig -t soa sun.com. @ns8.sun.com. +short | awk '{print $3}'

Yes.  All return S/N '2011101403' at the moment.

o  Do they all agree on the master nameserver stated in field #1 
in the SOA record?

 $ dig -t soa sun.com. @ns1.sun.com. +short | awk '{print $1}'
 $ dig -t soa sun.com. @ns2.sun.com. +short | awk '{print $1}'
 $ dig -t soa sun.com. @ns3.sun.com. +short | awk '{print $1}'
 $ dig -t soa sun.com. @ns8.sun.com. +short | awk '{print $1}'

Yes, all return 'ns1.sun.com.'

o  Do they all agree on the RNAME (zone contact e-mail address) field
#2 of the SOA record (which has the @ changed to a . for display
purposes)?

 $ dig -t soa sun.com. @ns1.sun.com. +short | awk '{print $2}'
 $ dig -t soa sun.com. @ns2.sun.com. +short | awk '{print $2}'
 $ dig -t soa sun.com. @ns3.sun.com. +short | awk '{print $2}'
 $ dig -t soa sun.com. @ns8.sun.com. +short | awk '{print $2}'

Yes, all return 'hostmaster.sun.com.'

o  Is the S/N in the recommended YYYYMMDDnn format?

Yes.  It's 2011101403, indicating last change was year 2011, month 10,
day 14, revision #03.

o  Is the SOA 'REFRESH' field (#4) in the range of 1200 to
43200 seconds (20 minutes to 12 hours) recommended by RFC1912
2.2 for how often slave nameservers check in with the master for
updates?

 $ dig -t soa sun.com. @ns1.sun.com. +short | awk '{print $4}'
 $ dig -t soa sun.com. @ns2.sun.com. +short | awk '{print $4}'
 $ dig -t soa sun.com. @ns3.sun.com. +short | awk '{print $4}'
 $ dig -t soa sun.com. @ns8.sun.com. +short | awk '{print $4}'

Yes, it's 3600 seconds (1 hour).

o  Is the SOA 'RETRY' field (#5) in the range of 120 to 7200 
seconds (2 minutes to 2 hours) the DNSstuff people consider reasonable
for the amount of time your secondary/slave nameservers will wait to
contact the master nameserver again if the last attempt failed?

 $ dig -t soa sun.com. @ns1.sun.com. +short | awk '{print $5}'
 $ dig -t soa sun.com. @ns2.sun.com. +short | awk '{print $5}'
 $ dig -t soa sun.com. @ns3.sun.com. +short | awk '{print $5}'
 $ dig -t soa sun.com. @ns8.sun.com. +short | awk '{print $5}'

Yes, it's 1200 (20 minutes).

o  Is the SOA 'EXPIRE' field (#6) in a reasonable range?  RFC1912
suggests 2-4 weeks aka 1209600 to 2419200 seconds.  This is how long a
secondary/slave nameserver will wait before considering its DNS data
stale if it can't reach the primary nameserver.

 $ dig -t soa sun.com. @ns1.sun.com. +short | awk '{print $6}'
 $ dig -t soa sun.com. @ns2.sun.com. +short | awk '{print $6}'
 $ dig -t soa sun.com. @ns3.sun.com. +short | awk '{print $6}'
 $ dig -t soa sun.com. @ns8.sun.com. +short | awk '{print $6}'

Yes, it's 1038800 = 12 days.

o  Is the SOA negative caching field (#7) in a reasonable range?
RFC2308 suggests a value of 1-3 hours.  

It's 900, which DNSstuff's report says 'seems normal', even though it
strikes me as a bit low -- but this is a judgement call.



3.  MX RECORD ISSUES:

o  What are the MX records?

 $ dig -t mx sun.com. @ns1.sun.com.       
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55110
;; flags: qr aa rd; QUERY: 1, ANSWER: 7, AUTHORITY: 4, ADDITIONAL: 8
;; WARNING: recursion requested but not available

;; ANSWER SECTION:
sun.com.		600	IN	MX	5 acsinet40.oracle.com.
sun.com.		600	IN	MX	5 acsinet41.oracle.com.
sun.com.		600	IN	MX	5 ucsinet40.oracle.com.
sun.com.		600	IN	MX	5 ucsinet41.oracle.com.
sun.com.		600	IN	MX	5 ucsinet42.oracle.com.
sun.com.		600	IN	MX	20 mx3.sun.com.
sun.com.		600	IN	MX	20 mx4.sun.com.

;; AUTHORITY SECTION:
sun.com.		900	IN	NS	ns8.sun.com.
sun.com.		900	IN	NS	ns2.sun.com.
sun.com.		900	IN	NS	ns3.sun.com.
sun.com.		900	IN	NS	ns1.sun.com.

;; ADDITIONAL SECTION:
mx3.sun.com.		900	IN	A	192.18.98.43
mx3.sun.com.		900	IN	A	192.18.98.31
mx4.sun.com.		900	IN	A	192.18.98.34
mx4.sun.com.		900	IN	A	192.18.98.36
ns1.sun.com.		900	IN	A	192.18.128.11
ns2.sun.com.		900	IN	A	192.18.99.5
ns3.sun.com.		300	IN	A	192.18.43.12
ns8.sun.com.		900	IN	A	192.18.43.12
$

o  Can nameservers querying from low-numbered port numbers resolve the
MS records?

# dig -t mx sun.com. @ns1.sun.com. -b 0.0.0.0#1020 +short
5 ucsinet41.oracle.com.
5 ucsinet42.oracle.com.
20 mx3.sun.com.
20 mx4.sun.com.
5 acsinet40.oracle.com.
5 acsinet41.oracle.com.
5 ucsinet40.oracle.com.
#

Yes.

o  Do the returned MX records include invalid characters in hostnames?

No.  See above.

o  Dod any of the MX records return a CNAME, which entails extra
processing?

No.  See above.

o  Does looking up the A records returned by MX lookups result in a
CNAME record (which is bad and barred by RFC974, RFC1034 3.6.2, RFC1912
2.4, and RFC2181 10.3)?

 $ dig ucsinet41.oracle.com. +short
 $ dig ucsinet42.oracle.com. +short
 $ dig mx3.sun.com. +short
 $ dig mx4.sun.com. +short
 $ acsinet40.oracle.com. +short
 $ acsinet41.oracle.com. +short
 $ ucsinet40.oracle.com. +short

All (correctly) return IPs.

o  Do all MX records (correctly) return hostnames, rather than IPs?

Yes.  See above.

o  Are there multiple MX records, for redundancy?

Yes.  See above.

o  Did the various nameservers return different IPs for the MX records?

No.  Details omitted for brevity.

o  Are the any duplicate MX records that point to the same IP (which can
cause confusion and waste resources)?  

No.  Details omitted for brevity.

o  Do all the IPs returned for MX records have matching PTR reverse
records (strongly recommended by RFC1912 2.1 and used as antispam
quality control by some receiving SMTP hosts)?

Yes.  Details omitted for brevity.

o  Can all the MX hosts be connected to?

FAIL.  Nope.  A bunch of them fail, e.g.:

$ telnet mx3.sun.com 25
Trying 192.18.98.31...
Trying 192.18.98.43...
telnet: Unable to connect to remote host: Connection refused
$

o  Do all the MX hosts claim in their SMTP greetings to be the host
being connected to?  Not doing so is a technical violation of RFC821 4.3
(and RFC2821 4.3.1). 

FAIL.  No.  Example:

$ telnet ucsinet41.oracle.com 25
Trying 156.151.31.69...
Connected to 156.151.31.69.
Escape character is '^]'.
220 SMTP Proxy Server Ready
quit
$

o  Do all the MX hosts accept mail from the null sender '<>' that is used
for reject/bounce messages and return receipts.

Yes.  (Test SMTP session using telnet omitted for brevity.)

o  Do all the MX hosts accept mail to postmaster?

Yes.  (Test SMTP session using telnet omitted for brevity.)

o  Do all the MX hosts accept mail to abuse?

Yes.  (Test SMTP session using telnet omitted for brevity.)

o  Do all the MX hosts accept mail to domain literal addresses of the
format 'user@[0.0.0.0]' as required by RFC1123 5.2.17, and make it more 
difficult to test the mail server and receive problem reports.

WARNING: not a significant problem.  (Test SMTP session using telnet
omitted for brevity.)

o  Are any of the MX hosts open relays?

No.  (Test SMTP session using telnet omitted for brevity.)

o  Is there an SPF record?

No.

$ dig -t spf sun.com +short
$



4.  WWW RECORD ISSUES:

o  Is there a www record?

Uh, yes.


o  Are all the IPs returned for 'www' public?

Yep.

$ dig www.sun.com       
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55535
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 3

;; ANSWER SECTION:
www.sun.com.		892	IN	CNAME
legacy-sun.oraclegha.com.
legacy-sun.oraclegha.com. 22	IN	A	137.254.16.113

;; AUTHORITY SECTION:
oraclegha.com.		159653	IN	NS	gdns2.oracle.com.
oraclegha.com.		159653	IN	NS	gdns1.oracle.com.
oraclegha.com.		159653	IN	NS	gdns3.oracle.com.

;; ADDITIONAL SECTION:
gdns1.oracle.com.	9780	IN	A	148.87.2.219
gdns2.oracle.com.	9780	IN	A	141.146.36.11
gdns3.oracle.com.	9780	IN	A	148.87.112.251
$


o  Is the 'www' record mediated by a CNAME, which is confusing and
entails an avoidable extra lookup?

WARNING:  Yes.  See above.


o  What is the unqualified domain name's A record?

Same as the www one.

~ $ dig sun.com 
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46144
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0

;; ANSWER SECTION:
sun.com.		300	IN	A	137.254.16.113

;; AUTHORITY SECTION:
sun.com.		900	IN	NS	ns2.sun.com.
sun.com.		900	IN	NS	ns8.sun.com.
sun.com.		900	IN	NS	ns1.sun.com.
sun.com.		900	IN	NS	ns3.sun.com.
$



So, you see, you can easily get free of charge, using standard tools,
everything DNSstuff offers via their CGIs for money -- albeit the
results aren't as pretty.