{"id":32990,"date":"2017-12-07T15:26:24","date_gmt":"2017-12-07T13:26:24","guid":{"rendered":"https:\/\/blog.superhosting.bg?p=32990"},"modified":"2022-04-02T11:18:34","modified_gmt":"2022-04-02T08:18:34","slug":"dns-how-it-works-part2","status":"publish","type":"post","link":"https:\/\/blog.superhosting.bg\/en\/dns-how-it-works-part2.html","title":{"rendered":"Levels of a Domain Name in the DNS Index (What is a DNS?)"},"content":{"rendered":"

In a previous article of the series \u201eWhat is a DNS?<\/a>\u201c we defined what a DNS is and why it is used for resolving domain names into IP addresses<\/a>. We learned that the web browser cannot perform a DNS lookup in the DNS Index on its own. Instead, the DNS resolver performs the lookup as it can find the important DNS record \u201cdomain.name=IP address\u201d in the Index. But to reach it the DNS resolver first has to look up all authoritative name servers, responsible for all levels in the domain name.<\/p>\n

For example, the domain superhosting.bg<\/strong> is actually comprised of two levels \u2013 superhosting<\/strong> and bg<\/strong>. The superhosting domain is actually a subdomain of the .bg domain.<\/p>\n

When a domain is fully specified with all its levels, such as blog.superhosting.bg<\/strong> (or blog.superhosting.bg.) it is called fully qualified domain name<\/strong> (FQDN<\/a>). Relative domain name<\/strong> means every other domain which does not include all levels, e.g. blog<\/strong> or blog.superhosting<\/strong>.<\/p>\n

Although the fully qualified domain name is specified as one whole name, e.g. \u201esuperhosting.bg<\/strong>\u201c, the DNS data for each level is located on different authoritative name servers on the web. From a technical point of view, the domain level is actually a DNS zone (the list of DNS records) when it comes to configuration. From the point of view of a regular user the domain level is called simply a domain<\/strong> (or an extension). You will see an example below.<\/p>\n

The domain levels are defined backwards and the (.) symbol plays a role of delimiter for the different levels.<\/strong><\/p>\n

For example, the domain superhosting.bg<\/strong>. consists of few levels (domains), so if we look at it backwards:<\/p>\n

root) .<\/strong>[white space character] \u2013 root level;<\/div>\n
1) bg<\/strong>.[] \u2013 top-level domain (subdomain of []);<\/div>\n
2) superhosting<\/strong>.bg. \u2013 second-level domain (subdomain of bg);<\/div>\n

Each level knows which the authoritative name servers for the next level are. We remind you that DNS records (the DNS zone) for the respective level are located on the authoritative name servers. The root level knows which the name servers for the bg level are and it, on its turn, knows which the name servers of the superhosting level are.<\/p>\n

The DNS resolver does not know (when they are missing in the DNS cache) which are the responsible name servers for superhosting.bg and in order to find them it will need to start looking from the root level of the DNS Index.<\/p>\n

However, the DNS resolver knows in advance the IPs of the root DNS servers and will select one of them to send its first query.<\/strong><\/p>\n

\"DNS<\/p>\n

 <\/p>\n

( root ) DNS Root<\/strong> (the DNS root level).<\/p>\n

If we imagine all domain names as a tree structure, the root level is the \u201croot\u201d itself where everything starts from.<\/p>\n

Normally every level has a domain name, only the root level of the DNS Index has a white space character \u201c \u201e. When printing, e.g. displaying the full domain name<\/strong> on screen, this character is not displayed \u201esuperhosting.bg. <\/strong>\u201c. For that reason the white space character is left out when typed and the final dot<\/strong> is accepted to be the end of the domain name.<\/p>\n

This final dot which separates the space root character from the next top domain level (TLD) is also left out when the domain name is typed by users in the browser or other applications such as email and ftp clients, etc.<\/p>\n

However, computer systems working with the domain itself might need the final dot character.<\/p>\n

\"DNS<\/p>\n

For example if DNS records are edited in the zone’s text file and the fully qualified domain<\/strong> name does not end with a dot \u201eivan.com<\/strong>\u201c the system will treat it as a relative name<\/strong> and will add the domain of the zone at its end \u201eivan.com.ivan.com<\/strong>\u201c. That\u2019s why subdomains can be typed only with a relative name such as www, which will turn into www.ivan.com. when the editor zone is edited through WHM.<\/p>\n

Normally, each registered domain can be loaded in the browser followed by the dot and white space character, e.g. superhosting.bg.[space]<\/strong> or \u201esuperhosting.bg.<\/strong>\u201c.<\/p>\n

The Root DNS zone<\/a> in the root level contains records of all authoritative name servers (as NS records), which are responsible for domains from the next top-level (TLD) .com, .net, .org, .info, .bg, .uk and others. As for November 2017 the root DNS zone contains 1541 top-level domains<\/a>.<\/p>\n

Top-level domains are unique and never repeated as the existence of two identical names such as .bg and .bg is not allowed. Specific organizations are responsible for every top domain, and entering them into the root zone<\/a> is administered by IANA<\/a> (Internet Assigned Numbers Authority). IANA<\/a> is a unit of ICANN<\/a>.<\/p>\n

Here are few sample DNS records for the .bg top domain<\/a> in the DNS root zone<\/strong>:<\/p>\n

bg. 172800 IN NS<\/strong> ns.register.bg.
\nbg. 172800 IN NS<\/strong> ns2.register.bg.
\nbg. 172800 IN NS<\/strong> ns3.register.bg.<\/div>\n

DNS record of the NS<\/strong> type is used to point to a name server, responsible for the domain\u2019s DNS zone. You can find out which one of the numerous pointed servers is the master authoritative name server<\/strong>, by sending a query for the SOA<\/strong> (Start of Authority) record.<\/p>\n

The root zone is located on root DNS servers<\/a> with the following 13 domain names: a.root-servers.net, b.root-servers.net, c.root-servers.net, d.root-servers.net, e.root-servers.net, f.root-servers.net, g.root-servers.net, h.root-servers.net, i.root-servers.net, j.root-servers.net, k.root-servers.net, l.root-servers.net, m.root-servers.net.<\/span><\/p>\n

There are hundreds of root DNS servers<\/a> behind the IPs of those 13 domains. Here comes the Anycast<\/a> to use so that the load can be regionally distributed. Anycast is a networking technique where the same IP prefix is advertised from multiple locations. There can be numerous physical servers or clusters from multiple locations around the world behind each IP (DNS root server). A full map of all physical servers around the world is available at root-servers.org<\/a>.<\/p>\n

The DNS resolver knows beforehand<\/a> which the IPs of the 13 DNS root servers are, so it does not perform a DNS lookup of their domains (a-m.root-servers.net). When a DNS lookup is initiated, the resolver will choose one of the servers and send a query.<\/strong><\/p>\n

( 1 )<\/strong> “.bg<\/strong>” Top-level domain (TLD). These are all domain names, placed before the root domain, in this case before the root dot.<\/p>\n

There is a certain Register, responsible for each top-level domain. The Register performs registration of subdomains<\/strong> to the top-level domain and is responsible for the support of the authoritative name servers to the top-level domain.<\/p>\n

Register.bg is responsible<\/a> for the \u201e.bg<\/strong>\u201c top-level domain. Register.bg offers registration of subdomains to the .bg<\/a> TLD, for example superhosting<\/strong>.bg, mysupersite<\/strong>.bg and others. When a domain is registered, for example superhosting.bg<\/strong>, the registrar enters to the .bg<\/strong> level the name servers, responsible for the superhosting.bg<\/strong> subdomain (this is also known as delegating a DNS zone).<\/p>\n

Here are a few sample DNS records for the second-level domain superhosting.bg in the DNS .bg zone<\/strong>:<\/p>\n

superhosting.bg. 345600 IN NS<\/strong> sns1.superhosting.bg.
\nsuperhosting.bg. 345600 IN NS<\/strong> sns2.superhosting.bg.<\/div>\n

The DNS zone for the .bg level is located on the authoritative name servers of Register.bg: ns.register.bg, ns2.register.bg, ns2.register.bg, etc.<\/p>\n

( 2 )<\/strong> “.superhosting.bg<\/strong>” second-level domain (2LD<\/a>), subdomain of the .bg TLD.<\/p>\n

Second-level domains must be registered through a registrar responsible for subdomain registration to the respective top-level domain.<\/p>\n

The DNS zone for the superhosting.bg domain is located on the authoritative name servers, specified in the .bg zone (sns1.superhosting.bg, sns2.superhosting.bg).<\/p>\n

The DNS record containing the IP address is located in the DNS zone (of superhosting.bg). The record looks like that:<\/strong><\/p>\n

superhosting.bg<\/strong>. 3600 IN A 91.196.125.21<\/strong><\/div>\n

The \u201cA\u201d DNS record is primary in the DNS Index. By using an \u201cA\u201d record you can point a domain to an IP.<\/p>\n

The DNS resolver performing a lookup for the superhosting.bg domain\u2019s IP will find it in this DNS zone. Afterwards, it will send back the IP to the DNS client. The web browser will connect to the server responsible for this IP.<\/p>\n

The DNS lookup usually takes up to few milliseconds. To compare, until you manage to pronounce \u201cWhat is this domain\u2019s IP?\u201d two seconds will already have passed.<\/p>\n

( 3 )<\/strong> “.blog.superhosting.bg<\/strong>” Third-level domain, superhosting.bg\u2019s subdomain.<\/p>\n

Normally third-level domains are not registered by an authorized registrar, but there are some exceptions, such as: mysite.a.bg<\/strong>, somesite.co.uk<\/strong>.<\/p>\n

The superhosting.bg\u2019s DNS zone contains records for all its subdomains as this is not the case only if superhosting.bg decides do delegate the DNS zone for a certain subdomain with NS records to another name server. Then the top (.bg) and second-level domains (superhosting.bg) \u2013 root<\/strong> delegates management of the subdomain zone .bg<\/strong> to the ns1.register.bg, ns2.register.bg name servers and .bg delegates the subdomain zone superhosting.bg<\/strong> to the name servers sns1.superhosting.bg, sns2
\nSimilarly superhosting.bg can delegate the subdomain zone blog.superhosting.bg<\/strong> to other name servers.<\/p>\n

The DNS \u0410 record of the blog.superhosting.bg subdomain looks like that:<\/p>\n

blog<\/strong> 60 IN A 185.123.188.58<\/strong><\/div>\n

<\/a><\/p>\n

In the next article<\/a> from the \u201eWhat is a DNS?\u201c series we will see the path of the DNS lookup which is performed by the DNS resolver as it uses it to reach the authoritative name server and the \u0410 record kept on it.<\/div>\n
Curious:<\/strong><\/em>
\nWhen you purchase a domain by SuperHosting.BG during its registration two authoritative name servers of the type nsxy.superhosting.bg and nsxz.superhosting.bg. are submitted. SuperHosting.BG submits a registration request for the domain name such as mysupersite.bg to the respective Registrar\/Register as it also submits the two name servers. The Registrar holds responsibility to register the domain together with the two name servers in the respective authoritative name servers for the .bg level.<\/div>\n
If you wish to submit specific name servers during your next domain\u2019s registration as they will differ from the default servers SuperHosting.BG will submit, please enter them into your customer profile\u2019s option Predefined DNS.<\/div>\n","protected":false},"excerpt":{"rendered":"

Domains are a combination of words separated by dots. Each word separated by a dot is a level (domain, label) in the DNS hierarchy.<\/p>\n","protected":false},"author":16,"featured_media":62863,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"_lmt_disableupdate":"","_lmt_disable":"","footnotes":""},"categories":[118,110],"tags":[204],"class_list":{"0":"post-32990","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-superhosting-tips-of-support-en","8":"category-superhosting-technology-en","9":"tag-dns-en"},"aioseo_notices":[],"modified_by":"\u041c\u0430\u0434\u043b\u0435\u043d\u0430 \u041c\u0435\u0442\u043e\u0434\u0438\u0435\u0432\u0430","post_mailing_queue_ids":[],"_links":{"self":[{"href":"https:\/\/blog.superhosting.bg\/en\/wp-json\/wp\/v2\/posts\/32990","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.superhosting.bg\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.superhosting.bg\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.superhosting.bg\/en\/wp-json\/wp\/v2\/users\/16"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.superhosting.bg\/en\/wp-json\/wp\/v2\/comments?post=32990"}],"version-history":[{"count":2,"href":"https:\/\/blog.superhosting.bg\/en\/wp-json\/wp\/v2\/posts\/32990\/revisions"}],"predecessor-version":[{"id":65493,"href":"https:\/\/blog.superhosting.bg\/en\/wp-json\/wp\/v2\/posts\/32990\/revisions\/65493"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.superhosting.bg\/en\/wp-json\/wp\/v2\/media\/62863"}],"wp:attachment":[{"href":"https:\/\/blog.superhosting.bg\/en\/wp-json\/wp\/v2\/media?parent=32990"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.superhosting.bg\/en\/wp-json\/wp\/v2\/categories?post=32990"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.superhosting.bg\/en\/wp-json\/wp\/v2\/tags?post=32990"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}