Background Info

Background Information

We first describe the DNS protocol in a bit more detail, then the binary protocol over the wire, and the zone file format.

DNS entry types

The domain name system serves different protocols by having different entry types. Each entry has a time-to-live associated with it, meaning how long this entry might be cached:

  • Each domain has metadata about itself – the so called “start of authority” (SOA) record: a hostmaster, a serial number, caching information (refresh, retry, expire, and minimum times).

  • DNS contains the information about which name servers are responsible for a given domain name (via the NS record).

  • Translation of a domain name to an IP address (an A record),

  • Translation of an IP address to its domain name (PTR – domain name pointer).

  • Other entry types of interest are MX, the mail exchange, which additionally contains a priority ordering of mail servers (as a 16 bit number in the so called preference field).

  • A TXT record contains plain text.

  • A CNAME record contains a delegation of one domain name to another domain name.

Protocol Format

The DNS binary protocol is stateless. Each DNS frame consists of bit fields, which can be further categorized into:

  1. a header, containing information about what kind of query or answer the frame carries,

  2. a query section,

  3. an answer section,

  4. an authority section, and

  5. an additional records section.

The concrete header format is described in the RFC in section 4.1.1 (https://tools.ietf.org/html/rfc1035#section-4.1.1). The header has a fixed length of 12 bytes and contains numbers that specify the amount of query, answer, authority and additional records.

We require only the presence of a query section and an answer section. The answer sent from the name server contains both the authoritative answer and the query.

The resource records in the different sections share a common structure: a domain name, a type and a class.

Queries contain only these three fields, while other records might contain additional information. This is also described in the RFC (https://tools.ietf.org/html/rfc1035#section-4.1.2 and following).

Domain names and their Compression

Domain names are split at each “.” character into a sequence of labels (thus, the domain name www.vscomp.org is split into 3 labels: www, vscomp and org). Each of the labels is encoded and decoded into a byte containing the length of the entry (3, 6, 3) followed by the actual data. The end of a domain name it is terminated with an empty string (length 0).

Many domain names share a common suffix, especially in answer frames. To save bandwidth, a compression mechanism is applied. Each domain name is a (possibly empty) sequence of labels, followed by a pointer to the common suffix inside of the DNS frame. To achieve this, a label starts with 2 bits which indicate whether it is a pointer or an actual label. An actual label starts with 00, followed by 6 bits which encode the length of the subsequent domain name in bytes. If the label starts with 11, it is a pointer, the next 14 bits indicate the byte-offset into the DNS frame where to look for the suffix. This points to a sequence of labels, which might be followed by a pointer to the common suffix. The compression mechanism is described in detail in the RFC https://tools.ietf.org/html/rfc1035#section-4.1.4.

Implementation of compression (and decompression) is mandatory.

An example from the RFC follows.

For example, a datagram might need to use the domain names F.ISI.ARPA, FOO.F.ISI.ARPA, ARPA, and the root.  Ignoring the other fields of the message, these domain names might be represented as:

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
20 |           1           |           F           |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
22 |           3           |           I           |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
24 |           S           |           I           |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
26 |           4           |           A           |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
28 |           R           |           P           |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
30 |           A           |           0           |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
40 |           3           |           F           |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
42 |           O           |           O           |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
44 | 1  1|                20                       |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
64 | 1  1|                26                       |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
92 |           0           |                       |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

The domain name for F.ISI.ARPA is shown at offset 20.  The domain name FOO.F.ISI.ARPA is shown at offset 40; this definition uses a pointer to concatenate a label for FOO to the previously defined F.ISI.ARPA. The domain name ARPA is defined at offset 64 using a pointer to the ARPA component of the name F.ISI.ARPA at 20; note that this pointer relies on ARPA being the last label in the string at 20. The root domain name is defined by a single octet of zeros at 92; the root domain name has no labels.

Zone File Format

The zone file format uses a colon-separated file format, one entry per line. Empty lines and lines beginning with a ‘#’ should be ignored. This file format is a clear subset of the zone file format used by djbdns (http://cr.yp.to/djbdns.html). We assume 7 bit US-ASCII encoding.

We have already described different entry types. In the zone file, the first character determines the type. We describe each possible entry line, followed by records it produces. Colon is a separator and might not be used inside of the fields. Each entry consists of at least one domain name (here “fqdn” – fully qualified domain name). The “ip” field is an IPv4 address in decimal dotted notation (like 10.0.0.1). Some fields are optional, indicated by square brackets. Records using optional fields which are not present are not produced, unless otherwise stated. The time-to-live (ttl) field is always last and optional, and its default value for this task is 86400 seconds. Colons are always mandatory (in contrast to the original, underspecified djbdns format).

 

  • .fqdn:[ip]:x:ttl
    • an NS (“name server”) record showing x as a name server for fqdn;
    • an A (“address”) record showing ip as the IP address of x; and
    • an SOA (“start of authority”) record for fqdn listing x as the primary name server and hostmaster@fqdn as the contact address. The serial is the modification time of the file (in seconds); refresh defaults to 16384 seconds, retry to 2048 seconds, expire to 1048576 seconds, and minimum to 2560 seconds.

     

  • Zfqdn:primary-name-server:hostmaster:serial:refresh:retry:expire:minimum:ttl
    • SOA record for fqdn. serial, refresh, retry, expire, and minimum may be omitted; they default to, respectively, the modification time of the file (in seconds), 16384 seconds, 2048 seconds, 1048576 seconds, and 2560 seconds.

     

  • &fqdn:[ip]:x:ttl
    • an NS record showing x as a name server for fqdn and
    • an A record showing ip as the IP address of x.

     

  • =fqdn:ip:ttl
    • an A record showing ip as the IP address of fqdn and
    • a PTR (“pointer”) record showing fqdn as the name of d.c.b.a.in-addr.arpa if ip is a.b.c.d.

     

  • +fqdn:ip:ttl
    • An A record showing ip as the IP address of fqdn.
    • This is just like =fqdn:ip:ttl except that no PTR record is produced.

     

  • ^fqdn:p:ttl
    • PTR record for fqdn. tinydns-data creates a PTR record for fqdn pointing to the domain name p.

     

  • @fqdn:[ip]:x:dist:ttl
    • an MX (“mail exchanger”) record showing x as a mail exchanger for fqdn at distance dist and
    • an A record showing ip as the IP address of x.

     

  • ‘fqdn:s:ttl
    • TXT (“text”) record for fqdn. tinydns-data creates a TXT record for fqdn containing the string s.

     

  • Cfqdn:p:ttl
    • CNAME (“canonical name”) record for fqdn. A CNAME record for fqdn pointing to the domain name p is generated.

     

Compositionality of Solutions

To achieve compositionality between solutions, we strongly encourage each solution to support the following request format for lookups:

Use the character from the zone file format prefixed by a question mark for a query (?+ns.vscomp.org).

The answer is exactly in the zone file format (+ns.vscomp.org:10.0.0.1:86400).

4 Comments

Comments RSS
  1. Andrei Paskevich

    The “Compositionality of Solutions” section is unclear. UDP datagrams containing DNS queries do not use question marks. Are we supposed to design/implement/verify some other interface to our server that supports this kind of queries ?

    • Hannes Mehnert

      You are not required to verify this interface – but this interface is used in our example data. If you define an interface between the parser and data provider, our proposal would be this text representation.

  2. Andrei Paskevich

    The examples you give suggest the following interpretations of some fields:
    1. “x”, “p”, “primary-name-server”, and “hostmaster” are fully qualified domain names
    2. “dist” is an unsigned 16bit integer

    Is this correct?

    (We ask, because the examples on the djbdns site use strings for “dist” and incomplete domain names, relative to the record owner.)

    • Hannes Mehnert

      Yes, both statements are correct. There is no support for incomplete domain names.

Leave a Comment