To address both an important need and a serious problem
Prior to the middle 1980's all machines connected to the ``internet'' used a common HOSTS.TXT file that provided all the hostnames and addresses in use. The file was flat and hostnames had to be unique in the file. As the number of hosts attached to the internet began to grow at an increasing rate, the central HOSTS.TXT file became more and more of a problem.
The need was ``host address translation''
- Humans use host NAMES because that is what they can remember
  When a user types a hostname into some application, a resolution must occur before the requested host can be contacted. With the hosts file, one could simply search the file for the given hostname and utilize the corresponding address.
  - ``Forward Lookups'' resolve hostnames into IP addresses
- Machines use host NUMBERS (IP addresses)
  For machines to actually communicate with eachother they need to use IP addresses. Hostnames must be resolved into IP addresses before those machines can send traffic back and forth. Some applications require that hostnames and IP addresses point to each other exclusively for security reasons. Obtaining a hostname from an IP address is thus required.
  - ``Reverse Lookups'' resolve IP addresses into hostnames
The problem was one of SCALE
- Originally a master HOSTS.TXT file was used
  - Similar in format to the modern /etc/hosts file
  - Maintained by a central authority
  - Every other host on the 'Net FTP'd the hosts file from the central server
- The hosts file became too large to easily download
- The number of machines trying to download the file was too much for one server to handle
DNS was thus defined to provide everything that the HOSTS.TXT file provided
- But to do so in way that didn't rely on a single file or server
- It had to be a Distributed Database of some kind
Original specifications for DNS are RFCs 882 and 883 (1983)
- Superceded by RFCs 1034 and 1035 (1987)
- Written by Paul Mockapetris
- There are dozens of other RFCs extending or relating to DNS

Solving the problem of scale

The key is to have globally distributed database
- No single machine would or could store all the data
- This solves both the ``large hosts file'' problem AND the ``single machine bottleneck'' problem
- Individual organizations are responsible for their own portion of the database
  - Special GLUE information is needed to connect the various portions

Original intent was to replace the HOSTS file

DNS still provides NAME to ADDRESS translation
Subsequently expanded to handle other related data such as:
- Host information like physical location or hardware type
- Email delivery information

Newest implementations offer additional features like:

Security to guarantee authentic data
Dynamic updates to the Database

Domain Name Space

The DNS distributed database framework

Information is indexed by Domain Name
The tree of domain names together is called the Domain Name Space

NODES in the tree have labels called Domain Names

Domain Names consist of up to 63 characters
- Case-insensitive, but most implementations propagate case
- Alphanumeric characters and the '-' (hyphen) character are allowed
- Shorter names are helpful for poor typists
Sibling nodes MUST be unique
- This rule makes the entire Name Space collision-free
Leaf nodes' labels are still Domain Names
- Although most people usually just call them hostnames

Fully-Qualified Domain Names (FQDNs)

Each node name from a leaf node to the root concatenated with dots
```
  bfs.cs.colorado.edu
```
Officially, the root node has a name of the NULL string
```
  bfs.cs.colorado.edu.NULL
```
Because the NULL string is usually denoted by a blank, an FQDN is sometimes shown with a trailing dot
```
  bfs.cs.colorado.edu.
```
- Some application software gacks if you use the trailing dot when specifying FQDNs
FQDNs uniquely locate nodes in the Name Space
- Not unlike an absolute pathname in the Unix filesystem hierarchy
There may be at most 127 nodes in an FQDN
- Unlikely to ever be a limitation

A Domain is just a sub-tree of the Name Space

Officially, this includes the FQDN of the node at the top of the sub-tree and ALL of its children
cs.colorado.edu IS in the colorado.edu domain; both are in the edu domain
Colloquially, the term 'domain' usually means 'zone'
- A Zone is a Domain without its sub-domains
  - i.e. no children that aren't leaf nodes
  - But this isn't always true (discussed below)
- cs.colorado.edu, colorado.edu, and edu are all seperate zones

The in-addr.arpa. domain

This sub-tree is used for reverse lookups
- i.e. to resolve an IP address into a Hostname

Zones, Delegation and Authority

Authority for a zone is Delegated by the parent zone

e.g. the Root zone delegates authority for the edu zone to the folks who maintain the data for the edu zone
- The edu zone delegates authority for the colorado.edu zone to admins for the University of Colorado
- The colorado.edu zone in turn delegates authority for the cs.colorado.edu zone to the CS Department admins
Delegation of Authority means exactly that some parent name server has data records that associate a given child zone with specific name servers

A zone can include its sub-domains

A zone is that portion of a Domain Name Space sub-tree that is managed by a single entity. Note that this definition might include sub-domains of the parent if those domains have not been delegated.

Sub-domains are in the parent zone if no glue data records exist that delegate authority to the sub-domain
This may depend on the size of the sub-domain and/or the desire of that sub-domain's admins. Large, active sub-domains might require their own zone management, while small or un-used sub-domains can be administered just as well by the parent domain.

The Bind Documentation defines a zone as follows:
```
   a zone is a point of delegation in the DNS tree.  A zone consists of
   those contiguous parts of the domain tree for which a name server has
   complete information and over which it has authority.  It contains
   all domain names from a certain point downward in the domain tree
   except those which are delegated to other zones.  A delegation point
   is marked by one or more NS records in the parent zone, which should
   be matched by equivalent NS records at the root of the delegated zone.
```
See below under Resource Records for more information about NS records.
- For example, a corporation foo.com might have separate domains for each of its corporate branches
  - sales.foo.com and office.foo.com get administered together in the same zone as foo.com by the main office admins
  - research.foo.com likes to do their own thing so they manage their sub-domain themselves as a separate zone

Zone authority usually includes at least two zones

When authority is delegated for a domain, the in-addr.arpa. sub-domain is also delegated
- The Forward Zone contains the hostnames
- The in-addr.arpa. sub-domain contains the IP addresses
  - Typically called the Reverse Zone
  - Usually each seperate subnet of an organization has its own reverse zone
    This is done despite that fact that all the hostnames involved are in a single Forward zone. The issue is one of organization of the DNS database zone files which we talk about further below. For example, the CS department's host are all in the 'cs.colorado.edu' forward zone, but each subnet (e.g. the 128.138.202/24, the 128.138.192.0/24, etc) has its own reverse zone. This makes more sense if you actually draw out the in-addr.arpa sub-trees involved - you'll see that the reverse zones are often distinct sub-trees; that they aren't always adjacent in terms of sibling nodes. For example, the CS department has authority over the 128.138.192.0/24, the 128.138.193.0/24, and the 128.138.198.0/24. But we do not have authority over the zones in between, like 128.138.195.0/24.
The term 'zone' often refers to both the forward and reverse zones together

DNS Queries

In a nutshell:

DNS Clients contact local DNS Name Servers for host address resolution
- These queries specify a hostname or IP address and expect (usually) the opposite value in return
Local DNS Servers may be authoritative for local names and addresses
- If they are, they respond directly to the queries with the relevant answers
- All other queries must be re-transmitted to name servers that are authoritative for the information requested
  - Exactly how this process works lies at the heart of DNS as a robust, distributed database

Queries come in two flavors

Recursive Queries are made by client applications
- The application makes a query and expects an answer or an error returned back
  - Client applications typically don't have the code to deal with answers that refer the client to another name server
- These queries are called recursive because it is expected that if the name server contacted doesn't already know the answer, then it will ask some other name servers until it gets the answer
Non-recursive queries are made by Name Servers
- The name server may get an actual answer back
- The name server may instead get a 'referal'
  - A referal means ``I don't know the answer, but here is the address of a name server that might know''
  - The name server then follows the referal and sends its query to the indicated address
Some name servers refuse to answer recursive queries
- Notably, the ROOT name servers always answer with referals

Here is how a query might get resolved:

I point my desktop browser at www.cs.berkeley.edu
A recursive query is sent to my local name server
- ``What is the IP address for www.cs.berkeley.edu?''
Local name server sends the query to a ROOT name server
- And gets back a referal to an edu zone name server
Local name server sends the query to the edu name server
- Gets back a referal to a berkeley.edu zone name server
Local server sends the query to the berkeley.edu name server
- Gets back a referal to a cs.berkeley.edu zone server
Finally, the query is sent to the cs.berkeley.edu server
- And the IP address for www.cs.berkeley.edu is returned
The local server returns the answer to my desktop computer

Resource Records

All data in the DNS is kept in Resource Records

There are dozens of record types but only a handful are used to any great extent
Two important record types are categorized as 'zone' records
```
  SOA    "Start of Authority" record
```
- Indicates the beginning of a zone and it should occur first in a zone file
- There can be only one SOA record per zone
- Defines certain values for the zone such as a serial number and various expiration timeouts
```
  NS     "Name Server" record
```
- Defines an authoritative name server for a zone
- Defines and delegates authority to a name server for a child zone
- NS Records are the GLUE that binds the distributed database together
```
 I  categorize the most common records as 'host' records
```
- Simply because they deal with host address information
- The Purple Book calls them 'basic' records
```
  A      Address record
```
- The A record simply maps a hostname to an IP address
- Zones with A records are called 'forward' zones
```
  PTR    Pointer record
```
- The PTR record maps an IP address to a Hostname
- Zones with PTR records are called 'reverse' zones
```
  CNAME  "Canonical Name" record
```
- The CNAME record maps an alias hostname to an A record hostname
```
  MX     "Mail eXchange" record
```
- The MX record specifies a host that will accept email on behalf of a given host
  - The specified host has an associated priority value
- A single host may have multiple MX records
  - The records for a specific host make up a prioritized list
  - The LOWEST priority host is tried first
  - If delivery cannot be made to that host then the next lowest priority host is tried, and so on
- The idea is that the lowest priority host is the final destination for the email
  - Higher priority valued hosts hold the email until it can be sent to the final destination
- It used to be that MX records were optional
  - A host without an MX record was considered to have an MX record only for itself
  - Modern Mail Transport Agents (like sendmail) can be configured to NOT deliver email to hosts if they don't have MX records
Another category of record types is 'security'
- These records are for new features designed to guarantee authenticity of zone data
```
  KEY     Public Key record
```
- The KEY record is used to associate a public key with a DNS name
```
  NXT     Next record
```
- The NXT record is used to handle negative answer caching
  - i.e. answers like ``host xyz doesn't exist in zone foo''
```
  SIG      Signature record
```
- The SIG record is used to cryptographically sign zone data
All the resource records shown above will be illustrated further
- Including record format syntax, when we look at zone files
There are many other records, see the RFCs or Bind doc

The 'nslookup' command is used to retrieve Resource Records (RRs)

The most basic usage just asks for an A, CNAME or PTR record
```
  % nslookup  <domain-name>
```
- The record type is determined by context (if the <domain-name> is a hostname or an IP address)
- The nslookup command uses the name servers specified in /etc/resolv.conf
  - You can specify a different server like so:
```
  % nslookup  <domain-name>  <server>
```

nslookup enters an interactive mode if you don't specify a domain-name:

  coatl % nslookup 
  Default Server:  mroe-fs.cs.colorado.edu
  Address:  128.138.242.197

You can specify a different server if you want to:

  coatl % nslookup - suod-fs
  Default Server:  suod-fs.cs.colorado.edu
  Address:  128.138.242.200

Type 'exit' or <CNTL> D to exit nslookup
The default in interactive mode is to ask for an A, CNAME or PTR record
- Just like the command-line default
- To send a query, just type in a domain name:
```
  > bfs
  Server:  suod-fs.cs.colorado.edu
  Address:  128.138.242.200
```
```
  Name:    bfs.cs.colorado.edu
  Address:  128.138.202.9
```
```
  >
```

You can tell nslookup to query for different record types:

  > set type=MX
  > bfs
  Server:  suod-fs.cs.colorado.edu
  Address:  128.138.242.200

  bfs.cs.colorado.edu  preference = 10, mail exchanger =
                                  nago.cs.colorado.edu
  bfs.cs.colorado.edu  preference = 99, mail exchanger =
                                  cs.colorado.edu
  ...

Queries for MX records return all associated MX records
Also returns NS authority records (not shown)
Also returns A records for all hosts referenced in the MX or NS records

Name Servers

A name server is a daemon process that answers DNS queries

They come in three basic types: Primary, Secondary, and Caching

Usually there is one Primary name server for a zone

a.k.a. Master or Primary Master
The Primary server loads DNS zone data from text files stored on local disk
The term 'zone' here refers to both the forward and corresponding reverse zones

Most sites have one or more Secondary name servers

a.k.a Slave or Secondary Master
The Secondaries load DNS zone data by contacting the Primary server
- All the data for the zone is transferred at one time (called a Zone Transfer)
  - New implementations of DNS support an Incremental Zone Transfer where only modified portions of the zone data are transferred
Secondaries know to get new data by comparing the SOA record serial numbers between their cached copy and the Primary

A third type of name server is the Caching server

Caching servers don't serve data for a specific zone
The caching server just remembers all of the answers for queries it has made
- Increases network efficiency because repeated queries don't need to be made; the cached answer can be used instead

One name server can play all three roles

The server can be Primary for some zones, Secondary for others and also Cache all other query data

A final category of name server is the Stealth Server

By definition, stealth servers DON'T have NS records pointing at them
- They cannot be used through normal DNS procedures
- They are not compliant with DNS RFC specifications
- You have to know the server's IP address to use it
  Despite being non-RFC-compliant, stealth servers are in common use and there is every reason to do so. These servers can reduce the overall traffic load on local your network infrastructure and there is no need for the rest of the world to use them or even know about them.
  
  Additionally, there is no reason stealth servers can't also be authoritative. Their 'stealthness' simply means that parent-zone NS records don't reference them.
Stealth servers are perfect for providing DNS in a NAT'd RFC 1918 environment
- Clients use the stealth server to resolve both local, private names/addresses as well as real, public ones

Every zone must be served by an Authoritative server

Both Primary and Secondary servers are considered to be authoritative
Having more than one Primary for a zone is the bad idea
- You must manually synchronize the zone data for the two servers
You should have at least one Secondary for the zone
- This is required by the RFCs
- Frequently at least one secondary will be 'off site'
  A common arrangement between two sites (who have different ISPs) is to swap secondaries so that each provides authoritave (via a secondary server) name service for the other. This is done for overall robustness of the DNS distributed system.

Parent zone must delegate to all authoritative servers

Primary and secondary name servers for a zone should all be referenced by NS records in the parent zone
Many sites actually only have a select subset of their servers referenced by the parent zone
- The parent zone's NS records are usually used by external queries for information about the local zone
- Really only three or so are really necessary
- Allows for a stricter firewall, with DNS traffic only going to a few hosts
  That is, incoming packets with a destination TCP port number for DNS. Reply traffic with a source port for DNS is a different deal. One safer way to allow it is to use a Stateful firewall rule that works for UDP (Like the OpenBSD PF).

Name servers can be configured to Forward queries

Stealth secondaries on local subnets, for example, that can't query through the firewall
These servers cache the query answers
- But they don't learn about the intervening zones' name servers
  Non-forwarding servers will follow recursive queries, and thus end up recieving referals, thus causing subsequent queries to other name servers.
Sites will sometimes designate several beefy machine as NON-forwarding servers
- All the other servers for the site forward to those servers
- This ends up building big caches of DNS data on the beefy servers

DNS Networking Information

DNS Servers listen on TCP and UDP port 53

Note that this is a configurable value, but that is also the well-known port number on which resolver libraries (i.e. client applications) expect to find DNS servers listening. Zone transfers (when a secondary server gets an entire set of zone data from a primary server) sometimes utilize a different port (1053 seems to be common) to allow for more specific firewall rules.

Port 53 is listed under the name 'domain' in /etc/services

  coatlicue% grep domain /etc/services 
  domain          53/tcp          nameserver      # name-domain server
  domain          53/udp          nameserver

Most queries use UDP
- Single packet with query goes to server
- Single packet with answer comes back
TCP is used for Zone Transfers (explained below)
- The larger amounts of data involved make TCP a better candidate

The header is described below. Not all of the remaining sections must have any data. For queries, only the 'question' section will have anything in it. Answers to standard (A,PTR,CNAME) queries will be found in the 'answers' section. Answers that are NS records are in the 'authority' section. Answers to other queries will be in the 'additional' section.

The ID value is arbitrarily chosen by the machine that generates the query, it is propogated into server responses. The QR bit is set to one for queries, and zero for answers. The opcode has only three possible values (at this time):

   0    A standard query
   1    An inverse query
   2    A server status request
        Other values are reserved for future use

The AA bit specifies that the name server's answer is authoritative. The TC bit indicates that the message has been truncated (due to MTU length being exceeded, usually). The RD bit specifies that the query is a recursive one, that the name server should recursively query other name servers for the answer. The RA bit is set by a name server to indicate that it is willing to answer recursive queries. The Z field is reserved and currently MUST be zero. The Rcode value indicates an error condition from the responding server.

The remaining 'count' fields indicate the number of queries or answers present in the respective message fields.

Zone Files

Primary name servers load their data from 'zone files'

There is one zone-file per zone for which the server is primary
The zone file format is defined by RFC and is independent of implementation (and implementation version)
Although some Directives (not resource records) will not be recognized by different (older) implementations. Also older implementations may not recognize certain resource records (such as the security records).
Zone files are often maintained by hand
- Perhaps using an RCS-like system
- Dynamic zones (a new feature) cannot normally be updated by hand
- Remember that zone files are just plain ASCII text files

Most entries in a zone file are Resource Records

There are a few other Directives or Control statements
- Some (like $TTL) are required by RFC
- Others (like $GENERATE) are implementation dependent
Comments are indicated with a semi-colon (';')
Blank lines are ignored

The first entry in a zone file MUST be the $TTL directive

This sets the default time-to-live for zone data that the server provides
That is, the amount of time (in seconds) that remote name servers will cache data that this (the local) name server has sent them.
The syntax for the $TTL directive is simple:
```
  $TTL  7200
```
- The number of seconds is specified as an integer
  The $TTL is no longer specified in the SOA record (it used to be the 'negative answer' value).

Most Resource Records have a common 5-field format:

  [name]  [ttl]  [class]  type  data

The name is a domain-name and is sometimes optional
- The '@' (at sign) short-hand for the domain-name of the zone itself
  Although not always (the $ORIGIN directive can be used to change it).
- When consecutive records refer to the same name
  - Only the first record must specify the name
  - Subsequent records MUST start with blank space
    When names are specified they MUST start in column one of the text file.
- Unqualified names (i.e. without a trailing dot) get the zone's domain added to them
  - This is a useful short-hand, but you need to be careful
- Fully qualified names MUST have the trailing dot
  - You know you are missing a trailing dot when your server generates names like:
```
  bfs.cs.colorado.edu.cs.colorado.edu
```
The ttl field can be used to set a TTL for the record
- This is almost never present in zone files except for the $TTL directive at the top
The class field defaults to the IN class
- That is, the Internet class; it is by far the most common
- Most people specify this field in their zone files but they really don't need to
  Two other classes are CH and HS. CH was for a defunct ChaosNet project. HS was for a slightly less defunct database project called Hesiod. Both from MIT, as I recall..
The type field specifies the Resource Record type
- e.g. A or NS
The data is dependent on the record type
- For an A record it would be an IP address
- For a PTR record it would be a hostname
- For other records it might be a text or integer value

The order of resource records mostly doesn't matter

Except for the SOA record which must be the first record
Other records are simply organized in a locally logical manner
Note well, though, that named will re-order all of your records based on a canonical ordering (mostly alphabetic). The sorted records only exist in the in-RAM version of the zone on your primary. The sorting is done to enable 'negative' responses using NXT records.

The second entry in a zone file is always the SOA RR

The Start Of Authority record specifies:
- The domain-name for which the record is authoritative
  - This domain-name is called the ORIGIN
- The Primary Master name server for the zone
- The SOA also specifies a contact admin email address
  - The AT sign ('@') gets converted to a DOT ('.') in this address
A typical SOA will look like this:
```
 @ IN SOA cs.colorado.edu. admin.cs.colorado.edu. (
           20010421      ; Serial Number
              86400      ; Refresh - every 24 hours
               1800      ; Retry   - 30 minutes
            1209600      ; Expire  - 2 weeks
               7200 )    ; Negative answers - 2 hours
```
- The '@' (at sign) is short-hand for the ORIGIN (the zone for which the SOA is authoritative)
  - The configuration file for the name server associates the zone file with a specified domain name which becomes the ORIGIN
    Note that while the configuration file for the name server specifies the domain of origin (that is, the ORIGIN) for zone file that gets loaded, it can also be specified in the zone file itself. (To change what gets appended to unqualified hostnames, for example.
    
    Note also (as stated above) that the FQDNs that are specified in the zone file MUST be terminated with a dot. If you do not terminate them with a dot, then the ORIGIN will get appended to the names, with results like:
```
  cs.colorado.edu.cs.colorado.edu
```
- Parentheses are used when a RR needs to span multiple lines in the text file
  - Older implementations were very picky about where parentheses were allowed
  - Newest versions allow them almost anywhere
The Serial Number is used by Secondary servers
- If their version of the value is LESS than the Primary's value, Then new data must be transferred from the Primary
- The integer value is arbitrary but must increase monotonically
- Many sites use the file modification-date for a serial number:
```
  20020403
```
- Sites that modify their zone data more than daily would add a suffix to the date:
```
  2002040301
```
- It is IMPORTANT to remember to update the Serial Number when you modify a zone file
  - If you don't, then your changes will NOT propogate to the Secondary servers
The remaining values in the SOA specify timeouts
- They are all specified in seconds
- All the timeouts can be tweaked from short to very long intervals
  - The tradeoff is one of efficiency versus accuracy
  - Short timeouts mean accurate data (for zones that change often)
  - Long timeouts improve network efficiency by holding the data longer on all the secondaries
- Local settings will depend on how static the zone data is
- The 'refresh' timeout specifies how long before a Secondary should query its Primary for the Serial Number
  - To determine if new zone data should be acquired
  - Newer implementations use a notification mechanism from Primary to Server
- The 'retry' value specifices how long a Secondary should wait between attempts to contact the Primary
  - For when the Primary can not be reached for some reason
- The 'expire' value specifies how long a Secondary can be authoritative for its data
  - For when the Primary can not be reached for a very long time
  - This value should be long (like several weeks)
  - Used to provide robustness when the primary gets whacked on the head
    Whacked on the head means something like a massive failure or a system upgrade that fails. Basically, if the primary server is out for a week, DNS should still continue to function.
- The final value is a Negative TTL value
  - It is used for answers to queries where the answer is ``no such record''
    This is important to avoid silly conditions where a client queries for some A record that doesn't exist. The local name server didn't cache the non-existance of the record, so when the flailing client application repeatedly asks for the record, it happily sends the query out only to get back an negative answer again... negative answer caching was implemented to avoid this problem.

NS records

A zone's NS records usually follow the SOA record
- The NS records use the same name as the SOA record (the ORIGIN)
- So the name is often just left blank
- Associated records will sometimes follow the NS records
  - Like A records for each of the name servers
NS records for delegated zones are near the top of the file as well
- These records must have the child zone as their name

The remaining records depend on the type of zone

Forward zones will have A, MX and CNAME records mostly
Reverse zones will have PTR records

Now have a look at some zone files

This is the master zone file for my own domain, xbalanque.net:

  ; start of authority record for xbalanque.net
  $TTL 7200
  @  IN  SOA  cs.colorado.edu.  admin.cs.colorado.edu. (
              20010421      ; Serial Number
                 86400      ; Refresh - every 24 hours
                  1800      ; Retry   - 30 minutes
               1209600      ; Expire  - 2 weeks
                  7200 )    ; Negative answers - 2 hours


       IN      A     198.11.19.5
       IN      MX    10 @
       IN      NS    cs.colorado.edu.
       IN      NS    ns.village.org.
       IN      TXT    "432 Gateway"


  localhost   IN    A     127.0.0.1


  coatlicue   IN    A     198.11.19.5
               IN    MX    10 @
               IN    HINFO    "SPARCstation Classic" "OpenBSD 2.8"


  ftp         IN    CNAME    coatlicue
  www         IN    CNAME    coatlicue
  mail        IN    CNAME    coatlicue
  xibalba     IN    MX       10 @
  xbalanque   IN    MX       10 @
  feanor      IN    MX       10 @

Note that the ORIGIN (@) is 'xbalanque.net'. Note also that I have an NS record that points to an off-site name server (ns.village.org). You have to make sure that all of the FQDNs specified in the zone file are terminated with dots.

There are a bunch of hostnames (e.g. 'xibalba' and 'feanor') that don't have IP addresses (no A records) but are simple MX records that have the ORIGIN as there only preference. I do this so that, if by chance I send mail from one of those hosts and the reply goes back to it directly, then the mail will just get sent to my gateway host.

The primary name server for xbalanque.net is 'cs.colorado.edu' (I don't manage the zone from my home machine, I manage it from work :). This a case where none of the authoritative name servers for the zone actually resides in the zone!

Another thing to point out is that I do not have a reverse zone. The University's ITS department controls the reverse zone for the entire 198.11.19.0/24 subnet. It would be a major pain for them to delegate out single IP address reverse zones to each person who wanted a static IP address. As a result they maintain the PTR record for my IP address.

   coatl % nslookup 198.11.19.5
   Server:  mroe-fs.cs.colorado.edu
   Address:  128.138.242.197


   Name:    coatlicue.Colorado.EDU
   Address:  198.11.19.5

I also run a stealth server inside my NAT'd home network. This server is not accessible from the outside world (which would be useless anyhow, because it resolves names for an RFC 1918 subnet!). Here is the Forward zone for my stealth server:

   ; start of authority record for xbalanque.net
   $TTL 3600
   $ORIGIN xbalanque.net.  ; added for clarity
   @  IN  SOA    xbalanque.net. tor.cs.colorado.edu. (
             2001031300         ; Serial Number
                   7200         ; Refresh - check every 2 hours for now
                   1800         ; Retry   - 30 minutes
                 604800         ; Expire  - 1 week (was 2 weeks)
                   7200 )       ; Minimum - 2 hours for now


                   IN      A       10.0.0.1
                   IN      NS      @
                   IN      TXT     "stealth DNS server for xbalanque.net"


   localhost               IN      A       127.0.0.1


   coatlicue               IN      A       10.0.0.1
   coalticue               IN      CNAME   coatlicue
   xibalba                 IN      CNAME   coatlicue
   www                     IN      CNAME   coatlicue
   quetzel                 IN      A       10.0.0.3
   xoxitl                  IN      A       10.0.0.4
   xbalanque               IN      CNAME   coatlicue
   bunky                   IN      CNAME   coatlicue
   hunapu                  IN      A       10.0.0.6
   boonie                  IN      CNAME   hunapu
   home-eye                IN      A       10.0.0.7
   judith                  IN      A       10.0.0.32
   mydhcp-33               IN      A       10.0.0.33
   feanor                  IN      A       10.0.0.34
   tala                    IN      A       10.0.0.35
   db-wired                IN      A       10.0.0.36
   mydhcp-37               IN      A       10.0.0.37
   mydhcp-38               IN      A       10.0.0.38
   dbw                             IN      A       10.0.0.39
   db-wireless             IN      CNAME   dbw
   mp3                             IN      A       10.0.0.40


   $GENERATE       41-128  mydhcp-$        A       10.0.0.$        ; dhcp address

The only really interesting thing to point out is the $GENERATE directive. This is a like a FOREACH loop to generate similar resource records. The second field specifies the range of values. the 'name' 'type' and 'data' portions of the record are given. A single '$' dollar-sign get's replaced with each value in the range. (Use a backslash to escape the dollar-sign if you actually want one in your names. This particular loop generates Address Records that look like:

   mydhcp-50   IN  A  10.0.0.50

   feanor % nslookup 10.0.0.50
   Server:  coatlicue.xbalanque.net
   Address:  10.0.0.1


   Name:    mydhcp-50.xbalanque.net
   Address:  10.0.0.50

The Internet class (IN) is implicit. Only a few records can be generated this way. Notably, NS, A, CNAME and PTR records can be.

Here is the Reverse zone file for my stealth server:

   ; start of authority record for xbalanque.net reverse zone
   $TTL 3600
   $ORIGIN 0.0.10.in-addr.arpa.  ; added for clarity
   @  IN  SOA    xbalanque.net. tor.cs.colorado.edu. (
           2001031300      ; Serial Number
           7200            ; Refresh - check every 2 hours for now
           1800            ; Retry   - 30 minutes
           604800          ; Expire  - 1 week (was 2 weeks)
           7200 )          ; Minimum - 2 hours for now


                   IN              NS              xbalanque.net.


   1               IN              PTR             coatlicue.xbalanque.net.
   3               IN              PTR             quetzel.xbalanque.net.
   4               IN              PTR             xoxitl-old.xbalanque.net.
   6               IN              PTR             hunapu.xbalanque.net.
   7               IN              PTR             home-eye.xbalanque.net.
   32              IN              PTR             judith.xbalanque.net.
   33              IN              PTR             mydhcp-33.xbalanque.net.
   34              IN              PTR             feanor.xbalanque.net.
   35              IN              PTR             tala.xbalanque.net.
   36              IN              PTR             db-wired.xbalanque.net.
   37              IN              PTR             mydhcp-37.xbalanque.net.
   38              IN              PTR             mydhcp-38.xbalanque.net.
   39              IN              PTR             dbw.xbalanque.net.
   40              IN              PTR             mp3.xbalanque.net.
   $GENERATE 41-128  $  PTR  mydhcp-$.xbalanque.net.

The 'dig' command also retrieves resource records

The Domain Information Groper
- Similar to the nslookup command, but more powerful
- Returns information in 'zone-file' format
- It can be directly cut+pasted into a zone file!

The simplest usage syntax is like this:

  dig  @server  domain.name  [record-type]  [class]

Record-type defaults to A; class to IN

  coatl % dig @mroe-fs xbalanque.net soa

  ; <<>> DiG 8.3 <<>> @mroe-fs xbalanque.net soa 
  ; (1 server found)
  ;; res options: init recurs defnam dnsrch
  ;; got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
  ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1,
                          AUTHORITY: 2, ADDITIONAL: 2
  ;; QUERY SECTION:
  ;;      xbalanque.net, type = SOA, class = IN

  ; ANSWER SECTION:
  xbalanque.net. 2H IN SOA cs.colorado.edu.
                       hostmaster.cs.colorado.edu. (
                    20010421        ; serial
                    1D              ; refresh
                    30M             ; retry
                    2W              ; expiry
                    2H )            ; minimum

  ;; AUTHORITY SECTION:
  xbalanque.net.          2H IN NS        cs.colorado.edu.
  xbalanque.net.          2H IN NS        ns.village.org.

  ;; ADDITIONAL SECTION:
  cs.colorado.edu.        2H IN A         128.138.243.151
  ns.village.org.         8H IN A         204.144.255.51

  ;; Total query time: 2 msec
  ;; FROM: coatl to SERVER: mroe-fs  128.138.242.197
  ;; WHEN: Wed Apr  3 13:42:45 2002
  ;; MSG SIZE  sent: 31  rcvd: 167

  coatl %

Notice that dig shows you each seperate section of the DNS message as well as the records that were contained in that section. Dig, of course, supports lots of other options. Read the manual page that ships with bind for further details.

BIND - the Berkeley Internet Name Domain

BIND is the reference implementation of DNS

Various versions of bind are by far the most common name server on the net
Bind is currently maintained by the ISC, http://www.isc.org
There are three main versions of bind in use
- Bind 4 - the oldest
  - No longer the bind that ships with OpenBSD
  - Has a radically different configuration syntax than later versions
  - None of the newer DNS features are available
- Bind 8 - current industry standard
  - Bind-8.3.4 is the most recent release of version 8
  - Ships with most modern Unix OSs
  - Bind-8.2.0 and later supports some advanced features found in Bind-9
- Bind 9 - the newest version
  - Supports many new features
  - Supports Version 8 configurations often without modification
  - Multi-threaded and resource intensive
    If you have an old or slow name server machine and you don't require the advanced features of Bind-9, you may want to just go with the newest Bind-8.
Always upgrade to the newest stable release for your version
- bind-9.2.2 is the most recent Bind-9 release
- Often the new releases contain critical security fixes
- Release information is sent to Bugtraq when it deals with security
- There are Bind specific mailing lists; see the ISC site for details
The latest source compiles on many platforms
- Nearly all of the common ones
- './configure; make; make install' works for most arches
  Bind 8 installs named into /usr/sbin. Bind 9 installs into /usr/local/sbin. Other utilitites will be in usual places below /usr or /usr/local (for bind8 or bind9 respectively).
  
  Note that the above './configure' line is adequate for many setups, but it is NOT adequate if you need to use any advanced cryptographic features. In that case, you need to explicitely turn on use of OpenSSL (and make sure it is installed). In the example below, simply turning it on is sufficient for OpenBSD.
  
  So, for example, I downloaded the current bind9 source (as of 1 April 2002 that was bind-9.2.1rc2 - rc=release candidate). Then I uncompress and untarred the archive, changed directories into it and ran the above commands:
```
  coatlicue% tar -zxf bind-9.2.1rc2.tar.gz
  coatlicue% cd bind-9.2.1rc2
  coatlicue% ./configure --with-openssl
  ...
  coatlicue% make
  ...
  coatlicue% sudo make install
  ...
```
  Note that for openbsd, the default bind9 install is somewhat orthogonal to either bind8 or the default bind4 because bind9 installs into /usr/local. If you install bind8, then the default 'make install' will stomp on the existing bind4 installation. (I found that this was perfectly reasonable when I installed bind8, as I wanted nothing to do with bind4!)
The name server supplied with Bind is called 'named'
- Pronounced name-dee
A number of other utilities are shipped with Bind
- Query tools like 'nslookup' and 'dig'
- Admin tools like 'rndc' and 'named-checkzone'
  rndc is the bind9 control utility. The bind8 version is called 'ndc'. Bind4 can only be minimally controlled using the 'kill' command and certain signals. Bind 8 & 9 also respond to signals sent with the kill command. See the documentation.
The Bind 8/9 config file lives in /etc/named.conf by default
- The Bind 4 config file was called 'named.boot'
  The default named.boot for OpenBSD lives in /var/named if you want to look at it or whatever.
The Zone Files typically live below /var/named
This is also a configurable thing. Many sites run named in a 'chroot'd environment, which we look at below. The chrooted '/' would be /var/named, for example.

Running named

Named should run with a NON-priviledged UID
- Using the '-u <user>' command line option
  Bind8 also offers the '-g <group>' command line option. That option is not available in bind9 as it just uses the primary group of the named user specified with the -u option. Note also in Bind 9 that '-g' forces named to run in the foreground (i.e. not as a daemon) for debugging
  
  As for any server daemon, you should take efforts to avoid running the daemon as 'root' or as any priviledged user. The reason is to forestall any possible exploit whereby the attacker gains shell or other access to the system through a bug in the daemon. Such bugs are bound to be discovered every now and then so it is vital to do everything you can to mitigate the potential damage that such an intrusion could wreak on your system(s). The next section is another general approach that is done as part of this sort of security strategy.
Named should run in a 'chroot'd environment
- Use '-t <dir>' to cause the specified <dir> to be the root
- You must provide some environment for named in the chrooted area
  - Particularly on when named is dynamically linked
    Look in /var/named on a stock OpenBSD system. This is the environment that named needs when its root is /var/named. For Solaris named's this directory would also probably have a 'usr' and a 'lib' directory populated with libraries and other things necessary for named to function.
    
    For example, here is an 'ls -lR' of the default /var/named on an OpenBSD-3.0 system:
```
   feanor % cd /var/
   feanor % ls -lRa named
   total 380
   drwxr-xr-x   5 root   wheel     512 Feb  4 00:19 ./
   drwxr-xr-x  24 root   wheel     512 Oct  1  2001 ../
   drwxr-xr-x   2 root   wheel     512 Oct 18 14:24 dev/
   drwxr-xr-x   2 root   wheel     512 Oct 18 14:24 etc/
   -r-xr-xr-x   1 root   bin    176128 Oct 18 14:27 named-xfer*
   -rw-r--r--   1 root   wheel     822 Oct 18 14:24 named.boot
   drwxr-xr-x   2 named  bin       512 Feb  4 00:19 namedb/
```
```
   named/dev:
   total 4
   drwxr-xr-x  2 root  wheel  512 Oct 18 14:24 ./
   drwxr-xr-x  5 root  wheel  512 Feb  4 00:19 ../
```
```
   named/etc:
   total 4
   drwxr-xr-x  2 root  wheel  512 Oct 18 14:24 ./
   drwxr-xr-x  5 root  wheel  512 Feb  4 00:19 ../
```
```
   named/namedb:
   total 12
   drwxr-xr-x  2 named  bin     512 Feb  4 00:19 ./
   drwxr-xr-x  5 root   wheel   512 Feb  4 00:19 ../
   -rw-r--r--  1 named  wheel   256 Oct 18 14:24 localhost.rev
   -rw-r--r--  1 named  wheel  2769 Oct 18 14:24 root.cache
   feanor %
```
    Note that files and directories that 'named' needs to write are owned by the named user. The files in the namedb subdirectory are special. Both of them are necessary for ALL name servers. The first, 'localhost.rev', provides the in-addr.arpa reverse zone record for the localhost (127.0.0.0/8) zone. The second file, 'root.cache', is called the the 'hints' file and contains Address Records for the thirteen ROOT dns servers.
    
    The executable, named-xfer, does what you might expect: it is used for transferring an entire zone from a remote server. It is almost always just invoked by named itself and not by hand (except for debugging).
    
    For my bind8 installation, there are a few other things that I needed to provide in the chrooted environment. In /dev (that would be the real directory /var/named/dev, if you are following all of this :) There is a /dev/null device file as well as a unix pipe file used for loggining:
```
  coatlicue% cd /var/named
  coatlicue% ls -l dev
  total 0
  srw-rw-rw-  1 root  wheel         0 Mar  6 09:51 log=
  crw-rw-rw-  1 root  wheel    2,   2 Jul 15  2001 null
```
    The /etc directory is also a bit more populated, although not much:
```
  coatlicue% ls -l etc
  total 32
  -r--r--r--  1 root  bin     877 Apr 28  2001 localtime
  -rw-r--r--  1 root  wheel  1075 Apr  3 14:35 named.conf
  -rw-r--r--  1 root  wheel  4438 Jul 15  2001 protocols
  -rw-r--r--  1 root  wheel  7764 Jul 15  2001 services
```
    Note the 'named.conf' file. I like to keep my bind config file in the /var/named area for organizational reasons. I create a symlink in the real /etc that points to the config file:
```
   coatlicue% ls -l /etc/named.conf
   lrwxr-xr-x  1 root  wheel  25 Jul 15  2001 /etc/named.conf@ ->
                                         /var/named/etc/named.conf
```
- Security holes that provide root access are limited to the chrooted area
  Of course you should try to run a version of bind that is patched for all known exploits! The chroot should be insurance against future bug discoveries.
Make sure you arrange for named to start at boot
- Turn OFF named in /etc/rc.conf for OpenBSD
  - Then add a snippet like the following to /etc/rc.local
```
  if [ -f /etc/named.conf -a \ 
     -x /usr/local/sbin/named ]; then
```
```
    /usr/local/sbin/named -t /var/named -u bind
```
```
  fi
```
    This would start the named server in /usr/local/sbin, presumably a bind9 server. The server would run as the user 'named' in the chrooted area below /var/named.
- Sys-V start up scripts should make use of the 'rndc' command directly.
  This command can propogate the 'start' and 'stop' args that a sysV runlevel script would receive. Actually, only bind8's 'ndc' command has the 'start' functionality right now. You have to start bind9 as indicated above for OpenBSD. The bind9 rndc utility does 'stop' named however. See below for more details.

Controlling Bind

All versions of bind respond to various Unix signals
- Send the running named a SIGHUP signal to reload the configuration file, for example
  This is the only way you can control Bind 4. There are other signals you can send. See the named manual page for more information. Note that Bind 9 responds to very few signals, SIGINT or SIGTERM to shut it down, SIGHUP to reload the config file.
- Bind developers say that the use of signals will be deprecated
Bind 8 has a control command called 'ndc'
- Speaks to named over Unix Pipes or TCP
  By default it only listens to a Unix Pipe (/var/run/ndc). You use the 'controls' bind configuration statement to configure on exactly what Unix Pipe or TCP Socket named will listen for ndc. For TCP you can also configure which interface, port number (953 by default) and IP addresses will be allowed.
Bind 9 has a control command called 'rndc'
- Only speaks to named over TCP
- rndc requires its own configuration file: /etc/rndc.conf
- Use of rndc REQUIRES a secret key that is exchanged for authentication
  - The key is encrypted with HMAC-MD5 before transmission
    HMAC stands for Hash-based Message Authentication Code. The point is not to be able to un-uncrypt the secret at the other end, the point is that each end can derive the encrypted text on their own (because of the shared secret key) and compare that with the other end's.
    
    We will look at the /etc/rndc.conf file in detail below under Bind Config.
Some rndc commands
```
  stop        stops named, duh ;)
```
```
  stats       dump stats to a file
```
```
  reload [zone]  reload zone files
```
```
  status      display server status info
```
There are a number of other commands, many common to both bind 8 and 9. The html web documentation that comes with bind describes their usage.

Run individual commands with rndc:

  % rndc  <options>  <cmnd>  [<cmnd>]

Options may be:

  -c config    specify an alternate config file
  -s server    specify an alternate server (than the
               default server spec'd in the config file)
  -p port      specify an altenate port to connect to
  -y key       specify a key-id, def'd in config file

Run rndc in an interactive mode
- Just don't specify any commands
Remember that rndc will NOT function with out secret keys configured
- Both ends must know the secret key
  Again, we will see how to set up the /etc/rndc.conf file when we look at bind configuration in general, next. The two are of course very similar.

BIND - named Configuration

The Config file is a simple ascii text file

Blank lines are ignored

Comments may be in any of three forms

   #   Shell-style comments on a single line

   //  C++ style comments on a single line

   /*  C-style comments which may span
    *
    *  multiple lines
    */

Note Well that the semi-colon ';' is NOT used for comments like it is in zone files.

Configuration is actually done with a series of 'statements'
- All statements must be terminated with a semi-colon ';'
  That's why the semi-colon isn't used to introduce comments!
- Most statements may be used more than once
  - Except for the 'options' and 'logging' statements
    Here are all the statements used in the named.conf file. A basic setup could get away with using only the options and zone statements.
```
  acl
  include
  options
  key
  trusted-keys
  server
  controls
  zone
  logging
  view
```

Address Match Lists specify a set of IP addresses

Before looking at the various configuration file statements it is important to understant the meaning and syntax of an Address Match List. This list just specifies a set of IP addresses or networks. Access Control Lists (acl) are just labeled versions of these lists.

In specific contexts these are called Access Control Lists (ACL)
The list may consist of one or more of the following types:
- An IP address
- A CIDR-block network
- A previously defined ACL
- An explanation point '!' may prefixed for negation
  - Note that the list is processed in order from left to right
The address list may also utilize a KEYWORD:
- 'any' - denoting all IP addresses
- 'none'
- 'localhost' - denoting the 127.0.0.1 address
- 'localnets' - denoting networks attached to local network interfaces

The 'acl' statement gives a label to an address list

  acl  <acl-id>  {
   ! 1.2.3.4;  1.2.3/24; localhost;
  };

Remember that address match lists are successful on a first-match basis, so order matters. In the above example, the negated host must occur before the allowed subnet.

Also, an ACL must be defined with an acl statement before it is used in the config file. The acl statement must be top-level (that is, not embedded within some other statement. For that reason, acl statements are usually made first at the top of the configuration file.

The 'include' statement

  include  "/path/to/file";

Note that if the path is absolute it is (hopefully) relative to the chrooted area
Of course, if you are not running a chrooted named, then the path is simply relative to the machines '/' root directory. You really should consider running a chrooted named instead!
If the path is not absolute then it is relative to the directory in which named is running
The include statement can be used just about anywhere it would make sense to use it, for Bind 9. Bind 8 is not quite as flexible apparently.
The included file is simply added at the point of the include statement in the made config file (as you might expect). Obviously, the included configuration information MUST be syntactically correct for the point at which it is inserted into the configuration file.
Typically, cryptographic keys are included this way
- Enabling the main config file to be world readable
- While the keys are kept in root-can-read-only files

The 'options' statement

There can be only one!
Defines global behavior for named
- Individual options can often be over-ridden within subsequent statements
  For example, the global behavior for the nameserver can be configured to accept only NON-recursive queries (like a root nameserver does). Then, within specific zone statements, recursive-query acceptance can be turned on for specific subnets (using an ACL, eh?).
There are over 50 options for Bind 9
- Fortunately, for many setups, only a few options are needed
- We will go over some of the important options below

Options live inside the options statement:

  options  {
    version    "we're not telling!";
    directory  "/";
  };

The version option default is the REAL version of Bind being run

The debate rages on over whether to set this to something else or not. The argument for changing it to something else (as shown above) is simply to avoid revealing information that might be of benefit to a hacker. The other side of the argument claims that ``security through obscurity'' is worthless and such tactics may harm legitimate attempts to map server types on the net. I personally tend to the former view, although I agree that security through obscurity is indeed not of much value. But it is definately not of NO value... whatevah

You can use 'dig' to query for the version string from a remote server. Here is the version information from my home stealth server:


   feanor % dig @xbalanque.net version.bind txt chaos


   ; <<>> DiG 2.2 <<>> @xbalanque.net version.bind txt chaos 
   ; (1 server found)
   ;; res options: init recurs defnam dnsrch
   ;; got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60927
   ;; flags: qr aa rd ra; Ques: 1, Ans: 1, Auth: 0, Addit: 0
   ;; QUESTIONS:
   ;;      version.bind, type = TXT, class = CHAOS


   ;; ANSWERS:
   VERSION.BIND.   0       TXT     "8.2.3-REL"


   ;; Total query time: 5 msec
   ;; FROM: feanor to SERVER: xbalanque.net  10.0.0.1
   ;; WHEN: Mon Apr  8 11:27:02 2002
   ;; MSG SIZE  sent: 30  rcvd: 64

Here is the version information from the CS dept primary:

   feanor % dig @cs.colorado.edu version.bind txt chaos


   ; <<>> DiG 2.2 <<>> @cs.colorado.edu version.bind txt chaos 
   ; (1 server found)
   ;; res options: init recurs defnam dnsrch
   ;; got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65000
   ;; flags: qr aa rd ra; Ques: 1, Ans: 1, Auth: 0, Addit: 0
   ;; QUESTIONS:
   ;;      version.bind, type = TXT, class = CHAOS


   ;; ANSWERS:
   VERSION.BIND.   0       TXT     "wouldn't you like to know..."


   ;; Total query time: 39 msec
   ;; FROM: feanor to SERVER: cs.colorado.edu  128.138.243.151
   ;; WHEN: Mon Apr  8 11:28:42 2002
   ;; MSG SIZE  sent: 30  rcvd: 83

The directory option sets named's runtime directory
- named will explicitely change directories to it
  The default is to simply remain in the invocation directory, where ever that may be.
- Use the '/' directory for chrooted servers
- Use '/var/named' for non-chrooted servers
  Or use the correct path for your dns zone files, whatever that is.
```
  options  {
    . . .
    notify  yes;
    also-notify { IP1 port 1053; IP2; };
    allow-notify { acl_id1; };
  };
```
Use 'notify' to turn on asynchronous notifications
- This is the Bind 9 default
  You need to explicitely turn it on for Bind 8. This causes the primary to notify secondaries when they need to reload zone information (because the serial number of the zone's SOA record has changed.) Bind 9 servers may need to turn notify OFF for specific secondaries that are known to not support asynchronous notifications. (This would be done on a per-server basis using the 'server' statement.)
- Overrides the SOA record 'refresh' timeout for zone updates
Use 'also-notify' to enable notifications for stealth servers
Because stealth servers don't have NS records pointing at them, you need to tell the primary server to send notifications to them by using the 'also-notify' clause. Assuming of course that you want your stealth servers to have current DNS zone information...
Use 'allow-notify' to permit notifications from non-primaries
This statement is typically used when a there are several tiers of nameservers at a site. Third tier nameservers will load their zone data from a second tier of secondary nameservers. This is where you need to tell the third tier nameservers to allow notifications from the second tier secondaries. The second tier nameservers don't need this clause because they will be transferring their zone data directly from the primary (i.e. the first tier).
```
  options  {
    . . .
    recursion   yes;  // this is the default
    allow-recursion { acl_id2; };
  };
```
Use the 'recursion' option to disable normal nameserver behavior
- This makes the nameserver respond to queries with referals instead of actual answers
- NOT RFC compliant
  Sites might disable normal query service for queries that come from off site. The theory is that those off-site queries really ought to be going to some nameserver that is local to the query source (i.e. that person's ISP). Recursion is then re-enabled for specific local networks.
The 'allow-recursion' option enables normal service for specific hosts or networks
- Typically this option will appear in conjunction with disabling recursion globally first
```
  options  {
    . . .
    listen-on  [port NN]  { acl_id3; };
    query-source [ address * ] [ port * ];
  };
```
Use 'listen-on' to change the port number on which named listens
The default is the 'domain' port from /etc/services, port 53. Change this value only when you have a good reason to. Nameserver may change the port numbers they query from and listen to for talking with specific other nameservers, which can allow a more restrictive firewall perhaps.
- You can also restrict named to only listen on specific interfaces
  You may specify the IP address of the interface. Perhaps this is only the local host interface, 127.0.0.1 (you might be able to just type the word 'localhost', but I'm not sure).
```
   listen-on { 127.0.0.1; };
```
  You can also specify a CIDR block for a local subnet, and named will just pick the interface with the relevant address. For my home stealth-server, I could do something like this:
```
   listen on { 10.0.0/24; };
```
Use 'query-source' to change the SOURCE port that named uses
- When it queries other nameservers
- Useful for stricter firewall rules
  By default it just picks a random high-numbered UDP port and uses that. You can restrict to something like '53' or '1053' to allow for a more restrictive firewall, for example.
```
  options  {
    . . .
    forwarders { IP1; IP2; ... };
    forward  only;   // or first
  };
```
The 'forwarders' options is useful for large sites
- Most internal nameservers are configured to use a small list of nameserver called 'forwarders'
- Forwarders themselves build large caches from site-wide traffic
  Note that this violates the normal DNS behavior for the local nameservers that contact the forwarders. They always contact the forwarders to resolve names (for which they are not authoritative already), instead of resolving the names themselves (e.g. by contacting the root server and following the referals.)
  
  Be careful that the forwarders aren't themselves forwarders, or at least be careful to avoid forwarding LOOPS!
The 'forward' option is only used if 'forwarders' has been set
- Setting 'forward only' causes the nameserver to ONLY query its forwarders
  The default is 'forward first' which allows the nameserver to default back to normal DNS behavior if its forwarders are unreachable.
```
  options  {
    . . .
    allow-query    { acl_id4 };
    allow-transfer { acl_id5; };
    blackhole      { acl_id6; };
  };
```
The 'allow-query' option restricts which hosts or nets the nameserver will answer to
Note that all other query sources get an error message returned to them, stating that such service is disabled.
The 'allow-transfer' option similarly restricts data access
- Only the specified hosts or networks can perform zone-transfers from the nameserver
  This option is becoming increasingly important to utilize as hackers take and abuse as much information as they can get their hot little hands on! Disabling zone-transfers except from specific other nameservers makes their job of mapping your network significantly harder than a simple data transfer process.
The 'blackhole' option designates a list of BAD hosts or networks
- DNS queries from blackholed hosts are completely ignored
  This is different from the behavior of hosts not in the 'allow-query' set. Blackholed hosts don't receive any notification for lack-of-service, they completely ignored, their packets dropped into the bit-bucket..
There are MANY other options
- For enabling some default Bind 9 features in newer versions of Bind 8
- For performance tweaking
- Lots of others
- Probably only useful for VERY specific circumstances
- See the Administrators Reference Manual that accompanies the Bind source

The 'key' statement

  key  key_id  {
     algorithm hmac-md5;  // the only alg
     secret "XYZZY";
  };

Defines a secret key and an algorithm to be used
The secret is an UNencrypted BASE-64 encoded binary string. The algorithm choice is currently only 'hmac-md5'. The 'key_id' is an arbitrary label for the key.
- Keys must be defined before they are used
  And they must be top-level statements in the configuration file.
  
  Typically, the key statements are kept in seperate files that can have restrictive (0400) unix file permissions. Those files are then sucked into the main config file with 'include' statements.
- Keys should be unique between different pairs of servers
  We will see below several different ways that keys are used by bind 9.
  - Thus, the use of keys doesn't scale well past a single site

The 'trusted-keys' statement is used with DNSSEC

Here is the generic syntax for the statement:
```
  trusted-keys  {
     domain flags protocol algorithm key;
     . . .
  };
```
- Each line represents a trusted key for a zone
  - That zone signs its zone data with the key
  - This nameserver can verify the signature and thus the data
We will look at DNSSEC in a bit more detail below

The 'server' statement

  server  IP_ADDR  {
     option1 .. ;
     option2 .. ;
  };

Use the server statement to change the global behavior on a per-server basis
The point is that you specify specific options that change your server's interaction with the specified server. In general, of course, you only specify those options that change the behavior from the global default for your server.
- Used for handling nameservers with known traits
  - Like interfacing a Bind 9 primary with a Bind 8 secondary
- Also used to set up shared-secret keys between servers
  We will look at an example of setting up shared-secret keys when we look at TSIG, one of the newer DNS security features.

The 'controls' statement configures access for 'rndc'

Or it configures access for 'ndc' if you are using Bind 8.

  controls  {
     inet IP_ADDR [port N] allow { acl_id8 }
            keys { key_id1; key_id2; };
  };

Multiple 'inet' clauses may be given
The IP_ADDR is the interface on which named listens for rndc
- Specify an '*' for 'all interfaces'
The port number defaults to 953
Keys MUST be used in Bind 9

We can now look at the '/etc/rndc.conf' file

The format is similar to the named.conf file
Only four statements are valid: key options server include
The 'key' statement looks exactly like it does in named.conf
Replicated here for your viewing pleasure:
```
  key  key_id  {
     algorithm hmac-md5;  // the only alg
     secret "XYZZY";
  };
```

Typical options statement looks like this:

  options {
     default-server localhost;
     default-key    key_id;
  };

The 'zone' statement

  zone "domain_name" {
     type  master;  // or slave
     file  "path/to/zone/file";
  };

Other possible types are: 'stub', 'forward', and 'hint'

Indicate whether your nameserver is primary or secondary
- For the given zone (specified by the domain_name)
Other options may be given here
- To allow transfers from specific servers, for example
There is a special zone type called 'hint'
- All name servers need to include a hint zone
- It includes a seed file for the addresses of the root nameservers
```
  zone  "."  {
     type  hint;
     file  "path/to/hints/file";
  };
```
Most nameservers always have a reverse zone for localhost
- The 'localhost' name is always dealt with in forward zones
- The in-addr.arpa address needs an explicit seperate zone
- The zone config for the reverse localhost zone looks like this
```
  zone "0.0.127.in-addr.arpa" {
     type master;
     file "localhost";
     notify no;
  };
```
  - Every nameserver is always 'master' for the zone
  - The zone doesn't need to receive asynchronous notifications

The 'view' statement is used to present different information based on the source of the DNS query

  view  "view_name"  {
     . . .
  };

For example, a site may want to present one set of data to its internal clients and a different (sanitized) set of data to external clients. Small private networks can make use of views in a big way by presenting full DNS information inside the network pertaining to the private addresses used on the network (one view). The server, for the same zone, can present different data records to the outside world (an external view), which is important when most internal hosts are not reachable on the net anyway.

If a 'view' statement is used
- ALL 'zone' statements MUST occur inside 'view' statements
We will look at views more closely below

The 'logging' statement is quite flexible

When named generates log-messages they are assigned certain values
- They are placed in one category
  - Defining what, in general, the message is about
    The categories are pre-defined in the Bind source. There are about 20. There is a list of categories given in TPB (page 472). This list can also be found in the Bind Administrator Reference Manual. Categories range from 'os' for Operating System related problems to 'xfer-in' for messages relating to incoming zone transfers.
- They are assigned a 'module' (for Bind 9 only)
  - Designating which part of the source generated the message
- They are assigned a 'severity' using the 'syslog' severity levels
Channels are defined log-message OUTPUT locations
- Log messages matching various characteristics can be sent to a specific output location
  - i.e. based on category, module and severity
- Output locations can be SYSLOG, a text file, or /dev/null
- Channels can be defined to add information to the message
  - Including the time, the category and the severity of the message

Here is the general syntax for the logging statement

  logging  {

     <channel-definition-1>;
     <channel-definition-2>;
     . . .

     category  <category-a>  {
        <channel-name-1>;
        . . .
     };
     category  <category-b>  {
        <channel-name-2>;
        . . .
     };
     . . .
  };

Here is the syntax for a channel definition

  channel  <channel-name>  {
     file /file/path [versions N | unlimited] [size M];
     syslog <facility>;
     severity <severity>;
     print-category yes;  // or no
     print-severity yes;  // or no
     print-time     yes;  // or no
  };

Use either the 'file' clause, OR the 'syslog' and 'severity' clauses
Files can be rotated through any number of past versions based on a size specification

There are some default channels

   default_syslog    logs with facility 'daemon'
                     and severity 'info' and worse

   default_debug     logs to a file called 'named.run'
                     with 'dynamic' severity

There are some others

The default logging statement for Bind 9 is

 logging {
   category default { default_syslog; default_debug; };
 };

Now let's look at some configuration files

Here is the configuration for my current home network stealth server. This server is version 8.2.3. I am in *slightly* less haste to upgrade the server because it doesn't listen to queries from the Internet.

  /*
   * named master conf file for xbalanque.net
   *
   *  stealth server for a private network
   *
   * RCS: $Id: dns.pmp,v 1.4 2003/03/26 19:19:20 tor Exp tor $
   */


  options {
          directory "/";
          pid-file "/named.pid";
          listen-on { 10.0.0.1; 127.0.0.1; };
          forward first;
          forwarders { 128.138.129.76; 128.138.243.151; };
          query-source port 1053;
  };


  zone "xbalanque.net" {
          type master;
          file "xbalanque.forward";
      allow-transfer { 10.0.0.5; };
  };


  zone "0.0.10.in-addr.arpa" {
          type master;
          file "xbalanque.reverse";
  };


  zone "." {
          type hint;
          file "cache.db";
  };


  zone "0.0.127.in-addr.arpa" {
          type master;
          file "localhost";
          notify no;
  };


  logging {
      channel syslog_info {
                  syslog local3;
                  severity info;
          };
          channel syslog_tor {
                  syslog local1;
                  severity info;
          };
          channel no_info_messages {
                  syslog local2;
                  severity notice;
          };
          category parser       { syslog_tor; };
          category security     { syslog_tor; };
          category load         { no_info_messages; };
          category lame-servers { no_info_messages; };
          category default      { syslog_info; };
  };

I plan to upgrade to Bind 9 soon, and use 'view' statements to present 10.0-net data inside and real xbalanque.net data outside. The internal view will be a primary server for the zone, while the external view will be a secondary server (the real primary is cs.colorado.edu).

The CS department currently runs to separate nameserver processes to facilitate the 'views' concept (they are Bind 8 servers, so no 'view' statement). Yes, we plan to upgrade soon... Here is the current config file for the external server:

  //
  // ACL's
  acl CUnets {
          128.138/16; 198.11.16/24; 204.228.69/24; 127.0.0.1;
  };
  acl rfc1597 {
          10/8; 172.16/12; 192.168/16;
  };


  //
  // Global options
  options {
          version "wouldn't you like to know...";
          directory "/";
          pid-file "/named-external.pid";
          named-xfer "/named-xfer";
          notify yes;
          /*
           * Since this daemon serves external hosts we bind to the
           * external address, 128.138.243.151.
           */
          listen-on { 128.138.243.151; };
          transfer-source 128.138.243.151;
          /*
           * If there is a firewall between you and nameservers you want
           * to talk to, you might need to uncomment the query-source
           * directive below.  Previous versions of BIND always asked
           * questions using port 53, but BIND 8.1 uses an unprivileged
           * port by default.
           */
          query-source address 128.138.243.151 port 53;
          /*
           * Choose local name servers over off-site ones.
           */
          topology {
                  localhost;
                  localnets;
                  CUnets;
          };
          /* 
           * Don't listen to known broken nameservers
           */
          blackhole {
                  209.234.73.115;
                  209.234.73.116;
                  209.234.73.117;
                  209.234.73.118;   
          };
  };


  //
  // Logging
  logging {
          // We want syslog stuff to go to local3
          channel syslog_info {
                  syslog local3;
                  severity info;
          };


          // We don't care about people's broken name servers
          category lame-servers { null; };


          // Use syslog_info channel unless we get a more specific match
          category default { syslog_info; };
  };


  //
  // Root servers cache
  zone "." in {
          type hint;
          file "named.cache";
  };


  //
  // Primaries
  //


  //
  // localhost
  zone "0.0.127.in-addr.arpa" in {
          type master;
          notify no;
          file "localhost";
  };


  //
  // CS
  zone "cs.colorado.edu" in {
          type master;
          file "forward-external/cs.colorado.edu";
  };


  //
  // CS reverse records (128.138.X.X)
  zone "245.138.128.in-addr.arpa" in {
          type master;
          file "reverse/245.138.128";
  };
  zone "244.138.128.in-addr.arpa" in {
          type master;
          file "reverse/244.138.128";
  };


  // ...  many other reverse zones edited out ...


  //
  // catbelly.com for garnett (garnett@catbelly.com)
  zone "catbelly.com" in {
          type master;
          file "catbelly/catbelly.com";
  };


  //
  // xbalanque.net for tor (tor@xbalanque.net)
  zone "xbalanque.net" in {
          type master;
          file "xbalanque/xbalanque.net";
  };


  // ... other zones for which we are primary deleted ...


  //
  // Secondaries
  //


  //
  // colorado.edu top level
  zone "colorado.edu" in {
          type slave;
          file "secondary/colorado.edu";
          allow-transfer { none; };
          masters {
                  128.138.240.1;
                  128.138.238.18;
          };
  };


  // ... other zones for which we are secondary deleted (about 50) ...

You can see that the CS department primary nameserver has a lot of duties! We are primary for a dozen or more different domains (like mine) and secondary for many dozens more.

TSIG - Transaction Signatures

TSIG uses shared-secrets and one-way hash functions

Data is combined with the secret, then hashed
- Only those who know the secret can create and/or verify the hash value
- Does NOT provide 'non-repudiation' (both sides use the same key)
- It is NOT public-key crypto
Each pair of hosts need a seperate shared-secret
- This is why TSIG authentication doesn't scale

Generate a secret key with 'dnssec-keygen'

 % dnssec-keygen -a hmac-md5 -b 128 -n HOST  hostA-hostB

'-a hmac-md5' - The algorithm must be hmac-md5, the only one currently supported
'-b 128' - The keysize is 128 bits
'-n HOST' - The key 'type' is a HOST key
Note that this host key has NO relationship with an SSH host key whatsoever. They are entirely different beasts!
The last argument specifies part of the output filename
Typically, the key is named for and stored in a file that contains both of the hostnames for which the key will be used. That is, if the key will be used to authenticate transactions between host A and host B, then the keyfile name should be ``hostA-hostB'' or something to that effect.
```
  coatlicue% dnssec-keygen -a hmac-md5 -b 128 -n HOST  hostA-hostB
  Khosta-hostb.+157+03361
```
- The real output file basename will be: 'Khosta-hostb.+157+03361'
  - The 'K' gets prepended, indicating a Key file
  - The number '157' is the algorithm (hmac-md5) used
  - The final number is the key's own fingerprint
- Two files actually get generated
  - A '<base>.key' file
  - A '<base>.private' file
  - The actual key can be found in either file
    For the above example, here are the contents of the two files:
```
  coatlicue% cat Khosta-hostb.+157+03361.key 
  hostA-hostB. IN KEY 512 3 157 EPsVoeqIeY0JAd3F/tyXLQ==
```
```
   coatlicue% cat Khosta-hostb.+157+03361.private 
   Private-key-format: v1.2
   Algorithm: 157 (HMAC_MD5)
   Key: EPsVoeqIeY0JAd3F/tyXLQ==
```
    Note that even though dnssec-keygen produces two key files, the keys are the same in each file. These are NOT a private/public keypair. The dnssec-keygen IS also capable of generating such keys, as we will see below under DNSSEC.

Cut+paste the key into a Bind config 'key' statement:

  key  hostA-hostB.  {
     algorithm hmac-md5;
     secret "EPsVoeqIeY0JAd3F/tyXLQ==";
  };

You could use this key for 'rndc' authentication
- Add the key-id into the 'controls' statement
  Here is what a 'controls' statement might look like that uses the above defined key:
```
  controls  {
     inet IP_ADDR allow { localhost; }
            keys { hostA-hostB.; };
  };
```
- Add the key statement and key-id into the '/etc/rndc.conf' file
  Here is what a complete /etc/rndc.conf file might look like:
```
  key  hostA-hostB.  {
     algorithm hmac-md5;
     secret "EPsVoeqIeY0JAd3F/tyXLQ==";
  };
```
```
  options {
     default-server localhost;
     default-key    hostA-hostB.;
  };
```

Note that transactions are not encrypted with TSIG
The point is to 'authenticate' the data, not to encrypt it. DNS is, by definition 'public' data; there may be a conceivable need to encrypt DNS data, but not in general. TSIG generates a checksum of the data being being transmitted incorporating the secret key at the same time. This value can ONLY be generated or verified by someone who also has a copy of the same secret key. In this way, the data can be verfied as authentic.
You can also use keys in Bind 'server' statements
- To use TSIG authentication between two servers each server must specify the key
  - For example, host A might have a server statement like this:
```
  server  hostB-IP-addr  {
     keys { hostA-hostB.; };
  };
```
  - Host B's server statement is similar:
```
  server  hostA-IP-addr  {
     keys { hostA-hostB.; };
  };
```
- Use 'allow-transfer' clause to enable TSIG to actually be used
  - Placed within the relevant 'zone' statement
  - Here is what host A's zone statement might look like:
```
  zone  mydomain.com  {
     type  master;
     file  "mydomain.com-forward";
     allow-transfer { key hostA-hostB.; };
  };
```
  - The use of keys in the 'allow-transfer' statement is safer than IP access control
    Because IP addresses can be spoofed more easily than secret keys!

Dynamically Updated Zones

Dynamic Updates provides for automatic updating of zone data

Authenticated Updaters are allowed to add, delete or modify Resource Records
Updaters may also modify (and add or delete) Resource Record sets (RRsets) which are groups of resource records that share the same name, class and type. That is, the same domain name (like www.yahoo.com) can map to multiple A records; all the host's A records taken together comprise an RRset. Such groups are allways returned together as the result of a query for that hostname: there is no way to get only one of the records. Typically (by default) these records are always returned in a round-robin fashion, rotating which record gets returned first for each answer.
- Authentication may be based on remote IP address
  Obviously this is an unsafe method as IP address may be easily spoofed (especially by someone who already has access to you local networks.
- Authentication may be based on TSIG keys
  Clearly this is a superior method, although it doesn't protect against compromised servers. Nor does it handle an authenticated server that is itself simply 'forwarding' a zone update to the master. Finally, TSIG can really only be used in local scenarios under you control, due to the non-scalability of TSIG's reliance on shared-secrets.
- Updaters may be able to update many or only specific RRs
  - The defaults allow for almost any record in the zone to be updated
  - Specific updaters MAY be constrained to updating only individual records
Dynamically updated zone files may NOT be edited manually
- You must halt the master server first, then edit the zone file
- Updates are tracked in a journal file
  Typically, the journal file is named after the zone file with '.jrn' appended to it.
  - The journal file gets written to the master zone file periodically
    And, of course, when you halt the server in a graceful way (with the rndc stop command or using the SIGTERM signal).
- Bind 9 provides the 'nsupdate' tool for submitting updates
- Current dhcp servers can submit updates
  Both 'nsupdate' and version 3 of the ISC dhcpd server are capable of using TSIG for authenticating updates.
Updating should ONLY be enabled for specific zones
- Most sites delegate a special child zone specifically as a dynamic zone
  This is important as it protects your primary zone's data integrity - you wouldn't want an updater (maliciously or not) to change the records for you webserver, for example!
- Enable updating using one of two clauses in the 'zone' statement
  - The (older) 'allow-updates' clause provides all-or-nothing update access
  - The 'update-policy' clause offers much more flexibility
Enabling updates with the 'allow-update' clause
```
  zone  dyn.xbalanque.net  {
     . . .
     allow-update  {  acl_id1;  acl_id2;  };
  };
```
- The 'allow-update' clause allows the specified hosts to updated any record
  - There is NO way to restrict what records they update
- TSIG keys may be used in Address Match Lists
```
     . . .
     allow-update  {  key dhcpd_key; };
     . . .
```
  - The key must have been previously defined in the config file
Enabling updates with the 'update-policy' clause
- The syntax for this clause is somewhat more complicated zone dyn.xbalanque.net { . . . update-policy { <policy-rule-1>; <policy-rule-2>; . . . }; };
- First note the contents of an update request
  That is, from an updater like 'nsupdate' or 'dhcpd'.
  - The name of the TSIG key used to sign the update request
    Note that the key name is not required - if it is not specified, no matches will be made in any policy rules, as they require a key. That is, if you specify a key-name for the identity. You can simply specify an IP address or hostname here if you really insist..
  - The domain-name and type of the record(s) being updated
- Each policy-rule specifies a set of priviledges with the following syntax
```
  grant|deny  identity  nametype  name  [types];
```
  - 'identity' is a key-id name, the identity of the updater
    It should be named for the domain-name of the updater, in most cases.
  - 'nametype' specifies the matching characteristics for the rule
    There are four possibilities for the nametype field:
```
   name
```
    'name' means that the domain-name being updated must be the same as the name specified in the name field of the policy-rule.
```
   subdomain
```
    'subdomain' means that the domain-name being updated must be a proper subdomain of the name in the name field of the policy-rule. Note that the domain-name being updated must still be legally within the authority of the dynamic zone!
```
   wildcard
```
    'wildcard' means that the domain-name being updated must match the wildcard expression in the name field of the policy-rule.
```
   self
```
    'self' is slightly different: the domain-name being updated must be the same as the name in the 'identity' field! This means that the name of the key (i.e. the contents of the identity field) must be the same as the domain-name - obviously..
  - 'name' is domain-name used for matching
    Here is an example bind config file for a dynamic zone in the CS department called 'vpn.cs.colorado.edu' that is used for offsite VPN presence. The updaters are shell scripts wrapped around the 'nsupdate' command.
```
   // Nameservice config file for CS VPNs
```
```
   options {
           version "wouldn't you like to know...";
           directory "/local/namedb";
           notify yes;
   };
```
```
   zone "." {
           type hint;
           file "named.root";
   };
```
```
   zone "vpn.cs.colorado.edu" {
           type master;
           file "vpn.cs.colorado.edu";
           update-policy {
                   grant *.vpn.cs.colorado.edu. self *.vpn.cs.colorado.edu. A;
           };
   };
```
```
   include "named.keys";
```
You can configure dhcpdV3 from isc.org to use TSIG updates
- The necessary config bits for dhcpd are similar to bind
  The following example is lifted directly from the v3 dhcpd.conf manual page. The example illustrates the config bits for the dhcp server when it is running on the same machine as the nameserver. Additionally, the dhcpd server will request updates for both A and PTR records because both zones are defined in the config file.
```
   key DHCP_UPDATER {
     algorithm HMAC-MD5.SIG-ALG.REG.INT;
     secret pRP5FapFoJ95JEL06sv4PQ==;
   };
```
```
   zone EXAMPLE.ORG. {
     primary 127.0.0.1;
     key DHCP_UPDATER;
   }
```
```
   zone 17.127.10.in-addr.arpa. {
     primary 127.0.0.1;
     key DHCP_UPDATER;
   }
```

Views

Views facilitate a concept known as 'Split DNS'

Split DNS means providing different zone data for the same zone
- Information returned depends on the query source
- Traditionally used to hide some host information from the outside
- Also useful for RFC1918 NAT networks
Traditionally provided by using two seperate server processes
- Bind 9 has the 'view' statement to accomplish the same thing
If a 'view' is used at all, views MUST be used completely
- All 'zone' statements can only occur inside of 'view' statements

Here is an example using views for my home network

Not yet implemented!
External view is a secondary server for the real zone
Internal view is a primary server for the RFC1918 version of the zone
Note also that the 'loggin' statement has been removed for clarity.

First define some access control lists to use:

  acl my_net {
     10.0.0.0/24;
  };

  acl off_site {
     !10.0.0.0/24; any; localhost;
  };

  /* mroe.cs.colorado.edu is the
   * real primary for xbalanque.net
   */
  acl mroe {
     128.138.243.151;
  };

Next come the global options:

  options {
     // we're starting in a chrooted area
     directory "/";
     pid-file "/named.pid";

     // disabling forwarders to build a big local cache:
     // forwarders { "mroe"; 128.138.129.76; };
     // forward first;

     // specific query source for the firewall
     query-source port 1053;

     // disabling recursion in general
     recursion no;
  };

Next is the INTERNAL view:

  view "internal" {
     match-clients { "my_net"; };
     recursion yes;

     zone "xbalanque.net" {
        type master;
        file "xbalanque.forward";
     };
     zone "0.0.10.in-addr.arpa" {
        type master;
        file "xbalanque.reverse";
     };
     zone "." {
        type hint;
        file "cache.db";
     };


     zone "0.0.127.in-addr.arpa" {
        type master;
        file "localhost";
        notify no;
     };
  };

Finally, the EXTERNAL view:

  view "external" {
     match-clients { "off-site"; };

     zone "xbalanque.net" {
        type secondary;
        file "xbalanque.fwd.external";  // cache file
        masters { "mroe"; };
     };

     // the real reverse zone is admin'd by colorado.edu

     zone "." {
        type hint;
        file "cache.db";
     };


     zone "0.0.127.in-addr.arpa" {
        type master;
        file "localhost";
        notify no;
     };
  };

DNSSEC - Security Extensions

DNSSEC comprises a set of extensions using public keys

Three related services are defined
- Public Key Distribution using KEY RRs
  - A perfect use for a secure DNS database!
- ORIGIN verification for servers and data
  - This one is perhaps the most important
    Without being able to verify the source of the data, the integrity of it is irrelevant, because the source provides the signitures that verify the integrity. If the source is unknown, then all bets are off.
- Verification of zone data integrity
  Confidentiality CAN be done, but Bind 9 doesn't use it, on the theory that the data is public. The point is to be able RELY on the public data.
  - Known as ``signing a zone''
Relies on a ``chain of trust''
- Everyone knows the root server's public key
  - It will get distributed in the HINTS file
- The root signs the TLDs' keys
  - For a child zone to be verifiable the parent zone must sign its public key
  - Parent zone's key is known because it's the root key
- The TLDs sign their child zone keys
  - The chain of signatures must be verifiable to the root key
- NOT IMPLEMENTED YET
  - The bind 'trusted-keys' config statement provides for un-verifiable parent zones
    We'll look at how that works below.

Generate a key-pair for a specific zone

  % dnssec-keygen -a RSA -b 512 -n ZONE xbalanque.net.
  Kxbalanque.net.+001+53599

Recall that the algorithm is the middle (001) number, while the last number is fingerprint of the key. Also recall that two files are generated, and this time it makes more sense.

  coatlicue% ls Kxbalanque.net.*
  Kxbalanque.net.+001+53599.key
  Kxbalanque.net.+001+53599.private

The public '.key' file, as mentioned above, is a DNS KEY Resource Record. Here is what it looks like (the file has ONE line in it, it is split apart for readability).

  coatlicue% cat Kxbalanque.net.+001+53599.key 
  xbalanque.net. IN KEY 256 3 1 AQPjRG1hINd3E7sw/F
          /cM4B2ZDOM+GWQoxeRLucwjLhin8TLdo552YjB
          wAXTllDUbbpfljIS7JeY5TGcyMUK0V/F

The name of the key is the 'domain name' for the KEY record. The class as usual is IN for Internet. The type, of course, is KEY. The remaining four values in the record are 'flags', 'protocol', 'algorithm' and 'key'. The flags field is a 16-bit value that designates the type of key and the uses for which the key is suitable (e.g. authentication, confidentiality). The 'protocol' field, 8 bits, designates the key use. A protocol value of '3' indicates DNSSEC. Other key uses might be IPsec or TLS. The 'algorithm' field value of '1' indicates that RSA is the algorithm. (You'll see a '3' for DSA). The 'key' field is public key.

Bundle the key and send it off to the parent zone for signing
- Most of us don't get to do this yet
- Bind 9 provides the 'dnssec-makekeyset' command
  - Bundles public keys to be signed with TTL and validation period
```
 % dnssec-makekeyset -t 172800 \ 
     Kxbalanque.net.+001+53599.key
 keyset-xbalanque.net.
```
  - Places a 'signing request' in the file 'keyset-xbalanque.net.'
  - Here is what the file looks like:
```
  coatlicue% cat keyset-xbalanque.net.
  $ORIGIN .
  $TTL 172800     ; 2 days
  xbalanque.net  IN KEY  256 3 1 (
          AQPjRG1hINd3E7sw/F/cM4B2ZDOM+GWQoxeRLucwjLhi
          n8TLdo552YjBwAXTllDUbbpfljIS7JeY5TGcyMUK0V/F
          ) ; key id = 53599
     SIG     KEY 1 2 172800 20020510193643 (
          20020410193643 53599 xbalanque.net.
          A4cZvEo9IynJo/K7GzEE1OsaIr1BkCXFx3SSjoBLVf1F
          vZfn+FU50Dvttgozfw6GY8mu7biVTjJ8nnlo9xiQ/w== )
```
  - Then send the file to the parent for signing using a secure method
    If you can.. The secure method of transfer is necessary until the root and TLD zones start signing child zone keys. When that happens, less paranoid methods may potentially employed. Although in the case of the initial signing of a child zone by its parent, some secure method of getting the child's public key to the parent is still necessary.
Signature Records contain the following information
- Type of record being signed followed by the algorithm used
  In the example above, a KEY record is being signed and the algorithm is '1' or RSA. I have no idea what the '2' represents, that follows the algorithm number. I'll look into it... oh no, wait. It is the 'labels' field, and it indicates how many labels are in the name of the SIG record. For 'xbalanque.net.' we have two labels and thus the number two appears.
- The TTL of the record being signed and the validity period for the signature
  These are the next three numbers (172800 20020510193643 20020410193643). The validity end and start (in that order) times have a format of yyyymmddhhssss. The TTL is of course in seconds (172800 is two days).
  
  The number following these values (53599, above) is the key's fingerprint.
- The signer's name (the key/domain name) and digital signature
Sign a child zone's key bundle
- Use the 'dnssec-signkey' command to sign child zone keys
- Requires a public key for the parent zone
```
 % dnssec-signkey keyset-xbalanque.net \ 
                Knet.+001+12345.private
```
  That is obviously a fake example..
  - Results in a 'xbalanque.net.signedkey' file
  - Looks similar to the request file, but the SIG is signed by the parent zone
Include the public key into the master zone file
- Either the signed or the unsigned version
- Include the key after the SOA record
```
  $INCLUDE Kxbalanque.net.+001+53599.key
```
- Whether your parent zone signs your key or not it should be $INCLUDED
  - If you want other servers to be able to authenticate your zone data
- If your key is NOT signed then the remote servers must include it in their own servers' config files
  i.e. by using the 'trusted-keys' statement

Use the 'trusted-keys' statement to authenticate servers

When their parent zone hasn't signed their public key
Here is the general syntax again:
```
  trusted-keys  {
     domain flags protocol algorithm key;
     . . .
  };
```
- 'domain' is the name of the public key's zone
  Which is of course, usually the name of the keyfile base too.
- 'flags', 'protocol' and 'algorithm' are the same values as found in the KEY record
  For the key we generated above, they would be 256, 3, & 1, respectively.
- The key is just the public key from a remote server you want to trust

Signing zone data with a zone's public key

Use the 'dnssec-signzone' command
```
 % cd /var/named
 % dnssec-signzone -o xbalanque.net xbalanque.fwd
 xbalanque.fwd.signed
```
- The '-o xbalanque.net' option specifies the ORIGIN for the zone
  - The named.conf 'zone' statement normally specifies the ORIGIN
- The last argument is the existing master zone file
- The zone's private key is automatically used
  If it exists in the current directory. You may also specify private key(s) as additional arguments on the command line (after the zone file).
- The command creates a file called 'xbalanque.fwd.signed'
  - The signed file contains the SAME zone information
  - Each record in the zone has an accompanying SIG record
  - The signed zone file is five times larger!

Here is part of the newly signed file

 ; File written on Wed Apr 10 15:18:22 2002
 ; dnssec_signzone version 9.2.1rc2
 xbalanque.net.          3600    IN SOA  xbalanque.net. tor.cs.colorado.edu. (
                                     2001031300 ; serial
                                     7200       ; refresh (2 hours)
                                     1800       ; retry (30 minutes)
                                     604800     ; expire (1 week)
                                     7200       ; minimum (2 hours)
                                     )
                     3600    SIG     SOA 1 2 3600 20020510211822 (
                                     20020410211822 53599 xbalanque.net.
                                     ueU49qSRlEsyC3pK4FjD0oHiQPGbn92KtIfN
                                     uhfPljKJpJbAy6lZCYHtBS1IdP3GnSz0/lSt
                                     oFp+vD/4MUAX4A== )
                     3600    NS      xbalanque.net.
                     3600    SIG     NS 1 2 3600 20020510211822 (
                                     20020410211822 53599 xbalanque.net.
                                     sbq/63PxSKWaCHfC/H7OFb/t9n6cIku6i7wg
                                     X0ypxbGmsPJMi02GKerecnOv5o45p/aXppWu
                                     Pwemkzopp1Xk6g== )
                     3600    A       10.0.0.1
                     3600    SIG     A 1 2 3600 20020510211822 (
                                     20020410211822 53599 xbalanque.net.
                                     ZkviPvqc4zfNWSRsBFttXrYV6E3hkYtO3hOo
                                     OmcgDciqetTNC5RUr6suZPUcC5uQ1x76whIQ
                                     J1fHC9RrFgoVTA== )
                     3600    TXT     "stealth DNS server for xbalanque.net"
                     3600    SIG     TXT 1 2 3600 20020510211822 (
                                     20020410211822 53599 xbalanque.net.
                                     HnxatPQJ8XPYxaAe1btjyso1NE+mtZKXTcVi
                                     uKZANzE3yOsnUYxPuPBsqsUxR+fKdRxAuX5u
                                     ceVGQUpsehjoeA== )
                     3600    KEY     256 3 1 (
                                     AQPjRG1hINd3E7sw/F/cM4B2ZDOM+GWQoxeR
                                     LucwjLhin8TLdo552YjBwAXTllDUbbpfljIS
                                     7JeY5TGcyMUK0V/F
                                     ) ; key id = 53599
             3600    NXT     boonie.xbalanque.net. A NS SOA TXT SIG KEY NXT
                     3600    SIG     NXT 1 2 3600 20020510211822 (
                                     20020410211822 53599 xbalanque.net.
                                     FMZcmL8agk+nD1wVjcsNcLe5qc9wM5nJ0ZcD
                                     56f42fsj6Dq/frFEg2EuqZ35cWFkimBQHbXS
                                     Jp264fmPOHSPQQ== )
  boonie.xbalanque.net.   3600    IN CNAME hunapu.xbalanque.net.
                     3600    SIG     CNAME 1 3 3600 20020510211822 (
                                     20020410211822 53599 xbalanque.net.
                                     SHIUy5UIb0yIBB+hO5o8+j/rMRAOv8k0uD+6
                                     QtgyoXaj6oUq6LODHY2r5YOHBy9M/fktLcXb
                                     wtz4GDqie5m/oQ== )
                     3600    NXT     bunky.xbalanque.net. CNAME SIG NXT
                     3600    SIG     NXT 1 3 3600 20020510211822 (
                                     20020410211822 53599 xbalanque.net.
                                     sNTRT4OBueAph+P4rlJzQ7Bk1C3F74n1hmXJ
                                     fFk+AM4Cs2YLdVxX8CAc4VvXjViGO+tJyNjZ

So, if a remote server received signed records like those above, it MUST already have the public key that was used to sign them in a 'trusted-keys' statement. Using that public key, the records can be authenticated. Until the 'chain of trust' is set up and the root servers sign the child zone keys and so on, the only way to guarantee authenticity is to securely obtain public keys from the servers you want to get authentic data from and install them into your own server.

Also take note of the NXT records, above. The NXT record is used to respond in the negative for some query. If, for example, a host B doesn't exist, then a query for B's address would return a NXT record. The record that gets returned is the NXT record that specifies where the record would have been if it were to exist (this is based on the canonical ordering of the zone data. So, if Hosts A and C exist, but B does not as we have already stated, then a NXT record like this might be returned:

    host-A   3600 IN  NXT  host-C

The record indicates that host-B doesn't exist, based on the canonical ordering.

References

DNS and Bind; Paul Albitz and Cricket Liu

4th edition; O'Reilly; 2001; ISBN 0.596.00158.4

The Purple Book (The Unix Sysadmin Handboook)

Chapter 16 covers DNS

The ISC website: http://www.isc.org/

Bind source (all versions)
ISC dhcpd (version 3 supports dynamic update)
DNSSEC FAQ - http://www.nominum.com/getOpenSourceResource.php?id=8
DNSSEC resources: http://www.dnssec.net/