DNS Hiyerarşisi

Giriş
DNS 1983 yılında tasarlanmış. Açıklaması şöyle.

Ultimately, the DNS system we still use today would be proposed in 1983.

Bu sistemde Parent DNS ve Root DNS kavramları var. Açıklaması şöyle.

DNS is a hierachy. DNS servers know either how to find a parent DNS server or how to find a list of the "root" servers.

If they find a parent DNS server they just ask it, and it asks its parent until it gets an authorative answer.

In most cases however, nameservers know the root nameservers, which in turn point them to the appropriate servers for the domain. (Or in some cases the appropriate server for the first part of the domain. This process is repeated until the domain name is resolved).

Root DNS Sunucuları
Bunlardan 13 tane var. Açıklaması şöyle

When we say DNS is hierarchical, what we mean is there is a set of root DNS servers which are responsible for, for example, turning .com into the .com nameservers, who will in turn answer how to get to google.com. The root DNS zone of the internet is composed of thirteen DNS server clusters. There are only 13 server clusters, because that’s all we can fit in a single UDP packet. Historically, DNS has operated through UDP packets, meaning the response to a request can never be more than 512 bytes.

Root DNS sunucularına fiziksel erişim kısıtlı. Açıklaması şöyle.

Root DNS servers operate in safes, inside locked cages. A clock sits on the safe to ensure the camera feed hasn’t been looped. Particularly given how slow DNSSEC implementation has been, an attack on one of those servers could allow an attacker to redirect all of the Internet traffic for a portion of Internet users. This, of course, makes for the most fantastic heist movie to have never been made.

Unsurprisingly, the nameservers for top-level TLDs don’t actually change all that often. 98% of the requests root DNS servers receive are in error, most often because of broken and toy clients which don’t properly cache their results. This became such a problem that several root DNS operators had to spin up special servers just to return ‘go away’ to all the people asking for reverse DNS lookups on their local IP addresses.

The TLD nameservers are administered by different companies and governments all around the world (Verisign manages .com). When you purchase a .com domain, about $0.18 goes to the ICANN, and $7.85 goes to Verisign.

DNS ve Cache'leme
Açıklaması şöyle

In reality a nameserver won't generally make all of these queries, because it will remember parts of it. IE the first time someone looks up any .com domain name, the DNS server they are using it will remember the nameservers (for 172800 seconds in this case), so it won't need to do another lookup. Similarly for all the more specific parts of the lookup.

Name Server'a Yeni Kayıt Ekleme
Açıklaması şöyle. Bir API aracılığıyla oluyor.

So if someone is registering example.com via Godaddy (or any registrar), Godaddy needs to (programmatically) get the nameservers for example.com entered into the ".com" nameserver. Similarly, if they are in AU, they need to enter the information into the ".com.au" space if they want to register "example.com.au" - and this would require an agreement with the people controlling the nameservers for ".com.au" space - which is why not all registrars can register all domains, and why getting new top level domains is such a process - they need to pay big money to register the TLD with the root nameservers.

Kendi DNS Sunucuma Başka Bir Adres İçin A Record Koyarsam Ne Olur?
Hiçbir şey olmaz. Çünkü kendi telefon rehberimi düzenlemekle aynı şeydir. Kimse benim DNS sunucumu sorgulamadığı için her şey normal çalışmaya devam eder. Sorgulama için izlenen adımlar şöyle. Benim sunucum recursive resolver veya root name server veya authoritative server olmadığı için kimse benim sunucuma soru sormaz.

1. You as the DNS client (or stub resolver) query your recursive resolver for www.example.com.
2. Your recursive resolver queries the </blockquote> for www.example.com.
3. The root name server refers your recursive resolver to the .com Top-Level Domain (TLD) authoritative server.
4. Your recursive resolver queries the .com TLD authoritative server for www.example.com.
5. The .com TLD authoritative server refers your recursive server to the authoritative servers for example.com.
6. Your recursive resolver queries the authoritative servers for www.example.com, and receives 1.2.3.4 as the answer.
6. Your recursive resolver caches the answer for the duration of the time-to-live (TTL) specified on the record, and returns it to you.

ISP Tarafından DNS Sorgusu Yönlendirme

Açıklaması şöyle. Burada biz bir başka DNS sunucusunu kullandığımızı sansak bile ISP'nin DNS'ine gideriz.

It is still possible and not uncommon though that your DNS query does not actually end at the DNS server you want to use but will still be handled by the ISP's DNS server. This can be done with a cheap redirection of all packets destined for port 53 to the ISP's DNS server. Enforcing the use of the ISP's DNS server is usually done if the ISP is ordered to block access to specific domains. But even without redirecting the ISP might be able to see what domains you query: DNS queries are by default not encrypted and thus visible to Deep Packet Inspection. When using DNS over HTTPS (DoH) or DNS over TLS (DoT) the ISP will no longer be able to intercept these DNS requests though, nor will it be able to see the content of the DNS queries. It can still determine the domains you visit from DPI on the web traffic itself though in most cases.

Deep Packet Inspection

Açıklaması şöyle.

Some ISP might also snoop at the traffic with Deep Packet Inspection (DPI) and might also block or delay traffic based on this. Some might also enforce an implicit proxy to modify the traffic. This is especially true in countries where the ISP is ordered to block specific sites. It happened also in the past that ISP injected their own advertisements in the traffic. Or mobile ISP where found to "enrich" the traffic to provide information about the client (like the phone number) to the final server in order to provide more targeted advertisements. Traffic modification is mostly impossible when HTTPS is used though, but blocking traffic will even work with HTTPS.

Domain name system security extensions - DNSSEC

Açıklaması şöyle

DNSSEC creates a secure domain name system by adding cryptographic signatures to existing DNS records. These digital signatures are stored in DNS name servers alongside common record types like A, AAAA, MX, CNAME, etc. By checking its associated signature, you can verify that a requested DNS record comes from its authoritative name server and wasn’t altered en-route, opposed to a fake record injected in a man-in-the-middle attack.

To facilitate signature validation, DNSSEC adds a few new DNS record types:

- RRSIG - Contains a cryptographic signature

- DNSKEY - Contains a public signing key

- DS - Contains the hash of a DNSKEY record

- NSEC and NSEC3 - For explicit denial-of-existence of a DNS record

- CDNSKEY and CDS - For a child zone requesting updates to DS record(s) in the parent zone.

Gerçek DNS sunucusu ile delegate eden DNS sunucusu aynı şifreleme algoritmasını kullanmalıdır.

Eğer sorgulayan DNSSEC seçeneğini kullanmazsa normal bir cevap alır. Açıklaması şöyle

DNSSEC is an extension of DNS in the sense that for a non validating resolver, answers are not different, even if the domain is DNSSEC enabled. So all return codes work in the same way.

Örnek

Şöyle yaparız. icann.org aslında DNSSEC kullanır ancak dig komutunda DNSSEC cevap istenmediği için NXDOMAIN cevabı veriyor. Eğer dig ile DNSSEC sonuçlarını da görmek istersek +dnssec seçeneği kullanılır

$ dig NS icann.org +short
b.icann-servers.net.
c.icann-servers.net.
ns.icann.org.
a.icann-servers.net.

$ dig @a.icann-servers.net does-not-exist-foobar.icann.org

; <<>> DiG 9.18.4 <<>> @a.icann-servers.net does-not-exist-foobar.icann.org
; (1 server found)
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38891
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 98228e9e0c5ef4e6
;; QUESTION SECTION:
;does-not-exist-foobar.icann.org. IN A

;; QUERY SIZE: 72

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 38891
                                       ^^^^^^^^