Providing content DNS service

The Internet Utilities contains four dæmons that provide DNS content service:

• The Generic Content Server and the Zone Transfer Content Server provide generic UDP and TCP name service, respectively. The can serve any sort of records to clients (including zone transfers in the case of the latter). The records that they serve are read from a database maintained by an administrator.

• The Fixed-data Content Server provides opaque name service and name service for dotted-decimal names, he latter as a means for reducing the impact of broken clients on the rest of Internet. It serves clients with two-way mappings between IP addresses and domain names, and with one-way mappings from oft-used but non-existent domain names to IP addresses. It calculates the domain names from the IP addresses, and does not use a database.

• The Text Content Server provides name service for TXT records, in the style used by organisations such as MAPS and ORBS. The text records are read from a database which stores TXT records more efficiently than the database for the generic name server.

Type of service provided by content servers

The content servers respond

• "refused" to incoming packets
  • that are responses rather than queries,
  • that contain resource records,
  • that do not contain exactly one question,
  • that are marked as truncated, or
  • that have an operation code other than "query";
• "bad format" to incoming packets that they cannot decompress;
• "not implemented" to incoming packets that contain questions asking about DNS classes other than "Internet"; and
• "server failure" if there is an internal error processing the packet.

All other responses depend from the contents of the database or whether the server knows how to generate the answers itself.

The content servers will respond "no such domain" to unrecognised names. This happens to help combat the problem of incorrect delegations.

Content servers can return either complete or partial responses. Only the Generic Content Server and the Zone Transfer Content Server provide referrals. The Fixed-data Content Server, and the Text Content Server all serve leaf domains on the content server graph, and so do not provide referrals.

To avoid truncation of a DNS/UDP response that would normally exceed the DNS/UDP datagram size limit, the content servers will first eliminate all of the "additional" section resource record sets. Only if that fails to reduce the response size to within the size limit, will the content servers eliminate all of the resource record sets and set the "truncated" flag in the response header to 1 .

The content servers do not eliminate "authority" resource record sets from responses in lieu of truncation, because that can change the semantics of a response from a referral into an enpty resource record set response.

Security

The primary purpose of content servers is to serve Internet at large. They are expected to be configured to listen on a public IP address.

The content servers do not execute programs based upon any data received from Internet, or indeed run any other programs at all. They can safely be run on a machine residing outside of a firewall.

In order that clients can recognise their responses as responses, the content servers send all responses from the same socket on which the original queries were received.

Resource usage

These servers are designed so that their memory requirements should remain constant over time. They generate their answers afresh or read them from a database with each request and do not cache any previous results in memory. (However, the operating system itself will of course cache the files comprising the database.)

Hosting one's own public domain

Suppose that one owned the domain some.corp. in the public DNS. Here is how to host that domain on one's own machines using the Internet Utilities:

• Set up an instance of the General-purpose Content DNS Server listening on a public IP address that is accessible from Internet at large, a.b.c.d .

• In this General-purpose Content DNS Server's database create a some.corp. "zone" source file. In that file place a nameserver record:

  nameserver some.corp. 604800 ""
    0       # priority 0
    0       # weight 0
    53      # must have this value for public content DNS service
    ""      # use an auto-generated intermediate name
    a.b.c.d  # the public IP address you chose above
    ;

• Add any other information about the domain to that file that you wish to publish to the world. For example, you may want to publish information about your Content HTTP and SMTP Relay servers, which are primarily on IP addresses e.f.g.h and i.j.k.l, with a 60/40 load balancing split, but fall back to IP address m.n.o.p in the events of server outages:

  # Record for new-style HTTP clients:
  service _http._tcp.some.corp. 604800 ""
    10 60 80 "" e.f.g.h ,
    10 40 80 "" i.j.k.l ,
    20 0 80 "" m.n.o.p ;
  
  # Old-style HTTP clients need a rôle hostname
  # and won't do load balancing or predictable fallback:
  hostfwd www.some.corp. 604800 "" e.f.g.h ;
  hostfwd www.some.corp. 604800 "" i.j.k.l ;
  
  # Record for new-style SMTP Relay clients:
  service _smtp._tcp.some.corp. 604800 ""
    10 60 25 "" e.f.g.h ,
    10 40 25 "" i.j.k.l ,
    20 0 25 "" m.n.o.p ;
  
  # Record for old-style SMTP Relay clients:
  mailhub some.corp. 604800 ""
    10 60 25 "" e.f.g.h ,
    10 40 25 "" i.j.k.l ,
    20 0 25 "" m.n.o.p ;

• Contact the administrators of the parent domain corp. and tell them to add, to the databases of their content servers, a referral that directs clients to the nameserver named a.ns.some.corp. with the IP address a.b.c.d for any names within the domain some.corp.. If they are using the the Internet Utilities, they just copy the nameserver record given above.

Anonymous sites

Where an organisation wishes to have machines connected to Internet but does not wish either the names of (or even the number of) those machines to be known to the outside world, the Fixed-data Content Server can be combined with the General-purpose Content DNS Server as the publically accesible DNS servers in the manner described here. This provides name service without providing meaningful information about the zone.

To the rest of Internet it will appear that all IP addresses, even unused ones, have matching hostnames. The rest of Internet will thus have no meaningful information about the number of hosts actually within the domain or what IP addresses are actually assigned. Also, because the Fixed-data Content Server does not support zone transfers, attackers cannot obtain a list of the hosts in the domain by requesting zone transfers.

Here is how to do this for the domain "some.corp." such that all of the hosts within "some.corp." will have opaque names within the domain "hosts.some.corp.", with both forward and reverse lookups available to the rest of Internet:

• Set up an instance of the Fixed-data Content Server listening on a publically accessible IP address that is accessible from Internet at large, a1.b1.c1.d1 . Instruct the server to serve the domain hosts.some.corp. by passing it the /DOMAIN:hosts.some.corp. option on its command line.

• Set up an instance of the General-purpose Content DNS Server listening on a second publically accessible IP address that is accessible from Internet at large, a2.b2.c2.d2 .

• Choose a hostname, srv1.ns.some.corp. to correspond to the IP address a2.b2.c2.d2 .

• In the General-purpose Content DNS Server's database place:

  • An A record for srv1.ns.some.corp. giving the IP address a2.b2.c2.d2 ;
  • An NS record for some.corp. giving the name srv1.ns.some.corp.;
  • A PTR record for d2.c2.b2.a2.in-addr.arpa. giving the name srv1.ns.some.corp.;
  • An MX record for some.corp. giving the opaque name of the mailserver machine, which will be of the form d3.c3.b3.a3.hosts.some.corp.;
  • An NS (referral) record for hosts.some.corp. giving the opaque name of the opaque name server d1.c1.b1.a1.hosts.some.corp.; and
  • An A (glue) record for d1.c1.b1.a1.hosts.some.corp. giving the IP address a1.b1.c1.d1 .

  In other words:

  nameserver some.corp. 604800 "" 10 0 53 srv1.ns.some.corp. a2.b2.c2.d2 ;
  service _smtp._tcp.some.corp. 604800 "" 10 0 25 "" a3.b3.c3.d3 ;
  mailhub some.corp. 604800 "" 10 0 25 "" a3.b3.c3.d3 ;
  hostrev srv1.ns.some.corp. 604800 "" a2.b2.c2.d2 ;
  nameserver hosts.some.corp. 604800 "" 10 0 53 d1.c1.b1.a1.hosts.some.corp. a1.b1.c1.d1 ;

• Contact the administrators of the parent domain corp. and tell them to add, to the databases of their content servers, a referral that directs clients to the nameserver named srv1.ns.some.corp. with the IP address a2.b2.c2.d2 for any names within the domain some.corp..

• Contact the administrators of the parent (reverse) domain(s) b1.a1.in-addr.arpa. (or whatever is appropriate) and tell them to add a referral to the databases of their content servers that directs clients to the nameserver named d1.c1.b1.a1.hosts.some.corp. with the IP address a1.b1.c1.d1 for any names within the domain c1.b1.a1.in-addr.arpa..

Providing service for large homogenous IP blocks

One may have large IP blocks where the choice of hostnames is irrelevant, as long as they have names of some sort. A typical case of this would be an ISP with an IP block for its customers that are assigned IP addresses dynamically via DHCP or via dial-up connections. Mainintaining the hostnames of the IP address block by hand in the database for a General-purpose Content DNS Server would be tedious and error prone. It could also involve quite a large database if the address range is large.

As long as the IP blocks do not need customized DNS data, which is very rarely the case, there is an easier way of providing content service in such situations. (Note: This refers to the actual IP addresses themselves, not to the customers using them or their machines.)

Here's how to serve names for the dial-up ports with IP addresses in the range a.b.*.* for the ISP with domain some.isp.:

• Set up an instance of the Fixed-data Content Server listening on a publically accessible IP address that is accessible from Internet at large, a.b.c.d . Instruct the server to serve the domain dialup.some.isp. by passing it the /DOMAIN:dialup.some.isp. option on its command line.

• To the database of the content server for the domain some.isp. add:

  • An NS (referral) record for dialup.some.isp. giving the opaque name of the opaque name server d.c.b.a.dialup.some.isp.; and
  • An A (glue) record for d.c.b.a.dialup.some.isp. giving the IP address a.b.c.d .

  In other words:

  nameserver dialup.some.corp. 604800 "" 10 0 53 d.c.b.a.dialup.some.isp. a.b.c.d ;

• Contact the administrators of the parent (reverse) domain(s) b.a.in-addr.arpa. (or whatever is appropriate) and tell them to add a referral to the databases of their content servers that directs clients to the nameserver named d.c.b.a.dialup.some.isp. with the IP address a.b.c.d for any names within the domain c.b.a.in-addr.arpa..

This causes the dial-up port with the IP address a.b.2.3 to automatically have the hostname 3.2.b.a.dialup.some.isp. without needing to list it explicitly in a database or a configuration file. Mappings in both directions also work. In particular, this allows dial-up clients to happily connect to wrongly written servers that perform reverse lookups in a misguided attempt to be secure.