Wandering Thoughts archives

On the name of USB flash memory drives

I've been somewhat confused about what to call USB flash memory 'disk drives' for some time, since I've seen several names. Courtesy of Pete Zaitcev here, who should know since he works on the Linux kernel USB stack among other things, I now have a pretty definite answer; they are properly called 'USB keys'. A 'Memory Stick' (with the capitals) is something entirely different, and 'memory stick' risks being confused with it.

(I suppose I could just have called them 'USB flash memory drives', but 'USB keys' is much shorter.)

(Yes, this is slightly belated. Every so often things moulder in my ideas file until some 2am when I really want to go to bed. And now you know more about the production process for WanderingThoughts entries than you were probably interested in.)

Update: and just after I published this entry, I ran across this Raymond Chen article that calls them 'USB memory drives'. Now I'm somewhat confused again.

How not to set up your DNS (part 6)

Today's illustrative example is about the odd things that can happen if you rename a nameserver without making sure that you tell the people delegating zones to you.

There are four nameservers for utoronto.ca: ns1, ns2, bay.cs, and ns1.tpc.int (following local practice, I'm dropping the .utoronto.ca bit a lot). Three of those four (everything except ns1) are also secondaries for all campus subdomains, including the domain jpint.utoronto.ca.

; sdig ns jpint.utoronto.ca.
ns1.jpint.utoronto.ca.
bay.cs.utoronto.ca.
ns2.utoronto.ca.
ns1.tpc.int.
; sdig a ns1.jpint.utoronto.ca.
128.100.16.12

There is also another machine, mto.jpint. Most of the time, if I asked for its IP address I got 128.100.16.27. Except once or twice, I didn't; I got 128.100.16.12, ns1.jpint's IP address.

Unfortunately, this nice proper set of NS records was a lie. The lie was exposed by asking ns1.utoronto.ca for NS information for jpint; it was of the opinion that the right nameserver was mto.jpint, to be found at the IP address 128.100.16.12.

What had happened is that jpint had renamed their primary nameserver; what had been 'mto.jpint' became 'ns1.jpint', and the 'mto.jpint' name was given a new IP address. But no one told the campus nameserver people about this, so the utoronto.ca zone carried the old NS data, with the old glue record for mto.jpint with its old IP address.

As secondaries, three out of four of the utoronto.ca nameservers then fetched the jpint zone from 128.100.16.12, and replaced their own idea of the jpint NS records and mto.jpint's IP address with the zone's information. Because it is not a campus secondary, ns1.utoronto.ca did not, preserving the original info to be handed out when queried.

As you can see, this is really quite hard to notice; the only real sign was the 'blue moon' wrong IP address for mto.jpint. I only really chased this down when I ran the domain through the dnsreport.com DNS consistency checker and it picked ns1.utoronto.ca to pull DNS information from, leading me to wonder just why ns1.jpint was being reported as a 'stealth NS record'.

This isn't a new problem; similar issues (but worse) used to happen in the old InterNIC days. (An explanation of those problems does not fit in the margin of this entry.)

(The jpint situation is in the process of being fixed, so hopefully soon you won't be able to see this for yourself.)

How not to set up your DNS (part 5)

This one is partly my fault, due to me inheriting responsibility for managing DNS for this organization. (Needless to say it's fixed now, but it gives me a useful cautionary example.)

This won't be presented in illustrated form, because it's simpler to just explain the problem. All of this is for the domain transportationtomorrow.on.ca.

• according to the .ca nameservers, the nameservers for the domain are ns1.jpint.utoronto.ca and mto.jpint.utoronto.ca.
• mto.jpint isn't responding with useful information (for complex reasons).
• ns1.jpint claimed that the nameserver for the domain was 'ns1.transportationtomorrow.on.ca'.
• ns1.jpint had no A record for ns1.transportationtomorrow.on.ca.

Odd things start happening when you and the level above you disagree on what a domain's NS records are. Worse things happen when your set of NS records don't work; usually what happens is that the first query works but subsequent queries fail.

(This happens because answers to DNS queries also usually contain NS records as well. So the first query is made to the real nameservers, but comes back with broken NS records as well as the answer. Your local nameserver then caches the broken NS records, and until they time out will try to send subsequent queries off to them.)

Actually the situation is not quite fixed yet, because I've been unable to figure out how to make the Solaris 2.4 machine's nameserver manage a successful zone transfer from the Bind 9 machine; named-xfer becomes unhappy with life, dying with the helpful error message 'getzone: print_update failed (46, 60)'.

(Why is the machine still running Solaris 2.4? Well, it's a Sparcstation 2, so the upgrade options are somewhat limited. We will probably try to install Debian on it at some point, just to have relatively recent versions of various daemons.)

How not to set up your DNS (part 4)

Presented in the traditional illustrated form:

; dig +short mx mail2world.com.
10 publicms2.mail2world.com.
10 publicms1.mail2world.com.
; dig +short a publicms1.mail2world.com.
216.163.188.54
; dig +short a publicms2.mail2world.com.
216.163.188.54

That's an, uh, interesting way to do redundant MXes. Or, in their case, redundant MX records.

Dropping packets versus rejecting them in firewall rules

There's a reasonably popular view that having your firewall drop undesired packets instead of sending ICMP rejections is 'more secure'. It is not; instead it is 'more annoying'.

(Technically this is not quite true; in a very limited set of circumstances, dropping all packets for a host can hide some information from attackers. The flipside is that dropping some but not all packets usually leaks information about what you're screening.)

Dropping packets is more annoying because attempted connections have to time out before they fail, instead of failing immediately with some species of 'connection refused'. Note that this doesn't matter much to attackers, who are using automated software (which may have its own rapid timeouts).

When you use DROP instead of REJECT, you are being hostile to the other end. Hopefully you are being deliberately hostile, having determined that they are up to evil or are otherwise undesirable.

(For example, we use DROP for kernel SMTP screening because once someone makes it into our kernel level SMTP blocks we actively don't like them and want to cause them what annoyance we can. I accept that it's not likely to be very much annoyance.)

Using DROP on connection attempts from the inside to the outside is especially problematic. Unless you are overloaded with internal security problems, most of those connection attempts have a human behind them, one who your firewall is busy annoying. Hopefully not very many of the people on the inside of your firewall are evil and deserve to be annoyed.

Also, people have a much easier time diagnosing 'connection refused' than 'mysterious connection timeouts'. It can even stop them from retrying their connection several times (and cluttering up your logs or counters).

(See also Drop versus Reject for another discussion of this issue.)