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 inconsistent with reality
• Hostname collisions became frequent (anyone could name their machine ``whitehouse.gov'' if they wanted to)

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

• 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, ...

Domain structure

• Similar to the structure of a hierarchical file system
• 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 grows more specific right to left rather than left to right

     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

• Each host on a network generally has some association with some set of DNS records
• This may include:
  • IP address records (A and AAAA records)
  • Mail routing information (MX records)
  • Aliases which point to a ``canonical'' host name (CNAME records)
  • SRV records, which point to a service (generally SIP services: SIP example), although this has been expanding recently
  • TXT records, generally used for SPF records (though there is now an explicit SPF record also)

The domain name space

• There may be any number of branches at a node
• 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 — think about this if and when we really do see a large number of TLDs! What would it mean to go to ssh linprog if there is a TLD also named linprog?
• Sibling nodes must (of course!) have unique names
• There are actually quite a variety of DNS record types: DNS record types at Wikipedia

Hosts

• A domain name is just an index into the DNS database — and there can multiple records of various types associated with a given domain name
• The 'hosts' are domain names that we like to think of as pointing to individual machine information, though with virtualization now prevalent, even that isn't quite right. Probably better now to regard "hosts" as individual operating system instances.
• The hosts are related 'logically' usually by geography, or organization, or some other concrete or abstract association
• 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
• Nodes at the leaves of the tree usually represent individual "hosts"
• Interior nodes may point to both host information and to sub-domain information, though this is becoming less common than it was in the past.

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 8 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
• ARPA - the oddball, it was just for ARPA originally but is now infrastructure

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:

• 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
• As you can see from the IANA page, we are also now seeing IDN (internationalized domain name) entries

Name servers

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

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:

• BIND9 → much of the DNS server world is based on running BIND9
• DNSMASQ → very popular for small lab environments; allows tight coupling of DNS and DHCP
• DJBDNS → high quality, easy-to-maintain DNS server
• NSD → important alternative to BIND9; explicitly created to attack "monoculture" problem
• MARADNS → interesting DNS alternative; configuration is via Python-like files
• PDNSD → powerful caching abilities; every useful for situations involving unreliable DNS

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 can 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 from the Internic: here

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 may refer the first server to another machine
• A local server generally responds to a 'recursive query', as do such public servers such as Google's 8.8.8.8 and OpenDNS's 208.67.222.222
• A recursive query places most of the work on the original name server
• When a recursive query is made the name server is obliged to go find the answer or return an error message, though of course UDP makes no guarantee as to whether it arrives

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

What if you have an IPv4 or IPv6 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
• However, 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.

# 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

• Each time a local name server processes a recursive query it learns a lot of information
• This can be cached which might speed 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 can be 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
      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.

• 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 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

• 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. However, DJBDNS was mostly dormant for many years, so it doesn't natively support such things SRV records.
• All of these programs are very easy to use these days: You may (or may not) have to make some changes to /etc/resolv.conf to take advantage of whatever you do use.

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