Tanenbaum, Computer Networks (extraits) Adaptation par J.Bétréma DNS The Domain Name System
RFC 1034 Network Working Group P. Mockapetris Request for Comments: 1034 ISI Obsoletes: RFCs 882, 883, 973 November 1987 DOMAIN NAMES - CONCEPTS AND FACILITIES 1. STATUS OF THIS MEMO This RFC is an introduction to the Domain Name System (DNS), and omits many details which can be found in a companion RFC, "Domain Names - Implementation and Specification" [RFC-1035]. That RFC assumes that the reader is familiar with the concepts discussed in this memo.
RFC 1034 (2) 2.2. DNS design goals The design goals of the DNS influence its structure. They are: - The primary goal is a consistent name space which will be used for referring to resources. In order to avoid the problems caused by ad hoc encodings, names should not be required to contain network identifiers, addresses, routes, or similar information as part of the name. - The sheer size of the database and frequency of updates suggest that it must be maintained in a distributed manner, with local caching to improve performance. Approaches that attempt to collect a consistent copy of the entire database will become more and more expensive and difficult, and hence should be avoided. The same principle holds for the structure of the name space, and in particular mechanisms for creating and deleting names; these should also be distributed. - etc.
RFC 1035 Network Working Group Request for Comments: 1035 Obsoletes: RFCs 882, 883, 973 P. Mockapetris ISI November 1987 DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION 1. STATUS OF THIS MEMO This RFC describes the details of the domain system and protocol, and assumes that the reader is familiar with the concepts discussed in a companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034]. The domain system is a mixture of functions and data types which are an official protocol and functions and data types which are still experimental. Since the domain system is intentionally extensible, new data types and experimental behavior should always be expected in parts of the system beyond the official protocol. The official protocol parts include standard queries, responses and the Internet class RR data formats (e.g., host addresses). Since the previous RFC set, several definitions have changed, so some previous definitions are obsolete.
The DNS Name Space A portion of the Internet domain name space.
Resource Records The principal DNS resource records types.
Resource Records (2) A portion of a possible DNS database for cs.vu.nl.
Name Servers Chaque zone possède (au moins) un serveur délégué Part of the DNS name space showing the division into zones.
Name Servers (2) Requête récursive : un résolveur sur flits.cs.vu.nl cherche l adresse de linda.cs.yale.edu
Requête : exemple 1 nslookup > set norecurse > set debug > www.cs.chalmers.se Server: donaser.labri.u-bordeaux.fr Address: 147.210.8.187 ------------ Got answer: HEADER: opcode = QUERY, id = 2, rcode = NOERROR header flags: response, recursion avail. questions = 1, answers = 0, authority records = 4, additional = 4 QUESTIONS: www.cs.chalmers.se, type = A, class = IN
Requête 1 : enregistrements «autorisés» AUTHORITY RECORDS: -> chalmers.se nameserver = cthns.chalmers.se ttl = 42710 (11 hours 51 mins 50 secs) -> chalmers.se nameserver = chalmers.se ttl = 42710 (11 hours 51 mins 50 secs) -> chalmers.se nameserver = ns.ckoia.chalmers.se ttl = 42710 (11 hours 51 mins 50 secs) -> chalmers.se nameserver = dns.uu.se ttl = 42710 (11 hours 51 mins 50 secs)
Requête 1 : enregistrements supplémentaires ADDITIONAL RECORDS: -> cthns.chalmers.se internet address = 129.16.1.3 ttl = 42710 (11 hours 51 mins 50 secs) -> chalmers.se internet address = 129.16.1.1 ttl = 40561 (11 hours 16 mins 1 sec) -> ns.ckoia.chalmers.se internet address = 192.36.120.11 ttl = 42710 (11 hours 51 mins 50 secs) -> dns.uu.se internet address = 130.238.7.10 ttl = 13359 (3 hours 42 mins 39 secs)
Requête : exemple 2 > www.cs.chalmers.se 192.36.120.11 Server: [192.36.120.11] Address: 192.36.120.11 ------------ Got answer: HEADER: opcode = QUERY, id = 3, rcode = NOERROR header flags: response, auth. answer, recursion avail. questions = 1, answers = 1, authority records = 4, additional = 4 QUESTIONS: www.cs.chalmers.se, type = A, class = IN ANSWERS: -> www.cs.chalmers.se internet address = 129.16.237.85 ttl = 43200 (12 hours)
Requête 3 : serveurs de courrier > set type=mx > cs.chalmers.se 192.36.120.11 Server: [192.36.120.11] Address: 192.36.120.11 ------------ Got answer: HEADER: opcode = QUERY, id = 7, rcode = NOERROR header flags: response, auth. answer, recursion avail. questions = 1, answers = 2, authority records = 4, additional = 5 QUESTIONS: cs.chalmers.se, type = MX, class = IN ANSWERS: -> cs.chalmers.se MX preference = 0, mail exchanger = pheidippides.md.chalmers.se ttl = 43200 (12 hours) -> cs.chalmers.se MX preference = 100, mail exchanger = chalmers.se ttl = 43200 (12 hours)
Requête 3 : enregistrements supplémentaires ADDITIONAL RECORDS: -> pheidippides.md.chalmers.se internet address = 129.16.237.91 ttl = 43200 (12 hours) -> chalmers.se internet address = 129.16.1.1 ttl = 43200 (12 hours) etc.
Requête 4 : SOA > set type=soa > chalmers.se 192.36.120.11 Server: [192.36.120.11] Address: 192.36.120.11 ------------ Got answer: HEADER: opcode = QUERY, id = 9, rcode = NOERROR header flags: response, auth. answer, recursion avail. questions = 1, answers = 1, authority records = 4, additional = 4 QUESTIONS: chalmers.se, type = SOA, class = IN
Requête 4 : réponse ANSWERS: -> chalmers.se ttl = 43200 (12 hours) primary name server = chalmers.se responsible mail addr = cth-nic.chalmers.se serial = 2002011702 refresh = 14400 (4 hours) retry = 3600 (1 hour) expire = 604800 (7 days) default TTL = 600 (10 mins)
Secure Naming (a) Normal situation. (b) An attack based on breaking into DNS and modifying Bob's record.
Secure Naming (2) How Trudy spoofs Alice's ISP DNS Server.
Secure Naming (3) Explications : Trudy gère son propre serveur DNS (serveur délégué pour le domaine trudythe-intruder.com), appelons le T. Le message 1 engendre des messages 1a (requête) et 1b (réponse), entre F, le serveur DNS du FAI d Alice, et C, le serveur DNS du domaine «top level».com ; ces messages n apparaissent pas sur le schéma. La réponse 1b contient, en plus de la réponse proprement dite (adresse IP de foobar.trudy-the-intruder.com), le nom du serveur DNS du domaine (authority record) et son adresse IP (additional record). F garde en mémoire cache tous les enregistrements (RR) comosant la réponse B.
Secure Naming (4) Pour répondre à la requête 2, F interroge directement T (message 3), sans passer par C. F construit séquentiellement les identificateurs permettant d apparier requêtes et réponses : faute inadmissible, un nouvel identificateur doit être imprévisible. Noter aussi que Trudy peut envoyer des requêtes DNS (et même une réponse) au serveur F ; possible, sauf si ces requêtes sont bloquées par un NAT (cas où le FAI de Trudy n est pas celui d Alice), ou si la réponse est bloquée par un pare-feu sortant (qui détecte que Trudy émet un paquet avec une adresse IP source falsifiée).
Format Messages DNS Mockapetris [Page 25] RFC 1035 Domain Implementation and Specification November 1987 4. MESSAGES 4.1. Format All communications inside of the domain protocol are carried in a single format called a message. The top level format of message is divided into 5 sections (some of which are empty in certain cases) shown below: +---------------------+ Header +---------------------+ Question the question for the name server +---------------------+ Answer RRs answering the question +---------------------+ Authority RRs pointing toward an authority +---------------------+ Additional RRs holding additional information +---------------------+
Format Messages DNS (2) 4.1.1. Header section format 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ ID +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ QR Opcode AA TC RD RA Z RCODE +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ QDCOUNT +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ ANCOUNT +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ NSCOUNT +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ ARCOUNT +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ ID A 16 bit identifier assigned by the program that generates any kind of query. This identifier is copied into the corresponding reply and can be used by the requester to match up replies to outstanding queries.
RFC 2535 Network Working Group D. Eastlake Request for Comments: 2535 IBM Obsoletes: 2065 March 1999 Updates: 2181, 1035, 1034 Category: Standards Track Domain Name System Security Extensions Extensions to the Domain Name System (DNS) are described that provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records.
DNS Security Extensions The extensions provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution services as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms.
Example An example RRSet for bob.com. The KEY record is Bob's public key. The SIG record is the top-level com server's signed hash of the A and KEY records to verify their authenticity.
Key RR The KEY resource record (RR) is used to store a public key that is associated with a Domain Name System (DNS) name. This can be the public key of a zone, a user, or a host or other end entity. A KEY RR is, like any other RR, authenticated by a SIG RR. KEY RRs must be signed by a zone level key.
Key RR (2) The public key in a KEY RR is for the object named in the owner name. A DNS name may refer to three different categories of things. For example, foo.host.example could be (1) a zone, (2) a host or other end entity, or (3) the mapping into a DNS name of the user or account foo@host.example. Thus, there are flag bits in the KEY RR to indicate with which of these roles the owner name and public key are associated. Note that an appropriate zone KEY RR MUST occur at the apex node of a secure zone and zone KEY RRs occur only at delegation points.
Key RDATA KEY RDATA format : 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ flags protocol algorithm +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / public key / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Protocol 1 is reserved for use in connection with TLS. 2 is reserved for use in connection with email. 3 is used for DNS security. 4 is reserved to refer to the Oakley/IPSEC [RFC 2401] protocol and indicates that this key is valid for use in conjunction with that security standard.
Algorithm 1 2 3 4 RSA/MD5 [RFC 2537] - recommended Diffie-Hellman [RFC 2539] - optional, key only DSA [RFC 2536] - MANDATORY reserved for elliptic curve crypto 254 private - OID : the public key area for the KEY RR and the signature begin with an unsigned length byte followed by a BER encoded Object Identifier (ISO OID) of that length. The OID indicates the private algorithm in use and the remainder of the area is whatever is required by that algorithm. Entities should only use OIDs they control to designate their private algorithms.
Sig RR The SIG or "signature" resource record (RR) is the fundamental way that data is authenticated in the secure Domain Name System (DNS). As such it is the heart of the security provided. The SIG RR unforgably authenticates an RRset of a particular type, class, and name and binds it to a time interval and the signer's domain name. This is done using cryptographic techniques and the signer's private key. The signer is frequently the owner of the zone from which the RR originated.
Sig RDATA 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ type covered algorithm labels +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ original TTL +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signature expiration +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signature inception +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ key tag +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name + / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ / / / signature / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+