Project 2: Dynamic DNS, Part AOctober 28, 2008Due Nov 12 @ 11:59:59 pmEE122: Introduction to Communication Networks (Fall 2008)Department of Electrical Engineering and Computer ScienceCollege of EngineeringUniversity of California, Berkeley1 OverviewIn this project, you will implement a DNS server system. The project has two parts:• Part A: Dynamic Domain Name System (DNS) server and client.• Part B: Peer-to-peer gossiping with the other DNS servers to learn DNS records.This document describes Part A.Your DNS server will implement a limited version of the real DNS protocol. Your server will interoper-ate with the live Internet DNS system. For example:• You will be able to query your server with standard commands like nslookup and dig.• We will give you your own publicly-accessible subdomain to be served by your server. Within thissubdomain you will be able to create your own names that anyone on the Internet can use.• If you’d like, and if you have your own server on which to run it, you can even purchase your owndomain name and use your server to serve it. (Surprisingly, ee122madeallmydreamscometrue.com isunclaimed as of this writing...)Standard old DNS servers like named on Unix learn their name-to-IP address mappings by reading a config-uration file. Your server, however, will be much, much slicker. Specifically, it will accept mapping messagesover the network from a dynamic DNS client. You can run the client on your laptop, so when you movearound from one wireless network to another and thus change IP addresses, your laptop will always beavailable at the same DNS name. This is similar to services such as DynDNS.com.Key concepts in Part A of the project include:• Working with a real protocol.• Use of UDP.• Use of soft state.12 Command line interfacesServerYour server should take one command line argument: a port to which to bind, accepting incoming UDPDNS queries. For example we should be able to run it on port 6001 like this:./server 6001It should then keep running, waiting for and replying to queries, until it is killed manually. Your serverdoesn’t need to print anything out to the console, although this will help you in debugging.Recall that the DNS protocol expects servers to run on port 53. But only root can bind to ports 1023 orless. So to run on the instructional machines, you’ll have to use a port number of 1024 or greater.It goes without saying that your server should not crash regardless of what it receives over the network,and should not have memory leaks.ClientThe dynamic DNS client should accept four arguments: a server IP, server port, a domain name, a corre-sponding IP address, and a TTL. For example:./client 128.32.48.169 6001 mylaptop.fakedomain.com 128.2.1.2 120The client should then contact the server at the given IP (here 128.32.48.169) and port (6001) using theprotocols described in Section 3 below. It should tell the server to install the given mapping (mylap-top.fakedomain.com → 128.2.1.2) for the given amount of time (120 seconds).If this all works, you should be able to query the server within the next two minutes...nslookup mylaptop.fakedomain.com 128.32.48.169 -port=6001...and get a reply showing the IP address 128.2.1.2.3 Network protocol and semanticsHaving specified the interface between humans and your programs in the previous section, we now specifythe interface between the programs themselves across the network.Your server will accept and reply to DNS Question messages on UDP. The client will install mappingsin the server by sending a DNS Response message to the server. Hence, it all comes down to the DNSprotocol. Next we give a detailed description of the DNS protocol, followed by how it should be used byyour client and server.The DNS protocolA DNS datagram is formatted as follows:• [16 bits] IDENTIFICATION. Set by the client when it sends a query, the server should keep this thesame in its reply, allowing the client to match up the response with the request.• [16 bits] PARAMETER. An assortment of bits annotating the query or response, indicating error con-ditions, and so on. As a simplification of the protocol, you don’t need to deal with most of these.Handle the bits as follows:– Bit 0 is set to 0 in queries, and 1 in responses. When your server gets a name lookup query, thisbit will be set to 0; its reply should set the bit to 1. To install a name mapping your dynamicclient should send a message to the server with this bit set to 1.2– Bit 5 is set to 1 if the message is a response and the answer is authoritative; otherwise the bit isset to 0. Your server should act as the authoritative name server for all names installed in it byyour dynamic client.– All other bits in the parameter field should be ignored in messages you receive, and should beset to 0 in messages that you send.• [16 bits × 4] NUMBER OF QUESTIONS, NUMBER OF ANSWERS, NUMBER OF AUTHORITY, NUMBEROF ADDITIONAL (in that order). These integers specify the number of entries in the correspondingfour sections which follow. As a simplification of the protocol, you may assume that the NUMBEROF QUESTIONS and NUMBER OF ANSWERS are are either 0 or 1; and the NUMBER OF AUTHORITY andNUMBER OF ADDITIONAL are always 0.• [Variable length] QUESTION SECTION. This section contains zero or more questions, the number ofwhich is specified above. You’ll need to deal only with zero or one questions. Each question has thefollowing format:– [Variable length] DOMAIN NAME. This is the name that the querier wishes to be translated toan IP address. It is not just a sequence of characters; instead it uses a representation that cancompresses the size if there are many names similar names mentioned in this datagram. Goodnews: we will give you code to translate from this format to a standard string, and vice versa.If you want, you can also implement this yourself.– [16 bits] TYPE. This integer can take any one of dozens of values specifying the type of query,including some corresponding to types we discussed in lecture like A, CNAME, and MX. As asimplification of the protocol, your server can assume that the query type is always A, in whichcase this field has the value 1 (not 4 as previously advertised).– [16 bits] CLASS. This integer describes the type of address requested in the reply. For the pur-poses of this project, this value should always be set to 1, which corresponds to the “Internetclass”. (Although several other classes are defined, they are not
View Full Document
Unlocking...