TCPtrace - An introduction

What is TCPtrace ?

Wireshark wins over TCPtrace on GUI

 

Its a tool designed to analyze the output logs from TCPdump. Previously, in my introduction to TCPdump I highlighted that the output logs created by TCPdump were not plain text and only special programs could interpret them, TCPdump is one of these program, as is Wireshark and TCPtrace.

So TCPtrace takes the output file from TCPdump as an input and it then outputs useful information and graphs.

How do I get TCPtrace ?

I downloaded it from the Ubuntu repositories using the typical 'sudo apt-get install tcptrace'. If this is not possible you can download it from here.

How do I input a TCPdump file to TCPtrace ?

You can call TCPtrace with a TCPdump file using  'tcptrace <my-file>' where my-file is the name of the file outputted by TCPdump. For example you could do something like:
$ sudo tcpdump -v -i wlan0 -w my_tcpdump_output -c 100
$ tcptrace my_tcpdump_output

The above will run TCPdump and create the output file called "my_tcpdump_output", this file is then passed as a argument to the TCPtrace tool

How do i interpret the basic TCPtrace output ?

The structure of the output is (in order from the top) :

• 1st line returns the name of the TCPdump output file that TCPtrace is currently analyzing
• Then it printed the version of TCPtrace and then this version was last compiled
• The next line states the number of packets seen and the number of those which were TCP
• The following line gives the elapsed wallclock time, this is the time TCPtrace took to process the file and it then gives the average number of packets processed by TCPtrace per second
• The following line gives the trace file elasped time, this is the time between the capture of the first packet and the last packet in the file
• The sequential lines contain information on each TCP connection
• First it gives the address and ports of the two machines involved in the connection
• Then is the label given to this connection by TCPtrace is printed in parenthesis
• The number proceeding '>' is the number of packets seen in the first host to second host direction
• The number proceeding '<' is the number of packets seen in the second host to the first host direction
• Then the connection is labelled with '(complete)' or '(reset)', with the connection being labelled as complete if SYN and FIN packets were seen

This output is TCPtrace's brief output. Just like TCPdump, you can stop the translation of IP address to domain names using the '-n' opinion.

When using TCPdump, you can see more detailed output using the '-v' option but with TCPtrace you can see more detailed output using the '-l' option.

When adding options to TCPtrace, you need to ensure the you place the extra options before the name of the input file and after the tool name.

When viewing the output from the long mode (when -l is the option) then all information is labelled. I'm now going to explain each label given in long output (warning .. this might take a while):

Packets and ACKS

• total packets - number of packets sent in that specific direction
• ack pkts sent - number of ACKs sent in that direction
• pure acks sent - number of ACK sent without data and the SYN,FIN&RST not set
• sack pkts sent - number of selective ACKs sent in that direction
• dsack pkts sent - number of duplicate selective ACKs sent in that direction
• max sack blks/ack - maximum number of selective ACK blocks seen in any selective ACK packet

Retransmissions

• unique bytes sent - total number of bytes sent excluding retransmittions
• actual data pkts - total number of packet with at least 1 byte of TCP payload
• actual data bytes - total number of bytes seen including retransmittion
• rexmt data pkts - total number of packets that where retransmittions
• rexmt data bytes - total number of bytes of data that where retransmittions

Window scaling / Probing

• zxnd probe pkts - total number of window probe packets seen
• zxnd probe bytes - total number of bytes sent in window probe packets
• outoforder pkts - number of packets that arrived out of order
• pushed data pkts - number of packets with the PUSH bit set, this means that the buffered data should be sent to the receiving application
• SYN/FIN pkts sent - number of packets with SYN or FIN bits set

etc... (sorry I hate leaving things half done, but I really wanted to move on, its in my to-do list)

How do I get RTT (Round-Trip-Time) from TCPtrace ?

TCPtrace will generate statistics on RRT when using with the opinions '-r' and '-l'. This will give data on RRT including the number of RTT samples found, RTT minimum,RTT maximum, RTT average, RTT standard deviation, RTT from TCP's hand shake. The same data is then available again for full-sized RTT samples only.

TCPdump - An introduction

As per usual, if you find any mistakes, concepts that could be explained better or have something to add, then please comment below and I'll correct it.

What is TCPdump ?

TCPdump is a command line tool that is used to look at packets on the network. TCPdump does not generate the packets itself but instead it analyzes the packets generated by other applications and from this, it can determine network behaviour and performance.

Despite being called TCPdump, you can choose from a range of protocols including IP,ARP, TCP and UDP.

How do I get TCPdump ?

From Ubuntu, I simply got it via 'sudo apt-get install tcpdump'. Otherwise the public repo is located here, along side some useful information and the manual pages.

You can also check the dependencies of TCPdump using 'apt-cache depends tcpdump'. The output that this returns for me is:

  Depends: libc6

  Depends: libpcap0.8

  Depends: libssl1.0.0

  Suggests: apparmor

  Conflicts: tcpdump:i386

 

If you get the package for the public repo, then you need will extract the content of the .tar.gz file using 'tar -zxf tcpdump-4.3.0.tar.gz' after using cd to move to the directory that you downloaded the file to, then install the program.

So I've got it.. but how do I use it ?

To start with use 'sudo tcpdump' to output to the terminal, this gives the standard output of TCPdump, using the default arguments since you have not passed TCPdump any arguments yet. To the output will be printed to the terminal, until you stop the program using Ctrl-C.

Don't be scared ... we will now begin the break this output down into understandable section (if you not scared then try 'sudo tcpdump -v' or 'sudo tcpdump -vv'  for a verbose output).

Changing network interface

When I'm using tcpdump, it listened on eth0 by default, but you can change this. Entering 'sudo tcpdump -D' will return a list of network interfaces that you can choose between. For me this returns:
        1.eth0
        2.wlan0
        3.usbmon1 (USB bus number 1)
        4.usbmon2 (USB bus number 2)
        5.any (Pseudo-device that captures on all interfaces)
        6.lo
The first item in the list is the Ethernet port, the 2nd is the Wireless card and the 3,4,5th is self explanatory. The 6th is the loopback virtual interface (more information here on wikipedia)

You can then change the interface, by calling TCPdump using 'sudo tcpdump -i <name-of-interface> '. For most of my work, I use the local Wi-Fi so can change the interface from Ethernet to wireless using 'sudo tcpdump -i wlan0'. 

Creating a file to store the tcpdump arguments

So far, we have only added one argument when we call TCPdump, but there will be a lot more to come. We can save these arguments, which filter the output of TCPdump to a file and then use the file when we call TCPdump.

Create the file using your favourite text editors (mine in gedit at the moment) and then pass the file to TCP dump using 'sudo tcpdump -F <my-file>'. The file dose not need any special file extension or layout.

You may need to change the file permissions so that TCPdump can extract the file. You can view the file premissions using 'ls -l <my-file>'. The 'ls' part is command line tool to list the files in a directory and the argument -l means use long format so the file permissions will be included. The file 10 characters are the file permissions, they are decoded as follows:

1. 'd' means this is a directory and '-' means this is a file
2. 'r' means that the file owner can read the file, '-' means they can't
3. 'w' means that the file owner can write to the file,  '-' means they can't
4. 'x'  means that the file owner can execute the file,  '-' means they can't. If this is a directory then 'x' means that the owner can list the files in directory, '-' means they can't.
5. 'r' means that the file group can read the file, '-' means they can't
6. 'w' means that the file group can write to the file,  '-' means they can't
7. 'x'  means that the file group can execute the file,  '-' means they can't. If this is a directory then 'x' means that the owner can list the files in directory, '-' means they can't.
8. 'r' means that everyone else can read the file, '-' means they can't
9. 'w' means that everyone else can write to the file,  '-' means they can't
10. 'x'  means that everyone else can execute the file,  '-' means they can't. If this is a directory then 'x' means that the owner can list the files in directory, '-' means they can't.

For me, the default file permissions are '-rw-rw-r--'. This therefore means that the file owner doesn’t have permission to execute the file. This can be changed using 'chmod u+x <my-file>'. The command line tool is chmod, this is used for changing file permissions, 'u' means we are considering the users permissions, '+' means we are granting a permission and 'x' means we can considering the execute permission. Now, if I redo 'ls -l <my-file>' the new result is -rwxrw-r--.

  

Sending the output to file

You can send the output of tcpdump to a file instead of printing it to the terminal using 'sudo tcpdump -w <my-file>'. This output is not saved as a plain text so you can't just read it in a text editor instead you need to use a special program to read the file and extract information from it. You can do this using tcpdump by 'tcpdump -r <my-file>'. Alternatively you can open it using wireshark, launch wireshark and using File>Open.

 

Filtering information by protocol

To filter packets by protocol, add the name of protocol to the arguments of tcpdump so use something like 'sudo tcpdump <name-of-protocol>'. The main protocols that I'm likely are use are IP, ARP, TCP and UDP but others are available, see the man pages for a full list

Filtering information by direction to different hosts

To filter packets by a direction and host, add the direction and then the host name. Possible direction options are src, dst, src or dst, src and dst. You specify the host using its IP address. You can use the logical operators not, or and and. For example, you can look up the local IP address of your machine using 'ifconfig <name-of-interface>'. If you don't specify the name of the interface, then all interfaces will be listed. Now if you only want to view incoming traffic you can use 'sudo udpdump dst <ip-address>'.

Change the level of detail 

Compared to the level of detail provided by the standard query, The detail can be reduced using '-q' for quiet output or increased using '-v' for verbose, '-vv' for more verbose and '-vvv' for even more verbose.

The opinion '-t' means do not print timestamp on each line and the option '-a' allows you to display each packet in ASCII or '-x' to display in hex or '-X' to display in hex and ASCII

View IP address instead of domain names

You can stop the translation of IP address to domain names using the '-n' opinion and you can stop the translation of port number too using the '-nn' opinion

Sources of Info

Wikipedia article, which contains very little information

Official public repo, including the man pages and FAQ 

Useful online tutorial at openmaniak, this site also has good tutorials on networking tools that I've previously covered including wireshark, OpenVPN, Iperf and ping.

Getting Client & Server Talking - Demo Pt 3

Now I have an Android phone running the client and my laptop running the server, its time to get them taking.

A quick inspection of the client code shows the line "public static final int [] IP_ADDR = {128,2362,110,172}; " I change this to the IP address of my laptop and reload the code onto my android phone.

I launch the server on my laptop, the client on the Android phone and here the troubleshooting begins. Nothing appears to happen on either the client or server so I:

1. check the network connection on both client and server  ✓
2. un-install the client application and re-install it ✓
3. check the IP address of the server is correct ✓
4. Try running client on emulator ✓ just got the exact same problem 

Taking a closer look at the IP address used:

I tried to find out the IP address of the server by visiting here but i thought that I should try to take a more technical approach. Visiting connection information in Ubuntu gives me a different IP address. Now I'm fairly sure that my server is behind a NAT as is my client.

Initally I assume that the different IP address are caused by the NAT, therefore the IP address from the website, is my public IP address (the IP address of the NAT) and the IP address given to my by my OS is the private IP address, that I am referred to by machines also behind the NAT.

This explaination fails to explain why using the IP address from the website didn't work and the IP address given to me by my OS doesn't have the normal structure that I would accociate with a private IP address.

So I now repeat my initial test using the different IP address (previously I used the address provided by a website and now I am using the one provided by the OS) and it works on both the android phone and the emulator.

But by use of the word "works" I mean that the server recognises that a client has connected and the GUI on the android client provides graphs showing latency and goodput, it unfortunately doesnt mean that I've yet found a good way to extract the data to make a comparision to the data provided by Iperf to test accuracy and reliably, on the assumption that Iperf will always produce accurate results that we can assume to be the true value.

The next useful step will be to continue to explore why this IP address works and the other one doesn't. As the client and server are now able to connect I can test if this IP address is working only because both client and server are behind the same NAT or is there something more complex going on. Currently both the laptop and android phone are making use of the same Wi-FI network, so the next step in testing if this will work when the client and server are not behind the same NAT is to change the network that either is using.

The plan for testing with would be:

• move server onto another WiFi network
• find out new IP address and update client code
• test if emulator can connect to server, it should do as it used same network connection as the host computer, which in this case is the server
• test if android phone can connect to server, it should not as its now not behind the same NAT as the server
• move the android phone onto the other WiFi network
• test if android phone can connect to server, it should now be able to 

As this test is not critical for now, I will move onto Part 4 next week, where I get Iperf collecting the same data between the android client and then compare the data collected

Running the Android Client - Demo Pt 2.1

An update for you on my progress on test the code to measure network performance between an android phone and a computer running a server written in Ocaml. So far, I have run the server and the client separately but not yet got them communicating. As explained in part 2 of this series, I decided to set up Eclipse with ADT Plugin on my desktop after getting some weird errors on my current laptop set up of Eclipse and ADT. The details of the problem are available here on Stackoverflow.com. There has been no clear solution to the problem. Therefore I have had to totally remove my install of Eclipse and ADT, so that I can start all over again.

DreamPlug

I've also been distracted the last few days by this piece of new kit, the DreamPlug. We are using it as part of the upcoming Signposts Demo at SIGCOMM in Helsinia.I will write an article on it soon

Finally I've fix my Eclipse set-up and I'm now able to load the client code onto the Android phone and run the server on my laptop. Part 3 will be coming very soon.

Also on a personal note, I am 20 today...

Running the Ocaml Server - Demo Pt 1

-->

I've got some code here and here in OCaml & Java, that I have been tasked with running, testing and fixing. I've already taken a look at the basic syntax but now its time to get to grips with some the libraries and related packages that Signposts makes use off.

THE SERVER IN OCAML

The first thing that took me by surprise was the number of files in the repo, considering that this is suppose to be a fairly straight forward project.

Oasis

The repo contains a file called “_oasis”, which on closer inspection includes a collection of metadata on the project. OASIS is a tools to integrate a configure, build and install system into an OCaml project. The _oasis files tells me that the entry point for the program is “server.ml” and the build dependences are the findlib packages lwt.syntax, lwt.unix, re, re.str.

The creater of the program will have ran “oasis setup”, which has generated setup.ml, _tags and myocamlbiuld.ml.

According to the instructions for OASIS you can configure, build and install the Ocaml program using:

• ocaml setup.ml -configure

• ocaml setup.ml -build

• ocaml setup.ml -install

Re_str

The server.ml file makes use of Re_str and two of the biuld dependences are the findlib packages re and re.str. I have found the packages here on github. Re stands for Regular expression and ocaml-re is a regular expression library doe Ocaml (that is still under development). This project has also made use of OASIS and installs without a problem

Compiling the Code

I cd into the directory and run ocaml setup.ml -configure, ocaml setup.ml -build and ocaml setup.ml -install. This generates a new dirctory “_biuld” and a new link to an executable in _biuld

Running the Code

I run a link to the execuated in _biuld and it return the following error:

Fatal error: exception Unix.Unix_error(50, "bind", "")

This means that the socked that the code is try to bind to is already in use. I inspected the code, identified the ports that were being used and ran “sudo netstat -ap | grep ':<portnumber>' “. This identified a process already using the port, the process was in fact an earlier attempt to run the project. I identified the process ID and killed the process, re-running “sudo netstat -ap | grep ':<portnumber>' “ showed that the port was now free. I can now happily run the executable in the _build directory. As this is a client-server implementation, I now need to move my attention to the client code

Running the Android Client - Demo Pt 2

[ Sorry but this is part 2 in the series, I have completed part 1 but will not be able to upload the article until tomorrow ]

This is the 2nd part of a series on my taking a look at the code here, to test it and then improve it if required. In part 1, I ran the Ocaml server on my laptop. In this part, I run the android client. Tomorrow (Monday), in part 3 I am going to get the client and server communicating. On Tuesday, I will hopefully collect some data that I can then extract in some suitable format. On Wednesday, I hope to run Iperf between my client and server to collect data and extract in some suitable format. On Thursday, I hope to have a day of collecting data using both the GitHub code and Iperf. Finally on Friday, I hope to use a statistics package such as MatLab to compare the data collected and see if there is a statistically significant difference.

Since I have managed to mess up my eclipse/android install (see part 1), this gives me a perfect excuse to set up eclipse with ADT Plugin on my desktop. I've also got my hands on a different android phone, since the code that testing was designed for API 10. The phone info is as follows: 

Model: HTC Hero Andriod Version: 2.3.7CPU: ARMv6- compatible processor #34Available memory: 190MBMod Version: CyanogenMod-7.2.0-RC1-UNOFFICAL
Build Number: GWK74

THE BIG PLAN

The stages in setting up the Android ADK, Eclipse and loading the code that I'm testing on the Android device (spec above)

1. Download the Android SDK (Software Development Kit)
2. The SDK only installs the SDK tools so to install other parts of the SDK, I've got to open up the Andriod SDK Manager, this is done by cd'ing into the tools/ directory and executing android SDK
3. To develop an Andriod app, I need to download the lastest Android SDK Platform-tools and at least on Android platform. The platform that I want is the one associated with Android 2.3.7 and API 10, I'm going to get the related SDK Platform. Documentation and System image.
4. Download and install the latest Eclipse Classic
5. Add the source of the ADT Plugin to the Repository in Eclipse and download the Developer Tools in via Eclipse
6. Specify the location of the Android SDK directory in the Preferences panel of Eclipse
7. Create a AVD (Android Virtual Device) in Eclipse with target platform 2.3.7 and API 10
8. Download the code that I'm testing from GitHub
9. Import the code into Eclpise
10. Test Code on the AVD
11. Plug in Android phone and test code on the Andriod phone

AND THEN THE REALITY

1

The Android SDK is avaliable from the Android Developer Site, the package for Linux is called android-sdk_r20-linux.tgz.


The download comes as a .tgz file, this can be extracted using: tar -zxf android-sdk_r20-linux.tgz after using cd to move to the directory that you downloaded the file to.

I've found that its useful the learn as your going along, the purpose of the arguments that you are passing to programs, so that you can then easily adjust the arguments in future to suit your needs. Using man tar, explains that -z means filter archive through gzip, -x means extract the filesand -f means that your next going to give the file name.I would highly recommend that when following tutorials with Unix commands that you use man to look up what the executable and its arguments do.


2

As with the last time I installed Android SDK, to launch the Android ADK Manager, I need to enter ./android SDK instead of android SDK. This then appears to work fine, but I would still be interested as to why I didn't work as expected.

[To clarify This command is entered after you use cd to move into android-sdk-linux/tools]


3

I selected the required packages (that I've listed in the plan above) and download them, simple as.


4

(Read this whole paragraph before beginning to download Eclipse) I download Eclipse Classic 4.2 for 32 bits as a .tar.gz file and extract the file (like before using tar -zxf eclipse-SDK-4.2-linux-gtk.tar.gz ). To install Eclipse, I cd into the new eclipse directory, to find no configure file, so my normal method of installing from .tar.gz files, of using ./configure && make && sudo make install will now not work. I little bit of research highlights that installing eclipse its not as straightforward as it might seem and the best approach for integration into Ubuntu is to get it from the software center, though I would prefer to continue to use the command line, I'm happy to leave it for now and return to this point at a later date


5

I start up eclipse, select my workspace and go into Help > Install New Software. I add the ADT Plugin at the URL https://dl-ssl.google.com/android/eclipse/. I then select the Developers Tools and install


6

With a slow connection,

you could be waiting sometime

I restarted Eclipse and configured the new ADT Plugin to link it to the Android SDK. On launching Eclipse, I'm presented with a Welcome to Android wizard (not used in the instruction at https://developer.android.com/sdk/installing/installing-adt.html)


7/8/9

Using the Eclipse GUI setting up a virtual device is straightforward. I navigate to the correct page on GitHub, download the code and extract as already done twice before and then I import the code as an existing Android project into Eclipse.


UNEXPECTED DIGRESSION


On loading the code, that I know should compile, eclipse highlights 2 errors and 13 warnings. As I'm just testing the code today before reviewing it next week. I will ignore the warming but deal with the errors as they prevent me from testing the code. The first error is from the line: import com.google.gson.Gson; I download the Gson project from googlecode and add it as an external libray to the project to overcome this. The second error is from the following line: public void onClick(View v). The error is that: The method onClick(View) must override a superclass method so this can be fixed by removing the above @Override annotation


10

Before I can run the code on the emulator, I create a new andriod project and add the code so far. I then use Run As > Android Application to test the code and it works

11

I put the android phone into USB debug mode, plug it in and run as. Again it works :)

"The best part about being a computer scientist is the feeling of satisfaction when something finally works"

RFC 1034 - An insight into the 1980's

-->

If you think that RFC make dry reading, maybe just maybe you just haven't given them enough of a chance yet. Today, I begin reading my first RFC, I choose RFC 1034 and I can genuinely say that I've found much more interesting than I was expect, in fact I've struggled to put it down (though I suspect that says more about me than RFCs) . RFC 1034 was written 1987 (before I was even born) and offers an insight to a world before DNS and how its designed envisioned DNS's future use. Below are my notes on the RFC so far (this is likely to be the first collection of notes out of 3). Sorry for the bullets but its my preferred way to take notes

-->

I've located the Request for comments (RFC) relating to DNS from the following page http://www.zoneedit.com/doc/rfc/. The RFC that I am going to begin with reading is RFC 1034. This RFC is developed in November 1987 and it titled “Domain Names – Concepts & Facilities”

-->

Historical Context

• Originally per host file in /etc/hosts for hostname to IP address mapping was updated via FTP.
• The bandwidth required to update this per host file was proportional to number of host squared, hence exponential grow of hosts mean new system was required
• The first operational packet switching network was the Advanced Research Projects Agency Network (ARPANET)
• When changes to the per host file were make, they took along time to propagate to all hosts

Common Ideas from Proposed Solutions

• Hierarchical name space with the hierarchy corresponding to organisations structures
• Using a full stop “.” to mark the boundary between hierachy levels

DNS Design Goals

• Consistent name space where names do not include network identifiers or addresses
• Distributed management with local caching
• Minimising attempts to collect consistent copies of entire database as this is not scalable
• Source (not client) control tradeoff between cost, speed and accuracy of caches
• All data associated with a name is tagged with a type
• Name server translations should be independent of communication system that carriers them
• The system should be useful across a wide spectrum of hosts

Usage Assumptions

• Initially total database size is proportional to number of hosts but this will grow in time
• System wide data will change slowly, subnet wide data will change rapidly
• Each organisation is responsible for its own domains including providing redundant name servers
• Clients use trusted name server before name server outside the “trusted set”
• Availability is more important than consistency so its ok that updates are not simultaneous
• Believe old data when new data is not yet avaliable
• Copies of translations are distributed with time-outs for refreshing, the distributor sets time-out value
• When a name server is presented with a query that can only be answered by some other server, either a recursive (name server asks another server to do query) or iterative (name server returns address of another name server to ask instead). The iterative approach is preferred but the recursive approach is still an option
• All data originates from master files keep on hosts that use the DNS
• All master files are updated by local sysadmin and all master files are text files that are read by a local name server
• User programs access name servers through standard programs called resolvers
• The standard format of master files allows them to be exchanged between hosts
• Sysadmin provides zone boundaries, master files of data, updates of master fules and refreshing policies
• DNS provides standard formats for resource data, standard method of querying the database, standard methods for name server to refresh local data from foreign name servers

DNS & Resource Records (RR)

• The names in the name space will have a tree structure and RR hold the data associated with each name
• Each node and leaf on the DNS tree has a set of information associated with it and a DNS query aims to extract this information
• A DNS query includes the name of interest and the type of information that is required

Name Servers

• These are server programs which hold information about the DNS tree structure and information set
• A name server may cache information on DNS tree structure or information associated with particular names
• In general, a name server has complete information from a subset of the DNS tree leaves and then pointers to other name server that can be used to get information on the other areas of the DNS tree
• A name server has authority for the area of the DNS tree for which it has complete information
• Authotitative information is organized into units called zones

Resolvers

• Resolvers are programs that extract information from the name servers in response to client queries
• All resolvers must have access to at least one name server
• Typically a resolver is a system routine that is accessible to user programs

DNS from a client prospective

• DNS is accessed via a procedure call to the local resolver
• The DNS consists of a single tree and the user can request information from any section of the tree

DNS from the resolvers prospective

• DNS is composed of an unknown number of name servers
• Each name server hold at least one piece of information from the DNS tree
• The DNS tree is static

DNS from the name servers prospective

• DNS is divided into zones
• The name server has local copies of some zones
• The name server must periodically refresh its zones from master copies in local files or foreign name server

Name Specification

• The term “node” is used to refer to both interior nodes and leaves
• Each node has a resource set, though this can be empty
• Each node has a label, 0 to 63 octets (an octet is 8 bits) in length
• Brother nodes may not have the same label
• The same label can be used by nodes that are not brothers
• The root label is null
• The domain name of a node (not the same as the label for a node) is the list of labels on the path from the node to the tree root
• The label that compose the domain name are read from (most specific) left to (most general) right, e.g. consider the structure of the DNS name for college computers as342.priv.queens.cam.ac.uk
• Domain names are case-insenstive
• In domain names the labels are separated by dots (.)
• A domain name ending in a dot represents a absolute/complete domain name
• A domain name not ending in a dot represents an incomplete domain name that should be completed by local software (aka relative domain name)
• The maximum domain name length is 255 octets (set of 8 bits), this includes labels and label lengths
• A domain is identified by a domain name and consists of the tree at and below that domain name
• A domain is a sub domain of another domain if it is contained within that domain
• You can test if a domain is a sub-domain of another, if the domain name is the within the end of the sub-domain e.g. cam.ac.uk is a sub-domain of uk and queens.cam.ac.uk is a subdomain of ac.uk
• Labels must follow the rules for ARPANET host names

Email

• The usually format of email addresses is localpart@maildomain, this is mapped to a domain name so that it can be looked up in the domain name tree by converting localpart into a single label (ignoring dots) then converting maildomain into a domain name (not ignoring dots) and replacing @ with a dot to form a domain name so the email address as342@cam.ac.uk will become as342.cam.ac.uk
• Domain names ( and therefore email addresses) are case insensative

Resource Records (RR)

• Each node in the tree has a set of resource information, this can be empty
• The set of resource information is composed of the set of Rrs
• Order of RRs is not significant and need not be preserved
• The owner of RR is the domain name where the RR is found, this is normally inplicit rather than being an explicit part of a RR
• The type of a RR is an encoded 16 value such as:

A – a host address

CNAME – the canonical name of an alias

HINFO – CPU & OS used by a host

MX – mail exchange for domain

NS – authoritative name server for the domain

PTR – pointer to another part of domain name space

SOA – start of zone of authority

• The class of a RR in an encoded 16 bit value such as IN – internet system or CH – Chaos System
• The TTL of a RR is the time to live of the RR, this is a 32 bit integer in seconds, this defines how long a RR can be cached for before discarding, this limit does not apply to authoritative data in zones (TTL of 0 will prevent caching)
• The RDATA of an RR contains different values depending on the type of class of the RR such as:
• If type is A and class is IN, then RDATA is a 32 bit IP address
• If type is A and class is CH, then RDATA is a domain name followed by a 16 bit octal Chaos address
• If type is CNAME, then RDATA is a domain name
• If type is MX, then RDATA is a 16 bit preference values followied by a host name willing to act as a mail exchange
• If type is NS, then RDATA is a host name
• If type is PTR, then RDATA is a domain name
• If type is SOA, then RDATA is several fields
• The structure of an RR is as follows:
• start of line gives the owner of the RR, next we list the TTL, the type and the class of the RR (dig giving results in different order)
• Domain names in RR's could point at the primary name not another alias to avoid extra indirection

Queries

• queries are carried in UDP or over TCP connection
• responses to queries are either the answer to the question, refers the requester to another set of name server or signals some error condition
• in general the resolver deals with queries on the users behalf
• DNS queries and responses have a standard format, the start is a opcode which is one for a standard query
• Then there are 4 section in a DNS query/response:
• Question – Query name and other parameters
• Answer – Carries RR's which directly answer the query
• Authority – Carries Rrs which describe other authoritative servers
• Additional – Carries Rrs which may be helpful in using the Rrs in the other sections
• A standard query specifies a target domain name (QNAME), query type (QTYPE) and query class (QCLASS)
• QTYPE field may specify a specific type, AXFR special zone transfer QTYPE, MAILB matches all mailbox related Rrs or * which (like the regular expression) matchs all RR types
• QCLASS field may contain a specific type or * to match all RR classes