• 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

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)



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 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 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


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.



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!

ICMP - Time Exceeded Message Analysis

Posted in ICMP Protocol

The ICMP - Time exceeded message is one which is usually created by gateways or routers. In order to fully understand this ICMP message, you must be familiar with the IP header within a packet. Our readers can also visit the IP Protocol section which covers the IP protocol structure in great depth.

When looking at an IP header, you will see the TTL and Fragment Flag fields which play a big part in how this ICMP message works. Please make sure you check them out before attempting to continue!

The ICMP - Time exceeded message is generated when the gateway processing the datagram (or packet, depending on how you look at it) finds the Time To Live field (this field is in the IP header of all packets) is equal to zero and therefore must be discarded. The same gateway may also notify the source host via the time exceeded message.

The term 'fragment' means to 'cut to pieces'. When the data is too large to fit into one packet, it is cut into smaller pieces and sent to the destination. On the other end, the destination host will receive the fragmented pieces and put them back together to create the original large data packet which was fragmented at the source.


Analysis of the ICMP Time Exceeded Message

Let's have a look at the structure of an ICMP - Time exceeded message:


ICMP - Redirect Message Analysis

Posted in ICMP Protocol

The ICMP - Redirect message is always sent from a gateway to the host and the example below will illustrate when this is used.

Putting it simply (before we have a look at the example) the ICMP - Redirect message occurs when a host sends a datagram (or packet) to its gateway (destination of this datagram is a different network), which in turn forwards the same datagram to the next gateway (next hop) and this second gateway is on the same network as the host. The second gateway will generate this ICMP message and send it to the host from which the datagram originated.

There are 4 different ICMP - Redirect message types and these are:


ICMP - Source Quench Message Analysis

Posted in ICMP Protocol

The ICMP - Source quench message is one that can be generated by either a gateway or host. You won't see any such message pop up on your workstation screen unless you're working on a gateway which will output to the screen all ICMP messages it gets. In short, an ICMP - Source quench is generated by a gateway or the destination host and tells the sending end to ease up because it cannot keep up with the speed at which it's receiving the data.

Analysis of the ICMP Source Quench Message

Now let's get a bit more technical: A gateway may discard internet datagrams (or packets) if it does not have the buffer space needed to queue the datagrams for output to the next network on the route to the destination network. If a gateway discards a datagram, it may send an ICMP - Source quench message to the internet source host of the datagram.

Let's have a look at the packet structure of the ICMP - Source quench message:



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


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