What are Top level domain server in DNS.Wants to understand its significance in real time network traffic

Question

Our company is looking forward to deploy and maintain own Public DNS . I am outline the deployment activity ,But little confused where to register my Company domain name and how to map my public DNS . Please any one explain traffic flow .

Answer 1

I used to work for a domain registry and was part of IETF DNS workgroups, so I'll give you a primer.

The Domain Name System is designed in a hierarchy. When you look up the data for a domain name, you generally go to the very top and work your way down.

• At the very top is the root. The root name servers are a number of servers spread around the world that any question always will start at - unless data is cached, we'll get to that later. As a normal user, you won't see them in a domain name, but they are there.

• Next are the Top Level Domains. They are divided into generic top level domains (such as .com, .net or .movie) and country code top level domains (such as .us for the US, .no for Norway or .cn for China).

• After that are the Second Level Domains. These are the ones you typically purchase as an end customer. For example, if you want to own example.com you go to a registrar, check if example.com is available and if so add it to the cart and hit checkout. You will then either have the registrar or another hosting company run your DNS for you, or you'll set up your own DNS servers and have the registrar delegate the domain to you. Delegation means that they'll register data that will say that your DNS servers are responsible for this domain.

• Once you own your domain, you can also set up Third Level Domains, or subdomains. This adds another hierarchy to the DNS servers. You can also set up hostnames, which for the average user will look like exactly the same thing.

So, let's take a look at an average DNS lookup.

Let's say you want to go to www.example.com. The first thing your DNS server will do is to go to the root servers to look up who's responsible for .com. Your DNS server already have the addresses for the root-servers built in, so there's typically no need to look them up. Instead, we look for the info for .com.

I'll use the program "dig" here, but I'll appreviate the output for readability.

First, we ask for the Name Servers (ns) for com. We ask this directly from the server a.root-servers.net which is one of the root servers for the DNS system.

$ dig ns com. @a.root-servers.net.

The output is as follows (again, abbreviated)

;; QUESTION SECTION:
;com.                           IN      NS

;; AUTHORITY SECTION:
com.                    172800  IN      NS      a.gtld-servers.net.

;; ADDITIONAL SECTION:
a.gtld-servers.net.     172800  IN      A       192.5.6.30
a.gtld-servers.net.     172800  IN      AAAA    2001:503:a83e::2:30

The QUESTION SECTION shows us what we're asking for, in this case the NS records for com.

The AUTHORITY SECTION shows us that the root-server is not responsible for .com, but it tells us who is. In this case it tells us that a.gtld-servers.net is responsible.

It also gives us an ADDITIONAL SECTION that contains address records (A for IPv4 and AAAA for IPv6) for a.gtld-servers.net. This address is called glue, and is not considered an authorative answer, but it's a hint telling us that this is the address that's been listed in the system. Glue records are needed when you need an IP address of a server that you can otherwise only reach by doing a DNS lookup, which you need the IP address of the nameserver for. It's all a bit recursive.

Anyway, let's keep going and lookup the nameservers for example.com. Now, this will differ a bit from what the real world DNS will tell you, but this is an example, so we'll use example data.

$ dig ns example.com. @192.5.6.30

We're asking the IP address of the a.gtld-servers.net that we got above. They are authorative for the .com domain and therefore should be able to tell us what nameservers example.com have.

;; QUESTION SECTION:
;example.com.                    IN      NS

;; AUTHORITY SECTION:
example.com.             172800  IN      NS      ns2.example.com.
example.com.             172800  IN      NS      ns1.example.com.

;; ADDITIONAL SECTION:
ns2.example.com.         172800  IN      A       192.0.2.4
ns1.example.com.         172800  IN      A       192.0.2.5

Now, here's why that glue is important. Since the nameservers of example.com are residing under example.com, they are managed by the nameservers under example.com. Essentially, you are told to call Bob for the number to Bob, because only Bob knows what Bob's phonenumber is. The glue is a hint. Bob might've changed number, but this is what the nameservers for .com knows.

Now that we know the address of the example.com nameservers, we can finally ask for the hostname.

$ dig a www.example.com. @192.0.2.4

;; QUESTION SECTION:
;www.example.com.                    IN      A

;; ANSWER SECTION:
www.example.com.             300     IN      A       192.0.2.10

We finally have the address record for the www.example.com hostname. Notice how there's no ADDITIONAL SECTION here, because there's no such section needed for this query. We're asking a straightforward question and getting a precise answer back from a server that is authorative for the domain.

Now, doing all of this lookup all the time is a bit of waste of time and resources, so what's typically done is that your local DNS server is acting as a cache. Did you notice the way all the DNS records look? The fields in a DNS record is as follows: Domain, Time To Live (TTL), Class (in our case IN for Internet), Type (A for address, NS for nameserver etc) and Data (for example an IP address for an A record).

The TTL in the DNS record is how long a cache is allowed to store the data for. Records that are expected to not change, or change only very rarely have long TTLs. For example the 172800 second TTL in the first few records we looked at. Records that may be updated on short notice have low TTLs, such as the 300 second TTL for www.example.com.

Whenever we do a DNS lookup, we don't need to go all the way to the root servers if the data we already are looking for is cached. We typically access .com domains all the time so that data is almost always cached in our local DNS server. This does, however, mean that whenever you change DNS data, it may take time for the changes to propagate. In practical terms, this means that you'll need to either change the TTLs in advance, or tell your boss that it will take time for any changes to fully take effect.

To register your domain, you'll typically want to go to a registrar for the Top Level Domain you want to register under. Most hosting companies and Domain registrars will be able to register domains under a number of different Top Level Domains, so you can pretty much choose any one of them.

The Registrars are resellers for the Registry. The Registry is the company or organization that actually runs the Top Level Domain in question, but as an end user, all you have to deal with is the Registrar, or even just your hosting company.

Most registrars have webinterfaces that handle a lot of the technical details of delegation and DNS records, but even so understanding the fundamentals of DNS will make your life so much easier even if you rely on the webinterface of your registrar.

If you want to learn more about DNS, and if you're working in IT, you really should know how DNS works because it's the source of so many potential issues, I'd recommend the book DNS and Bind from O'Reilly. It's very comprehensive and will make you an expert on DNS. If you want to run your own DNS servers I highly recommend that you read this book. It does cover the Bind DNS server software, but the same principles apply to any DNS server software out there.