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 5.8.32.218
ns2.megabulkmessage218.com. IN A 8.8.8.8
[...]

One of these two listed nameservers is not like the other.

8.8.8.8 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, 8.8.8.8 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 8.8.8.8 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 megabulkmessage218.com. @5.8.32.218
[nothing; we get the standard 'no such data' response]
; sdig a gadswoonsg.megabulkmessage218.com. @5.8.32.218
178.235.61.115
; sdig mx gadswoonsg.megabulkmessage218.com. @5.8.32.218
10 mail.megabulkmessage218.com.
; sdig a mail.megabulkmessage218.com. @5.8.32.218
149.154.64.43

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

But:

; dig a randomname.megabulkmessage218.com. @5.8.32.218
[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).