Internet Technologies I, Session 5

Internet Technologies I, Session 5. Client/server applications: DNS. 10 November 01.

1. DNS: Introduction

Domain Name Service (DNS) maps between names and information associated with those names. Most commonly it's used for mapping between between names and IP addresses, but in fact DNS understands a variety of data types. DNS is worth examining closely for a variety of reasons:
- It's ubiquitous. Applications now generally allow users to specify network resources by name. Actual packet transmission though involves specifying endpoints in terms of IP addresses. Name-to-number translation needs to happen before packet transmission can proceed. (Another way to make the point is to observe that IP, TCP, and UDP are entirely ignorant of DNS).
- It has a distinctive architecture (it's client/server--there are all these name servers listening on port 53--but it's a true distributed system rather than one involving simple client/server interaction).
- Name allocation in the Internet is currently a highly-charged political matter.

2. DNS Resources

Books
- Albitz and Liu, DNS and BIND. 4th ed. O'Reilly.
Newsgroups
- comp.protocols.tcp-ip.domains
- comp.protocols.dns.bind
FAQs
- comp.protocols.tcp-ip.domains FAQ
IETF DNS-related standardization
- DNS extensions working group
- DNS operations working group
Websites
- U.S. federal government policy
- ICANN (Internet Corporation for Assigned Names and Numbers); see www.icannwatch.org for a critical view of ICANN; also Michael Froomkin's papers
- DNSRD (DNS Resources Directory)
- Men&Mice DNS resources
Tools
- dig and nslookup (on Unix/Linux; other tools available for other operating systems--see in particular the DNSRD tools section)

3. Motivation for the system--human:computer::name:number

We (humans) do better with names (and given an economy in which the Internet plays a significant role, there's added incentive to attach real-world names to associated network resources)
Machines do better with numbers
- Space (IP addresses consume 32 bits; domain names consume 8 x number-of-characters-in-the-name bits)
- Computation (packet forwarding, and the underlying operations like bit-masking it relies on, as we've seen, are relatively straightforward processes when they operate on 32-bit addresses; routing would be far less efficient if it operated on domain names--think about what a router would need to know and do if the destination address it saw on a packet took the form (say) stumpy.hp.com)
So, how about if we let each do its thing, and have some system for translating between names and numbers?; that system is DNS.

4. Models

Centralized
- Name god has a book (of name / number entries); you ask the name god to put new entries in the book; you ask the name god to look up existing entries in the book
- But this just won't scale. The name god will be very busy scribbling in the book. And either the name god's server (if you do remote lookups against The Book) or (if you periodically download copies) the network (or both) will be very busy.
- But this is how the Internet worked 'til the mid-'80s: name-to-number mappings were held in a file called HOSTS.TXT that you could ftp from sri-nic. For a taste of name service '80s-style, consider M. Muuss on the tcp-ip mailing list, 3 February 84:
```
The strategy that we use at BRL is to download the NIC table to ONE
machine once a night (at 0400 EST), and redistribute it to all BRLNET
machine locally. The procedure  is entirely automated, and makes heavy
use of the UNIX RSH/RCP facility (Bravo, Berkeley!).
    
```
Decentralized
- Name space
  - Structure the name space--in a hierarchical, tree-structured way
    - There's a specific syntax for representing positions in this space: domain names take the form "x.y.z", i.e. a set of labels separated by period, most general term right-most
    - The top-most tier of the tree is more or less frozen: we have a set of functional TLDs (which however ICANN is now in the process of expanding--.info, .biz, and .name are now in play; .museum is just around the corner) and a set of TLDs derived from ISO country codes [in a truly global Internet, wouldn't it be nice if we didn't have this functional vs. geographical schizophrenia?]
  - Delegate authority over different subtrees of the namespace to different organizations. What it means to be given a domain name is this:
    - Someone--that someone would be the authority for the higher-level domain--gives you authority over part of an existing domain: e.g. the .edu authority delegates responsibility for marlboro.edu to Marlboro College
    - You can then:
      - Make up whatever names you like in the subdomain
      - Associate IP addresses (or other info) with those names
        
        DNS has a notion of resources and 'resource records', and knows about several types of these: an 'A' record maps a name to an IP address; a 'CNAME' record defines an alias, i.e., it maps a name to another name; a 'PTR' record maps an IP address back to a name; and so on.
        It's crucial to understand that there's no necessary correspondence between the structure of the namespace and physical network topology. All the names inside a domain may be associated with a single IP address block, but they need not be (take a simple case--all the names under marlboro.edu happen to be associated with 12.6.230.x-12.6.231.x or 216.114.150.x-216.114.151.x addresses, but consider what would happen if we used some hosting service for our websites or opened a campus in Honolulu). Similarly, all the IP addresses in a given block may be associated with names in a given domain, but they need not be (for example almost all the 12.6.230.x-12.6.231.x and 216.114.150.x-216.114.151.x addresses are associated with marlboro.edu domain names, but there are a few exceptions--one is that 216.114.150.12 is associated with www.unitedwaywindham.org, a domain we're hosting on zonorus).
      - Subdelegate!
  - Structuring the name space removes the possibility of name conflict (as long as sibling nodes in the tree have distinct names, there's no possibility of confusion). Delegating authority distributes the administrative load of the system.
- Distributed database
  - There's a tree of servers, corresponding to the namespace tree (not necessarily in one-to-one correspondence: a given server typically holds information for an entire subtree or 'zone' (e.g. everything under marlboro.edu; or everything under marlboro.edu except what's been subdelegated); in fact a given server may hold information for many disjoint subtrees (e.g. the nameserver running on 12.6.230.2 is authoritative for marlboro.edu, marlboro.vt.us, daveweisberg.com, and several other domains)
  - Each nameserver (I except the case of so-called 'caching-only' servers, which don't store any authoritative information, only what they've learned from others) knows
    - Information for some domain or domains. This information takes the form of DNS resource records. Here's a chunk from the file for the domain marlboro.edu. Each line is a resource record, and takes the form name (in this case interpreted relative to marlboro.edu) + 'class' (always IN = Internet) + 'type' (= resource record type) + data.
      ... akbar IN A 12.6.230.2 IN MX 0 akbar IN MX 10 crinifer big IN A 12.6.230.3 snowy IN A 12.6.230.4 ...
    - Where the root name server is (well, are--there are several)
    - Where the nameservers for any subdomains are; and by virtue of these last two features, it's possible to get from any nameserver to any node in the name space, and to do so economically
  - How resolution works
    - Client application wants to send to some destination; has destination's domain name but not the IP
    - Application hands off to a piece of client-side software called the "resolver" that formulates and sends a DNS query to the local name server; it knows the server's IP via some kind of prior configuration, manual or otherwise. DNS messages have a specific format:
      id (16 bits; request identifier) flags (16, distributed as follows: QR (1; 0 = query, 1 = response) Opcode (4; 0 = standard...) AA (1; 1 = I claim to be authoritative for this data) TC (1; 1 = stuff get truncated (I hit the message-size limit), resend with TCP) RD (1; 1 = 'recursion desired' = could you do all the work and give me the answer) RA (1; 1 = I know how to recurse) Stuff (3; must be all zeros) Rcode (4; 0 = no error...) number of questions (16) number of answers (16) number of authority records (16) number of additional records (16) questions answers authorities additionals
      ...where a question takes the form domain name (encoded as described by Comer in 24.15) + query class + query type (A...), and where answers, authorities, and additionals are resource records of the form:
      domain name type (16) class (16) time-to-live (32; validity-in-seconds) resource data length (16) resource data
    - If the server is "authoritative" for the information requested, it returns the answer; otherwise (we approximate the truth in three steps)
      - It goes to the root nameserver--i.e., it makes itself a client to another nameserver--and follows the tree down 'til it gets to the nameserver authoritative for the queried name; then returns the answer to the original client
      - Also, the server should cache the response; so what really happens is, before you start chasing through the whole chain of servers starting at the root, look in the cache and see if you've already got the answer (if so, hand it directly to the original client)
      - Also cache the locations of all the intermediate name servers!
    - Here's an example of an interaction between a DNS client and a nameserver--as it appears in the "dig" DNS utility. I tell dig the nameserver I want to query ("@akbar"), the domain I'm interested in ("hvo.wr.usgs.gov"), the kind of resource record I'm looking for ("a"), and I ask it to print the query as well as the response ("+qr"). Notice that we only see the interaction between the client ("dig") and the nameserver it's directly querying--but not the interactions between akbar and the chain of servers it traverses to discover the server authoritative for wr.usgs.gov. This is typical of client queries: the client makes a "recursive" query, meaning that the server should go off and ask as many servers as it has to to find the answer to the client's question, and only then report back to the client. By contrast when a server queries another server it makes an "iterative" query, in which case the server queried returns either the answer (if it's authoritative for the domain in question) or the location of the nameserver one step closer to the authority for the domain--but it doesn't query any additional nameservers on behalf of the questioner.
      [root@ns /root]# dig @akbar hvo.wr.usgs.gov a +qr ; <<>> DiG 9.1.3 <<>> @akbar hvo.wr.usgs.gov a +qr ;; global options: printcmd ;; Sending: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60959 ;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;hvo.wr.usgs.gov. IN A ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60959 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;hvo.wr.usgs.gov. IN A ;; ANSWER SECTION: hvo.wr.usgs.gov. 259181 IN A 130.118.4.30 ;; AUTHORITY SECTION: wr.usgs.gov. 259181 IN NS ns.wr.usgs.gov. wr.usgs.gov. 259181 IN NS ns2.wr.usgs.gov. wr.usgs.gov. 259181 IN NS ns.cr.usgs.gov. wr.usgs.gov. 259181 IN NS ns.er.usgs.gov. ;; ADDITIONAL SECTION: ns.cr.usgs.gov. 86381 IN A 136.177.16.3 ns.er.usgs.gov. 86381 IN A 130.11.48.2 ns.wr.usgs.gov. 259181 IN A 130.118.4.2 ns2.wr.usgs.gov. 259181 IN A 130.118.4.7 ;; Query time: 19 msec ;; SERVER: 12.6.230.2#53(akbar) ;; WHEN: Sat Nov 10 09:07:06 2001 ;; MSG SIZE rcvd: 188
  - Further architectural elaborations are possible
    - To build some robustness into the system, there's always been a requirement that you have at least two servers (on separate power circuits) per domain.
    - Forwarders. A large organization will require multiple name servers. Each of these can cache, unfortunately independent name servers won't share cache information, whereas what you'd really like to build up is a large central cache to minimize DNS lookups across the general Internet. But it's possible to arrange a set of name servers in a hierarchy through a technique called 'forwarding'. For example, you might have a name server on each LAN segment; these will field requests from local clients, but won't carry out the lookups themselves, instead forwarding them to a central server. The idea is that such a central cache will speed lookups, since (to use the diagram below) clients on LAN 2 can benefit from data cached because of lookups initiated from LAN 1.
    - "Split DNS". There are a number of security issues associated with DNS. To minimize the threat of direct or indirect attack, many organizations give different DNS views of their networks to internal and external clients--in particular they may show to external clients DNS information only for devices hosting services intended for public consumption. Split DNS can be implemented in different way: one would be to run separate internal and external nameservers, configuring local clients to point at the former, but having the latter registered in your parent domain (such that an external client, having to discover your nameserver by walking down from the root of the name tree, would be directed to these). It's also possible in current versions of BIND, the nameserving software in predominant use in the Internet, to run split DNS on a single nameserver instance. BIND configuration files consist of a set of zone files (containing resource records for the domains for which the server is authoritative) and a main control file, by default /etc/named.conf. This latter contains a set of "zone" statements, essentially pointers to the zone files; it may also wrap zone statements in "view" statements, where each view has a "match-clients" clause that stipulates the IP address blocks a client needs to come from to see the information in the zone files for the view. So by setting up full and filtered zone files, and pointing to those files from zone statements wrapped in different "views" in named.conf, you get... split DNS. Here's a piece of what such a named.conf would contain:
      ... // control what internal clients see view "inside" { // define the IP blocks of your internal networks match-clients { !216.114.150.92; 12.6.230/23; 216.114.150/23; 10/8; }; // for each of your domains (here just marlboro.edu), what's the data file // containing the DNS info you want internals to see zone "marlboro.edu" { type master; file "MChosts"; }; }; // as above, except for the rest of the world view "outside" { match-clients { any; }; zone "marlboro.edu" { type master; file "MChosts-external"; }; };
  - Relation to underlying protocols. Some network apps use UDP exclusively as their transport protocol, others use TCP exclusively. DNS uses both (in general). The "well-known" port number for DNS is 53--that's both UDP 53 and TCP 53. DNS uses UDP for individual queries (although it'll switch over to TCP if it doesn't get a response to a query or if it gets an error because the size of the response exceeded the maximum size of UDP messages), TCP for zone transfers (i.e., bulk transfer--a la FTP--of the data defining a domain from a primary server to a backup)
  - 'Reverse lookups' (number-to-name) [gloss on Comer 24.17-18]
    - Why bother?
      - Logging (sometimes we'd like to log in the more human-consumable form)
      - Security (sometimes we need the name--e.g. for name-based authentication [whether name-based authentication is a good idea is another story]; sometimes we need to make sure name and number correspond)
    - How?--the tree is indexed by name, how're we supposed to find the number in the first place? Brute force search doesn't sound too promising.
    - We solve the problem using DNS itself. DNS maps from names to some kind of information. Why not treat the numbers as names, and map from them back to the 'real' domain names? More particularly:
      - Build a special subtree of the name tree, under in-addr.arpa, that's structured along the lines of the dotted-decimal representation of IP addresses. That is, we stop thinking about dotted-decimal IPs as convenient representations for numbers, construe them instead as sequences of (dot-separated) ASCII labels, and build out the name tree accordingly. E.g., consider the class C networks 199.200.201.0 and 199.200.202.0. For purposes of number to name mapping, we think of these networks as nodes in the overall name hierarchy:
      - Next, delegate authority in the in-addr.arpa subtree just as we delegate authority elsewhere in the name tree. E.g. Mumble State comes into existence and connects to the Internet. Its service provider gives it the class C block 199.200.202.0. It registers itself in the DNS by getting authorization to use the mumble.edu domain (from the .edu authority) and the 202.200.199.in-addr.arpa domain (from the 200.199.in-addr.arpa authority--possibly Mumble State's service provider).
      - Set up a nameserver that's authoritative for both the 'forward' (mumble.edu) and 'reverse' (202.200.199.in-addr.arpa) domains (and tell the owners of the parent domains the IP address of the nameserver)
      - The data file for an in-addr.arpa domain will (largely) consist of PTR records that map back to 'real' domain names. E.g. Mumble State starts off by setting up a machine called 'corn-chex' at 199.200.202.46. The data file for the mumble.edu domain will have an entry of the following form:
        
        corn-chex IN A 199.200.202.46
        
        The data file for the 202.200.199.in-addr.arpa domain will have an entry that looks like this:
        
        46 IN PTR corn-chex.mumble.edu.
      - With all this machinery in place, lookup goes like this. Some application somewhere wants to resolve 199.200.202.46 to a name. It hands off to its resolver, which formulates a DNS query for PTR records for the the domain name 46.202.200.199.in-addr.arpa and sends the query to its nameserver. And then (barring cached data) the usual cycle beings: the local nameserver contacts the root server, which returns the name of the server authoritative for the arpa domain; the local server contacts the arpa server, which returns the name of the server authoritative for in-addr.arpa; ...and so on 'til the local server receives the name of the 202.200.199.in-addr.arpa server; the request goes to that server, it sees it's authoritative, further that it has a PTR record for '46', and so returns it.
      - Notice that when you convert an IP address in dotted decimal representation into an in-addr.arpa domain, the byte order gets reversed: 199.200.202.46 turns into 46.202.200.199.in-addr.arpa, not 199.200.202.46.in-addr.arpa. This follows from the fact that domain names and (dotted-decimal) IP addresses have opposite orientations: in domain names it's the most general term (the TLD) that's right-most, in IP addresses it's the most specific term (the host component) that's right-most. If we flip the byte order of the dotted-decimal IP when constructing an in-addr.arpa domain, we end up with an entity whose global ordering is least to most general. A node in a tree constructed along these lines corresponds to a block of consecutive IP addresses (10.in-addr.arpa will contain the PTR records for all 10.x.x.x addresses, 20.168.195.in-addr.arpa will contain the PTR records for all 195.168.20.x addresses), and we can easily walk down the tree 'til we reach a node corresponding to the block of IP addresses assigned to some organization--responsibility for which node it makes perfect sense to delegate to that organization. Which is to say that if we reverse the bytes, management of the in-addr.arpa domain is feasible. If we don't reverse the bytes, i.e., if the IP address 200.200.14.19 corresponds to the reverse domain 200.200.14.19.in-addr.arpa, nodes in the tree don't correspond to contiguous chunks of the IP address space, and all hell breaks loose. Let's say this scheme is in effect, and let's say further that authority over 200.14.19.in-addr.arpa is delegated to some DNS-administrator-in-hell. This person is responsible for all IP addresses that end in 200.14.19. But no single organization owns 1.200.14.19, 2.200.14.19, etc., no single organization can legislate the number to name mappings for this domain. Rather, the administrator-in-hell is going to have to deal with requests to make PTR record updates from ~256 different organizations. Conversely, an organization-in-hell owning a class C address block would have to deal with ~256 different administrators-in-hell to update its PTR records. Which is no way to run a distributed database.
      - Just one more thing. We've seen that number-to-name mapping relies on the structure of dotted-decimal representations and on the correspondence between that structure and the allocation of blocks of IP addresses. But what happens when authority over IP addresses doesn't correspond to the structure of dotted-decimal addresses, what happens if your block of addresses doesn't align to a byte boundary, what happens with subnets?
        Let's say that marlboro.edu wants to delegate authority for the subdomain design.marlboro.edu, and that it wants to allocate a set of IP addresses--smaller than a class C-sized block--for use in that domain--let's say the addresses from 12.6.230.152 through 12.6.230.160. Delegating the forward domain is no problem. If I want to delegate design.marlboro.edu from marlboro.edu, I do this in the marlboro.edu zone file (assume that name service for the new domain is going to be handled by a machine called vault.design.marlboro.edu):
        
        design IN NS vault.design.marlboro.edu. vault.design.marlboro.edu. IN A 12.6.230.1555
        
        Fine, how about the reverse domain? Well, in principle it should look rather similar. If I had the class B address 175.177.0.0, and wanted to delegate control over 175.177.10.0 to the new domain, I'd just say this in the 177.175.in-addr.arpa data file
        
        10 IN NS vault.design.marlboro.edu.
        
        But if I own the 12.6.230.x addresses and therefore control the 230.6.12.in-addr.arpa domain, and want to delegate 12.6.230.152 through 160, there's no direct way to do so, no way to express that range in terms of the structure of a dotted-decimal address (short of delegating on a per-IP basis, which would be a nightmare to administer since it would force the subdomain administrator to deal with n individual domain delegations). However RFC 2317 describes the following lovely way of circumventing the problem:
        
        It's really names (i.e. ASCII strings) under in-addr.arpa, even though they look like numbers. So we could just make up some additional name under 230.6.12.in-addr.arpa, e.g. '152-160', and delegate authority over it:
        
        152-160 IN NS vault.design.marlboro.edu
        
        That is, if anybody asks about domain names under 152-160.230.12.in-addr.arpa, refer them to the nameserver vault.design.marlboro.edu
        
        Then, for the 'regular addresses' under 230.6.12.in-addr.arpa that we want to delegate (152, 153, etc.), we can't just have PTR records--if, inside the data file for 230.6.12.in-addr.arpa, I just have:
        
        152 IN PTR whatever.design.marlboro.edu.
        
        ...then I haven't delegated anything! I'm trying to get rid of these things! But why not use CNAME to alias these addresses into the funny-looking subdomain we created in step 1? That is, if I have:
        
        152 IN CNAME 152.152-160.230.6.12.in-addr.arpa.
        
        ...then if somebody wants to know the name corresponding to 12.6.230.152, that gets translated to an inquiry after 152.230.6.12.in-addr.arpa; but the response to that query will be that it's just an alias for 152.152-160.230.6.12.in-addr.arpa; so we go try to look that up, and at some point we'll need to know who handles the names under 152-160.230.6.12.in-addr.arpa; but in step 1 we delegated that domain to vault.design.marlboro.edu, so we connect to that server and ask about 152.
        
        And if vault.design.marlboro.edu has PTR records of the form
        
        152 IN PTR whatever.design.marlboro.edu.
        
        ...everything will be wonderful. Notice in particular here that the setup of the CNAMEs in the in-addr.arpa domain of the parent is a one-time deal: once this has been done, the administrator of that domain need do nothing more, and the administrator of the subdomain can make whatever changes to the PTR records that he or she desires. But the whole point of the exercise was to effect that kind of delegation of responsibility.

5. DNS is not perfect from a security point of view

Root compromise. There've been a number of buffer overflow exploits, yielding root privileges for a remote user, that involve BIND. See for example http://www.cert.org/advisories/CA-2001-02.html. Such compromises give the intruder complete control of the nameserving machine (including the ability to fabricate data).
Denial of service. DNS is currently being used as a vehicle for denial of service attacks. See for example http://www.cert.org/incident_notes/IN-2000-04.html. The idea is to send a steady stream of requests to one or more DNS servers, spoofing the source address of the victim. The responses, typically much larger than the queries, converge on the victim. (This is one of a family of bandwidth-amplifying DoS attacks. Cf. 'smurfing').
Inadequate notion of authentication. DNS is built directly on UDP, and really doesn't have the facilities for any kind of decent authentication--historically the only thing that happened was that the id field in the header was checked, and this is easily spoofed. Consider the implications of "client flooding": somebody's listening on the wire, sniffing outbound DNS packets, and then tries to beat the real nameserver to the punch--responding to the client with plausible but entirely fabricated data. Even barring a packet sniffer, a related attack is possible which "poisons the cache" of a server. Here's what we do: (a) connect to the target name server and ask a question that'll force a lookup on our name server; (b) we notice the transaction ID on this request; (c) now, still connected to the target, we ask for the address of www.microsoft.com; (d) and then we stream responses to the target incremented from the ID we saw in the initial transaction--i.e., we hope we're talking to a server that's using a nice simple sequencing algorithm.
Sometimes you don't even need to sync to the ID number of a DNS query. Some nameservers aren't very careful about the data they accept and cache--some will accept and cache not only answers to questions that weren't asked but also answers from servers that aren't really authoritative for the data. So here's what we do. We want to poison the cache of ns.vulnerable.org. We officially register pure-as-the-driven-snow.org, and set up a nameserver for it, ns.pure-as-the-driven-snow.org. We tweak the software on ns.pure-as-the-driven-snow.org such that whenever it receives a query, it throws in an extra response--say an A record for access-your-account.visa.com that just happens to point to a machine under our control on which we've set up a mirror of Visa's site. Now we connect to ns.vulnerable.org (e.g. with "dig"), and innocently query on www.pure-as-the-driven-snow.org. Since we're really authoritative for that domain the query chain eventually reaches our nameserver, it returns the bogus data along with the response to the actual query, ns.vulnerable.org caches the bogus data, and any of its clients trying to reach visa.com get redirected to us. For a current vulnerability in this area, see the recent CERT Incident Note on "Cache Corruption in Microsoft DNS Servers".
More generally still you could ask when does an information service give out too much information (and does DNS cross the line)? Take the case of zone transfers--laudably enough, we're trying to build some robustness into the system, some mechanism by which we can feed data to backup servers, but the default behavior is that anybody can do a full transfer of your zone files. Is this what you really want?

6. Recent developments in DNS

NOTIFY (a mechanism by which primary nameservers can inform secondaries of changes; the old method was that secondaries would poll at pre-set intervals)
UPDATE (aka 'dynamic DNS'; a mechanism for updating DNS databases on the fly)
- The traditional update mechanism involved a sysadmin editing some config files and restarting the DNS process.
- Now BIND for example supplies some command-line utilities that let us do things like this
```
update add foo.marlboro.edu 7200 A 12.6.230.247
```
- But the larger hope is that this'll lead to automated update, e.g. via DNS/DHCP interaction
- UPDATE is an extremely powerful (not to say scary) mechanism
IXFR (wouldn't it be nice if, when a primary needs to do a zone transfer to a secondary, it could just send changed data rather than the full zone file? IXFR now provides a way of doing this kind of incremental transfer)
DNSSEC defines a "public key cryptography" scheme that insures authenticity of origin and data integrity.
- Background on public key cryptography
- DNSSEC-aware nameservers operate on a new set of resource record types
  - There's a key-generation process that yields a KEY record that holds the public key for the zone. This is placed in the data file for the zone.
  - There's a signing-process in which SIG records are created for each 'regular' resource record in the data file: these are digital signatures: they're encryptions (using the zone's private key) of digests of the original data.
  - The data file also includes a SIG record corresponding to the zone's key record. This is produced by the parent zone (i.e., a higher authority guarantees the authenticity of the zone)
  - So, client chucks a request at a nameserver and receives back one or more content RRs and corresponding SIG RRs. It authenticates the server's public key, and then runs through the regular public key routine: use the public key to decrypt the SIG; hash the original data and compare to the decrypted SIG; if they match the data are unaltered and must've been produced by the authoritative zone.

IT Home | Notes