COMP3331/9331 Computer Networks and Applications

Assignment for Term 2, 2024

DNS Implementation

1. Goal and Learning Objectives

In this assignment, you will have the opportunity to implement a simplified version of DNS. Your applications are based on a client-server model consisting of one server and multiple clients, where:

1.   A client can accept some user query, send it to the server, wait for a response, and upon receiving a response, display the results.

2.   A server waits for client queries, and upon receiving a query, attempts to resolve it using resource records found in a master file, then replies with the appropriate response.

All client-server communication will be over UDP (TCP cannot be used for this assignment).

You will additionally submit a report.

On completing this assignment, you will gain sufficient expertise in the following skills:

1.   A deeper understanding of how DNS works.

2.   Socket programming for UDP transport protocol.

3.   Designing an application layer protocol.

2. Master File

The master file is a text file that contains resource records (RRs) in text form. Each line contains one record. Any number of spaces act as a delimiter between the separate items that make up a record. The items that make up a record, in the order they appear on a line, are:

Where:

•   domain-name: is said to be the "owner" of the record. The labels in the domain name are expressed as character strings and are separated by dots.

-    All domain names will end with a dot.

-    All domain names will be 256 characters or less.

-    All domain names will be in lower case.

-    All labels within a domain name will start with a letter, end with a letter or digit, and have as interior characters only letters a-z, digits 0-9, and hyphens.

-    All labels will be 63 characters or less.

•   type: specifies the type of the resource in the resource record, which will be one of the following:

-    A: a host address.

-    CNAME: identifies the canonical name of an alias.

-    NS: the authoritative name server for the domain.

•   data: is the type-dependent data which describes the resource:

-    A: a 32-bit IP address expressed as four decimal numbers separated by dots and without any embedded spaces.

-    CNAME: a domain name, which follows the previously stated rules for domain names, and specifies the canonical or primary name for the owner.  The owner name is an alias.

-    NS: a domain name, which follows the previously stated rules for domain names, and specifies a host which should be authoritative for the domain.

Resource records with the same domain-name and type form. a resource set.  The order of RRs in a set is not significant, and need not be preserved by the client or server.

You may assume that each resource record in the master file will be unique, but you should not assume any particular ordering of the master file.

You may assume that the master file contains at least one NS record for the root zone, and its corresponding A record, meaning the server can always refer the client to some other name server which will provide eventual access to an answer. You may also assume there will be no circular CNAME references, and no NS records that point to a CNAME record.

The master file will be named master.txt.  It will be located in the working directory of the server, and it will follow the format and rules stated above.

Do not hard-code any resource records within your server program.  The records must be read from the file when the server is executed. Failure to do so will likely result in your applications not passing any testing.

Do not hard-code any path to the master file, or assume any name other than master.txt, within your server program. The program must read the file master.txt from the current working directory. Failure to do so will likely result in your applications not passing any testing.

You may assume that the master file will contain no more than 256 records, there will be no blank lines, and there will be no leading or trailing whitespace on any line.  Furthermore, the final record will have no trailing newline.

A sample master file is provided. A different master file will be used during marking. You may assume the file will be present, will have the same name, and will follow the same format and rules.

3. Message Format

You are to design the message format. Your design may utilise a single format for both queries and responses, or they may be distinct. However, conceptually the messages should include the information detailed below. You may assume that the resource records contained within any message, stripped of any whitespace between the fields, will not exceed 2048 bytes.

3.1. Client Query

+---------------------+

|         Header        |

+---------------------+

|        Question       | the question for the server

+---------------------+

Minimally the header section should include:

• qid: A 16-bit unsigned integer, randomly generated by the client, as an identifier for the query.

This identifier is copied into the corresponding response by the server. The question section should include:

•   qtype: The type of the query, and will be one of the types listed in Section 2. Master File.

•   qname: The target domain name of the query, which will follow the rules detailed in Section 2. Master File

3.2. Server Response

+---------------------+

|          Header         |

+---------------------+

|        Question        | the question for the server

+---------------------+

|          Answer         | RRs answering the question

+---------------------+

|      Authority       | RRs pointing toward an authority

+---------------------+

|      Additional      | RRs holding additional information

+---------------------+

Minimally the header section should include:

•   qid: The 16-bit unsigned integer identifier of the query to which this is a response. Similar to the qid, the question section duplicates the question section of the query.

The last three sections have the same format: a possibly empty list of concatenated resource records (RRs). The answer section contains RRs that answer the question; the authority section contains RRs that point toward an authoritative name server; the additional section contains RRs which relate to the query, but are not strictly answers for the question.  All RRs will follow the rules detailed in Section2. Master File.

4. Client

4.1. File Name and Arguments

The main code for the client must be contained in one of the following files:

•    client.c

• Client.java

•    client.py

You are free to create additional helper files and name them as you wish. The client should accept the following arguments:

1.   server_port: The UDP port number on which the server is listening.  This will be the same argument supplied to the server.

2.   qname: The target domain name of the query. This will be well formed, as discussed in Section 2. Master File, will always be provided in lower case, and will always include a trailing  . to represent the root domain.

3.   qtype: The type of the query.  This will be one of the types listed in Section 2. Master File, and will always be provided in upper case.

4.   timeout: The duration in seconds, greater than 0 but no more than 15, which the client should wait for a response before considering it a failure and terminating.

Execution of your client should be initiated as follows:

C:

$ ./client server_port qname qtype timeout

Java:

$ java Client server_port qname qtype timeout

Python:

$ python3 client.py server_port qname qtype timeout

During testing, we will ensure that the command-line arguments provided are in the correct format. We will not test for erroneous arguments, missing arguments, etc.  That said, it is good programming practice to check for such input errors.

4.2. Client Operation

Upon execution, the client should:

1.   Construct a message that will carry the provided qname and qtype in its question section.

2.   Assign a randomly generated, 16-bit unsigned integer as the qid.

3.   Using an ephemeral port (i.e. one allocated by the operating system), send the message to the server_port of the localhost (127.0.0.1).

4.   Wait up to timeout seconds for a response.

5.   If received, print the response, otherwise, print an error message.

6.   Terminate.

4.3. Client Output

You are free to nominate the output format, provided it is easily human readable, but minimally it must include:

• The qid carried in the response, as a decimal integer.

•   A Question section heading, followed by the qname and qtype found in the response.

•   For each of the Answer, Authority, and Additional sections:

-    A section heading, followed by the resource records contained in that section of the response.

-    You are free to choose whether or not a heading is printed out for any section that does not contain any records.

Important: Tutors will be relying on the output in order to mark your client. If it does not produce any output, then it cannot be marked. If the output is difficult to read, or some of the output is missing, then you should not expect full marks, even if your implementation is otherwise correct.

Please do not email course staff or post on the forum asking if your output is acceptable. This is not scalable for a course of this size. If you are unsure of your output, then you should follow the example output.

Examples are provided in Appendix G. Sample Interactions.

5. Server

5.1. File Name and Arguments

The main code for the server must be contained in one of the following files:

• server.c

• Server.java

• server.py

You are free to create additional helper files and name them as you wish. The server should accept the following argument:

1.   server_port: The UDP port number on which the server should listen for client queries. We recommend using a random port number between 49152 and 65535 (the dynamic port number range).  This will be the same port argument supplied to the client.

C:

$ ./server server_port

Java:

$ java Server server_port

Python:

$ python3 server.py server_port

During testing, we will ensure that the command-line arguments provided are in the correct format. We will not test for erroneous arguments, missing arguments, etc.  That said, it is good programming practice to check for such input errors.

5.2. Server Operation

Upon execution, the server should:

1.   Read in the master file, and initialise an in-memory cache with these records.

a.   You are free to design the cache internals, with the help of any general purpose (i.e. non-DNS) standard libraries, as you see fit.

2.   Bind to the server_port of the loopback interface (127.0.0.1).

a.   During testing the server and all clients will be executed on the same host.

3.   Loop forever, listening for queries. Upon receiving a query, the server should:

a.   Delay processing the query for a random amount of time of 0,  1, 2, 3, or 4 seconds. Meanwhile the server should still be able to listen for (and similarly delay/process) other queries.  This will allow us to assess how well your server can multiplex queries from multiple clients.

b.   Once the delay period has elapsed for a given query, construct the appropriate response, utilising its cache.

c.   Send the response back to the client.

The server needs to support multiple clients simultaneously.  A robust way to achieve this is to use multithreading.  In this approach, you might have a main thread to listen for new queries.  When a query is received the server might spawn a new thread, which will sleep for the delay duration, process the query, send a response, and then terminate.  However, we do not mandate any specifics.  You may elect to solve this some other way.  Regardless of your approach, you should not assume any arbitrary limits on the number and frequency of clients.

You may also note that during testing the server will always be started before any client requests are made, the server will not be manually terminated, and should the server crash, it will be restarted.

5.3. Query Processing

1.   Attempt to match the qname.

a.   If the whole of qname is matched, we have found the node.

If the data at the node is a CNAME, and qtype doesn't match CNAME, copy the CNAME RR into the answer section of the response, change qname to the canonical name found in the CNAME RR, and start again. Note, in this scenario the ordering of the CNAME records in the answer section should follow the order in which they're added, which should also be reflected in the client output.

Otherwise, copy all RRs which match qtype into the answer section, and go to step 2.

b.   If the match fails, we have a referral.

Find the closest ancestor zone to qname for which there are known name servers. Copy all NS RRs for the zone into the authority section.  For each name server, copy any known A records into the additional section.  Go to step 2.

2.   Send the response.

You may assume that all queries are resolvable, via an answer and/or a referral.

5.4. Server Output

You are free to nominate the output format, provided it is easily human readable, but it must log to the terminal all messages sent and received, and minimally include:

•   A timestamp of when the message was sent or received, with at least millisecond precision.

•   Whether the message was sent or received.

•   The client port number.

• The qid of the message, as a decimal integer.

•   The qname and qtype carried in the message.

•   If the message is a query received, the period of delay until the query will be processed.

-    Note, this should be printed when the query is received, not when the  query is processed.

A general template may look like:

:  (delay: s)

Important: Tutors will be relying on the output in order to mark your server. If it does not produce any output, then it cannot be marked. If the output is difficult to read, or some of the output is missing, then you should not expect full marks, even if your implementation is otherwise correct.

Please do not email course staff or post on the forum asking if your output is acceptable. This is not scalable for a course of this size. If you are unsure of your output, then you should follow the example output.

Examples are provided in Appendix G. Sample Interactions.

6. Report

You should submit a small report (no more than 2 pages) named report.pdf. This should include:

•   Details of which language you have used (e.g., C) and the organisation of your code (Makefile, directories if any, etc.).

•   The overall program design and any data structure design, for example, any data structures used to represent resource records, application messages, and the cache.

•   Known limitations, for example, if your program does not work under certain circumstances, then report those circumstances.

•   Also indicate any segments of code that you have borrowed from the Web or other sources.