DNS 101. What it is and how it works

The so-called “Internet” is a vast network of different ISP connected with each other. What makes it easily accessible to the billions of us is the addressable translation of IP address into domain name.

DNS is a critical service to serve the Internet. Let's dig into exactly how it works, what's the governance around it and what risks you can be exposed to and mitigate them.

How domain names work?

It all starts with the Top-level domain names (TLDs), such as “.com”, “.org”, “.eu”, “.io”, “.shop”…
But who gets to decide the management of those top-level domains?

That’s the job of the ICANN Organization, The Internet Corporation for Assigned Names and Numbers that has two critical roles:

• Accredited “Registrar” to register domain names for multiple TLDs deepening their level of authorization and compliance.
• Allocates IP addresses to five Regional Internet Registries(RIRs) and is in line with IETF decisions. The RIRs then allocate addresses to Internet Service Providers, who sub-allocate to networks and individual users. (source https://icann.org)

You can list and search accredited registrars here on the ICANN website at https://www.icann.org/en/accredited-registrars?filter-letter=a&sort-direction=asc&sort-param=name&page=1

Depending on your business and level of security, you should be careful about which company you decided to trust as they would be responsible to declare the name server that manages the resolution of your domain.

Domain Registration

Let’s now take the example of this blog, the domain name is plab.io and is registered on Gandi. plab is the name reserved on the TLD .io

The first role of a registrar is to publish to the TLD manager that you are the owner of the domain and the registrar that manages it. There is one crucial piece of information that’s come with this publication, the list of Name Server that will manage the resolution of the domain. That’s where a lot of people got confused with DNS, the default setup of your domain is usually bound to the Name Server of the registrar, but managing the resolution of your domain or subdomain is up to the specific DNS server published with the registration of the domain.

You have two ways to find the published Name Server of a domain. The first one is by resolving the NS record of the TLD zone, but we will see that in the next chapter. The second way, is by using WHOIS. No, it’s not an acronym, it is a system that asks the question, who is responsible for a domain name or an IP address?

ICANN has provide an online website to look up as easy as possible at https://lookup.icann.org/en/lookup There is also a command-line “whois” shipped by default on mainstream Linux distribution and MacOS, the advantage of this command is that it look over multiple Network Information Center (NIC) approved by ICANN**.**

❯ whois plab.io
Domain Name: plab.io
Registry Domain ID: ce6962ed82f747c380ad84561f81f5cc-DONUTS
Registrar WHOIS Server: whois.gandi.net
Registrar URL: https://www.gandi.net
Updated Date: 2022-07-01T05:55:39Z
Creation Date: 2014-04-11T23:38:17Z
Registry Expiry Date: 2023-04-11T23:38:17Z
Registrar: Gandi SAS
Registrar IANA ID: 81
Registrar Abuse Contact Email: abuse@support.gandi.net
Registrar Abuse Contact Phone: +33.170377661
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Registry Registrant ID: REDACTED FOR PRIVACY
Registrant Name: REDACTED FOR PRIVACY
Registrant Organization:
Registrant Street: REDACTED FOR PRIVACY
Registrant City: REDACTED FOR PRIVACY
Registrant State/Province:
Registrant Postal Code: REDACTED FOR PRIVACY
Registrant Country: FR
Registrant Phone: REDACTED FOR PRIVACY
Registrant Phone Ext: REDACTED FOR PRIVACY
Registrant Fax: REDACTED FOR PRIVACY
Registrant Fax Ext: REDACTED FOR PRIVACY
Registrant Email: Please query the RDDS service of the Registrar of Record identified in this output for information on how to contact the Registrant, Admin, or Tech contact of the queried domain name.
Registry Admin ID: REDACTED FOR PRIVACY
Admin Name: REDACTED FOR PRIVACY
Admin Organization: REDACTED FOR PRIVACY
Admin Street: REDACTED FOR PRIVACY
Admin City: REDACTED FOR PRIVACY
Admin State/Province: REDACTED FOR PRIVACY
Admin Postal Code: REDACTED FOR PRIVACY
Admin Country: REDACTED FOR PRIVACY
Admin Phone: REDACTED FOR PRIVACY
Admin Phone Ext: REDACTED FOR PRIVACY
Admin Fax: REDACTED FOR PRIVACY
Admin Fax Ext: REDACTED FOR PRIVACY
Admin Email: Please query the RDDS service of the Registrar of Record identified in this output for information on how to contact the Registrant, Admin, or Tech contact of the queried domain name.
Registry Tech ID: REDACTED FOR PRIVACY
Tech Name: REDACTED FOR PRIVACY
Tech Organization: REDACTED FOR PRIVACY
Tech Street: REDACTED FOR PRIVACY
Tech City: REDACTED FOR PRIVACY
Tech State/Province: REDACTED FOR PRIVACY
Tech Postal Code: REDACTED FOR PRIVACY
Tech Country: REDACTED FOR PRIVACY
Tech Phone: REDACTED FOR PRIVACY
Tech Phone Ext: REDACTED FOR PRIVACY
Tech Fax: REDACTED FOR PRIVACY
Tech Fax Ext: REDACTED FOR PRIVACY
Tech Email: Please query the RDDS service of the Registrar of Record identified in this output for information on how to contact the Registrant, Admin, or Tech contact of the queried domain name.
Name Server: ns-360.awsdns-45.com
Name Server: ns-1447.awsdns-52.org
Name Server: ns-947.awsdns-54.net
Name Server: ns-1691.awsdns-19.co.uk
DNSSEC: signedDelegation
URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of WHOIS database: 2022-07-03T17:07:35Z <<<

For more information on Whois status codes, please visit https://icann.org/epp

Terms of Use: Donuts Inc. provides this Whois service for information purposes, and to assist persons in obtaining information about or related to a domain name registration record. Donuts does not guarantee its accuracy. Users accessing the Donuts Whois service agree to use the data only for lawful purposes, and under no circumstances may this data be used to: a) allow, enable, or otherwise support the transmission by e-mail, telephone, or facsimile of mass unsolicited, commercial advertising or solicitations to entities other than the registrar's own existing customers and b) enable high volume, automated, electronic processes that send queries or data to the systems of Donuts or any ICANN-accredited registrar, except as reasonably necessary to register domain names or modify existing registrations. When using the Donuts Whois service, please consider the following: The Whois service is not a replacement for standard EPP commands to the SRS service. Whois is not considered authoritative for registered domain objects. The Whois service may be scheduled for downtime during production or OT&E maintenance periods. Queries to the Whois services are throttled. If too many queries are received from a single IP address within a specified time, the service will begin to reject further queries for a period of time to prevent disruption of Whois service access. Abuse of the Whois system through data mining is mitigated by detecting and limiting bulk query access from single sources. Where applicable, the presence of a [Non-Public Data] tag indicates that such data is not made publicly available due to applicable data privacy laws or requirements. Should you wish to contact the registrant, please refer to the Whois records available through the registrar URL listed above. Access to non-public data may be provided, upon request, where it can be reasonably confirmed that the requester holds a specific legitimate interest and a proper legal basis for accessing the withheld data
. Access to this data can be requested by submitting a request via the form found at https://donuts.domains/about/policies/whois-layered-access/ Donuts Inc. reserves the right to modify these terms at any time. By submitting this query, you agree to abide by this policy.

Hierarchy of domains resolutions

Previously, we saw how the registration of a domain name for a specific TLD works. But we still have to know who is managing the TLD and how it can be resolved from any computer in the world?

There is one organization that sits on the top of the NIC hierarchy, that’s the Internet Assigned Numbers Authority (IANA) which manages the top of the DNS tree by administrating the zone configuration of the root nameservers.

IANA is initially managed by ICANN but since August 2016, ICANN incorporated Public Technical Identifiers, a non-profit affiliate corporation to take the management of IANA.

You can also view the list of TLDs and which company is managing the NIC of the domain extension at https://www.iana.org/domains/root/db The TLD manager is granting authorization to the registrar in order to publish the domain registration that we saw earlier.

Root nameservers

IANA is administering the 13 Root Name Servers in the world that hold the configuration for resolving all records operated by TLD managers.

It’s not really 13 actual servers, it’s a logical representation in the form of “letter.root-servers.net”, where letter ranges from a to m. 10 of them are managed by US corporation and university.

• The M is managed by the Japan WIDE Project organization
• The K is managed by RIPE NCC, a regional internet registry representing European and the Middle East interest.
• The I is managed by Sweedish private company Netnod AB based in Stockholm

All the root servers are working in Anycast addressing, meaning there is one IP Address per logical name server that can be geographically distributed to many servers. It’s up to the ISP that manages the network to redirect you to one of the actual servers behind the IP address.

According to wikipedia, most of them are running using BIND software, and the root server configuration with ~1500 TLDs is available at https://www.internic.net/domain/root.zone

Tracing Resolution

Does my computer look over the root name servers every time I access a website?

No, and that’s the beauty and the beast of resolving domain, there’s cache everywhere! it’s probably the most replicated cache in the world.

That’s why I introduce you “dig”, the most useful command line to debug domain resolution. it’s a tiny program to resolve domains, subdomains, and specific records on a specific name server.

❯ dig A plab.io

; <<>> DiG 9.10.6 <<>> A plab.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34192
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;plab.io.			IN	A

;; ANSWER SECTION:
plab.io.		60	IN	A	99.86.91.103
plab.io.		60	IN	A	99.86.91.116
plab.io.		60	IN	A	99.86.91.90
plab.io.		60	IN	A	99.86.91.99

;; Query time: 235 msec
;; SERVER: 10.1.0.1#53(10.1.0.1)
;; WHEN: Thu Jun 30 14:51:24 +07 2022
;; MSG SIZE  rcvd: 100

We can notice the Answer section with the TTL of 60 and 4 IP addresses associated.

But they're also critical information, the SERVER that provides that resolution. It’s 10.1.0.1 and as you can imagine it’s neither a root domain server nor a registrar server.

Every local network relay on a local DNS server, most of the time it’s the router that’s assigned DHCP IP address that would push the resolver IP address.

Under UNIX system, resolver hosts are automatically injected into the configuration file /etc/resolv.conf. Every application of the operating system will then rely on that resolver to resolve the IP of a domain name.

The job of this resolver is to return the resolution if it’s a known domain, otherwise, the request is just passed to the upper level of the stack. We are calling them recursive resolvers.

When the first resolver knows the answer it would stop the recursivity and return the result. The query would be cached according to the Time To Value (TTL here at 60sec) before carrying out again the query to the upper levels.

We can also execute this tracing by using dig command, let’s try by asking to the Cloudflare recursive resolver on the Name Server IP 1.1.1.1

❯ dig +trace plab.io @1.1.1.1

; <<>> DiG 9.10.6 <<>> +trace plab.io @1.1.1.1
;; global options: +cmd
.			517325	IN	NS	a.root-servers.net.
.			517325	IN	NS	b.root-servers.net.
.			517325	IN	NS	c.root-servers.net.
.			517325	IN	NS	d.root-servers.net.
.			517325	IN	NS	e.root-servers.net.
.			517325	IN	NS	f.root-servers.net.
.			517325	IN	NS	g.root-servers.net.
.			517325	IN	NS	h.root-servers.net.
.			517325	IN	NS	i.root-servers.net.
.			517325	IN	NS	j.root-servers.net.
.			517325	IN	NS	k.root-servers.net.
.			517325	IN	NS	l.root-servers.net.
.			517325	IN	NS	m.root-servers.net.
.			517325	IN	RRSIG	NS 8 0 518400 20220713050000 20220630040000 47671 . b7KhnvuyZhf3EmHvlwMhgz6YBvMr2EajqnpovDYSSWlDl1HXIpMflHl+ 3+AOx1tsb9TeJujmV3lzFV861kg3Kd7sKTd/NLm0czcz8sLGbg96Dmbg ITDZ3/txziKKGNU6gjHZVyJkK6pEwcFsEhZufKup7FmHfZVPZ9H2QmE0 Vlmcu9Y3B19h2+KAVuwVsS58qReShRTHR+wuck+XEbYyMt2LM/A2gkkp TDr5qbcfHdfoaRiG1WFB52/w97Bm10oBAqW4s05DOwDuta5nDAhuisxR UIXOy2WbGI0BYxSpsZiQJztjamZoGN1thDFkAX8RessNU1Dtp6cQIaY3 U6PkYg==
;; Received 1097 bytes from 1.1.1.1#53(1.1.1.1) in 238 ms

io.			172800	IN	NS	a0.nic.io.
io.			172800	IN	NS	a2.nic.io.
io.			172800	IN	NS	b0.nic.io.
io.			172800	IN	NS	c0.nic.io.
io.			86400	IN	DS	57355 8 2 95A57C3BAB7849DBCDDF7C72ADA71A88146B141110318CA5BE672057 E865C3E2
io.			86400	IN	RRSIG	DS 8 1 86400 20220713050000 20220630040000 47671 . YSZego0OkTuiRAdik84dlw4fq2XpyGOeNn7o9eLrsNiZ/f6sDYRB3Q5k RUSs6UBYalF5viNdlgopKJM0ni8A1LQ47JCk3o0MaRKagVn39SPztKan ZffhNGB9/pakK9/4SX5a/Whe3kaCSvYP1EhxxrUlAmriSkj5LemPvYH2 4/eRHj1TvaJms4W7GwJOiIa93ylhyIRDAU78wNqagWwsfg675wnfd/v7 L729R1CIC8YrmEa6PBRMovZS7/Rvq3w6ze4lzGeWy7q3qeR5TG7h1Lt6 d1aI0HicmrEpuItAZ353Nmqg1tj9VkJ955LET1xIeZeRCoAu2EXC5ZKM bZo8XA==
;; Received 619 bytes from 199.7.91.13#53(d.root-servers.net) in 223 ms

plab.io.		3600	IN	NS	ns-360.awsdns-45.com.
plab.io.		3600	IN	NS	ns-1447.awsdns-52.org.
plab.io.		3600	IN	NS	ns-1691.awsdns-19.co.uk.
plab.io.		3600	IN	NS	ns-947.awsdns-54.net.
0d790076pp5pfktg2hrthj5bj6ckckcb.io. 3600 IN NSEC3 1 1 10 332539EE7F95C32A 0D7BD4G2J0SLS1QJ0OVHK6NSRI6V9MIK  NS SOA RRSIG DNSKEY NSEC3PARAM
0d790076pp5pfktg2hrthj5bj6ckckcb.io. 3600 IN RRSIG NSEC3 8 2 3600 20220721081748 20220630071748 50244 io. ysif5JpS7M32HoEISQRQv5FPcX9SLC3WNyRnljpXXuw4EFpY37rKv7Ri xUhETp8urelxYkDvsX+tGe6NM1O5QRUes1M8grDYVBkIZUOodGL4pBe4 azRuLGsvHszn5nGhulZi48R4Z92/qQdYycSIM3GChJYr4OXPAbHKRE8w vJI=
0mn1f7kbha4ff1nbicm1ogo0le8kbf3k.io. 3600 IN NSEC3 1 1 10 332539EE7F95C32A 0MNNP0L5R7LED8DLLE1D70KN80U9H7TL  NS DS RRSIG
0mn1f7kbha4ff1nbicm1ogo0le8kbf3k.io. 3600 IN RRSIG NSEC3 8 2 3600 20220716154118 20220625144118 50244 io. RI/gNdQsXb4rje8goeplL5sVN9WF3vZwiCPS7Kt0gAlEXaWPPQ4BgO7E mP0GA/MYmJR+6ZSlkxPUgk9K4VOhtdvfk4ZIouf7351d/rCmdR10dleT czLZCrKmL6AWANOQLwY1ClPR8mm8buJvsRvUqVd54mgJgNrdKtfPWR+u vnk=
;; Received 675 bytes from 65.22.160.17#53(a0.nic.io) in 513 ms

plab.io.		60	IN	A	99.86.91.116
plab.io.		60	IN	A	99.86.91.90
plab.io.		60	IN	A	99.86.91.103
plab.io.		60	IN	A	99.86.91.99
plab.io.		172800	IN	NS	ns-1447.awsdns-52.org.
plab.io.		172800	IN	NS	ns-1691.awsdns-19.co.uk.
plab.io.		172800	IN	NS	ns-360.awsdns-45.com.
plab.io.		172800	IN	NS	ns-947.awsdns-54.net.
;; Received 240 bytes from 205.251.193.104#53(ns-360.awsdns-45.com) in 299 ms

As you can see Cloudflare is asking for the resolution of .io extension to the root name server before going to the TLD manager to finally discover the Authoritative Name server declared in the NS record of plab.io

DNS Attack surface

DNS is a critical service to serve the Internet, most of all the public connectivity would always reach a peer using a domain and rarely directly the IP address.

Let’s see what I consider the three real important threat vectors associated.

DDoS

• With enough network and computing capacity, an attacker could food some important DNS server that manages the most used TLD such as .com or .net. That could cause massive partial or total disruption of DNS resolution.
• In 2016, the DNS provider Dyn suffer the biggest DDoS attack at that time, leveraged by the boom of unsecured ioT. Many big tech companies such as Airbnb, Amazon, BBC, CNN, eBay, Netflix, and Twitter relying on Dyn were partially interrupted.
• If the DNS server is using Anycast, that will mitigate the risk of flooding specific servers and make it easier to load-balanced the incoming requests.

DNS hijacking threat

• Do you feel confident in the security of the admin panel of your DNS provider?
• DNS hijacking consists in gaining control of the authority that manages your domain name. The attacker could obtain the login credentials of your DNS provider and change the zone configuration to redirect the traffic to a compromised website that looks just like yours.
• With a smart craft, the attacker could also act as a proxy to record information and redirect all the requests to the original server. It’s completely transparent for the client and takes more time to detect.
• Once your DNS provider compromised, the attacker change the DNS record of targeted websites. This has unfortunately happened to Netnod in 2019 when valid credentials of the backend tool Extensible Provisioning Protocol (EPP) has been stolen by what appears to be a Man In The Middle attack.

DNS Spoofing (cache poisoning)

• The most accessible and efficient way to corrupt the resolution of a domain is by the alteration of one of the DNS resolvers that’s on the path of the client resolution.
• The spoofing technique is not only used by hackers, it’s also employed by ISP to censure Internet content, such as the illegal website that’s been called by a legal court.
• Fun fact, the China Telecom service is spoofing VPN domain resolution by redirecting to Facebook IP addresses, why? because Facebook is banned at the national level and it’s an easy way for ISP to block traffic of specific services.
• To avoid DNS poisoning, DNSSEC extension should be enabled on each domain, if the resolver is compatible, it will check the key with the parent zone to ensure the resolution is not altered.