How not to set up your DNS (part 7)
Presented in point form, because the illustrated form is too verbose:
- The subdomain bos.netsolhost.com has nameservers NS1.bos.netsolhost.com and NS2.bos.netsolhost.com.
- according to the nameservers for netsolhost.com, these have IP addresses 188.8.131.52 and 184.108.40.206 respectively.
- according to 220.127.116.11, these actually have IP addresses 10.49.34.11 and 10.49.34.12 respectively.
- 18.104.22.168 doesn't respond.
The 10.*.*.* IP addresses are RFC 1918 private addresses, so no one outside netsolhost.com can get to them. The net effect that the first query for something in bos.netsolhost.com will return useful information but everything after that fails, because when 22.214.171.124 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 126.96.36.199 (allegedly
'vux16.bos.netsolhost.com') kept trying to send us email with the
MAIL FROM of 'email@example.com'. 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.
On not logging things
One of the machines I help look after is an open, read-only Usenet server (details here; the open access is a 'because we can' thing). You might be surprised to know that the server logs only minimal information about NNTP sessions, and this is a deliberate action that required hacking the software a bit.
When I was setting up the machine and planning open access for everyone on campus, I found myself thinking about how I'd feel if, for example, some day a department head came to us to say 'I want to know what newsgroups people in my department are reading'. Much like library borrowing records, what newsgroups people read can be embarrassing or damaging; did I really want to be in a position of turning over that information?
As system administrators, we often default to logging everything we can that doesn't expose obvious security risks. But this opens up more subtle abuses and risks (especially as people seem much more willing to go snooping through computer logs than other records, perhaps because computer logs are seen as 'less private').
So I'd like to urge sysadmins to consider the merits of not logging things. Consider if you really need to know that piece of information, or whether you're hoovering it up just because.
(The issue is not new with computers; librarians have been dealing with this for a long time and take it quite seriously.)