FSU

Introduction to ``Domain Name Service'' (DNS)

Overview of DNS

In the early 1980s an architecture for DNS was proposed, based on the idea of ``resource records''. (See RFCs 882 and 883)

The InterNIC was set up to manage DNS; however, this responsibility was given over to ICANN (Internet Corporation for Assigned Names and Numbers), and now the ``InterNIC'' is just a website. One of the most important activities of ICANN is to accredit registrars; see ICANN's purpose page.

Today, there are hundreds of registrars, and prices for domain names have dropped to around $10-$20 per year.

Features

Software

Domain structure

     Hostname: xi.cs.fsu.edu. (read as "edu" then "fsu" then "cs" then "xi")
     Filename: /home/username/directory/file (read as "home" then "username" then "directory" then "file")

Host names

The domain name space

Hosts

The domain name space

Terms

The domain name space

Naming rules - the original 7 top-level domains were:

The domain name space

Naming rules - the current top-level domains are (courtesy of IANA):

The domain name space

International TLDs (ISO 3166-1 names) and some descendants:

Name servers

Zones

Name servers

Generally keep more than one name server for any given zone

  1. Redundancy: fault tolerance
  2. Load: localize it as much as possible

Name server software

Lots of software exists to do DNS (take a look at Wikipedia Comparison of DNS server software); names to know are:

Duties of a simple resolver

How does the name server resolve names

Root name servers

Technical operation information about the root servers can be found at http://www.root-servers.org

The root name servers are authoritative for the top-level domains (edu, org, us, dk, etc.)

List of root servers at from the Internic: here

Root name servers

Recursion

Mapping addresses to names (``reverse look-ups'')

What if you have an IPv4 or IPv6 number and want to find the host name?

Create a part of the domain name space that uses addresses as names 

Mapping addresses to names (``reverse look-ups'')

For example type:

# nslookup 128.186.120.2
Server:		128.186.120.179
Address:	128.186.120.179#53

2.120.186.128.in-addr.arpa	name = diablo.cs.fsu.edu.

# nslookup 2001:500:2c::254
Server:		128.186.120.179
Address:	128.186.120.179#53

Non-authoritative answer:
4.5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.2.0.0.0.0.5.0.1.0.0.2.ip6.arpa	name = ns.isc.afilias-nst.info.

Mapping addresses to names (``reverse look-ups'')

Now, as you can see in the previous slide, many nslookup versions will do this automatically.

Caching

Caching

time to live (TTL)

Configuring DNS: Client side

Setting up clients: configure /etc/resolv.conf

      domain cs.fsu.edu
      nameserver  127.0.0.1
      nameserver  128.186.120.179
      nameserver  128.186.120.178
      nameserver  8.8.4.4

Overview of DNS

The client will (generally) try the nameservers in order: 127.0.0.1, then 128.186.120.179, then 128.186.120.178, then (maybe) 8.8.4.4.

      nslookup chi
      Server:  TRANTOR.UMD.EDU
      Address:  128.8.10.14
 
      Name:    chi.cs.fsu.edu
      Address:  128.186.121.20

However, please note that caching daemons such as nscd can cause bizarre anomalies!

Caching-only servers

Setting up a caching-only nameserver is very easy to do these days: for example, on many Redhat platforms BIND's caching setup is available via yum -y caching-nameserver or yum -y bind, then just turn on default installation /etc/init.d/named start and change /etc/resolv.conf.

Debian and Ubuntu have a package bind9 that does similar work.

[root@sophie root]# nslookup
> www.yahoo.com
Server:         127.0.0.1
Address:        127.0.0.1#53
 
Non-authoritative answer:
www.yahoo.com   canonical name = www.yahoo.akadns.net.
Name:   www.yahoo.akadns.net
Address: 68.142.226.43
Name:   www.yahoo.akadns.net
Address: 68.142.226.45
Name:   www.yahoo.akadns.net
Address: 68.142.226.50
Name:   www.yahoo.akadns.net
Address: 68.142.226.35
Name:   www.yahoo.akadns.net
Address: 68.142.226.38
Name:   www.yahoo.akadns.net
Address: 68.142.226.39
Name:   www.yahoo.akadns.net
Address: 68.142.226.41
Name:   www.yahoo.akadns.net
Address: 68.142.226.42
>

Logging and named

errors: like most daemons, named errors (and other information) are routed through syslog, which you control with /etc/syslog.conf or /etc/rsyslog.conf:

Here is what you might see in /var/log/messages

[root@sophie root]# egrep -i named /var/log/messages
Feb 14 10:18:20 sophie named[7597]: starting BIND 9.2.4 -u named -t /var/named/chroot
Feb 14 10:18:20 sophie named[7597]: using 1 CPU
Feb 14 10:18:20 sophie named: named startup succeeded
Feb 14 10:18:20 sophie named[7597]: loading configuration from '/etc/named.conf'Feb 14 10:18:20 sophie named[7597]: no IPv6 interfaces found
Feb 14 10:18:20 sophie named[7597]: listening on IPv4 interface lo, 127.0.0.1#53Feb 14 10:18:20 sophie named[7597]: listening on IPv4 interface eth0, 128.186.120.8#53
Feb 14 10:18:20 sophie named[7597]: command channel listening on 127.0.0.1#953
Feb 14 10:18:20 sophie named[7597]: zone 0.in-addr.arpa/IN: loaded serial 42
Feb 14 10:18:20 sophie named[7597]: zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700
Feb 14 10:18:20 sophie named[7597]: zone 255.in-addr.arpa/IN: loaded serial 42
Feb 14 10:18:20 sophie named[7597]: zone 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 1997022700
Feb 14 10:18:20 sophie named[7597]: zone localdomain/IN: loaded serial 42
Feb 14 10:18:20 sophie named[7597]: zone localhost/IN: loaded serial 42
Feb 14 10:18:20 sophie named[7597]: running

Configuring DNS: Client side

Setting up static clients is quite easy with bind. Just change resolv.conf:

      domain cs.fsu.edu
      ; local nameserver
      127.0.0.1
      ; CS nameserver
      nameserver  128.186.120.178
      ; opendns, just for backup
      nameserver 208.67.222.222 

NOTE: DHCP clients by default overwrite /etc/resolv.conf; if you are configuring a DHCP client to use a fixed /etc/resolv.conf, you would have to look to see how to override the DHCP daemon's attempts to overwrite /etc/resolv.conf

Understanding DNS problem resolution

Traditionally, a client would try the listed nameservers in order: 127.0.0.11, then 128.186.120.178, then ``opendns''; each machine was given 30 seconds to fail, thus a name lookup failure could take 90 seconds to be reported with three servers listed.

A simple named.conf file

options {
	directory "/var/named";
	dump-file "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
	/*
	 * 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 * port 53;
};

// 
// a caching only nameserver config
// 
controls {
	inet 127.0.0.1 allow { localhost; } keys { rndckey; };
};

zone "." IN {
	type hint;
	file "named.ca";
};

zone "localdomain" IN {
	type master;
	file "localdomain.zone";
	allow-update { none; };
};

zone "localhost" IN {
	type master;
	file "localhost.zone";
	allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
	type master;
	file "named.local";
	allow-update { none; };
};

zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.
         0.0.0.0.0.0.0.ip6.arpa" IN {
        type master;
	file "named.ip6.local";
	allow-update { none; };
};

zone "255.in-addr.arpa" IN {
	type master;
	file "named.broadcast";
	allow-update { none; };
};

zone "0.in-addr.arpa" IN {
	type master;
	file "named.zero";
	allow-update { none; };
};

More on caching nameservers

NAT and APIPA

The idea behind NAT (network address translation) was two-fold: 1) we were running out of IPv4 addresses (down to less than 5% free from the latest reports, I believe; IPv4 Address Exhaustion) and 2) it provides some amount of security by creating isolated networks. The idea is that you cannot route into these networks; a NAT router instead do a translation trick to get you in and out of the network. This allows networks like 192.168.*.* and 10.*.*.* to be used many, many groups.

If you deal with APIPA (169.254.*.*) addresses (see WS2008, pp. 263-264), these are the literally random addresses that Microsoft seems to delight in throwing out if there's nothing else available. Microsoft, Sun, and Apple have actually put out an RFC on these non-routable addresses: RFC3927.

Let's look at the old .tlh.fl.us domain

Key Hays at ACNS was kind enough to send me a copy of the actual BIND file used for the ancient .tlh.fl.us domain. Let's take a look:

$TTL 1d
@	IN	SOA	dns1.fsu.edu.	hostmaster.acns.fsu.edu. (
			2006070500 ;Serial YYYYMMDDNN
			3600	;refresh every 1 hours
			900 	;retry after 15 minutes
			3600000 ;expire after 1000 hours - about 42 days
			86400	;minimum ttl of 1 days )
			)
@	IN	NS	dns1.fsu.edu.
	IN	NS	dns2.fsu.edu.
	IN	NS	name.ufl.edu.
	IN	NS	t1dns1.anl.gov.
	IN	NS	tldns2.anl.gov.
;
; Centel's  FSU_INTERNET
; 
;
$ORIGIN tlh.fl.us.
;
; Centel's  FSU_PEERING connected via Sprint router 576_1_ENET (en02)
fsu	IN	A	198.102.72.5
	IN	HINFO	CISCO ROUTER
RMON-MAN IN	A	198.102.72.6
RMON-MAN2 IN	A	198.102.72.7
SMON-MAN IN	A	198.102.72.8
;
;i**Birdsong Nature Center**
freenet		IN	CNAME	tfn.net.	;Jun02-2006 as per ***REDACTED***
www.freenet	IN	CNAME	www.tfn.net.	;Jun02-2006 as per ***REDACTED***
;
; as of 11/15/96 we are no longer paying for suranet, but they continue to 
; give us free connectivity to the internet.
;suranet	IN	A	198.102.72.10
;
; Beaches & Shores on Tennessee St. = depman
; supported by ACNS contract with Beaches & Shores
;depman	IN	A	198.102.72.15
;
firn	IN	A	198.102.72.20
	IN	HINFO	CISCO ROUTER
;
; Centel's FSU_PEERING connected to FSU_PEERING (en01)
FSU-Centel-peering IN	A	198.102.72.25
	IN	HINFO	CISCO ROUTER
;
; Community colleges Library Automation - sponsored by FIRN
;ccla	IN	A	198.102.72.35
;
; supreme court of the state of florida - sponsored by FIRN
; ***REDACTED***
supreme-court	IN	A	198.102.72.40
	IN	HINFO	CISCO ROUTER
;
; Leon County School Board - sponsored by SCRI
; ***REDACTED***
; 12/7/99 - moved to a FIRN closed users group.
;lcsb	IN	A	198.102.72.50
;	IN	HINFO	CISCO 4700
;
; Jefferson County School Board - sponsored by FIRN
;jcsb	IN	A	198.102.72.55
;
; Tallahassee Community College - sponsored by FIRN
;tcc	IN	A	198.102.72.60
;	IN	HINFO	"Who:***REDACTED***" "***REDACTED***"
;tcc-firewall IN	A	198.102.72.61
;
;  Wakulla Co Schools - sponsored by FIRN
wakulla	IN	A	198.102.72.70
;
;  Cisco in Tallahassee?
cisco	IN	CNAME	cisco.webanchor.com.
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
;
; exchange  -  ***REDACTED***
;
exchange IN	MX	10 mailer.fsu.edu.
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
; wildflorida  -  ***REDACTED***
;
wildflorida IN	CNAME	sysntw2.acns.fsu.edu.
www.wildflorida IN  CNAME   sysntw2.acns.fsu.edu.
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
; usdcnf - US District Court of North Florida
;
;          ***REDACTED***
;          United States District Court 
;          110 East Park Avenue, Suite 122 
;          Tallahassee, Florida  32301
;          ***REDACTED***
;
usdcnf	IN	MX	10 mailer.fsu.edu.
ccmgate.usdcnf IN MX	10 mailer.fsu.edu.
p4Fll29.usdcnf IN MX	10 mailer.fsu.edu.
paflnd.usdcnf IN MX	10 mailer.fsu.edu.
pcflnd.usdcnf IN MX	10 mailer.fsu.edu.
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
; Delegated zone for .ci.tlh.fl.us.
;
; Contact(a):	***REDACTED***
;		City of Tallahassee, municipal government
;		***REDACTED***
;		***REDACTED***
;
; Contact(t):	***REDACTED***
;		***REDACTED***
;		City of Tallahassee, municipal government
;		***REDACTED***
;		***REDACTED
;
; Contact (other) ***REDACTED***
;		***REDACTED***
;
;ci	IN	NS	ns1.ci.tlh.fl.us.
;	IN	NS	int3.state.fl.us.
;ns1.ci IN A	68.16.31.2	
; Three records above replaced with this one per verbal
; request from ***REDACTED***, SLG 17 Feb 2006
ci	IN	NS	cityhall2.ci.tlh.fl.us.
cityhall2.ci IN	A	167.75.254.249
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
; Delegated zone for .hcs.tlh.fl.us.
;
; Contact(a,t):	***REDACTED***
;		Hayes Computer Systems
;		1311 Paul Russell Road
;		Tallahassee, FL 32301
;		***REDACTED***
;		***REDACTED***
;
hcs	86400	IN	NS	hcstlh01.hcs.tlh.fl.us.
	86400	IN	NS	cntfl.com.
hcstlh01.hcs 86400 IN	A	199.44.4.2
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
; Delegated zone for .tmrmc.tlh.fl.us.
;
; Contact(a,t):	***REDACTED***
;		Tallahassee Memorial Regional Medical Center
;		Magnolia Drive and Miccosukee Street
;		Tallahassee, FL 32308
;		***REDACTED***
;		***REDACTED***
;
#tmrmc	86400	IN	NS	tmrmc.tlh.fl.us.
tmrmc	86400	IN	NS	cntfl.com.
	86400	IN	NS	server.cntfl.com.
tmrmc	86400	IN	A	199.44.40.2




The upshot of all this "DNS" stuff

I have gone through a lot of historical information; much of this is simply based on practice, and is certainly not written in stone.

Remember: DNS is just a database. If you aren't using DNSSEC, it's not even authenticated.

Here's a practical example of treating DNS as a simple database. I have mentioned Spamhaus before in class. Here's a sample of the Spamhaus database being used to detect spam:

2010-10-17 06:20:48 someserver postfix/smtpd[13566]: NOQUEUE: reject: RCPT
  from business-188-111-104-077.static.arcor-ip.net[188.111.104.77]: 
  554 5.7.1 Service unavailable; Client host [188.111.104.77] blocked 
  using xbl.spamhaus.org; http://www.spamhaus.org/query/bl?ip=188.111.104.77; 
  from= to= proto=SMTP helo=business-188-111-104-077.static.arcor-ip.net

So how does Spamhaus work? As mentioned before, it employs DNS to provide this service. DNS is just a database.

So let's ask it about the address that the world sees as our mail server as, using the conventions the Spamhaus has established for querying its database of known spammers. That means using a concocted DNS query that actually encodes our question:

$ dig 13.122.186.128.zen.spamhaus.org

; <<>> DiG 9.6.2-P2-RedHat-9.6.2-4.P2.fc11 <<>> 13.122.186.128.zen.spamhaus.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8330
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;13.122.186.128.zen.spamhaus.org. IN	A

;; AUTHORITY SECTION:
13.122.186.128.zen.spamhaus.org. 300 IN	SOA	need.to.know.only. 
        hostmaster.spamhaus.org. 1010211330 3600 600 432000 150

;; Query time: 43 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Oct 21 09:43:34 2010
;; MSG SIZE  rcvd: 113

Good! It doesn't report anything about this address, which means that this machine has not been reported as a spammer.

Now let's choose an IP address that just contacted our mailserver a few minutes ago, 87.114.37.48:

$ dig 48.37.114.87.zen.spamhaus.org

; <<>> DiG 9.6.2-P2-RedHat-9.6.2-4.P2.fc11 <<>> 48.37.114.87.zen.spamhaus.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63031
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;48.37.114.87.zen.spamhaus.org.	IN	A

;; ANSWER SECTION:
48.37.114.87.zen.spamhaus.org. 900 IN	A	127.0.0.11

;; Query time: 43 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Oct 21 09:30:04 2010
;; MSG SIZE  rcvd: 63

It comes back with an A record for this address, 127.0.0.11. Does that mean that we now have a legitimate IP number for that concocted DNS name, 48.37.114.87.zen.spamhaus.org? Of course not; the A record that we received with the IP address 127.0.0.11 does not literally mean that. Instead, what it does mean is that this ip number, 87.114.37.48, is listed somewhere with Spamhaus, and we should be wary of accepting email from this address. (It turns out that 127.0.0.11 specifically means that this IP number is in a range of IP numbers that should not be sending email. The gory details are here.)

The upshot, continued

While we have mostly talked about A, AAAA, MX, PTR, and NS records in class, there is also a general record called the "TXT" record.

One way that these TXT records can used is for publishing SPF (Sender Policy Framework) records. These records can be used (optionally!) to publish rules to help determine legitimate originators of email for a given domain. (There are now also explicit SPF records in DNS, but I don't know of anyone yet using this record type.)

Here's a typical SPF TXT record. It's from Microsoft (which has been quite involved in the SPF and SenderID specifications):

$ dig microsoft.com TXT

; <<>> DiG 9.6.2-P2-RedHat-9.6.2-4.P2.fc11 <<>> microsoft.com TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5105
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;microsoft.com.			IN	TXT

;; ANSWER SECTION:
microsoft.com.		3600	IN	TXT	"v=spf1 mx include:_spf-a.microsoft.com
 include:_spf-b.microsoft.com include:_spf-c.microsoft.com include:_spf-ssg-a.microsoft.com
 ip4:131.107.115.212 ip4:131.107.115.215 ip4:131.107.115.214 ip4:205.248.106.64
 ip4:205.248.106.30 ip4:205.248.106.32 ~all"

;; Query time: 224 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Oct 21 09:59:20 2010
;; MSG SIZE  rcvd: 506

If you check hp.com, you see that they provide no SPF TXT records.

If you check ibm.com, they have what initially seems to be an odd SPF record: it says that nobody can legitimately send email from "@ibm.com":

$ dig ibm.com TXT

; <<>> DiG 9.6.2-P2-RedHat-9.6.2-4.P2.fc11 <<>> ibm.com TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21146
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ibm.com.			IN	TXT

;; ANSWER SECTION:
ibm.com.		600	IN	TXT	"v=spf1 -all"

;; Query time: 179 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Oct 21 10:11:37 2010
;; MSG SIZE  rcvd: 49

It turns out that all email from ibm.com actually should come from subdomains such "@us.ibm.com" and "@de.ibm.com":

$ dig us.ibm.com TXT

; <<>> DiG 9.6.2-P2-RedHat-9.6.2-4.P2.fc11 <<>> us.ibm.com TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17506
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;us.ibm.com.			IN	TXT

;; ANSWER SECTION:
us.ibm.com.		600	IN	TXT	"v=spf1 ip4:32.97.182.0/24
 ip4:32.97.110.0/24 a:d25xlcore010.ca.ibm.com a:isource.boulder.ibm.com
 a:g01zcdsmtp002.ahe.pok.ibm.com a:g01zciwass001.ahe.pok.ibm.com ~all"

;; Query time: 46 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Oct 21 10:18:03 2010
;; MSG SIZE  rcvd: 206

$ dig de.ibm.com TXT

; <<>> DiG 9.6.2-P2-RedHat-9.6.2-4.P2.fc11 <<>> de.ibm.com TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20083
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;de.ibm.com.			IN	TXT

;; ANSWER SECTION:
de.ibm.com.		600	IN	TXT	"v=spf1 mx ~all"

;; Query time: 270 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Oct 21 10:35:28 2010
;; MSG SIZE  rcvd: 55