Origin of DNS

Domain name (human readable) -> IP address (machine usable)
"Phone book of the internet"

Started off with Network Control Protocol (NCP) instead of IP
Used Interface Message Processors (switches)
Max 64 IMPs with max 4 hosts = max 256 hosts
6 bit for destination IMP, 2 bit for the actual destination

Instead of DNS, there use to be a centrally administered host table
From 1973, distributed as HOSTS.TXT

Next step: replace NCP with TCP
Created by Vint Cerf from 1973-1979
Jon Postel proposed splitting the addressing part off into the Internet Protocol

January 1st 1983: Arpanet switched from NCP -> TCP/IP
256 -> 4.294.967.296 hosts
A host table doesn't scale

November 1983: Paul Mockapetris introduced Domain Name System: RFC 882

Original idea
HOSTS.TXT does not scale
To make DNS scale, split it hierarchically

root -> Top Level Domains -> "second level domains"

Jake Feinler invented the TLDs to split it evenly
.mil, .edu, .gov, .org, .com
However, that didn't really work out
com. 157.9M
cn. 21.0M
de. 17.6M
net. 12.6M
org. 11.2M
uk. 10.2M
ru. 6.7M
nl. 6.1M
# Total: 371.1M

Authority gets delegated

IANA is a function, carried out by ICANN
If you get delegated authority, you get authority over a zone
Starts from the parent, e.g. .jp, but can be delegated further, such as .ac.jp

Domain Name Space

Split up the name space hierarchically
. root
.net, .org, .nl: Top Level Domains (TLD)
Domain name is a sequence of labels
The values between the dots
3 labels: os3, nl, empty root label
Fully Qualified Domain Name (FQDN)
www.os3.nl.
Has a dot at the end to indicate the root label
A domain is a domain name, together with all the domain names below it
The top zone and all zones below it
Zone
Organisational unit of authoritative information
Resource records
Actual DNS content
Apex records: os3.nl.
Zone content served by Authoritative Name Servers
ANS will delegate authority by referring to a child name server
ANS serving the root zone are called root servers
Lookup done by Resolvers

Original root served by 4 hosts, running JEEVES and BIND
Now, through anycasting, we have 1868 root servers

Multiple types of TLDs
Generic: gTLD
.gov, .edu, .com, ...
You can also get a custom one for $185.000
Country code: ccTLD
.us, .uk, au, ...
Internationalised domain names
.ไทย

DNS Operation

Stub resolver in client devices
Stub resolver asks caching recursive resolver (e.g. your router)
Records have a TTL (seconds)
If a record is not present, ask the Authoritative servers

Iterative mode:
The server refers the client to another server and lets the client pursue the query
Recursive mode:
The server will answer the query, or contact other servers to find the answer
Can be considered to have a name server side (which answers the query) and a resolver side (which performs the recursive resolution)

Uses UDP: authoritative servers servers can be stateless
Caching reduces load to authoritative servers and reduces latency

Zone Content - Resource Records

Resource Records

Owner: example.net
TTL
Class: IN, CH, HS (internet, chaos net, ...) always IN nowadays
Type: A, AAAA, CNAME, ...
Resource data (RDATA): depends on type

New types can be added, you only need expert review
Better to register a new type than to abuse TXT

There also exist "query types" or "meta types"
* to ask for all records
NXDomain to indicate no result

A Record

Name -> IPv4
Can be more than 1

AAAA Record

Name -> IPv6
Common to be >1

CNAME Record

Name -> Canonical name
E.g. www.unbound.net. -> unbound.net.
No subdomains, use DNAME for that
Only one RR with the same owner (except DNAME)
For service referrals use service records like SRV, SVCB, HTTPS

PRT Record

Address -> Domain name
Useful for:
Troubleshooting
Logging
Reverse DNS

MX Record

Mail Exchange record
1st RADATA field: priority, try the server with lowest prio first
2nd RDATA field: SMTP server for the domain

NS Record

Name Server record
Delegates authority -> makes DNS decentralised
E.g. os.nl. -> ns1.os3.nl.

Something something the parent zone hijacks the child zone's name

NS record is always 1 in parent and 1 in child
They should be the same, but they are not always
The NS data above the zone cut is non-authoritative
Considered "less reliable"
NS data below the zone cut is authoritative

Parent-centric vs child-centric resolvers
During recursion, learn from non-authoritative domains (get ns1.os3.nl from .nl domain server)
But if it gets the actual data from os3.nl, the record will be replaced

From a clear chache
Get the IPs for root servers from root hints
Then ask for the NS record set from said root server to replace this "unreliable" data

SOA Record

Start Of Authority
At the zone's apex
Administrates the zone's parameters
Primary server
Email address
Version of zone
Control plane parameters for secondary servers

Resource Records Set (RRset)

A set of RRs with the same:

• Owner
• Class Type
  But with different RDATA

Zone Content - Zone Files

A list of RRs in presentation format
Empty owner, class or TTL = use last value
Makes data smaller in transport

Zone file starts with $ORIGIN
Must be a FQDN, thus end with .
Free standing @ will be replaced with the current origin

Name Server Types & Zone Transfers