Difference between revisions of "Create a DNS Entry"

From CSLabsWiki
(Creating A records: Added need to increment serial number)
Line 28: Line 28:
talos IN A
talos IN A
metapod IN A
bacon IN A
@ IN A
@ IN A
Line 46: Line 46:
3 IN PTR talos.cslabs.clarkson.edu.
3 IN PTR talos.cslabs.clarkson.edu.
10 IN PTR metapod.cslabs.clarkson.edu.
10 IN PTR bacon.cslabs.clarkson.edu.

Latest revision as of 23:36, 27 September 2016

The Domain Name System is a UDP service offered by various hosts on the internet to resolve user-friendly domain names to IP addresses. The service is arranged hierarchically, with delegation proceeding from the "root zone" of 13 root name servers, through each component of a domain name (from root to "com.", from "com." to "example.com.", etc.).

Clarkson University is authoritative (delegated by the root zone) for the domain clarkson.edu. As per arrangements with the university, our nameserver at (Talos) is the authoritative nameserver for the cslabs.clarkson.edu subdomain.

Presently, it runs BIND9 on Debian. The instructions below should be valid for any instance of BIND9, so long as you can determine the location of the configuration files. (Debian, in particular, likes to break the configuration into several different files.)

Finding Configuration Files

On most systems, the configuration is somewhere in /etc; on CRUX systems, I found it in /etc/named.conf, whereas it typically lives (in the form of several hierarchically-included files) in the directory "/etc/bind" on Debian hosts (as Talos), also as named.conf.

This page does not cover the configuration of the named server; the only thing that is important is that, somewhere in the config or something included in the config, you should find a directive like:

zone "some.subdomain.org" in {
        type master;
        file "/path/to/zonefile"; 

In particular, on Talos, this configuration is found in named.conf.local, and the zone serves the cslabs.clarkson.edu domain. Wherever you find the file, open it and be prepared to edit it.

Creating A records

A DNS A-record is an address record, and is the fundamental record used to map names to IP addresses. This is arguably the most important type of record, with many of the others being used for administrative or domain-specific tasks.

The zone file you are editing probably already has a number of A-records; here are a few examples:

talos                   IN A  
bacon                   IN A  
@                       IN A  

The "@" symbol indicates the root (relative to the zone--in this case, cslabs.clarkson.edu). Note that none of the records end with a dot; doing so would cause the name to be absolute (and thus, unless it were cslabs.clarkson.edu., outside of the zone).

Follow the template to add any subentry to the zone. Then increment the serial number at the top of the file. When you are done, run rndc reload, and the zones will be reloaded.

Verifying the status: On a client with dig, run dig @nameserver fully.qualified.domain.name, and you should see a response containing your A-record.

Creating reverse records

While not strictly necessary, having a reverse lookup (resolving IP addresses to domain names) can be useful, especially when diagnosing issues. Reverse lookups for the IP address w.x.y.z are accomplished by resolving a name z.y.x.w.in-addr.arpa for PTR records, and so your nameserver will have to be authoritative over zones corresponding to the IP addresses it will map names to. Talos, in particular, is authoritative over 144.153.128.in-addr.arpa and 145.153.128.in-addr.arpa--you will want to look up and open for editing the zone files associated with these zones.

Once you have found the zone file corresponding to the correct reverse name, simply add the appropriate reverse line. Continuing the last example:

3                       IN PTR  talos.cslabs.clarkson.edu.
10                      IN PTR  bacon.cslabs.clarkson.edu.

As always, follow the template and increment the serial number and run rndc reload when you are done.

Verifying the status: On a client with dig, run dig @nameserver -x dotted.quad.ip.address, and you should see a response containing the PTR record with the correct name.

Other record types

While you probably won't encounter them for simple tasks like this, you should at least be aware of some other record types you might encounter:

  • CNAME records give aliases to other names. For example, if web is a CNAME to web3, then resolving "web." will result in the same address as "web3.".
  • AAAA records contain IP6 addresses. The reverse addresses for IP6 are slightly different from IP4, but have the same general idea.
  • TXT records contain arbitrary text.
  • MX records refer mail exchangers. Mail servers (usually using SMTP) will try to deliver mail to the server specified in an MX record (usually another domain name). For example, the MX of "clarkson.edu" is "mail.clarkson.edu", which is the Barracuda spam filter for receiving mail destined to addresses "@clarkson.edu".
  • SRV records generalize this specialization of MX records for SMTP to arbitrary services. They require slightly more contrived domain names, but allow various services to automatically redirect to appropriate servers upon being given the domain root (or some other special name).
  • NS records contain administrative and authoritative information about the server serving this zone.
  • Various DNSSEC record types exists as well.