ITS wiki

The Incompatible Timesharing System

User Tools

Site Tools


Chaosnet support in BIND

Earlier versions (e.g. 9.3.1) of BIND (the standard DNS server on the Internet) only supported the Chaosnet class as a kludge to handle queries for server software version etc (see documentation). With the support for Chaosnet for ITS, it would be nice to support Chaosnet in DNS. It turned out to be fairly easy to add support for A (address) resource records.

The Chaosnet support is now included in the standard distribution of BIND (as of version 9.4).


The official documentation hasn't been updated yet, so here is some.

Textual format of A entries:

name class type net/domain address (octal)
MD.dom1 CH A CH-ADDR.dom2 3141

where net/domain is the Chaosnet (domain) where the address belongs (Chaosnet is a LAN, not an internet). This should be used both to see whether the address is useful for the client (which should be on the same net) and for address-to-name lookups corresponding to IN-ADDR.ARPA - in this case,

 3141.CH-ADDR.dom2 	CH 	PTR 	MD.dom1 

Of course the “CH-ADDR” label can be just any legal DNS label, and dom1 and dom2 can be the same or not.

The binary resource record format is the net/domain name followed by the 16-bit address (as specified by RFC1034).

BIND config

To use the Chaos class in BIND, you need two things as a minimum: a zone declaration in your named.conf file, and the zone file itself. Unfortunately there is another complication: BIND enforces separation of classes, which forces you to keep IN and CH data for the same host in different files, and to wrap your Chaos zone in a view declaration. (Because of this, the occurrences of “CH” in the zone file example below are redundant.)

Example zone declaration in a view in named.conf:

    view "chaos" CH {
      match-clients { any; };
      zone "" CH {
    	  type master;
    	  file "";

If you have secondary name servers for your Chaosnet data, you need to add explicit notification configuration, since bind will otherwise try to contact the secondary servers over Chaosnet, and fail since bind itself does not run over Chaosnet (yet ;-)).

In that case, try something like

    view "chaos" CH {
      match-clients { any; };
      zone "" CH {
    	  type master;
    	  file "";
          notify explicit;
          also-notify {; };

where is the IP address of your secondary name server.

Example contents of the zone file

Note that the class indicator “CH” is redundant since the zone and view specify that already.

    @	SOA	localhost.	root.localhost. (	2005050702
    						1H )
    	NS	localhost.	

    ;; A Chaos A record has two parts:
    ;; - the domain/network of the address (Chaosnets are LANs - the address is local to the net),
    ;; - the (octal!) address itself
    ;; Without ending ".":s, the domain defaults to $ORIGIN which defaults to the zone name,
    ;; so "MD" means "" and "CH-ADDR" means ""
    	A	CH-ADDR 3141

    ;;; PTR records to find names from addresses.
    3141.CH-ADDR PTR MD

Note that once you add the view for CH, you'll have to add one for the IN zones too. Wrap them all in, e.g.,

    view "default" IN {
      match-clients { any; };


Write a DNS forwarder for Chaosnet, so you can pretend to have a Chaosnet DNS server on your ITS system. Need to check how the protocol was done in e.g. Symbolics systems.

chaos-dns.txt · Last modified: 2018-04-24 17:21 by victor