How not to set up your DNS (part 17)
Here is an interesting one that caused me to go digging into the moderate depths of DNS arcana:
; sdig ns just-dust.com dns1.name-services.com. dns2.name-services.com. dns3.name-services.com. dns4.name-services.com. dns5.name-services.com. ; dig mx servidor134.just-dust.com [...] ;; [...] status: SERVFAIL, [...]
This isn't for any simple reason, such as the servers refusing to answer
us or not being authoritative or whatnot. Instead, they have managed to
get the 'no such record' reply wrong; instead
of returning a SOA record for just-dust.com, they return what looks like
a lame delegation response (pointing at themselves), except that it has
aa bit set.
What may be going on is that name-services.com seems to be running a very peculiar nameserver that has the moral equivalent of a wildcard CNAME record for just-dust.com, but only for A record queries; if you ask directly for a CNAME for foo.bar.just-dust.com, you get a normal 'no such data' reply, but if you ask for the A record for that you get back a reply with a CNAME plus an A record. Presumably as a result of this, almost all queries for MX records of names inside the just-dust.com zone get these lame delegation replies.
(Not all MX queries; just-dust.com MXes to mail.just-dust.com, and name-services.com will return an MX record for that.)
How to tell a DNS no data reply from a lame delegation
When you query an authoritative nameserver for a record that doesn't
exist, what you get back is a reply with status NOERROR, the
aa bit set, no ANSWER section, and the zone's
SOA record as
the sole record in the AUTHORITY section. (And no ADDITIONAL section.)
When you query a nameserver for a record in a zone that it doesn't serve, what you get back is a reply with status NOERROR, no ANSWER section, some zone's NS records, and some A records for the NSes in the ADDITIONAL section. Which zone you get depends; generally it is the closest zone to your target zone that the nameserver knows about, eg if you query for foo.bar.org, you may get the root NSes, the .org NSes, or even the bar.org NSes if the nameserver knows them.
(You do not necessarily get A records for all of the NS targets, just the ones that the nameserver knows. I believe that there are circumstances where you can get no A records at all.)
If the nameserver you are querying is listed in an NS record for the zone, such a reply is a 'lame delegation'; the NS record is pointing to a nameserver that is not actually a nameserver for that zone. In some situations the NS records such a lame delegation returns will include the very nameserver you are querying, for example if you are making a nonrecursive query to an informal secondary that has cached NS information but not the record you're looking for.
(A secondary server that doesn't have a copy of the zone data will not be seen as a lame delegation, because such a server returns a SERVFAIL answer instead of NOERROR plus NS records.)
Note that not all nameservers even return replies for zones that they don't serve. Some will just drop your queries on the floor.