Tutorial 2 - 2023W2

Today’s tutorial is an opportunity to start or continue working on the DICT client. You will also learn about how DNS works.

Part I: Netcat server

In addition to creating TCP connections to existing servers, netcat can also be used as a server. This is useful if you want to test how your DICT client handles unexpected responses from the server. To run netcat as a server, use the command nc -l <port_number>. (On some machines, you may need to add a -p flag, nc -l -p <port_number>.) Once netcat is running as a server, you can connect to it using the hostname localhost (netcat will need to be running on the same machine as your DICT client for this to work properly). You can manually type responses into the terminal window; however, this can get tedious after a while. Instead, place the responses you want your server to send into a text file and then pipe it to the netcat command: nc -l 2628 < server_responses.txt. You can obtain some sample responses by connecting to a real DICT server (e.g. dict.org) and copying the responses into the server_responses.txt file.

Now it’s your turn. Prepare a text file with some responses you’d expect from the DICT server and start netcat in server mode. Connect to it with your DICT client and see if it works! It’s important that the order of responses in your text file should correspond to the order in which commands are sent by the DICT client. The DICT client will always start by connecting to the server, and then immediately sending a SHOW DB then a SHOW STRAT command.

Note: Netcat should come preinstalled on Macs and is available on most Linux distributions via your default package manager. Windows users can install netcat by following these instructions: https://www.configserverfirewall.com/windows-10/netcat-windows/. Windows users will need to use ncat instead of nc in the provided commands.

Part II: DNS

Let's introduce a couple of tools and techniques that you’ll find useful for understanding the DNS protocol. We will use dig to make DNS queries, and Wireshark to investigate the format of DNS Messages.

The DNS protocol is declared in multiple RFCs, including revisions and added features. You can refer to these RFCs throughout the tutorial

RFC

• RFC 1035 contains the format and use of DNS messages.
• RFC 1034 describes the concepts and elements of the DNS protocol. While you don't need to get familiar with all of these elements, this is a good reference to get more information about the meaning of specific keywords like "resource records" and "aliases".
• RFC 3596 extends the DNS protocol to support AAAA record types, used for IPv6 addresses.
• RFC 6891 provides a way of consuming large DNS messages over UDP.

Try answering the following questions by looking up the RFCs.

1. What is the purpose of the ‘AA’ (Authoritative Answer) flag in a DNS response?
2. What is DNS name compression and why is it used?
3. What happens when a DNS query returns no results? What is the typical DNS response in this case?
4. What is the difference between a DNS ‘CNAME’ record and an ‘A’ record?

Message compression

Let's decode the bytes of a DNS message by hand and understand how message compression is implemented in DNS. Message compression is described in RFC 1035 Section 4.1.4.

DNS Messages in Wireshark

If you haven’t already done so in tutorial 1, please download Wireshark and open dns.pcap (File -> Open). This file contains a single DNS request and its corresponding response. See if you can answer the following questions about this request:

1. What kind of record is being requested?
2. What name is being looked up?
3. How many answers were provided?
4. What other sections of the DNS response contain information?
5. How would you use the information provided in the other sections?
6. This file is only supposed to contain one request/response pair, but there are 4 packets. Why?

Dig

Dig is a command line program for making DNS queries. You may find it useful when developing your DNS client to ensure that your code produces the correct result. We’ll be using the version of dig that’s installed on the department’s linux servers. You may already have dig installed locally – it’s likely that these exercises will work with any version of dig, but if something isn’t working as expected locally you should try using the department’s linux servers instead.

Some alternatives to dig are

• drill: drill [@nameserver] name [type]
• resolvectl: resolvectl query [--type type] name

The syntax of a dig query is dig [@nameserver] name [type]. By default, dig requests the A record (IPv4 address) for the provided host name. You can specify the type of record after the name if you want to retrieve a different kind of record. If you don’t specify a nameserver to serve your DNS query, dig will use the system default (as specified in the /etc/resolv.conf file). Try to answer the following questions using dig:

1. What IPv4 address can be used to connect to github.com?
2. Can github.com be accessed over IPv6?
3. Are any other records returned when you query github.com for an IPv6 address? What does it mean?
4. Does github.com have any mail exchanges?
5. What name servers does github.com use?
6. Try querying for an IPv4 address from one of the name servers in part (5). Do you get the same answer as in part (1)?

DICT Protocol Handling & RFC Reading (DIY)

Walking through the SHOW DB command:

Section 2.4 of RFC2229 says that a Dict Server’s responses will be made of 2 parts: a status and a textual section. Answer the following questions based on this section of the RFC. Note that the codes given aren’t necessarily real codes that the RFC implements.

1. What does the first digit of a status code mean? What about the second? What about the third?
2. Given the RFC code definition, what could the following codes mean: 50z, 25z, 11z, 42z.
3. Given the RFC code definition, what would be the reasonable code for:
   1. A successful command process has started
   2. Too many parameters were sent with the command
   3. Authentication has begun and now requires a password from the Client

Now that responses are somewhat clear, we will go through how the RFC implements the <SHOW DB> command (Section 3.5.1 of RFC2229).

First, we will look at the General Status Responses. Using netcat, we can connect to a dict server and try to make some of the responses occur. Which ones could you make happen and which ones couldn’t you?

Along with the general responses, the SHOW DB command has 2 distinct responses: 1) 110 n databases present - text follows, 2) 554 No databases present. Based on the description of the command, we will expect that when we use a correct SHOW DB command that the response will be of the form:

110 n databases present - text follows
database1 description1
database2 description2
database3 description3

Notice how the string is terminated. Now, let's test the command using netcat.

In order to process this response programmatically, we use what we have done in this tutorial section, along with the last tutorial’s socket programming (essentially the programmatic version of netcat)!

Review the list of functions that you’ll be implementing and map them to the relevant command in the RFC2229.

• getDefinitions()
• getMatchList()
• getDatabaseList()
• getStrategyList()
• getDatabaseInfo()

Once you’ve determined which commands you need to use, test them in netcat to see what the responses look like. Try sending responses that are malformed and seeing what error codes are returned; in the assignment you will have to handle returned errors correctly!

You’ll also probably have to manipulate the responses to produce the data structure(s) expected by the GUI application that uses your DICT client. Take a look at the additional classes we’ve provided for the assignment - you may find them useful for parsing responses...