Wandering Thoughts archives

On the naming of machines (part 2)

I've recently been forcefully reminded of an important thing about naming machines, namely that you should give your machines hostnames that are not English words that you will use in your email and notes. That way you can actually find where you mention your machines when you go searching through the same, instead of getting lost in the clutter.

(For example, we had a machine called 'mix'. I rapidly gave up searching our work email archive for information about its history.)

This doesn't mean that you can't use recognizable words. You just need to pick words that you'll never use in notes and email except when they refer to your machines. If you are going to search all of your email, the best names are somewhat person-dependent; for example, if you correspond with people about Greek mythology, 'hermes' and 'lachesis' may not be the best names for machines.

Sometimes you can save a dangerous name by consistently adopting a longer form of it. For example, I used to be responsible for a machine called 'disk' (it was our fileserver, and all of our servers had functional names like that); however, we almost always added the subdomain when talking about it and called it 'disk.srv'.

(Similarly, naming a machine after the service it offers or the program it runs to do that is inviting confusion in searches. This doesn't mean you can't use such things as the basis for the hostname; just don't use them directly. For example, our new IMAP server is called 'aviary', not 'dovecot'.)

The excessive cleverness of some people's reverse DNS

I have to say that I'm bemused by the amount of effort that people will go to just to avoid coming up with hostnames for their machines. (This is different from the lazy people, who just don't bother creating PTR records at all.)

By now I am used to the people who carefully give their IP addresses a PTR record of the IP address itself:

2.0.0.127.in-addr.arpa. PTR 127.0.0.2.

(Naturally these show up as invalid reverse DNS, since there is no corresponding A record.)

I see enough of these that my tool for doing reverse DNS lookups prints them specially. I'm never sure if these are deliberate or just the result of a well intentioned person being told that all of their IP addresses should have PTR records, whether or not they have hostnames.

Recently, though, someone did this one better: they gave their IP addresses PTRs to themselves in the .in-addr.arpa zone and then gave them corresponding A records; the result was entirely valid hostnames like 35.95.2.81.in-addr.arpa. The sheer blank Zen-like perfection of this perfectly valid yet completely useless non-answer still stuns me, especially since they had to go to extra work to add the A records. (But at least they have valid reverse DNS.)

(Also, I would be remiss if I didn't give an honorable mention to as15444.net, a domain that is named after their ASN.)

How not to set up your DNS (part 17)

Here is an interesting one that caused me to go digging into the moderate depths of DNS arcana:

; sdig ns just-dust.com
dns1.name-services.com.
dns2.name-services.com.
dns3.name-services.com.
dns4.name-services.com.
dns5.name-services.com.
; dig mx servidor134.just-dust.com
[...]
;; [...] status: SERVFAIL, [...]

This isn't for any simple reason, such as the servers refusing to answer us or not being authoritative or whatnot. Instead, they have managed to get the 'no such record' reply wrong; instead of returning a SOA record for just-dust.com, they return what looks like a lame delegation response (pointing at themselves), except that it has the aa bit set.

What may be going on is that name-services.com seems to be running a very peculiar nameserver that has the moral equivalent of a wildcard CNAME record for just-dust.com, but only for A record queries; if you ask directly for a CNAME for foo.bar.just-dust.com, you get a normal 'no such data' reply, but if you ask for the A record for that you get back a reply with a CNAME plus an A record. Presumably as a result of this, almost all queries for MX records of names inside the just-dust.com zone get these lame delegation replies.

(Not all MX queries; just-dust.com MXes to mail.just-dust.com, and name-services.com will return an MX record for that.)

How to tell a DNS no data reply from a lame delegation

When you query an authoritative nameserver for a record that doesn't exist, what you get back is a reply with status NOERROR, the aa bit set, no ANSWER section, and the zone's SOA record as the sole record in the AUTHORITY section. (And no ADDITIONAL section.)

When you query a nameserver for a record in a zone that it doesn't serve, what you get back is a reply with status NOERROR, no ANSWER section, some zone's NS records, and some A records for the NSes in the ADDITIONAL section. Which zone you get depends; generally it is the closest zone to your target zone that the nameserver knows about, eg if you query for foo.bar.org, you may get the root NSes, the .org NSes, or even the bar.org NSes if the nameserver knows them.

(You do not necessarily get A records for all of the NS targets, just the ones that the nameserver knows. I believe that there are circumstances where you can get no A records at all.)

If the nameserver you are querying is listed in an NS record for the zone, such a reply is a 'lame delegation'; the NS record is pointing to a nameserver that is not actually a nameserver for that zone. In some situations the NS records such a lame delegation returns will include the very nameserver you are querying, for example if you are making a nonrecursive query to an informal secondary that has cached NS information but not the record you're looking for.

(A secondary server that doesn't have a copy of the zone data will not be seen as a lame delegation, because such a server returns a SERVFAIL answer instead of NOERROR plus NS records.)

Note that not all nameservers even return replies for zones that they don't serve. Some will just drop your queries on the floor.

The benefits of growing your toolbox

Although we weren't going to use our new gigabit backbone connection immediately, I wanted to check that we really could get something close to gigabit performance through it and that everything was working smoothly. When you're doing network performance testing, you really need to do it from a platform that you trust, so that any slowness can be attributed to the stuff in the middle and not to your end having issues.

As it happened, the most trustworthy machine for this was my office workstation. But since it was my workstation, I didn't want to disconnect it from its regular home in order to do testing, which meant that I needed a way to force the gigabit test traffic to flow over the interface connected to the touchdown switch and not, say, over the regular default route's interface (which would go out our 100 mbit backbone connection); fortunately I already knew how to do that.

Since I looked into the dual identity routing issues purely for my own use, this makes a great illustration of the benefits of growing your toolbox; working out how to set up my own home VPN gave me the tools I needed to easily test a new gigabit backbone connection at work.

This has become a relatively common thing for me; over and over again I've found myself applying the results of earlier curiosity to practical problems that have come up at work. Knowing more, even if it initially seems irrelevant, has made me a better system administrator.

(It helps if you're an intellectual magpie and take delight just in learning cool stuff. Then any future payoffs are just a surprise bonus and it's not work to do the scavenging.)

Adventures in network design, illustrated by our new backbone connection

Our current connection to the campus backbone is a 100 megabit connection. While we have a (somewhat) new gigabit backbone connection, we are not using it yet because we need to revise our network architecture.

One of the issues with our current network setup is that it was designed before firewalls were common. As a result, our current backbone connection connects directly to one of our /24 subnets, where (of course) a number of our servers live. This forces us to use a bridging firewall instead of a routing one, because we want those servers to be behind the firewall.

If you can, you really want to use a routing firewall:

• OpenBSD's pfsync and CARP support only works (well) with routing firewalls, which means that our current firewall doesn't have an automatic hot backup; if it fails, the recovery procedure requires someone to go to the machine room.
• bridging firewalls can't do some things.

Given this, what you generally want is that your touchdown subnet (the subnet that your external connection sits on) to have only your external connection and your routing firewall. In theory we could achieve this even with our current connection, but for two issues: first, a /24 is a pretty large chunk of network space to use up for just two things, and second, a number of our servers on that subnet have by now very well known IP addresses and would be hard to move.

Our new gigabit connection uses a very small touchdown network for just this sort of network setup. However, this means that to use it we pretty much need to build a new firewall setup and shuffle how our internal routing is done, and we haven't yet had time to do either.

(We are fortunate that no one is really chomping at the bit to have gigabit connectivity to elsewhere on campus.)