• Best VPN Service

    Top VPNs that Unlock Netflix, provide Secure Torrenting, Strong Encryption, Fast Downloads, DNS Leak Protection, Identity Protection and have Cheap VPN prices.

    read more

    Hyper-V Concepts

    It's time to get familiar with Hyper-V Virtualization, virtual servers, virtual switches, virtual CPUs, virtual deployment infrastructure (VDI) and more.
    Read more

Hot Downloads

Binary & The Internet Protocol

Posted in IP Protocol

To understand the Internet Protocol, we need to learn and understand Binary. It is very important to know and understand Binary because part of the IP protocol is also the "Subnetting" section which can only be explained and understood when an IP Address is converted to Binary!

This article deals with the analysis of IP addresses and covers the conversion of IP address to binary. We explain the conversion process with much detail using our well known diagrams. At the end of the article, readers will be able to understand and explain how IP address to binary conversion is performed and also calculate quickly the 32bit addressing scheme.

Those who are experienced in Binary can skim this section quickly, but do have a look through.

A lot of people are not aware that computers do not understand words, pictures and sounds, when we interact with them by playing a game, reading or drawing something on the screen. The truth is that all computers can understand is zeros (0) and ones (1) !

What we see on the screen is just an interpretation of what the computer understands, so the information displayed is useful and meaningful to us. 

Binary: Bits and Bytes

Everyone who uses the Internet would have, at one stage or another, come across the "Byte" or "Bit" term, usually when you're downloading, you get the speed indication in bytes or KBytes per second. We are going to see exactly what a Bit, Byte and KByte is, so you understand the terms.

To put it as simply as possible, a Bit is the smallest unit/value of Binary notation. The same way we say 1 cent is the smallest amount of money you can have , a Bit is the same thing but not in cents or dollars, but in Binary.

A Bit can have only one value, either a one (1) or a zero (0). So If I gave you a value of zero: 0, then you would say that is one Bit. If I gave you two of them: 00, you would say that's two Bits.

Now, if you had 8 zeros or ones together: 0110 1010 (I put a space in between to make it easier for the eyes) you would say that's 8 Bits or, one Byte ! Yes that is correct, 8 Bits are equal to one Byte.

The picture below gives you some examples:

ip-binary-1

It's like saying, if you have 100 cents, that is equal to one Dollar. In the same way, 8 Bits (doesn't matter if they are all 1s or 0s or a mixture of the two) would equal one Byte.

And to sum this all up, 1024 Bytes equal 1 KByte (Kilobyte). Why 1024 and not 1000 ? Well it's because of the way Binary works. If you did the maths, you would find the above correct.

DNS Response Message Format

Posted in Domain Name System (DNS)

The previous article covered the DNS Query message formats. In the article we analysed them in great detail and showed how various options are selected by the host using the Flags/Parameters field.  This article moves one more step ahead by covering the DNS response received from the previously generated DNS queries. DNS responses, in the case of a recursive DNS query, come directly from the DNS server that received our initial DNS query, while in the case of a non-recursive DNS query, the response arrives from the last DNS server the client (PC) queries in order to get the required DNS information.

DNS Analysis - Server Response

Here is the response (highlighted section in the screenshot below) to the previous DNS query sent to DNS server with IP address 139.130.4.4:

dns-response-format-1

Something worth paying attention to is the time it took to receive and answer to our DNS query, which was only 0.991 seconds!

There are a lot of factors that contribute to this fairly fast reponse: The UDP transport protocol , which does not require any 3-way handshake, the load of the initial DNS server queried, the load of the other DNS servers that had to be ask, the connection speeds of everyone (our workstation, DNS servers, etc), and the traffic load between all paths our packets have taken during this DNS query/response!

Analyzing a DNS Packet

Following is the Ethernet II packet that runs on the local network. The structure is the same as our previous DNS query packet, but varies in size:

dns-response-format-2

Now, to make the analysis of the DNS Section easier we have also included the DNS Query (left) and DNS Response (right). This allows us to easily compare both DNS query and response packets:

 dns-response-format-3       dns-response-format-4

By comparing the two packets, we can see that there are fields in the DNS Response packet (marked with green arrows) that didn't exist in the Query. Let's see again what each field means and anaylse them again as we did in the previous page.

The DNS Section in a response packet is considerably larger and complex than that of a query packet. For this reason we are going to analyse it in parts rather than all together. The query had only one section that required in-depth analysis whereas the response has three since the first one is the original query sent:

Here is the section of a DNS response:

dns-response-format-5

You can clearly see that everything after the  block labeled "DNS Query Section" is new. We are going to focus on these 3 new blocks, which are part of the DNS Response Section, as the rest has been covered in the previous article.

 
DNS Response Section

The diagram below shows you the contents of the 3 new blocks (sections) we are looking at and they are:

  • Answers
  • Authoritative Nameservers
  • Additional Records

 dns-response-format-6 dns-response-format-7

What we need to need understand is that each of these three sections have identical fields. Even though the information they contain might seem a bit different, the fields are exactly the same and we will see this shortly.

In the picture above, we have only expanded the first part of the Answer section which is underlined in green so you can compare the fields with the ones contained in the left hand picture.

This picture below shows the expanded version from the first part of both Answers & Authoritative sections. We have already marked and labeled the fields to prove to you that they are all identical and vary only in the information they contain:

dns-response-format-8

 

Looking carefully at both Answers & Authoritative sections, we notice that the Resource Data field is first, where according to the analysis of the sections in the picture above (left side), you would expect it last.

The actual position of the field is last, but it's presented first by the packet analyser to make the presented data more user friendly.

This is also the reason the first line of each part in each section is used to provide a quick summary of the information captured.

For example, looking at line 1 in the Answers Section (underlined in green), we get a summary of the data that will follow: www.firewall.cx, type INET, cname firewall.cx.

This proves that the fields in all of these 3 sections contained in the DNS Response Section are identical, but contain different values/data.

 

 

 

 

 

Looking at each section (coloured area), one can notice that there are actually two answers which appear as a hierachical tree with the boxed '+' symbol next to them.

A question often asked is why are there two answers for each section and could there be more or less answers?

The answer is simple and logical, there are as many answers as needed, depending on the way the domain has been setup. For example, Firewall.cx currently has two nameservers configured domain, which explains the two answers for each section. If we had three nameservers configured, then we would get three answers per section.

To help make this clear, we also captured a DNS Response packet from a DNS query for the domain ibm.com:

dns-response-format-9

As it is evident, our query for IBM.COM gave us a response which has 4 answers per section!

Again, each answer in every section has identical fields, but different data/values.

You might have noticed a pattern here as well. In every DNS Response you will find the same number of answers per section.

For example, the screenshot on the left shows us 4 answers for the Answers, Authoritative and Additional records sections and this is no coincidence.

The Type field will help us understand why. Let's take a look at it.

 

 

 

 

 

The Type Field

The Type field determines the type of information we require about a domain.

The table below contains the most frequently requested Type of DNS information:

Type
Meaning
Contents
A
Host Address
32-Bit IP Address of host or domain
CNAME
Canonical Name (Alias)
Canonical domain name for and alias e.g www
HINFO
CPU & OS
Name of CPU and Operating System
MINFO
Mailbox
Info about a mailbox or mail list
MX
Mail Exchange
16-bit preference and name of the host that acts as a mail exchange server for a domain e.g mail.firewall.cx
NS
Name Server
Authoritative name server for the domain
PTR
Pointer
Symbolic link for a domain. e.g net.firewall.cx points to www.firewall.cx
SOA
Start Of Authority
Multiple fields that specify which parts of the naming hiererchy a server implements
TXT
Arbitrary Text
Uninterpreted string of ASCII text

To give a simple example, when we have a Type=A , we are given the IP Address of the domain or host (look at Answers section below), whereas a Type=NS means we are given the Authoritative Name Servers that are responsible for the domain (look at Authoritative Name Servers section below).

The screenshot below, was taken from our first example (query for firewall.cx) and we can see why the Type field is responsible for the data we receive about the domain:

dns-response-format-10

As we can see, the Type field (red circle) in the first answer of the Authoritative Name Servers section is set to NS, which means this part contains information about the Authoritative name servers of the queried domain.

Going to the first answer of the Additional records, we can see that the Type field here is set to A, which means the data contained in this part is an IP address for the particular host.

When requesting the name servers for a domain, it also also essential their IP address is also provided, so that the client can construct a DNS query and send it to the name servers for that domain.

In this article we analysed the DNS response message format by looking into the details of a DNS response packet. We also covered the different DNS type field messages and explained the contents of the DNS Response message.

Back to the DNS Protocol Section

   or                         

Back to the Network Protocols Section

Type
Meaning
Contents
A
Host Address
32-Bit IP Address of host or domain
CNAME
Canonical Name (Alias)
Canonical domain name for and alias e.g www
HINFO
CPU & OS
Name of CPU and Operating System
MINFO
Mailbox
Info about a mailbox or mail list
MX
Mail Exchange
16-bit preference and name of the host that acts as a mail exchange server for a domain e.g mail.firewall.cx
NS
Name Server
Authoritative name server for the domain
PTR
Pointer
Symbolic link for a domain. e.g net.firewall.cx points to www.firewall.cx
SOA
Start Of Authority
Multiple fields that specify which parts of the naming hiererchy a server implements
TXT
Arbitrary Text
Uninterpreted string of ASCII text

DNS Query Message Format

Posted in Domain Name System (DNS)

This section will deal with the analysis of the DNS packets by examining how DNS messages are formatted and the options and variables they contain. To fully understand a protocol, you must understand the information the protocol carries from one host to another, along with any options available.

Because the DNS message format can vary, depending on the query and the answer, we've broken this analysis into two parts:

Part 1 analyses the DNS format of a query, in other words, it shows the contents of a DNS query packet to a DNS server, requesting to resolve a domain.

Part 2 analyses the DNS format of a response, that is, when the DNS server is responding to our inital DNS query.

This breakdown help make our analysis easier to understand and follow, rather than analyzing DNS queries and answers on the same page.

 

DNS Analysis - Host Query

As mentioned in the previous sections of the DNS Protocol, a DNS query is generated when the client needs to resolve a domain name into an IP Address. This could be the result of entering "www.firewall.cx" in the url field of your web browser, or simply by launching a program that uses the Internet and therefore generates DNS queries in order to successfully communicate with the host or server it needs.

We've also included a live example (using a packet analyser), to help better understander the packets contents. Later on we'll be analysing each field within the DNS packet. For now, let's check out what a packet containing a DNS query would look like on our network:

dns-query-format-1

The above captured DNS query was generated by typing ping www.firewall.cx from the prompt of our Linux server. The command generated this packet, which was then placed on our network and sent to a DNS server on the Internet. 

Notice the Destination Port which is set to 53, the port the DNS protocol. In addition, you'll notice that the transport protocol  used is UDP:

dns-query-format-2

        dns-query-format-3
Ethernet II (Check Ethernet Frames section for more info) is the most common type of frame found on LANs, in fact it probably is the only type you will find on 95% of all networks if you're only running TCP/IP and Windows or Unix-like machines. This particular one contains a DNS section, which could be either a Query or Response. We are assuming a Query, so it can fit nicely in our example.

We are going to take the DNS Section above and analyse its contents, which are already shown in the picture above (Right hand side, labeled "Capture") taken from my packet analyser.

Here they are again in a cool 3D diagram:

dns-query-format-4

 

From this whole packet, the DNS Query Section is the part we're interested in (analysed shortly), the rest is more or less overhead and information to let the server know a bit more information about our query.

The analysis of each 3D block (field) is shown in the left picture below so you can understand the function of each field and the DNS Query Section captured by my packet sniffer on the right:

dns-query-format-5        dns-query-format-6

All fields in the DNS Query section except the DNS Name field (underlined in red in the picture above), have set lengths. The DNS Name field has no set length because it varies depending on the domain name length as we are going to see soon.

For example, a query for www.cisco.com will require DNS Name field to be smaller than a query for support.novell.com simply because the second domain is longer.

 

The DNS Name Field

To prove this I captured a few packets that show different lengths for the domain names I just mentioned but, because the DNS section in a packet provides no length field, we need to look one level above, which is the UDP header, in order to calculate the DNS section length. By subtracting the UDP header length (always 8 bytes - check the UDP article for more information) from the bytes in the Length field, we are left with the length of the DNS section:

dns-query-format-7

     dns-query-format-8

The two examples clearly show that the Length Field in the UDP header varies depending on the domain we are trying to resolve. The UDP header is 8 bytes in both examples and all fields in the DNS Section, except for the DNS Name field, are always 2 bytes.

 

The Flags/Parameters Field

The Parameter Field (labeled Flags) is one of the most important fields in DNS because it is responsible for letting the server or client know a lot of important information about the DNS packet. For example, it contains information as to whether the DNS packet is a query or response and, in the case of a query, if it should be a recursive or non-recursive type. This is most important because as we've already seen, it determines how the query is handled by the server.

Let's have a closer look at the flags and explain the meaning of each one. We've marked the bit numbers with black on the left hand side of each flag parameter so you can see which ones are used during a response. The picture on the right hand side explains the various bits. You won't see all 16 bits used in a query as the rest are used during a response or might be reserved:

dns-query-format-9

   dns-query-format-10

As you can see, only bits 1, 2-5, 7, 8 and 12 are used in this query. The rest will be a combination of reserved bits and bits that are used only in responses. When you read the DNS response message format page, you will find a similar packet captured which is a reponse to the above query and the rest of the bits used are analysed.

And that just about does it for the DNS Query message format. Next up is the DNS Response message format page which we are sure you will find just as interesting!

 

Next - DNS Response Message Format

or                                 

Back to the Network Protocols Section

 

DNS Queries & Resolution Process

Posted in Domain Name System (DNS)

This section will help you understand how the DNS queries work on the Internet and your home network. There are two ways to use the domain name system in order to resolve a host or domain name to an IP Address and we're going to look at them here. There is also a detailed example later on this page to help you understand it better.

Queries and Resolution

As mentioned in the introduction section, there are two ways for a client to use the domain name system to obtain an answer.

One of these involves the client contacting the name servers (this is also called a non Recursive query) one at a time until it finds the authority server that contains the information it requires, while the other way is to ask the name server system to perform the complete translation (this is also called a Recursive query), in which case the client will send the query and get a response that contains the IP Address of the domain it's looking for.

It's really exciting to see how DNS queries work. While analysing with you the packets that are sent and received from the DNS server, I'm going to show you how the client chooses the method by which it wants its query to be resolved, so you will truly understand how these cool features work ! The DNS Query/Response Message Format pages contain all this packet analysis information, so let's continue and prepare for it !

Our Example DNS Resolution

We will now look at what happens when your workstation requests a domain to be resolved. The example that follows will show you the whole procedure step by step, so make sure you take your time to read it and understand it !

When someone wants to visit the Cisco website (www.cisco.com), they go to their web browser and type "http://www.cisco.com" or just "www.cisco.com" and, after a few seconds, the website is displayed. But what happens in the background after they type the address and hit enter is pretty much unknown to most users. That's what we are going to find out now !

The picture below shows us what would happen in the above example: (for simplicity we are not illustrating both Primary and Secondary DNS servers, only the Primary)

dns-resolution-1

Explanation:

1. You open your web browser and enter www.cisco.com in the address field. At that point, the computer doesn't know the IP address for www.cisco.com, so it sends a DNS query to your ISP's DNS server (It's querying the ISP's DNS because this has been set through the dial-up properties; if you're on a permanent connection then it's set through your network card's TCP/IP properties).

2. Your ISP's DNS server doesn't know the IP address for www.cisco.com, so it will ask one of the ROOT DNS servers.

3. The ROOT DNS server checks its database and finds that the Primary DNS for Cisco.com is 198.133.219.25. It replies to your ISP's server with this answer.

4. Your ISP's DNS server now knows the IP address of Cisco's DNS server, so it then sends a recursive query to Cisco.com's DNS server and asking to resolve the fully qualified domain name www.cisco.com.

5. Cisco's DNS server checks its database and finds an entry for www.cisco.com. This entry has an IP address of 198.133.219.25. Since the IP address of the DNS server and webserver (www) are identical, this means they are likely to be both on the same physical server. Load-balancing mechanisim can also have the same effect, making multiple services and physical machines have the same IP address.

6. Your ISP's DNS server now knows the IP address for www.cisco.com and sends the result to your computer.

7. Your computer now knows the IP address of Cisco's website and is able to directly contact it. Naturally, the next step is to send an http request directly to Cisco's webserver and download the webpage.

I hope you didn't find it too hard to follow. Remember that this query is the most common type. The other type of query (non recursive) follows the same procedure, the difference is that the client does all the running around trying to find the authoritative DNS server for the desired domain, I like to think of it as "self service" :)

Next - DNS Query Message Format

or                           

Back to the Network Protocols Section

The DNS Protocol

Posted in Domain Name System (DNS)

If you ever wondered where DNS came from, this is your chance to find out ! The quick summary on DNS's history will also help you understand why DNS servers are run mostly on Linux and Unix-type systems. We then get to see the layers of the OSI Model on which DNS works and, towards the end of the page, you will find out how the Domains (and DNS servers) are structured on the Internet to ensure uptime and effectiveness.

The History

DNS began in the early days when the Internet was only a small network created by the Department of Defence for research purposes. Host names (simple computer names) of computers were manually entered into a file (called HOSTS) which was located on a central server. Each site/computer that needed to resolve host names had to download this file. But as the number of hosts grew, so did the HOSTS file (Linux, Unix, Windows and NetWare still use such files) until it was far too large for computers to download and it was generating great amounts of traffic ! So they thought ... Stuff this .. let's find a better solution ... and in 1984 the Domain Name System was introduced.

The Protocol

The Domain Name System is a 'hierarchically distributed database', which is a fancy way of saying that its layers are arranged in a definite order and that its data is distributed across a wide range of machines (just like the roots of a tree branch out from the main root).

Most companies today have their own little DNS server to ensure the computers can find each other without problems. If you're using Windows 2000 and Active Directory, then you surely are using DNS for the name resolutions of your computers. Microsoft has created its own version of a "DNS" server, called a WINS server, which stands for Windows Internet Name Service, but this is old technology and uses protocols that are nowhere near as efficient as DNS, so it was natural for Microsoft to move away from WINS and towards DNS, after all, the whole Internet works on DNS :)

The DNS protocol works when your computer sends out a DNS query to a name server to resolve a domain. For example, you type "www.firewall.cx" in your web browser, this triggers a DNS request, which your computer sends to a DNS server in order to get the website's IP Address ! There is a detailed example on the pages to follow so I won't get into too much detail for the moment.

dns-protocol-1

 

The DNS protocol normally uses the UDP protocol as a means of transport because of its small overhead in comparison to TCP; the less overhead a protocol has, the faster it is !

In the case where there are constant errors and the computer trying to request a DNS resolution can't get an error free answer, or any answer at all, it will switch to TCP to ensure the data arrives without errors.

 

This process, though, depends on the operating system you're using. Some operating systems might not allow DNS to use the TCP protocol, thus limiting it to UDP only. It is rare that you will get so many errors that you can't resolve any hostname or domain name to an IP Address.

The DNS protocol utilises Port 53 for its service. This means that a DNS server listens on Port 53 and expects any client wishing to use the service to use the same port. There are, however, cases where you might need to use a different port, something possible depending on the operating system and DNS server you are running.

In the following pages we'll be looking at the actual DNS packet format, where you are able to see exactly the contents of DNS query, so we won't analyse the packet structure here.

Next we'll take a close look at how the Internet domains and DNS servers are structured to make sure the model works flawlessly and efficiently!

CCENT/CCNA

Cisco Routers

  • SSL WebVPN
  • Securing Routers
  • Policy Based Routing
  • Router on-a-Stick

VPN Security

  • Understand DMVPN
  • GRE/IPSec Configuration
  • Site-to-Site IPSec VPN
  • IPSec Modes

Cisco Help

  • VPN Client Windows 8
  • VPN Client Windows 7
  • CCP Display Problem
  • Cisco Support App.

Windows 2012

  • New Features
  • Licensing
  • Hyper-V / VDI
  • Install Hyper-V

Linux

  • File Permissions
  • Webmin
  • Groups - Users
  • Samba Setup