How not to set up your DNS (part 7)

January 12, 2006

Presented in point form, because the illustrated form is too verbose:

  • The subdomain has nameservers and
  • according to the nameservers for, these have IP addresses and respectively.
  • according to, these actually have IP addresses and respectively.
  • doesn't respond.

The 10.*.*.* IP addresses are RFC 1918 private addresses, so no one outside can get to them. The net effect that the first query for something in will return useful information but everything after that fails, because when answers your first query it also feeds you the bad nameserver IP addresses and 'poisons' your nameserver cache.

I've seen all the elements of this one separately, but this is the first time I've seen glue record hell and leaking internal domains with internal-only IP addresses combined so creatively.

We noticed this because (allegedly '') kept trying to send us email with the MAIL FROM of ''. In the process of verifying incoming mail, we want to do A and MX queries; as the first query, the A query worked, but the MX query got timeouts. When I noticed the repeated '454 temporarily unresolvable address' replies for something that was at least partially resolvable (because we accepted it as a HELO name) I started digging.

Comments on this page:

From at 2006-08-24 22:04:40:

This is an amusing post. I periodically see E-mail from "" perculating onto the Internet. It fails for similar reasons (as you can see from dig), though I doubt they intend for the senders to pollute the Internet with messages from an internal domain. The HowNotToDoDNS pieces are awesome! Keep them coming.

- Ryan

Written on 12 January 2006.
« On not logging things
An unconventional reason for large RAID stripe sizes »

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

Last modified: Thu Jan 12 11:04:00 2006
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.