Over the past two articles on DNS we have seen just how big the Domain Name Service protocol actually is. It performs more then simple domain name resolution as we have seen, and also is a key player in the delivery of email via the MX resource record. In this last part on DNS we will actually break out various fields in the DNS header.
DNS and it’s bits and bytes
Over the course of the past two articles we have covered DNS at a fairly high level. We did not delve into any system administration content really, but concentrated more on getting a solid feel for what the protocol does, and how it does it. Lastly we also took a look at how a DNS packet looks like on the wire as it were. In this last part of the DNS article series we will take one DNS packet and go through the DNS header. This will allow you to hopefully better understand the protocol itself, and how it works. You may feel that going through the DNS packet, hex value by hex value, as unimportant.
My feelings on the matter are that being able to completely parse the packet will give you a sense of confidence when dealing with DNS. This in turn will allow you to approach any network related issue involving DNS with self-assurance. That kind of self-assurance will only come from having an understanding of not only how the protocol itself works, but also what it looks like in a packet format.
We are now familiar with the domain name service at a high level. What we now need to do is become familiar with some specifics. To that end we will take a look at about a half dozen or so resource records, and explain what they mean. This will be done with example packets so that we can visualize them, vice simply read about them. The resource records we will cover below are in no specific order. On that note let’s get on with it!
Seen in the packets below are various non-routable IP’s, namely 192.168.1.200 and 192.168.1.100, which I put in place to substitute the real IP addresses that were in the packets. Lastly, I have included a selection of both RCODE’s and Resource Records for us to take a look at. With that said let’s take a look at our first packet, which contains an RCODE.
We know already that the bulk of the TCP/IP protocol suite resides at the application layer. What about some of the other protocols though? Are there any that interact with hardware? In this article we will discuss the Spanning Tree Protocol and what it does for you.
Spanning Tree Protocol
We are familiar with most protocols and how they are used. Further to that we also know that the bulk of protocols in the TCP/IP suite reside at the application layer. There are also other key protocols such as IP which is used for routing purposed as it contains the IP addresses field. You can map this IP protocol to the networking layer, and that in turn is associated with routers. Are there any other protocols associated with hardware devices? Indeed there is and an example would be the Spanning Tree Protocol. This protocol is a layer two (layer two = data link layer) protocol that is associated with switches and bridges. Predominantly switches really as bridges have fallen by the wayside in terms of usage.
Most protocols and standards associated with the Internet have been standardized by the IEEE. This governing body has given the Spanning Tree Protocol the designation 802.1d or aka IEEE 802.1d. This type of jargon is important to remember in case you are trying to state a question clearly in order to get a response. Being able to talk in the industry lingo is quite important. What makes sense to you may not make sense to someone else, hence the need for industry terms. With that said let's get on with the STP itself.
Can you imagine a world where you would have to memorize each and every IP address for the sites that you liked? The Internet certainly would not be as popular as it is today were this the case. Not to mention our beloved email, and the crucial role that DNS plays with its delivery. Read on, to learn more about one of the most unheralded protocols in existence today.
Domain Name Service aka DNS
The Domain Name Service is what I would call a “dense” protocol. I would call it dense because there is so much to DNS that it has resulted in many books being written solely on DNS, what it is, and what it does. Unlike some other application layer protocols, which perform only one function, DNS does the normal resolution of domain name to IP address and other things like help route your email. By route I don’t mean that DNS has suddenly turned into a routing protocol, but rather that, through the propagation of something called MX records, your email can be sent to the right mail server.
In this series of articles on DNS we will cover the structure of the domain name service as a whole. We will then go on to cover a bit more about how DNS actually works via its hierarchical design. Furthermore we will cover quite a few examples of what are called resource records and RCODES, also what they mean and how we can break them out. This will be done at the packet level to help give us context in case you have to investigate your network at the packet level at some future date. Just remember that, as I mentioned before, this series of articles will really only just scratch the surface of DNS. What I won’t be covering is the actual setup of DNS on a network, and the troubleshooting of it. With that said let’s begin our exploration of this often unappreciated protocol.
This article will describe how to setup and configure NAT in Windows 2003. NAT, or Network Address Translation, is a widely used IP translation and mapping protocol that works on the network layer (level 3) of the OSI model. It is sometimes referred to as a routing protocol because of the way it allows packets from a private network to be routed to the Internet.
Knowledge Center 
