How not to set up your DNS (part 23)
Presented in the traditional illustrated form, more or less:
; dig ns megabulkmessage218.com @a.gtld-servers.net. [...] megabulkmessage218.com. IN NS ns1.megabulkmessage218.com. megabulkmessage218.com. IN NS ns2.megabulkmessage218.com. [...] ns1.megabulkmessage218.com. IN A 18.104.22.168 ns2.megabulkmessage218.com. IN A 22.214.171.124 [...]
One of these two listed nameservers is not like the other.
126.96.36.199 is of course the famous open resolving DNS server that Google operates. It is in no way an authoritative DNS server for anyone, even if you try to use it as one. Lookups will probably fail, because I believe that most DNS resolvers set the 'no recursion' flag in their queries to what they believe are authoritative DNS servers and when it sees that, 188.8.131.52 doesn't answer even when it almost certainly has the data in cache (instead it returns a SERVFAIL).
(This is thus an extreme case of an informal secondary, although I suppose it was probably inevitable
and there are likely plenty of other people using 184.108.40.206 this way
with other domains. After all, it appears to work if you test it
by hand, since tools like
dig normally set the recursive flag on
Since this is a spammer's DNS server (as you might have guessed from the domain name), things are a little bit peculiar with its results.
; dig ns megabulkmessage218.com. @220.127.116.11 [nothing; we get the standard 'no such data' response] ; sdig a gadswoonsg.megabulkmessage218.com. @18.104.22.168 22.214.171.124 ; sdig mx gadswoonsg.megabulkmessage218.com. @126.96.36.199 10 mail.megabulkmessage218.com. ; sdig a mail.megabulkmessage218.com. @188.8.131.52 184.108.40.206
(The MX target is SBL295728, the A record is in the SBL CSS and listed in the CBL and so on. Basically, you name a DNS blocklist and 220.127.116.11 is probably in it. And the domain name is currently in the Spamhaus DBL.)
; dig a randomname.megabulkmessage218.com. @18.104.22.168 [nothing; we get the standard 'no such data' response]
So this spammer is clearly making up random names for their spam run and running a very custom nameserver that only responds to them. Anything else gets a no such data response, including SOA and NS queries for the domain itself. Since there's nothing entirely new under the sun, we've seen this sort of DNS server cleverness before.
It's interesting that trying to get the NS records for the domain from your local resolving DNS server will fail even after you've looked up the A record for the hostname. The NS records (and glue) from the .com nameservers don't have particularly low TTLs, and given that the A record resolves your local DNS server was able to get and use them. But these days clearly it immediately throws them away again to avoid cache poisoning attacks (or at least won't return them for direct queries).