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

Host name to IP number mapping was originally done by downloading a static file
The UNIX version of this file is /etc/hosts (the file that we ftp'd in was called hosts.txt)
The central file was maintained by the Stanford Research Institute Network Information Center (SRI-NIC)
As the Internet grew this scheme became unworkable
The size of the file became too large
The load on SRI-NIC site became too heavy
The file was always inconsistent with reality
Hostname collisions became frequent (anyone could name their machine ``whitehouse.gov'' if they wanted to)

Overview of DNS

In 1984 Paulk Mockapetris of USC designed the architecture of DNS. It's based on the idea of ``resource records''. 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. Today, there are hundreds of registrars, and prices for domain names have dropped under $10.

Features

Local control, with each segment is updated locally
Global access, with each segment is available (almost) immediately to the rest of the world upon update
Robustness, to be achieved through replication
Adequate performance, to be achieved through caching

Software

Servers: called name servers, contain information about some segment of the network and make it available to clients
Examples of DNS servers: MaraDNS, BIND, DJBDNS, dnsmasque, ...
Client: resolvers, a set of library routines that resolve names by accessing a server (originally a separate library, like libresolv.a, now usually part of libc.a)
Domain name server software is also available for non-UNIX platforms, such as Windows 2008 and Macintosh OS X.

Domain structure

Similar to the structure of a hierarchical file system
The root's name is the null label `` `` but is written as a single dot ``.''
Each node represents a 'domain'
Every domain is named
The full domain name is the sequence of labels from the domain to the root, separated by periods
Unlike a file system pathname the name is read from leaf to root (right to left rather than left to right)

     xi.cs.fsu.edu

Domain management

Each domain may be managed by a different organization
The organization may divide itself into subdomains
Then delegate responsibility for maintaining them
ICANN (currently) manages the ``provisioning'' of top-level domains

Domain management

What is ICANN?

The Internet Corporation for Assigned Names and 
Numbers (ICANN) is responsible for managing and 
coordinating the Domain Name System (DNS) to ensure 
that every address is unique and that all users of 
the Internet can find all valid addresses. It does 
this by overseeing the distribution of unique IP 
addresses and domain names. It also ensures that 
each domain name maps to the correct IP address.

ICANN is also responsible for accrediting the 
domain name registrars. "Accredit" means to identify 
and set minimum standards for the performance of 
registration functions, to recognize persons or 
entities meeting those standards, and to enter 
into an accreditation agreement that sets forth 
the rules and procedures applicable to the 
provision of Registrar Services.

Host names

Each host on a network has a domain
The domain points to information about the host
This may include:
- An IP address (A records)
- Mail routing information (MX records)
- Aliases which point to the real (``canonical'') host name (CNAME records)

The domain name space

There may be any number of branches at a node
Some implementations limit the tree's depth
The suggested length is 12 or less characters
A domain name that is written relative to the root is called a 'fully-qualified domain name' - FQDN
Names without trailing dots (``leading dots'') are sometimes interpreted as relative to some domain other than root
Sibling nodes must have unique names
The name of a domain is the domain name of the node at the top of the domain (example purdue.edu)
Again, similar to a file system
A node is in multiple domains
So, a domain is just a sub-tree of the domain name space (``sub-domain'')
Must not use underscore ("_"), although other similar naming schemes (prominently, NIS) have allowed this.

Hosts

Where are the hosts?
A domain name is just an index into the DNS database
The 'hosts' are domain names that point to individual machine information
The hosts are related 'logically' usually by geography or organization
They are NOT necessarily related by network or IP address or hardware type
You could have 10 different hosts on 10 different networks in ten different countries all in the same domain (hp.com)
Nodes at the leaves of the tree usually represent individual hosts
Interior nodes may point to both host information and to sub-domain information For example, ``hp.com'' is both the name of a domain and the name of a machine that routes mail

The domain name space

Terms

top-level domain (TLD): a child of root (edu)
first-level domain: a child of root (edu)
second-level domain: a child of 1st level domain (fsu.edu)

The domain name space

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

com - commercial organizations
edu - educational organizations
gov - governmental bodies
mil - military organizations
net - networking organizations
org - non-commercial organizations
int - international organizations

The domain name space

International names (ISO 3166-1 names)

2-letter designations are reserved for each country (e.g.: DE - Germany, DK - Denmark, CH - Switzerland)
Each country may organize its domain space however it wishes
For example, Australia uses edu.au and com.au
And Britain uses co.uk - corporations, ac.uk - academic community
And the U.S. uses states: fl.us, then cities: tlh.fl.us

Name servers

Zones

A program that stores information about the domain name space is called a Domain Name Server
A name server generally has complete information about some part of the domain name space
The subspace is called a 'zone'
The server is said to have 'authority' for one or more zones
What is the difference between a zone and a domain?
A zone is a connected subset of tree nodes in domain name space, and which has a master DNS server

Name servers

Types of name servers

Primary (master) → Gets the data for its zones from flat data (text) files
Secondary (slave)
1. Gets the data for its zone from another server
2. It periodically updates its local data by copying the primary master's files
3. This is called a 'zone transfer'

Name service clients

These are the clients that access name servers
In BIND these are a set of library routines
These are compiled (or linked via shared library) into ssh, sftp, scp, telnet, etc. so that these programs will use DNS to resolve names (``gethostbyname()'' and others)

Duties of a simple resolver

Sometimes called a 'stub resolver'
Querying a name server
Interpreting the response
[Perhaps send more queries]
Returning a reply to the program that it is servicing

How does the name server resolve names

If the name is in the name server's zone then it can give the resolver an immediate 'authoritative' response
If not, then the name server must search the domain name space for an answer
It only needs one piece of information to get started: the location of a root-level server

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 http://www.internic.net/zones/named.root

Root name servers

They can point you to the name servers for each of the top-level domains
They, in turn can point you to their subdomains, etc. until the name is resolved

Recursion

The first name server can make multiple requests
Successive requests refer the first server to another machine
A local server generally responds to a 'recursive query'
A recursive query places most of the work on a single name server
When a recursive query is made the name server is obliged to go find the answer or return an error message

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

What if you have an IP number and want to find the host name?

This is useful to make output more readable
Used for some security checks
This was easy with the old /etc/hosts tables
BUT the DNS data is indexed only by name
Could do an exhaustive search
The clever solution:

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.

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

Now, as you can see, newer nslookup versions will do this automatically.

Caching

Each time a local name server processes a recursive query it learns a lot of information
This is cached which speeds up successive queries
Example:
- Say our server has already looked up the address of eecs.berkeley.edu
- This means it has cached the name servers for both eecs.berkeley.edu and berkeley.edu
- If we now make a query for baobab.cs.berkeley.edu the local server can skip the root-level query and go right to berkeley.edu

Caching

time to live (TTL)

A TTL is the amount of time that information is cached before it is discarded
The trade-off is between consistency and performance
Remember, caching is also performed by other actors: in particular, nscd can cache names, and it uses its own TTLs, not those of the actual RRs. Applications such as browsers often also do a good bit of caching of ip values.

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

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

you can comment out 127.0.0.1 then use nslookup and see results
or put a bogus address in the first entry to see if the resolver tries number 2
the changes should take effect immediately

      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 CentOS, BIND's caching setup is available via yum -y caching-nameserver, then just turn on default installation /etc/init.d/named start and change /etc/resolv.conf

[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:

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*							/dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;news.none;authpriv.none;cron.none		/var/log/messages

# The authpriv file has restricted access.
authpriv.*						/var/log/secure

# Log all the mail messages in one place.
mail.*							/var/log/maillog


# Log cron stuff
cron.*							/var/log/cron

# Everybody gets emergency messages
*.emerg							*

# Save news errors of level crit and higher in a special file.
uucp,news.crit						/var/log/spooler

# Save boot messages also to boot.log
local7.*						/var/log/boot.log

#
# INN
#
news.=crit                                        /var/log/news/news.crit
news.=err                                         /var/log/news/news.err
news.notice                                       /var/log/news/news.notice

And here is what you 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

DNS 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

Setting up caching-only BIND server used to be popular; as mentioned before, then nscd appeared to be more popular. nscd however has been problematic: it has been my experience that it can cache old or bad data, and fail to respect TTLs. (p. 504 of LAH.)
Relatively recently, dnsmasq has appeared, which incorporates support for most of a local DNS server and also includes a DHCP server.
maradns and djbdns are both more traditional and more security-aware caching nameservers.
All of these are very easy to do these days: You may (or may not) have to make some changes to /etc/resolv.conf

[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

NAT and APIPA

The idea behind NAT (network address translation) was two-fold: 1) we were running out of IPv4 addresses (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 it 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.

Here's a typical SPF 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 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

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

Overview of DNS

Features

Software

Domain structure

Domain management

Domain management

Host names

The domain name space

Hosts

The domain name space

The domain name space

The domain name space

Name servers

Name servers

Name servers

Name service clients

Duties of a simple resolver

How does the name server resolve names

Root name servers

Root name servers

Recursion

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

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

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

Caching

Caching

Configuring DNS: Client side

Overview of DNS

Caching-only servers

Logging and named

Configuring DNS: Client side

DNS resolution

A simple named.conf file

More on caching nameservers

NAT and APIPA

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

The upshot of all this "DNS" stuff

The upshot, continued

Logging and `named`

A simple `named.conf` file

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