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 184.108.40.206 ns2.megabulkmessage218.com. IN A 220.127.116.11 [...]
One of these two listed nameservers is not like the other.
18.104.22.168 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, 22.214.171.124 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 126.96.36.199 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. @188.8.131.52 [nothing; we get the standard 'no such data' response] ; sdig a gadswoonsg.megabulkmessage218.com. @184.108.40.206 220.127.116.11 ; sdig mx gadswoonsg.megabulkmessage218.com. @18.104.22.168 10 mail.megabulkmessage218.com. ; sdig a mail.megabulkmessage218.com. @22.214.171.124 126.96.36.199
(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 188.8.131.52 is probably in it. And the domain name is currently in the Spamhaus DBL.)
; dig a randomname.megabulkmessage218.com. @184.108.40.206 [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).