Wandering Thoughts: Recent Entries For 2006/01/12

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 205.178.146.11 and 205.178.146.12 respectively.
• according to 205.178.146.11, these actually have IP addresses 10.49.34.11 and 10.49.34.12 respectively.
• 205.178.146.12 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 205.178.146.11 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 205.178.145.65 (allegedly 'vux16.bos.netsolhost.com') kept trying to send us email with the MAIL FROM of '627834.640381@vux16.bos.netsolhost.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?

We could have drawn up a strong privacy policy. But privacy policies are subject to being overridden by higher powers, such as department heads who can get the ear of the Dean. What would I do then? In the end the best way to protect this information was to not collection it, because what you don't log you can't be required to produce later. (We could always be required to introduce logging, but this would take more than semi-casual curiosity backed by political power.)

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.)