How not to set up your DNS (part 23)

July 19, 2016

Presented in the traditional illustrated form, more or less:

; dig ns
[...] IN NS IN NS
[...] IN A IN A

One of these two listed nameservers is not like the other. 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, 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 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 their queries.)

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 @
[nothing; we get the standard 'no such data' response]
; sdig a @
; sdig mx @
; sdig a @

(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 is probably in it. And the domain name is currently in the Spamhaus DBL.)


; dig a @
[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).

Written on 19 July 2016.
« An interesting (and alarming) Grub2 error and its cause
Official source release builds should not abort on (compilation) warnings »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Jul 19 14:24:05 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.