[RFCI-Discuss] Interesting Question
Abuse Desk
abuse at despam.us
Fri Jan 6 12:28:18 EST 2006
On Dec 4, 2005, at 5:34 PM, Derek J. Balling wrote:
> On Dec 4, 2005, at 2:25 PM, Alex van den Bogaerdt wrote:
> > Well... you didn't ask for authority, you asked for name servers.
>
> Right, but if the server isn't authoritative, then -- especially if
> it's authoritative for the parent zone -- it should be providing me
> with the direction to go to get the answer.
>
> One could argue that
>
> o If a.gtld-servers.net is authoritative for "COM"
> o If it is asked for "NS" for "YAHOO.COM"
> o If it says "I don't have an authoritative answer" (no "aa" flag)
> o If it doesn't point in a direction of authority
>
> That regardless of what "helpful info" it puts in the ANSWERS
> section, then that path is dead, and no such servers exist, because
> non-authoritative answers aren't worth the bits that carried them.
Ignoring the aberrant behavior of the gtld-servers.net nameservers for
the moment, taking the above argument to the next step for a particular
domain, we query a.gtld-servers.net for targetresume.com:
; <<>> DiG 9.2.3 <<>> @a.gtld-servers.net targetresume.com ns
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41
;; flags: qr rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
;; QUESTION SECTION:
;targetresume.com. IN NS
;; ANSWER SECTION:
targetresume.com. 172800 IN NS ns1s.on-linejobs.com.
targetresume.com. 172800 IN NS ns2.on-linejobs.com.
;; ADDITIONAL SECTION:
ns1s.on-linejobs.com. 172800 IN A 216.242.235.43
ns2.on-linejobs.com. 172800 IN A 72.245.169.130
;; Query time: 360 msec
;; SERVER: 192.5.6.30#53(a.gtld-servers.net)
;; WHEN: Fri Jan 06 11:35:59 2006
;; MSG SIZE rcvd: 115
Then we continue our quest for authoritative NS records, and run into
the following twin brick walls (non-authoritative answers with the name
of a nameserver that doesn't exist):
; <<>> DiG 9.2.3 <<>> @ns1s.on-linejobs.com targetresume.com ns
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;targetresume.com. IN NS
;; ANSWER SECTION:
targetresume.com. 3600 IN NS ns1s.
;; Query time: 320 msec
;; SERVER: 216.242.235.43#53(ns1s.on-linejobs.com)
;; WHEN: Fri Jan 06 11:34:21 2006
;; MSG SIZE rcvd: 52
; <<>> DiG 9.2.3 <<>> @ns2.on-linejobs.com targetresume.com ns
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;targetresume.com. IN NS
;; ANSWER SECTION:
targetresume.com. 3600 IN NS ns1s.
;; Query time: 330 msec
;; SERVER: 72.245.169.130#53(ns2.on-linejobs.com)
;; WHEN: Fri Jan 06 11:34:58 2006
;; MSG SIZE rcvd: 52
and just to be on the safe side:
; <<>> DiG 9.2.3 <<>> @a.root-servers.net ns1s.
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;ns1s. IN A
;; AUTHORITY SECTION:
. 86400 IN SOA A.ROOT-SERVERS.NET.
NSTLD.VERISIGN-GRS.COM. 2006010501 1800 900 604800 86400
;; Query time: 310 msec
;; SERVER: 198.41.0.4#53(a.root-servers.net)
;; WHEN: Fri Jan 06 12:03:45 2006
;; MSG SIZE rcvd: 97
Such behavior should cause a totally-compliant resolver not to even get
to the stage of looking for an MX record, shouldn't it?
Extending the search, let's look for an MX record:
; <<>> DiG 9.2.3 <<>> @ns1s.on-linejobs.com targetresume.com mx
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;targetresume.com. IN MX
;; ANSWER SECTION:
targetresume.com. 3600 IN MX 10
mail.targetresume.com.
;; ADDITIONAL SECTION:
mail.targetresume.com. 3600 IN A 72.245.169.131
;; Query time: 420 msec
;; SERVER: 216.242.235.43#53(ns1s.on-linejobs.com)
;; WHEN: Fri Jan 06 11:56:49 2006
;; MSG SIZE rcvd: 71
; <<>> DiG 9.2.3 <<>> @ns2.on-linejobs.com targetresume.com mx
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;targetresume.com. IN MX
;; ANSWER SECTION:
targetresume.com. 3600 IN MX 10
mail.targetresume.com.
;; ADDITIONAL SECTION:
mail.targetresume.com. 3600 IN A 72.245.169.131
;; Query time: 410 msec
;; SERVER: 72.245.169.130#53(ns2.on-linejobs.com)
;; WHEN: Fri Jan 06 11:55:18 2006
;; MSG SIZE rcvd: 71
So those nameservers aren't authoritative for the mailservers of
targetresume.com either.
Is or should such behavior enough to qualify a domain for bogusmx
listing?
Does it make sense to add a criterion for bogusmx that if any MX record
(including an implicit MX record of priority 0 as an A record in the
absence of a real MX record) is found for a domain or subdomain by
following the NS record chain from the root, and that MX record is not
authoritative, then the domain or subdomain queried for that MX record
shall be considered bogus because "non-authoritative answers aren't
worth the bits that carried them"?
Would a new bogusns zone fit the bill instead?
The SOA record is similarly hosed, referencing nameserver "ns1s." and
contact "hostmaster@" as "hostmaster.".
The same situation exists for targetresume.net.
Reference: RFC2181 Section 5.4.1
--
Thanks and Best Regards,
Abuse Desk
DeSpam.Us
More information about the RFCI-Discuss
mailing list