Chapter 14

p. 188

RFCs 1034 and 1035 have been updated many times, with the most important general update being RFC 2181. RFC 2535 (as modified by RFCs 2931, 3007; 3008, 3090 and 3226) contains security extensions to the DNS.

p. 189

Stevens says that arpa is used for address-to-name mappings, but it has recently (RFC 3172) been re-categorised as the ``infrastructural domain'' for the Internet, which means that it could be used for more. ip6.arpa and e164.arpa³⁸ are in use, as well as the common in-addr.arpa Stevens describes.

p. 189

The country codes are listed in ISO 3166 (one of the more frequently changing ISO standards at the moment!). An on-line version, listing 239 country codes as of December 1999, can be found at http://www.din.de/gremien/nas/nabd/iso3166ma/codlstp1.html. DIN is the German standards authority, which hosts the ISO 3166 Maintenance Agency.

p. 189

Several sites outside the U.S.A. use .com, .edu (largely in Canada, but the University of Bath has registered bath.edu for example) and .net: two examples are the ISP .freeuk.com and JANET itself .ja.net. It used to be rare for organisations wholly outside North America to use .org, but there are some³⁹ -- the most curious is the British Council offices in Portugal, which live at www.britishcouncilpt.org.

In 2001, two new ``generic'' top-level domains were authorised: .info⁴⁰ and .biz. For more information about these and other new top-level domains (e.g. .name, .museum, .coop, .aero), see http://domains.dan.info/structure/new-tlds.html.

Some other countries (e.g. Austria -- .at) have a system like the U.K., with .ac.at being universities. Others (e.g. Germany -- .de) do not, and reliance has to be placed on the format of the next name, e.g. uni-paderborn.de means the University of Paderborn.

p. 190

RFC 2812 describes ``best current practice'' in the DNS. In particular, it recommends that at least one secondary server be on a different international backbone from the primary server.

p. 191

Most clients in fact use the combination of the IP address of the server and the identification field to match responses to requests (a 16-bit field by itself is sufficient for an individual resolver, but not for a server that is asking many other servers for answers). It is therefore important (see RFC 2181; section 4) that a multi-homed server uses the same IP address for the reply as the IP address in the request. Similarly, the same port number must be used in the reply as in the request.

pp. 193-4; Figs 14.5, 14.8

These are somewhat misleading, since they imply that the query type and query class are properly aligned on 16-bit boundaries, and that (in 14.8) the time-to-live is aligned on a 32-bit boundary. In fact, no padding of any of the domain names (which are just sequences of bytes) is done, so these can start anywhere. This may necessitate some fancy `C' code to unpick the data structures corresponding to these packet formats, byte-by-byte.

p. 194

TTLs of 0 seem to cause problems with some name servers, and 1 is probably the best value to use for ``as little caching as possible''.

pp. 196-7

In fact, authority need not be delegated on network IDs: since if RIPE (for example) has two Class A sized blocks of Class C addresses which it manages (194.x.y.z and 195.x.y.z), it would make sense for 194.in-addr.arpa and 195.in-addr.arpa to be delegated to RIPE by the NIC. It might then sub-delegate Class `B' sized blocks to individual countries, and so on.

However, delegation does have to take place on byte boundaries. So some-one who obtains a ``super-C'' of 16 class C addresses under CIDR, say 195.1.16.x to 195.1.31.x, still needs 16 delegations, e.g. 16.1.195.in-addr.arpa from the owner of the network 195.1, i.e. the DNS sub-tree 1.195.in-addr.arpa. In practice, this is not much work once the delegation has been obtained, but is easily over-looked. Conversely, some-one with a ``sub-C'' allocation has to have delegations for each IP address.

Put bluntly, in-addr.arpa and sub-netting/CIDR do not go smoothly together. See RFC 2050 for a description of how the process is managed. RFC 2317 provides a technique for circumventing the problem that the owners of non-octet boundary subnets cannot manage their in-addr.arpa space: essentially we create a CNAME record for each machine (although Stevens does not show this, there is no reason why we can't have four levels below in-addr.arpa), pointing to a new object in this domain (one per subnet, and describing how the subnet is laid out, e.g. 0/26.x.y.z.in-addr.arpa for a subnet holding addresses $0\ldots63$ of z.y.x.0), which has an NS record pointing to servers of the owners of the relevant subnet. This requires no modification to the DNS lookup mechanism⁴¹. Since a CNAME cannot point to a CNAME, though, we cannot apply the trick recursively, i.e. a owner of one of these subnets cannot sub-allocate using this trick.

p. 197

If we analyse the performance of compression on the response in figure 14.3 (p. 203; details shown in p.204), we see that the compressed format would have 213 bytes⁴², whereas the uncompressed version (still legal -- a server does not need to compress) would be 332 bytes⁴³.

p. 201

There are many more kinds of DNS records than are discussed here: 47 in the latest on-line update to the Assigned Numbers RFC. RFC 2535⁴⁴introduced KEY records for storing public key encryption parameters, SIG records for signing the data held in a DNS zone, and NXT records to authenticate the non-existence of a record in a domain.

p. 201

CNAME records are very heavily used for WWW servers: it has become instinctive to type http://www.anything. Hence a company may start out with one machine on the Internet (startup.co.uk), with a CNAME of www.startup.co.uk, and grow that to a dedicated machine (possibly called www.startup.co.uk, but preferably called www1.startup.co.uk, with a back-up machine called www2.startup.co.uk), and then to a series of web servers, using ``round-robin'' in BIND to share the load between them.

p. 207

Stevens states that ``caching can reduce the number of packets exchanged [in Figure 14.16]''. In fact, if there were no caching, the exchange in 6/7 would be repeated before 10/11. The diagram also assumes that the root servers know the client's/server's name server address directly, which is unlikely in practice, since the root servers generally do not practise recursion. Caching will certainly help here, though, as name-severs for uk. are likely to cache most of ac.uk., and research-active universities elsewhere in the world are likely to know a server for ac.uk. from their cache, rather than having to go via a root server and uk.. Equally, some root servers know about org. directly, and some serve .arpa, or even .inaddr.arpa directly.

root servers

On 28.5.2002, the root name servers seemed to be distributed as follows:

a.root-servers.net

seems to be at Network Solutions Inc. (who run the root zone) in the States.

b.root-servers.net

is at isi.edu, which runs IANA and RFC-editor.

c.root-servers.net

is in PSI.net (? near Chicago).

d.root-servers.net

appears to be at the University of Maryland.

e.root-servers.net

appears to be in Qwest.

f.root-servers.net

appears to be at ISC.org - Internet Software Consortium(producers of BIND, the main DNS for UNIX).

g.root-servers.net

also appears to be in Qwest, or parts of MILNET beyond Qwest.

h.root-servers.net

appears to be in MILNET.

i.root-servers.net

is in Sweden (probably originally connected with Craig Partridge, now operated by Netnod.se).

j.root-servers.net

seems to be at Network Solutions in the States.

k.root-servers.net

seems to be at LINX (London INternet eXchange).

l.root-servers.net

seems to be at ICANN.

m.root-servers.net

seems to be in Japan.

general

A good comment on DNS performance from Barry Margolin (barmar@bbnplanet.com): ``We're primary or secondary for over 30,000 domains. Our servers are Sun Ultra 1's with 450MB RAM. The named process is using about half of this.'' Later: ``150-200 queries/sec on our three authoritative servers, if I'm interpreting the statistics correctly. And our regional caching servers handle 200-300 queries/sec.''