DNS: Domain Name Service

1. Domain Name System structure and functionality

2. DNS Clients or resolvers
3. DNS Servers: functionalities and types
4. Zone file and DNS records (RR)
5. Server BIND9

Mercedes Rodríguez, José Ramón Rodríguez, November 21

DNS structure and functionality 1
• DNS (Domain Name System) purpose: name resolution => to
translate user-friendly domain names into IP addresses.
• Default ports:
– Port 53/UDP: for DNS queries and responses with an UDP datagram size
limited to 512 bytes.
– Port 53/TCP: for large DNS responses (IPv6 queries, DNSSEC) and zone
transfers.
– Port 853/TCP: DNS over TLS.
• Internet DNS is a distributed and scalable system of nameservers: it
operates through a network of interconnected servers around the world. DNS
infrastructure can scale to handle millions of queries and remain reliable even
if some servers go offline.
• DNS implementation covers 3 requisites:
– Need for names hierarchy: inverted tree hierarchy starting with the root (.)
– Need for load balancing among nameservers: master and slaves
– Need to delegate nameservers administration: domains and subdomains

2
DNS structure and functionality 2
Domain names: text strings representing an
inverted tree hierarchy, where levels are
separeted by dots:
• Root (.): highest level domain
• TLD, Top Level Domain (first level)
• SLD, Second Level Domain
• Undefined amount of lower level nodes,
belonging to organizations and private users.
 TLDs, two kinds:
 gTLD (Generic TLD) : .com, .net, .org, etc.
 ccTLD (Country Code TLD) or geographics: .es, .fr, .uk, etc. (ISO 3166-1 standard)
 Top-Level Domain List
 FQDN (Full Qualified Domain Name), host name and subdomains and domains it belongs to,
including root domain (it ends with a dot).
 255 chars maximum, domain and subdomain names being 63 bytes maximum.
 Limited charset: {A-Z, 0-9, -}, case unsensitive.
 Withing domain ”.es” special chars may be included (ñ, á, é, í, ó , ú, ü, etc).
3
DNS structure and functionality 3
• Authority: every node in the
hierarchy receives an
authority, which is an entity
or person responsible of the
node management and
exploitation.
• Delegation: that authority
may delegate the
management of the lowest
levets of its domain.

 Root domain: former authority belonged to IANA (ICANN).

 Root Zone Database
 Root Zone File
 gTLDs are managed by ICANN, and ccTLDs are delegated by ICANN to countries.
 ccTLD ”.es” was granted, in 1988, to RedIRIS. From 2000, is managed by Red.es,
belonging to Spanish Goverment.
 Root servers: the root server system consists of more than 1600 instances operated
by the 12 independent root server operators (root-servers.org)
4
Domain name registry

Example, domains .es => https://www.dominios.es/

5
DNS client = DNS resolver
• Users generally do not communicate directly with a DNS resolver. Unless a DNS
tool such as nslookup, dig, or host is being used, domain name resolution typically
occurs transparently. Applications like web browsers or email clients automatically
send requests to the local DNS resolver to perform the lookup.
• Diagram of the architecture of the process by which domain name queries are
serviced and resolved (Aaron Filbert, CC BY-SA 4.0 , via Wikimedia Commons):

6
DNS resolution tools: dig, nslookup, host
• dig
– https://manpages.ubuntu.com/manpages/jammy/man1/dig.1.html
– https://www.cyberciti.biz/faq/linux-unix-dig-command-examples-usage-
syntax/
– https://linuxize.com/post/how-to-use-dig-command-to-query-dns-in-
linux/
• nslookup
– https://manpages.ubuntu.com/manpages/jammy/man1/nslookup.1.html
– https://www.geeksforgeeks.org/nslookup-command-in-linux-with-
examples/
• host
– /https://manpages.ubuntu.com/manpages/jammy/man1/host.1.html
– https://www.cyberciti.biz/faq/linux-unix-host-command-examples-usage-
syntax

7
DNS resolution process 1
• In Linux, /etc/nsswitch.conf file specifies the information
sources and lookup order:
– Ej. hosts: files mdns4_minimal dns
• files => /etc/hosts file
• mdns4_minimal => AVAHI multicast mechanism, only affecting to
.local suffixed names
• dns => use DNS servers specified in /etc/resolv.conf
• In Windows, C:\Windows\System32\drivers\etc\hosts is
checked first.
• When a client's hosts file or cache does not have the
requested information, the resolver queries a DNS server
defined in the host's configuration (e.g., netplan).
8
DNS resolution process 2
• The resolution process can be either recursive or
iterative:
– Recursive: The DNS server takes full responsibility for
resolving the query, contacting other DNS servers as
needed, and returning the final result to the resolver.
– Iterative: The DNS server responds with the best
information often referring the resolver to another DNS
server for further queries.
• The resolver ultimately receives an answer: either an
A record (and related CNAME if applicable) or an
NXDOMAIN response if the domain name does not
exist.
9
 Recursive vs. iterative resolution

Recursive

Iterative

10
DNS server, main features
• It mantains a {domain name, {IP addresses}} database.
– Domain (and subdomain) data are stored within “zone files”. Every
individual record is called Resource Resource (RR).
– A DNS server can be authoritative of one or more zones and returns
authoritative responses on those zones.
– DNS server may store a temporary cache, containing recent responses, to
accelerate following queries or lookups on the same information.
• Lookup types:
– Forward: returns an IP address from a domain name.
– Reverse: returns a domain name from an IP address.
• Lookup types, based on how a queries are forwarded:
– Iterative resolution.
– Recursive resolution.

11
Server types
• Primary or master:
– Stores registries of a namespace or “zone”.
– Updatable by zone files’ administrator.
• Secondary or slave:
– Obtains zones from primary servers through zone transfers.
– Zone files are read only.
• Cache:
– It is a queries forwarder.
– It registries client's resolutions in cache.
– It is not authoritative in any zone.

12
Zone authoritative servers
• When a name server contains a zone, is called “authoritative” for
that zone.
• It is posible to store the same zone in several DNS servers, a master
and one or more slaves. All of them are authoritative, as far as
information within slaves is updated.
• Zone transfers: To transfer data from a master to a slave server.
– 2 types of zone transfer - full (AXFR) and incremental (IXFR).
– The process of checking and updating is called a zone refresh, always
initiated by the slave.
– The zone transfer decision is made based on the serial number in the
SOA record. Only if the serial number on the master is greater than the
serial number on the slave, the slave will request a zone transfer over
TCP.

13
DNS database: Zone File
• A DNS zone file is a plain text file that contains the mapping
between domain names and IP addresses (DNS RR or resource
records) for a specific domain or zone. It acts as the DNS
database for a zone and is stored on an authoritative DNS
server. Format: RFC 1035.
• Contents:
– Comments: line begins with “ ; ”.
– Directive: it begins with “ $” and represents variables.
– Resource Records (RR): characteristics, properties and
entities of the domain.
– Spaces or tabs to give the zone file a clean look.

14
Zone File example for 'daw.com' domain
$TTL 2D ; default TTL for zone
$ORIGIN daw.com. ; base domain-name
;
@ IN SOA ns1.daw.com. hostmaster.daw.com. (
2025012701 ; serial number
12H ; refresh
15M ; refresh retry
3W ; expiry
2H ; nxdomain ttl
)
@ IN NS ns1.daw.com.
IN NS ns2.daw.net.
;
3w IN MX 10 mail.daw.com.
IN MX 20 mail.asir.net.
;
;Domain hosts includes previous NS and MX records
ns1 IN A 10.0.100.1
mail IN A 10.0.100.2
server IN A 10.0.100.1
prof IN A 192.168.1.10
alumn1 IN A 192.168.1.11
;
;Aliases
www IN CNAME server.daw.com.
ftp IN CNAME ftp.daw.net.
15
Zone file directives
• $TTL (TimeToLive): compulsory, default time (sec) that the RR is stored
in resolver's cache.
– Each RR can their own TTL. If omitted, it takes the $TTL value. Default
value > 2D.
– Time suffixes allowed: Y (yearS), M (months), W (weeks), D (days),
H (hours), M (minutes), S (seconds).
– Considerations :
• Short TTL => RRs are flushed out of the cache more quickly,
leading to more frequent queries and higher workloads on DNS
servers.
• Long TTL => DNS changes propagate slower.
• $ORIGIN: optional, domain name.
– Suffix for any RR that is not a FQDN-RR.
– It can be used several times in the zone file.
– Any ocurrence of @ (at-symbol) in the zone file is replaced by the
previous $ORIGIN value.
16
DNS records: RR types
Tipo Significado Función
First and compulsory RR. Defines the primary DNS server for
Start Of
SOA the zone, the administrator's email, and important timing
Authority
parameters.
Lists the authoritative name servers for the domain. At least,
NS Name Server
there must be one NS (master).
MX Mail Exchange Specifies the mail servers for the domain (SMTP/IMAP/POP).
A Address Maps a domain name to an IPv4 address.
AAAA Address Maps a domain name to an IPv6 address.
Canonical Alias for another domain name. Eg. Multiple webservers
CNAME
Name associated to only one IP, can shared the IP using CNAME.
Specifies services and ports for a domain (service name,
SRV SeRVices
protocol, priority, weight, service port and host).
Maps an IP address to a domain name (reverse DNS lookup).
PTR PoinTeR
It is placed in the Reverse Zone File.
TeXT
TXT Any piece of information in text.
information
17
RR types and syntax 1
SOA domainname ttl-RR IN SOA master-DNS-name admin-email
serial refresh-time retry-time expiration-time ttl-nx

• domainname: zone domain name; @

• ttl-RR: TTL; if omitted, it takes $TTL value.
• serial: it must increase after any zone change. Recommended syntax
(RFC1912): YYYYMMDDnn (YYYY=year, MM=month, DD=day,
nn=revision number).
• refresh-time: time for DNS slaves to synchronized.
• retry-time: if DNS slave fails to synchronized with the master, time to
retry periodically.
• expiration-time: time to give up after several synchronization retries.
• ttl-nx: time to live for a non-existent error in resolver cache.

18
RR types and syntax 2
NS domainname ttl-RR IN NS DNS-server-name
• domainname: zone domain name; it can be @ wildcard
• ttl-RR: TTL, se puede omitir; en ese caso, es el del $TTL.
• DNS-server-name: DNS server’s FQDN name.

MX domainname ttl-RR IN MX priority mail-server-name

• priority: load balancing mechanism. Lower the value, higher the
priority. The main server is normally 10.

A hostname ttl-RR IN A ipv4

AAAA hostname ttl-RR IN AAAA ipv6

• An IP can have several RR for several names.

• A hostname can have several RR for several. BIND answers with the set
of all IPs in a different order each time to balance the workload.

19
RR types and syntax 3
CNAME: aliasname ttl-RR IN CNAME realname
• To assign an alias to a name.
• Rule: if a name is placed in the roght side of a RR, it cannot be in
the left side of a CNAME RR.
• Eg:
$ORIGIN fp.com.
...
@ IN A 192.168.1.50
IN A 192.168.1.51
IN A 192.168.1.52
www IN CNAME fp.com.
...

20
RR types and syntax 4
PTR: ip-host ttl-RR IN PTR hostname
• To translate IP to names for reverse lookups.
• ip-host can be IPv4/IPv6.
• RR PTR are placed in a zone file with $ORIGIN:
– IPv4: <reverse-net-ip4>.in-addr.arpa.
– IPv6: <reverse-net-ip6>.ip6.arpa.
• Eg:
–Eg. 192.168.1.1 and 10.0.100.1 :
4.4.8.8.in-addr.arpa. IN PTR dns.google.
1.0.0.1.in-addr.arpa. IN PTR one.one.one.one.
–Eg. 2001:4860:4860::8844 and 2606:4700:4700::1001 :
4.4.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.
4.1.0.0.2.ip6.arpa IN PTR dns.google.
1.0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.7.4.0.0.7.
4.6.0.6.2.ip6.arpa IN PTR one.one.one.one.

21
Bind9 server
• Installation: sudo apt install bind9
/etc/bind
├── bind.keys
├── db.0
├── db.127
├── db.255
=>Zone files with the default RR
├── db.empty
├── db.local
├── db.root
├── named.conf =>main configuration file
├── named.conf.default-zones
├── named.conf.local =>file for zone definition
├── named.conf.options =>file for global configuration
├── rndc.key
└── zones.rfc1918

• Features:
– User bind, group bind, daemon /usr/sbin/named, arguments /etc/default/bind9
– Cache: /var/cache/bind
22
Bind9 server
• named.conf: main Bind configuration file that includes:
– named.conf.options:
• options section: global parameters.
• acl directives: for creating lists.
– named.conf.local: to define zones with zone directive,
• For an authoritative master’s zone: type master;
• For an authoritative slave’s zone: type slave;
– named.conf.default-zones: default Bind zones.
– db.*: there are some default zone files, eg.
• db.root: root servers (hint zone): Root Hints File
• db.local: localhost to 127.0.0.1 resolution.
• db.empty: empty zone to copy as template.

23
Example of named.conf.options
#Define a list of trusted IP networks:
acl "trusted-networks" {127/8; 10/8; 172.16/16;};

options {
#Directory where BIND stores its cache and other working files:
directory "/var/cache/bind";
#External DNS servers (Google's public DNS) for forwarding queries:
forwarders {8.8.8.8; 8.8.4.4;};
#Enable DNSSEC to ensure responses are authentic and unmodified:
dnssec-validation auto;

#Allow DNS queries from any IP address (publicly accessible):

allow-query {any;};
#Allow recursive queries only from "trusted-networks" clients:
allow-recursion {"trusted-networks";};
#Disable zone transfers entirely to prevent replication of the server's
#DNS zones by unauthorized clients:
allow-transfer {none;};

#Port and IP addresses on which BIND will listen for incoming queries:
listen-on port 53 {any;};
listen-on-v6 port 53 {::1;};
};
24
Example of named.conf.local
//Define the zone for the domain 'daw.com':
zone "daw.com" IN {
type master;
file "/etc/bind/db.daw.com"; //Path to the zone file for daw.com
allow-update { none; }; //Disable dynamic updates to this zone
allow-transfer {"trusted-networks";}; // Only allow zone transfers to
}; //IPs within "trusted-networks"

//Reverse zone for the 192.168.1.x network (if applicable to your network):
zone "1.168.192.in-addr.arpa" IN {
type master; //This server is the master for reverse lookups
file "/etc/bind/db.192"; //Path to the reverse zone file
};

//Additional zones for subdomains if required (eg. Subdomain dev.daw.com):

zone "dev.daw.com" IN {
type master;
file "/etc/bind/db.dev.daw.com"; //Path to the subdomain's zone file
allow-update { none; };
};
25
Checking Bind9 configuration:
named-checkconf, named-checkzone
• Commands to check configurations:
– named-checkconf - named configuration file syntax checking tool.
– named-checkzone - zone file validity checking tool. It checks the syntax and
integrity of a zone file. It performs the same checks as named does when
loading a zone.
– named-compilezone - similar to named-checkzone, but it always dumps the
zone contents to a specified file in a specified format.
• Usage:
– named-checkconf filename
• filename indicates the name of the configuration file to be checked. If not
specified, it defaults to /etc/bind/named.conf. Correct if there is no output.
– named-checkconf -l
• -l lists all the configured zones. Each line of output contains the zone name, class
(e.g. IN), view, and type (e.g. primary or secondary).
– named-checkzone [-d] zonename /path_to/zone-filename
• Correct if there is an "Ok" output.
• -d enables debugging.
26
Credits
• DNS: https://en.wikipedia.org/wiki/Domain_Name_System
• IANA: https://www.iana.org/domains
• DNS tutorial: https://www.fpgenred.es/DNS/index.html
• List of RR: https://en.wikipedia.org/wiki/List_of_DNS_record_types
• All DNS record types: by Ruurtjan Pul, NsLookup.io:
https://www.nslookup.io/learning/dns-record-types
• ISC's Open Source Knowledgebase (BIND 9): https://kb.isc.org/docs
• BIND9 documentation: https://kb.isc.org/docs/aa-01031
• BIND9 configuration examples:
https://www.fpgenred.es/DNS/consideraciones_generales.html
• BIND Best Practices – Authoritative

27