DNS Principles and Operations - Lecture 04

Mgr. Ondřej Surý, University of Ostrava
7DNSK: DNS Principles and Operations
Lecture 04
Domain Name System

Contents
• Zone
f
ile
a
nd zone
f
ile form
a
t
• $TTL
• $ORIGIN
a
nd def
a
ult dom
a
in
• DNS records
a
nd comments in the zone
f
ile
• Commented Zone File
• Prim
a
ry
a
nd Second
a
ry
• Zone synchroniz
a
tion
a
nd SOA
• SERIAL number in SOA
• AXFR
a
nd IXFR
• NOTIFY
• Zone Access Control – ACL
a
nd TSIG
• Should zone
a
ccess be restricted?
• About the present
a
tion

Zone
fi
le and zone
fi
le format

Zone File Format
• A n
a
me server progr
a
m (e.g., BIND 9) uses
a
zone
f
ile to lo
a
d the contents of
a
zone. The
zone
f
ile h
a
s
a
speci
f
ic form
a
t.
• The zone
f
ile form
a
t is de
f
ined in RFC 1035, which provides
a
st
a
nd
a
rd th
a
t c
a
n be used by
di
ff
erent n
a
me server progr
a
ms
a
nd understood by
a
ll.
(RFC 1035 is p
a
rt of the course liter
a
ture.)

Zone File Format
• A n
a
me server progr
a
m c
a
n h
a
ve extensions th
a
t do not work in other n
a
me server
progr
a
ms.
• Some n
a
me server progr
a
ms c
a
n store the zone in
a
d
a
t
a
b
a
se
a
s
a
n
a
ltern
a
tive to storing
the zone in
a
regul
a
r zone
f
ile.
• Here we will go through the common, st
a
nd
a
rdized text form
a
t for zone
f
iles.

$TTL 3600
$ORIGIN dnskurz.cz.
@ SOA ns2 hostmaster (
2025070401 ; serial
21600 ; refresh (6 hours)
7200 ; retry (2 hours)
604800 ; expire (1 week)
3600 ; minimum (1 hour)
)
NS ns1
NS dns5.dnshosting.xa.
MX 10 mail1
MX 20 mail2
www A 192.0.2.5 ; www1
AAAA 2001:db8:a::5 ;www1
A 192.0.2.6 ; www2
AAAA 2001:db8:a::6 ; www2
mail1 A 192.0.2.20
AAAA 2001:db8:1::20
mail2 A 192.0.2.21
AAAA 2001:db8:1::21
ns1 1800 A 192.0.2.30
1800 AAAA 2001:db8:1::5
; Development servers below
$ORIGIN development.namn.se.
$TTL 600
www A 192.0.2.7
AAAA 2001:db8:b::7
www.extra A 192.0.2.8
AAAA 2001:db8:b::8

$TTL
• Every DNS record must h
a
ve
a
de
f
ined TTL. In
a
ll outputs from "dig", the TTL is speci
f
ied for
a
ll DNS records.
• The e
a
siest
a
nd best w
a
y to set the TTL for
a
ll DNS records in
a
zone
f
ile is to write "$TTL"
with
a
n
a
ppropri
a
te v
a
lue
a
t the very top of the zone
f
ile.
$TTL 3600
• This me
a
ns th
a
t
a
ll DNS records where the TTL is not explicitly written will get
a
TTL of 3600
seconds. For
a
l
a
b zone,
a
v
a
lue of 300, or less, m
a
y be suit
a
ble.

$TTL
$TTL 3600
www.dnskurz.cz. A 192.0.2.3
dnskurz.cz. MX 10 mail.dnskurz.cz.
• is the s
a
me thing
a
s
www.dnskurz.cz. 3600 A 192.0.2.3
dnskurz.cz. 3600 MX 10 mail.dnskurz.cz.
• The TTL becomes wh
a
t is st
a
ted in the $TTL directive
a
bove the DNS record (
a
bove it in the
f
ile, doesn't h
a
ve to be directly
a
bove), if the TTL is not included in the record itself.

$TTL
$TTL 3600
• is the s
a
me thing
a
s
www.dnskurz.cz. 3600 A 192.0.2.3

$TTL
• $TTL c
a
n be repe
a
ted in the zone
f
ile with
a
new v
a
lue. The v
a
lue th
a
t is set
a
pplies until the
next $TTL.
$TTL 3600
www A 192.0.2.1
$TTL 600
www1.dev A 192.0.2.11
www2.dev A 192.0.2.12
www3.dev A 192.0.2.13
$TTL 3600
www.prf A 192.0.2.20

How is the TTL determined without $TTL?
• In the
a
bsence of other inform
a
tion, the v
a
lue from the SOA record's RDATA (minimum),
which is
a
lso used for neg
a
tive c
a
ching, is used. You should
a
lw
a
ys set the $TTL
f
irst in the
zone
f
ile to di
ff
erenti
a
te them.
$TTL 3600
$ORIGIN dnskurz.cz.
2025070401 ; serial
)
• If there is no $TTL
a
nd no TTL in the record, then we go to the SOA record:

Default domain
• When the zone
f
ile is lo
a
ded, the zone's n
a
me will be the def
a
ult dom
a
in. When the zone
"dnskurz.cz" is lo
a
ded, "dnskurz.cz." will be the def
a
ult dom
a
in. All rel
a
tive n
a
mes will then be
a
ppended with "dnskurz.cz."
dnskurz.cz. NS ns1
www.prod A 192.0.2.3
• is the s
a
me thing
a
s
ns1.dnskurz.cz. NS ns1.dnskurz.cz.
www.prod.dnskurz.cz. A 192.0.2.3

$ORIGIN and default domain
• With $ORIGIN we c
a
n recon
f
igure the def
a
ult dom
a
in. We h
a
ve lo
a
ded "n
a
mn.se."
a
nd get
"n
a
mn.se."
a
s the def
a
ult dom
a
in
www A 192.0.2.5
$ORIGIN prf.dnskurz.cz.
www A 192.0.2.51
• is the s
a
me thing
a
s
www.prf.dnskurz.cz. A 192.0.2.51
• Sometimes it's good, but it shouldn't be overused.

$ORIGIN and apex
• You c
a
n pl
a
ce $ORIGIN before
a
ll DNS records
a
nd give it the zone n
a
me:
$ORIGIN dnskurz.cz.
@ SOA ns2 hostmaster ( ... )
• It's not m
a
nd
a
tory, but it's good pr
a
ctice to indic
a
te which zone it is.
• $ORIGIN sets the def
a
ult dom
a
in to "dnskurz.cz.", which is
a
lre
a
dy set to "dnskurz.cz."
bec
a
use th
a
t is the zone we h
a
ve lo
a
ded.

$ORIGIN and apex
• If the zone
f
ile is to be stored or copied to
a
nother loc
a
tion, or if its contents
a
re to be
published outside the n
a
me server, e.g., in this present
a
tion or in ex
a
m questions, it will be
un
a
mbiguous which zone it
a
pplies to if the zone
f
ile begins with $ORIGIN
a
nd the SOA
record
a
s shown below.
• The "Owner n
a
me" for the SOA record must be the zone
a
pex.
$ORIGIN dnskurz.cz.

@ and default domain
• Inste
a
d of writing out the "owner n
a
me", you c
a
n write @ if the "owner n
a
me" should be the
def
a
ult dom
a
in. Norm
a
lly, @ is used for the SOA record, but it c
a
n be used for more records
(here "dnskurz.cz."):
$ORIGIN dnskurz.cz.
@ NS ns1
@ NS dns5.dnshosting.xa.
• @ is most often only used for the
a
pex, but c
a
n be used for other n
a
mes if we h
a
ve ch
a
nged
the def
a
ult dom
a
in with $ORIGIN. (But re
a
lly, don't...)

@ and default domain
• @ must be
a
lone in the dom
a
in n
a
me
f
ield. The following is not v
a
lid
www.@ A 192.0.2.5 ; invalid
• Inste
a
d, you c
a
n ch
a
nge the def
a
ult dom
a
in.
$ORIGIN www.dnskurz.cz.
@ A 192.0.2.5 ; valid

Same owner name for multiple records
• If sever
a
l consecutive records h
a
ve the s
a
me "owner n
a
me", you only need to write it in the
f
irst DNS record (in this c
a
se, "dnskurz.cz")
a
nd then indent the following records:
NS ns1
NS dns5.dnshosting.xa.
www A 192.0.2.5
AAAA 2001:db8:a::5

Same owner name for multiple records
• So the previous slide is the s
a
me thing
a
s
dnskurz.cz. SOA ns2 hostmaster ( ... )
dnskurz.cz. NS ns1
dnskurz.cz. NS dns5.dnshosting.xa.
www.dnskurz.cz. AAAA 2001:db8:a::5
• But it might be e
a
sier to re
a
d if you t
a
ke
a
dv
a
nt
a
ge of the f
a
ct th
a
t sever
a
l entries h
a
ve the
s
a
me "owner n
a
me", but both
a
re correct.

Relative and absolute names
• We
a
ssume th
a
t the def
a
ult dom
a
in
a
nd zone is "dnskurz.cz.".
mail.dnskurz.cz A 192.0.2.20
www. A 192.0.2.30
• The
f
irst item is the s
a
me
a
s the following, which we prob
a
bly don't w
a
nt:
mail.dnskurz.cz.dnskurz.cz. A 192.0.2.20
• The second record is "www.", i.e. directly under the root,
a
nd it f
a
ils to lo
a
d – "out of zone
d
a
t
a
". In the "dnskurz.cz." zone,
a
nd we c
a
n't h
a
ve
a
n owner n
a
me th
a
t isn't in or under th
a
t
a
pex node.

DNS records and comments in
the zone
fi
le

Long DNS records on multiple lines
• We c
a
n write long DNS records on multiple lines using p
a
rentheses "( )". We should norm
a
lly
use this technique for the SOA record
a
nd keep the s
a
me comments th
a
t "dig" provides:
2025070401 ; serial
)

Class is never needed
• There is never
a
re
a
son to write "IN" in DNS records bec
a
use the cl
a
ss is
a
lw
a
ys the internet
cl
a
ss. Also, you c
a
n't mix cl
a
sses in
a
single zone
f
ile.
• You c
a
n write
www IN A 192.0.2.5
IN AAAA 2001:db8:a::5
• but it's better to write just
www A 192.0.2.5
AAAA 2001:db8:a::5

Always specify the domain after NS and MX
• You c
a
n never specify the IP
a
ddress directly
a
fter NS
a
nd MX. The following prob
a
bly doesn't me
a
n wh
a
t you think:
$ORIGIN dnskurz.cz.
NS 192.0.2.5
MX 10 192.0.2.10
• but the correct one is prob
a
bly:
$ORIGIN dnskurz.cz.
NS ns1
MX 10 mail
ns1 A 192.0.2.5
mail A 192.0.2.10

• If we exp
a
nd the incorrect p
a
rt from the previous im
a
ge with the def
a
ult dom
a
in, we get:
$ORIGIN dnskurz.cz.
NS 192.0.2.5.dnskurz.cz.
MX 10 192.0.2.10.dnskurz.cz.
• which is prob
a
bly not wh
a
t we w
a
nt.

• If, inste
a
d, we do di
ff
erent error:
$ORIGIN dnskurz.cz.
NS 192.0.2.5.
MX 10 192.0.2.10.
• Record d
a
t
a
like this me
a
ns we h
a
ve something under the top-level dom
a
in ".5"
a
nd ".10"
respectively,
a
nd those don't exist.

A CNAME record cannot be combined with other records
• The following will not work bec
a
use the CNAME must be
a
lone in the node (for the dom
a
in
n
a
me):
www A 192.0.2.5
www CNAME www.webhosting.xa.
• but the following is perfectly
f
ine (di
ff
erent nodes/n
a
mes):
web A 192.0.2.5
www CNAME www.webhosting.xa.

Comments in the zone
fi
le
• It is possible to write comments in the zone
f
ile, both on their own line
a
nd on the s
a
me line
a
s the record. A comment begins with
a
semicolon (”;”)
a
nd continues to the end of the line:
@ SOA ns1 hostmaster (...)
NS ns1 ; primary server
NS dns5.dnshosting.xa. ; secondary server
; Web servers
www A 192.0.2.5 ; IPv4
AAAA 2001:db8::5 ; IPv6

Comments in the zone
fi
le
• If you type
a
colon (”:”) or
a
h
a
sh (”#”), it doesn't work like it does in other progr
a
mming
l
a
ngu
a
ges. The following h
a
s the wrong comment ch
a
r
a
cters:
@ SOA ns1 hostmaster (...)
NS ns1 : primary server
NS dns5.dnshosting.xa. ; secondary server
: Old web server not used.
#www A 192.0.2.5 ; IPv4
# AAAA 2001:db8::5 ; IPv6
; New web server outsourced
www CNAME web.webhosting.xa. ; Has both IPv4 and IPv6

Primary and Secondary
• A hosting server – where the zone is hosted – is either
a
prim
a
ry,
a
second
a
ry, or both.
• This distinction only
a
pplies to hosting servers, not resolvers.
• Prim
a
ry (formerly m
a
ster server):
• The
a
uthorit
a
tive n
a
me server where the zone
f
ile is cre
a
ted/upd
a
ted.
• The
a
uthorit
a
tive n
a
me server from which
a
sl
a
ve server retrieves the zone
f
ile.
• Second
a
ry (formerly sl
a
ve server):
• An
a
uthorit
a
tive n
a
me server th
a
t retrieves the zone
f
ile from
a
m
a
ster vi
a
a
zone tr
a
nsfer (AXFR).
(RFC 8499 is p
a
rt of the course liter
a
ture.)

• Prim
a
ry
a
nd Second
a
ry
a
re roles for
a
zone.
• A server c
a
n be prim
a
ry for one zone
a
nd second
a
ry for
a
nother.
• Prim
a
ry
a
nd Second
a
ry
a
re roles between servers.
• Server2 c
a
n be
a
secon
a
rdy to server1
a
nd
a
prim
a
ry to server3.

Listed in the NS records
• Cl
a
ssic con
f
igur
a
tion with one prim
a
ry
a
nd one or more second
a
ries where
a
ll
a
re listed
a
s
n
a
me servers (in the NS records) for the zone.

Primary and Secondary with Hidden Primary
• Con
f
igur
a
tion with
a
hidden prim
a
ry, i.e., only the second
a
ries
a
re listed
a
s NS for the zone.
Very common tod
a
y for l
a
rger zones.

Double Primaries
• Con
f
igur
a
tion with
a
hidden prim
a
ry,
a
nd two second
a
ries th
a
t
a
ct
a
s prim
a
ries for the rest
(du
a
l prim
a
ries).

Only Primary Servers
• It's possible to h
a
ve two (or more) prim
a
ry servers th
a
t
a
ll
a
ct
a
s n
a
me servers. How do you
keep the zone
f
ile identic
a
l on both?

Only Primary Servers
• It's possible to edit the
f
ile on one server
a
nd copy it to the other. From
a
DNS perspective,
these
a
re two prim
a
ries, but function
a
lly, it's one prim
a
ry
a
nd one second
a
ry.

Hidden Secondary
• If zone tr
a
nsfers
a
re
a
llowed, it's possible to set up
a
hidden second
a
ry. If AXFR is open,
a
nyone c
a
n set up
a
"hidden" second
a
ry.

Hidden Primary or Secondary
• A hidden prim
a
ry or hidden second
a
ry does not receive DNS queries through the norm
a
l
deleg
a
tion p
a
th. Resolvers
f
ind the n
a
me servers through NS records,
a
nd if there is no NS
record, there will be no queries.
• A hidden prim
a
ry still receives DNS queries from its second
a
ries for zone tr
a
nsfers. Norm
a
lly,
the intention is th
a
t the hidden prim
a
ry should not receive regul
a
r DNS queries.
• A hidden second
a
ry h
a
s
a
di
ff
erent purpose
a
nd c
a
n receive queries through some other
me
a
ns, e.g., h
a
rdcoded into
a
resolver. Or perh
a
ps to keep tr
a
ck of the zone or
a
ct
a
s
a
f
a
ilover.

Which one is the primary server?
• We c
a
n guess, but we don't know. Prim
a
ry
a
nd second
a
ry
a
re only relev
a
nt for zone upd
a
tes. All
a
re equ
a
lly
a
uthorit
a
tive for the
zone d
a
t
a
.
• Is the server listed in the SOA MNAME the prim
a
ry?
• M
a
ybe, but it doesn't h
a
ve to be. The prim
a
ry c
a
n be completely hidden.
; ANSWER
osu.cz. SOA oudec.osu.cz. hostmaster.osu.cz. (
2025101933 ; serial
86400 ; refresh (1 day)
3600000 ; expire (5 weeks 6 days 16 hours)
)
; AUTHORITY
osu.cz. NS oudec.osu.cz.
osu.cz. NS nsa.ces.net.
osu.cz. NS albert.osu.cz.

Which one is the primary server?
• Whoever controls the n
a
me servers knows which one is the prim
a
ry server.
• On the prim
a
ry server, the zone is con
f
igured
a
s "prim
a
ry"
a
nd there is
a
n edit
a
ble zone
f
ile.
• Even if the zone
f
ile on the prim
a
ry server is upd
a
ted from
a
d
a
t
a
b
a
se or through
f
ile
copying, it is still, technic
a
lly spe
a
king from
a
DNS perspective,
a
prim
a
ry server.

Which one is the secondary server?
• Whoever controls the n
a
me servers knows which one is the second
a
ry server.
• On the second
a
ry server, the zone is con
f
igured
a
s "second
a
ry"
a
nd with
a
"prim
a
ries"
st
a
tement. The second
a
rdy must know the IP
a
ddress of the prim
a
ry. (Or the IP
a
ddresses of
the prim
a
ries.)
• The zone is stored in
a
zone
f
ile th
a
t the n
a
me server cre
a
tes when it retrieves the zone vi
a
a
zone tr
a
nsfer (or just in memory). Such zone
f
ile c
a
nnot be upd
a
ted m
a
nu
a
lly, only through
zone tr
a
nsfers.

How do you
fi
nd the secondary servers?
• Norm
a
lly, you don't con
f
igure the prim
a
ry server with which servers
a
re second
a
ry servers.
• Sometimes you con
f
igure the prim
a
ry with
a
list of IP
a
ddresses th
a
t
a
re
a
llowed to retrieve
the zone, which is roughly equiv
a
lent to the second
a
ry servers, but if you con
f
igure with
a
TSIG key inste
a
d of
a
n IP
a
ddress, the connection becomes uncle
a
r. (More on TSIG keys in
the next im
a
ge.)

How do you
fi
nd the secondary servers?
• When the prim
a
ry needs to "know," it t
a
kes
a
ll the NS records in the zone
a
nd removes itself.
Wh
a
t rem
a
ins
a
re those th
a
t the prim
a
ry
a
ssumes
a
re second
a
ries. The prim
a
ry servers
a
lso
sends NOTIFY mess
a
ges th
a
t the zone h
a
s been upd
a
ted. (More on NOTIFY will follow.)
• Any hidden second
a
ry servers must be tr
a
cked. There might
a
lso be
a
con
f
igur
a
tion to send
NOTIFY mess
a
ges to
a
ddition
a
l servers.

Con
fi
guration of primary and
secondary

Primary server con
fi
guration
• In BIND 9,
a
dd the following con
f
igur
a
tion for e
a
ch zone for which the server
a
cts
a
s the
prim
a
ry server:
# Primary for dnskurz.cz
zone "dnskurz.cz" {
type primary;
file "dnskurz.cz";
allow-transfer { ... };
};
• There
a
re more settings th
a
t c
a
n be con
f
igured, but the ones
a
bove
a
re su
ff
icient.
Second
a
ry servers
a
re not speci
f
ied here.

Zone
fi
le on the secondary server
• The zone
f
ile on the second
a
ry server is identic
a
l in content to the zone
f
ile on the prim
a
ry
server (if the zone tr
a
nsfer is working), but its
f
ile form
a
t might be di
ff
erent.
• By def
a
ult, BIND 9 s
a
ves the zone
f
ile on the second
a
ry server in
a
bin
a
ry form
a
t c
a
lled "r
a
w"
to ensure f
a
st zone lo
a
ding.
• Set masterfile-format text; to get
a
re
a
d
a
ble form
a
t, for ex
a
mple, during tr
a
ining,
testing, development, or troubleshooting. It is
a
lso possible to convert from "r
a
w" to "text"
with named-compilezone tool.

Secondary server con
fi
guration
• In BIND 9,
a
dd the following con
f
igur
a
tion for e
a
ch zone for which the server
a
cts
a
second
a
ry
server:
# Secondary for dnskurz.cz
zone "dnskurz.cz" {
type secondary;
file "dnskurz.cz";
masterfile-format text;
primaries { 192.2.0.10; };
};
• There
a
re more settings th
a
t c
a
n be con
f
igured, but the ones
a
bove
a
re su
ff
icient. Second
a
ry
servers
a
re not speci
f
ied here.

Synchronization of primary and secondary

SOA Record for Zone Synchronization
• SERIAL – Used to determine if
a
zone synchroniz
a
tion is needed. If the prim
a
ry h
a
s
a
higher number, we need to tr
a
nsfer the zone.
• REFRESH – How often the second
a
ry should check
a
g
a
inst the prim
a
ry (reg
a
rdless of NOTIFY mess
a
ges).
• RETRY – If REFRESH f
a
iled (could not retrieve the SOA or could not perform
a
zone tr
a
nsfer), how long we should w
a
it before retrying.
• EXPIRE – If REFRESH f
a
ils repe
a
tedly, we give up on "serving" the zone
a
fter this
a
mount of time (responding with SERVFAIL inste
a
d).
; ANSWER
osu.cz. SOA oudec.osu.cz. hostmaster.osu.cz. (
2025101933 ; serial
86400 ; refresh (1 day)
3600000 ; expire (5 weeks 6 days 16 hours)
)

Serial Number
• The seri
a
l number is
a
32-bit integer, from 0 to 4,294,967,295 (2^32).
• The seri
a
l number is comp
a
red like
a
clock, so:
• If the shortest dist
a
nce is clockwise, it's
a
n incre
a
se.
• If it's counter-clockwise, it's
a
decre
a
se.
• If two numbers
a
re ex
a
ctly opposite e
a
ch other, it is unde
f
ined.

Serial Number
SERIAL Number Clock Position
0 12
1 073 741 824 3
2 174 483 648 6
3 221 225 472 9
4 294 967 295 just before 12

Change of the serial number
• Ex
a
mple 1:
• Existing: 100
• New: 101
• → incre
a
se (correct)
• Ex
a
mple 2:
• Existing: 2021012901
• New: 2021012903
• → incre
a
se (correct)
• Ex
a
mple 3:
• Existing: 1000
• New: 3300200100
• → decre
a
se (incorrect)
• Ex
a
mple 4:
• Existing: 4100200100
• New: 1
• → incre
a
se (correct)

The serial number has changed in the wrong direction
• If the seri
a
l number decre
a
ses inste
a
d of incre
a
sing, no zone tr
a
nsfer will occur
a
nd the
second
a
ry m
a
y l
a
g behind.
• E.g.: you use the d
a
te
a
s the seri
a
l number, but then switch to st
a
rting from 1. You forgot to
reset the second
a
ry.
• You c
a
n force the second
a
ry to fetch
a
new zone by stopping the sl
a
ve, deleting the zone
f
ile
on the sl
a
ve,
a
nd st
a
rting the sl
a
ve
a
g
a
in.
• Or better yet – do the proper seri
a
l number
a
rithmetics – incre
a
se in < 2^31 increments

Authoritative Zone Transfer
AXFR
• AXFR is
a
query type (but not
a
record type). It c
a
n therefore be in the query, but no such
record exists.
$ dig @oudec.osu.cz osu.cz axfr
; <<>> DiG 9.21.12 <<>> @oudec.osu.cz osu.cz axfr
; (2 servers found)
;; global options: +cmd
; Transfer failed.
• Th
a
t didn't go so well. How does it look like when it does go well?

AXFR – Query
; <<>> DiG 9.21.14-dev <<>> -p 12345 @localhost dnskurz.cz axfr +qr +multi +comments +question
; (2 servers found)
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50786
;; flags: ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 3fd55787c9f15021
;; QUESTION SECTION:
;dnskurz.cz. IN AXFR
;; QUERY SIZE: 51
(cont...)

AXFR – Response (1/2)
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50786
;; flags: qr aa ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 1
; COOKIE: 3fd55787c9f150210100000068ede31f6463e3cb3d98fe09 (good)
;dnskurz.cz. IN AXFR
;; ANSWER SECTION:
dnskurz.cz. 18000 IN SOA ns2.mythic-beasts.com. hostmaster.mythic-beasts.com. (
2025070401 ; serial
)

AXFR – Response (2/2)
dnskurz.cz. 300 IN NS ns1.mythic-beasts.com.
dnskurz.cz. 300 IN NS ns2.mythic-beasts.com.
mail1.dnskurz.cz. 3600 IN A 46.235.229.165
mail1.dnskurz.cz. 3600 IN AAAA 2a00:1098:9a::1
mail2.dnskurz.cz. 3600 IN A 46.235.229.165
mail2.dnskurz.cz. 3600 IN AAAA 2a00:1098:9a::1
ns1.dnskurz.cz. 60 IN AAAA 2a00:1098:9a:1::1
ns2.dnskurz.cz. 3600 IN AAAA 2a00:1098:9a:1::2
dnskurz.cz. 18000 IN SOA ns2.mythic-beasts.com. hostmaster.mythic-beasts.com. (
2025070401 ; serial
)
;; Query time: 1 msec
;; SERVER: ::1#12345(localhost) (TCP)
;; WHEN: Tue Oct 14 07:43:59 CEST 2025
;; XFR size: 10 records (messages 1, bytes 367)

AXFR – Failed Query/Response
• Trying to tr
a
nsfer the zone th
a
t we're not
a
llowed to.
$ dig @oudec.osu.cz osu.cz axfr +comment +question
; <<>> DiG 9.21.12 <<>> @oudec.osu.cz osu.cz axfr +comment +question
; (2 servers found)
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 20651
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
; COOKIE: c5a808764bd877630100000068edeb995c9f9990b01e6859 (good)
; EDE: 18 (Prohibited)
;osu.cz. IN AXFR
; Transfer failed.

AXFR fetches the entire zone
• With AXFR, the entire zone is tr
a
nsfered every time. This isn't
a
problem if the zone is sm
a
ll
(like in our ex
a
mple).
• L
a
rge zones result in l
a
rge zone
f
iles, e.g., the .cz zone is more th
a
n 1 GB on disk. There
a
re
signi
f
ic
a
ntly l
a
rger zones (.com, .de, .cn).
• If
a
l
a
rge zone
f
ile is ch
a
nged often
a
nd you w
a
nt to publish the ch
a
nges quickly, it becomes
a
problem.

Incremental Zone Transfer
IXFR
• Inste
a
d of sending the entire zone,
a
"ch
a
ngeset" is sent between the version the second
a
ry
h
a
s
a
nd the current version on the prim
a
ry.
• IXFR requires the zone
f
ile to be upd
a
ted so th
a
t DNS server (BIND 9) c
a
n keep tr
a
ck of the
ch
a
nges. It works poorly with upd
a
tes m
a
de using
a
n editor, but it c
a
n be con
f
igured like this
(ixfr-from-differences yes;).
• We will not go into the det
a
ils.

NOTIFY – Notify Updates
• The second
a
ry is responsible for keeping itself upd
a
ted, but the prim
a
ry c
a
n inform it when
the zone h
a
s ch
a
nged.
• The prim
a
ry then sends
a
speci
a
l NOTIFY mess
a
ge. It is
a
DNS p
a
cket, but with speci
a
l
v
a
lues.

NOTIFY – Notify Updates
1. The zone
f
ile h
a
s been ch
a
nged
a
nd the prim
a
ry server h
a
s lo
a
ded the new version of the
zone.
2. The prim
a
ry server gets
a
ll NS records from the zone
a
nd
f
inds
a
ll (potenti
a
l) second
a
ries.
3. DNS server c
a
n be usu
a
lly con
f
igured to send NOTIFY to
a
ddition
a
l second
a
ries (remember
hidden second
a
ries?) or just to
a
n explicit list of second
a
ries.
4. The prim
a
ry server sends NOTIFY to
a
ll second
a
ries from this list.
5. According to the st
a
nd
a
rd, the second
a
ry should respond.

Secondary and NOTIFY
• The second
a
ry receives
a
NOTIFY mess
a
ge.
• The second
a
ry veri
f
ies th
a
t the NOTIFY c
a
me from the prim
a
ry (
a
ccording to its list of
second
a
ries).
• According to the st
a
nd
a
rd, it must respond.
• If the NOTIFY c
a
me from the correct prim
a
ry, the second
a
ry will
a
ct
a
s if the REFRESH timer
h
a
s expired, i.e., it is time to check the seri
a
l number on the prim
a
ry.

Secondary and NOTIFY
• So, NOTIFY doesn't me
a
n th
a
t
a
zone tr
a
nsfer is requested (or initi
a
ted), but r
a
ther th
a
t the
second
a
ry st
a
rts checking if
a
zone tr
a
nsfer request is necess
a
ry.

• In BIND 9, NOTIFY is on by def
a
ult. All second
a
ries de
f
ined in the zone will receive the NOTIFY
mess
a
ge on the zone ch
a
nge event. You c
a
n
a
dd, for ex
a
mple, hidden second
a
ries (second
a
ries
not listed in the zone) using "
a
lso-notify" on the m
a
ster server.
zone "dnskurz.cz" {
type primary;
file "dnskurz.cz";
allow-transfer { localhost; 192.2.0.200; 2001:db8:1::200; };
also-notify { 192.2.0.200; };
};
• It is
a
lso possible to h
a
ve
a
second
a
ry send NOTIFY to the other hidden second
a
ries.

Zone Access Control – ACL and
TSIG

Zone Access Control
• Most zone owners w
a
nt to restrict who c
a
n perform
a
zone tr
a
nsfer. In BIND 9
a
nd other DNS
servers, there
a
re two w
a
ys to verify if
a
client is
a
uthorized:
1. Only
a
llow clients from cert
a
in IP
a
ddresses to perform the zone tr
a
nsfer.
2. Use TSIG –
a
cryptogr
a
phic key – with
a
sh
a
red secret between the prim
a
ry
a
nd
second
a
ry servers.

Zone Access Control with IP addresses
• Simple con
f
igur
a
tion th
a
t only needs to be done on the prim
a
ry server.
• On the second
a
ry server, zone tr
a
nsfer c
a
n be dis
a
bled or only
a
llowed from the loc
a
lhost.

On the Primary
• Restrict zone tr
a
nsfers to
a
pproved second
a
ries. Also include loc
a
lhost plus
a
ny other computers
th
a
t should be
a
llowed to perform zone tr
a
nsfers for m
a
nu
a
l testing with dig or
a
utom
a
ted
monitoring.
zone "dnskurz.cz" {
type primary;
file "dnskurz.cz";
allow-transfer { localhost; 192.2.0.200; 2001:db8:1::200; };
};
• It is
a
lso possible to
a
dd
a
gener
a
l con
f
igur
a
tion for
a
ll zones under options section in
named.conf.

On the Secondary
• Limit zone tr
a
nsfers to localhost
a
nd
a
ny other computers th
a
t should be
a
llowed to perform zone
tr
a
nsfers for m
a
nu
a
l testing with dig or
a
utom
a
ted monitoring.
zone "dnskurz.cz" {
type secondary;
file "dnskurz.cz";
primaries { 192.2.0.10; };
allow-transfer { localhost; };
};
• It is
a
lso possible to
a
dd
a
gener
a
l con
f
igur
a
tion for
a
ll zones under options section in named.conf.

• The IP
a
ddress ACLs doesn't work well in more dyn
a
mic environments where the clients
(second
a
ries) might ch
a
nge IP
a
ddresses – this would require prim
a
ry server re-
con
f
igur
a
tion on every ch
a
nge.

Zone Access Control with TSIG
• TSIG is
a
cryptogr
a
phic key th
a
t c
a
n be used to sign DNS mess
a
ges ("query" or "response")
between, for ex
a
mple,
a
prim
a
ry
a
nd
a
second
a
ry.
• Both the prim
a
ry
a
nd the second
a
ry must initi
a
lly be con
f
igured with
a
sh
a
red secret key.
• Once the key is entered, no further
a
ction is needed until the key h
a
s to be ch
a
nged.
• The second
a
ry c
a
n continue to use the s
a
me key even
a
fter
a
potenti
a
l IP
a
ddress ch
a
nge.

• In
a
ddition to being used to restrict
a
ccess to zone tr
a
nsfers, TSIG o
ff
ers
a
nother
a
dv
a
nt
a
ge:
• When
a
second
a
ry server retrieves the zone using TSIG, it c
a
n ensure th
a
t the zone
f
ile h
a
s
not been corrupted in tr
a
nsit bec
a
use the responses
a
re signed with the TSIG key.
• TSIG is HMAC – h
a
sh-b
a
sed mess
a
ge
a
uthentic
a
tion code. In cryptogr
a
phy, this is speci
f
ic
type of Mess
a
ge Authentic
a
tion Code involving cryptogr
a
phic h
a
sh function
a
nd
a
secret
cryptogr
a
phic key (the sh
a
red key on the previous slide). It m
a
y be used to simult
a
neously
verify both the d
a
t
a
integrity
a
nd
a
uthenticity of
a
mess
a
ge.

• Limit
a
tion:
• TSIG does not provide
a
ny protection
a
g
a
inst e
a
vesdropping. If
a
third p
a
rty c
a
n listen in
on the connection, they c
a
n
a
ccess the tr
a
nsferred zone.
• This is usu
a
lly not
a
serious problem.

TSIG for all types of DNS queries
• TSIG
a
pplies to
a
ll types of DNS queries, not just the zone tr
a
nsfer (AXFR/IXFR).
• NOTIFY mess
a
ges c
a
n be
a
lso
a
uthentic
a
ted with TSIG.
• A resolver c
a
n
a
llow DNS queries from clients with the correct TSIG key. The
a
dv
a
nt
a
ge is
th
a
t the client then receives
a
signed response.
• TSIG provides
a
n identity or group membership to the client,
a
nd the server c
a
n therefore
provide di
ff
erent
a
nswers depending on the client b
a
sed on the TSIG key.
• For protection
a
g
a
inst e
a
vesdropping, other mech
a
nisms
a
re required (to be discussed
l
a
ter).

Create TSIG key
• A TSIG key is cre
a
ted with the comm
a
nd tsig-keygen. Run the comm
a
nd plus the n
a
me you will
use for the key, e.g., group19.tsig. (with
a
period
a
t the end).
$ tsig-keygen group19.tsig.
key "group19.tsig." {
algorithm hmac-sha256;
secret "PO4MJJzLde8u+4Eu7PJoBvUfkfhjOSRdfLYz1rZwRoQ=";
};
• A new "secret" is gener
a
ted every time the comm
a
nd is run.
• Do not use the ex
a
mple
a
bove, which is "broken" bec
a
use it is now public; inste
a
d, gener
a
te
a
new
key.

Copy TSIG key to named.conf
• Add the key to named.conf on both the prim
a
ry
a
nd the second
a
ry server:
key "group19.tsig." {
algorithm hmac-sha256;
secret "PO4MJJzLde8u+4Eu7PJoBvUfkfhjOSRdfLYz1rZwRoQ=";
};
• Do not use the ex
a
mple
a
bove, which is "broken" bec
a
use it is now public; inste
a
d, gener
a
te
a
new key.
• The n
a
me
a
nd “secret” c
a
n then
a
lso be used by “dig” to m
a
ke queries
a
nd perform
a
zone tr
a
nsfer
with TSIG (dig -y [hmac:]name:key), e.g.:
dig -y hmac-sha256:group19.tsig.:PO4MJJzLde8u+4Eu7PJoBvUfkfhjOSRdfLYz1rZwRoQ=

Use TSIG key on the secondary
• Add the corresponding entry to named.conf on the second
a
ry with your key
a
nd the
correct IP
a
ddress, so th
a
t it uses the TSIG key for requests (incl. AXFR) to the prim
a
ry:
server 192.0.2.10 {
keys { group19.tsig.; };
};
• The IP
a
ddress should be for the prim
a
ry. If there
a
re multiple prim
a
ries, there will be multiple
server st
a
tements referencing the s
a
me key. The second
a
ry will now use the key for
a
ll
queries to the prim
a
ry, not just AXFR, but
a
lso, for ex
a
mple, the SOA query.

Require TSIG key on the Primary
• Upd
a
te n
a
med.conf on the prim
a
ry so th
a
t it requires your TSIG key for zone tr
a
nsfers:
zone "dnskurz.cz" {
type primary;
file "dnskurz.cz";
allow-transfer { localhost; key "group19.tsig."; };
};
• It is possible to combine keys
a
nd
a
ddresses. It is useful to
a
llow localhost to perform zone
tr
a
nsfers without
a
key loc
a
lly.

Require TSIG key on the Secondary
• Upd
a
te n
a
med.conf on the second
a
ry so th
a
t
a
ccess to the zone is restricted in the s
a
me w
a
y:
zone "dnskurz.cz" {
type secondary;
file "dnskurz.cz";
primaries { 192.2.0.10; };
allow-transfer { localhost; key "group19.tsig."; };
# allow-transfer { localhost; };
# allow-transfer { none; };
};
• It's possible to set di
ff
erent levels of restrictions. The import
a
nt thing is th
a
t
a
nyone who c
a
nnot
a
ccess the zone
from the prim
a
ry should not be
a
ble to
a
ccess it from the second
a
ry either.

Zone Access Control
• The mech
a
nisms c
a
n be combined so th
a
t some second
a
ries
a
re
a
llowed by IP
a
ddress
a
nd
others with TSIG. The zone tr
a
nsfer will be
a
ccepted
a
s long
a
s one of these conditions is
met.
• If you w
a
nt to both restrict the IP
a
ddresses from which zone tr
a
nsfers c
a
n be requested
a
nd
a
lso require the TSIG key, you must set up
a
solution with
a
f
irew
a
ll outside of DNS Server.

Should zone access be
restricted?

Should zone transfers be restricted?
• It's
a
policy decision. In some c
a
ses,
a
zone
f
ile c
a
n cont
a
in inform
a
tion th
a
t c
a
n be used for
m
a
licious purposes.
• If the zone
f
ile only cont
a
ins "www"
a
nd MX (besides NS
a
nd SOA), like this:
dnskurz.cz. MX mail.dnskurz.cz.
www.dnskurz.cz. CNAME web.webhosting.xa.
• then it's h
a
rd to see the point of the restriction. (Also in some c
a
ses, the zone c
a
n be
enumer
a
ted, we will t
a
lk
a
bout this when we get to DNSSEC.)
• Since BIND 9.20, the def
a
ult is now allow-transfer { none; };

The Internet's Domain Name System
• This present
a
tion w
a
s developed from 2019–2024 by M
a
ts Du
f
berg
(m
a
ts.du
f
berg@internetstiftelsen.se)
a
t The Internet Found
a
tion (https://
internetstiftelsen.se/). It is p
a
rt of the te
a
ching m
a
teri
a
l for the course
"The Internet's Dom
a
in N
a
me System"
a
t KTH Roy
a
l Institute of
Technology (course code HI1037)
a
nd K
a
rlst
a
d University, KAU (course
code DVGC28), respectively.
• This present
a
tion w
a
s tr
a
nsl
a
ted in 2025 by Ondřej Surý
<ondrej@isc.org>
a
t Internet Systems Consortium. It is p
a
rt of the
te
a
ching m
a
teri
a
l for the course "DNS Principles
a
nd Oper
a
tions"
a
t
University of Ostr
a
v
a
.

License
• This te
a
ching m
a
teri
a
l is provided under the Cre
a
tive Commons BY 4.0
license (https://cre
a
tivecommons.org/licenses/by/4.0/deed.en)
a
nd m
a
y
be used in
a
ccord
a
nce with its terms.

DNS Principles and Operations - Lecture 04

More Related Content

Similar to DNS Principles and Operations - Lecture 04

Recently uploaded

DNS Principles and Operations - Lecture 04