Lecture 7
Name Server Types & Zone Transfers
DNS required that multiple servers serve every zone
More robust and scalable
Also slightly more secure
- Primary: owner of the zone
- Hidden Primary
- Secondary: get the zone data from the primaries
- Stealth (unlisted primary or secondary)
- Lame (listed but not serving)
Zone Transfer
The secondary starts w/o any data
It has the primaries in it's config
It will pull the data with an AXFR query from the primary, it gets a SOA record
SOA Record
Start Of Authority
At the zone's apex
mname:
rname: hostmaster contact
serial: if the serial is already known, discard it
refresh: consider the zone fresh for X time, afterwards, do another transfer (pull)
If the serial number is the same, discard and consider it fresh for X again
retry: if the primary is down, wait for X to try again
expire: discard the zone after this time, only really happens when primary is not reachable
minimum: TTL for response of values that do not exist
An incremental transfer is also possible
IXFR query type
Include known SOA serial in authority section of the request
Returns all deleted and added RRs
When a primary's zone transfers it can push the update
Special opcode (4) NOTIFY
Secondary behaves as if SOA refresh has passed
Zone transfers often limited by ACLs
Only allow secondaries to transfer the zone
Used to be secured with TSIG (RFC8945)
Shared secret, which is shared out-of-band
Present in config, not in zone data
Still transferred in cleartext, but it does provide mutual identification
Nowadays, transfer over TLS -> XoT (RFC9103)
DNS Resource Records
TXT Record
Used to hold descriptive text, max 255-bytes
If you need longer fields, start next strings with a space
Can also be abused for other things
Sender Policy Framework (SPF)
Expect email from this domain to come from these IP addresses
MUST be published as a TXT record
DomainKeys Identified Mail (DKIM)
Mail server will sign with private key, public key is published using this TXT field
Domain-based Message Authentication, Reporting and Conformance (DMARC)
Policy to indicate what to do with SPF and DKIM
Used to be hard to get new RR types, which is why we abuse TXT records
Service Records (SRV)
Used for MX records
But intended for services in general
- Priority
- Weight
- Port
- Target
HTTPS Service Record
Container format
- Alias mode: this domain is not here, look at RDATA field 2 to find it
- TargetName (alias target or alternative endpoint)
- Params
- Address Layer Protocol Negotiation (ALPN): h3,h2 -> supports HTTP2&3
Service Binding of Designated Resolvers (SVCB)
Find out what methods a resolver support
DoT
DoH
Wildcards
A domain name exists if the name itself, or any descendant has data
Import to note: empty non-terminals can exist
If you query this empty node, you will get a response indicating that it exists, yet the answer section will be empty
Asterisk label (i.e. wildcard) is a label containing "*"
Wildcard domain name is a name with a "*" as it's leftmost label
???
Closes encloser: the longest ancestor of a query that does exist
Source of Synthesis: a wildcard domain name "*.<closest-encloser>", which may or may not exist
Next closer: is the name one label longer than the closes encloser
Example
%20Inter-Networking%20and%20Routing/Attachments/Pasted%20image%2020250923104959.png)
matching.the.wildcard.apex: wildcard match, NOERROR
matching.empty.apex: Wildcard match, NOERROR, NoData (empty non-terminal)
something.else.empty.apex: Wildcard match, NOERROR, NoData (empty non-terminal)
leaf.matching.empty.apex: Wildcard match
leaf.*.empty.apex: Normal match
DNS Message Wire Format
%20Inter-Networking%20and%20Routing/Attachments/Pasted%20image%2020250923110647.png)
- OpCode
- Only 0 (query), 4 (notify) and 5 (update) are really used
- RCODEs
- ...
- QDCOUNT
- Always 1!
- Query
- QNAME Sequence of labels
+-+-+-+-+-+-+-+-+
|type| length |
+-+-+-+-+-+-+-+-+
/ label / - QTYPE (2 bytes)
- QCLASS (2 bytes) ← almost always IN (1)
- QNAME Sequence of labels
- ANCOUNT
- Answer section
- answers
- NSCOUNT
- Authority section
- Referral information NS records
- May contain SOA & NS for
NXDOMAIN&NODATA
- ARCOUNT
- Additional section
- Glue, TSIG, header extension (EDNS0 ← OPT Pseudo record)
- NAME = sequence of labels
0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
| type | length |
+--+--+--+--+--+--+--+--+
/ label / - www.os3.nl. on the wire:
3, “www”, 3, “os3”, 2, “nl”, 0
03 77 77 77 03 6f 73 33 02 6e 6c 00 - cx dx ex fx = Compressed label
c00c refers back to QNAME
Extension Mechanism ( EDNS(0) )
OPT RR for general extensions
Fixed part and variable set expressed as {attr, value} pairs
Fixed part looks like so:
%20Inter-Networking%20and%20Routing/Attachments/Pasted%20image%2020250923113520.png)
Before OPT was defined, the max response size was 512 bytes
The Issue
Flag day 2019: many authoritative name servers were still using old software that did not support EDNS
Requests containing EDNS were just ignored
So resolvers have to fuck around and find out if a name server supports EDNS
To stop this, EDNS got put into the standard
If your server does not support it, the resolver will simply not use it
Issue #2
Fragmentation was an issue
The UDP response could get fragmented
Firewalls did not like this
With IPv4, routers in the middle would fragment, with IPv6 the endpoints have to do it
However, name servers cannot do Path Maximum Transfer Unit Discovery (PMTU Black Holes) as they do not have state
If too big, it returns a Packet Too Big (PTB) ICMP message
However, since the server has no state, it does not know the original query and cannot re-send it
Max UDP payload size was set to 1232, so we do not need PMTU
Simple DNS infra
When a zone transfer fails repeatedly, and the expiration time runs out, the secondary will stop serving the zone and respond with SERVFAIL
This is good, since it will force resolvers to try other servers
With tiered zone transfer, the amount of time that non-fresh data keeps being served adds up
Solution: EDNS EXPIRE option
Primary zone sets expiration timer, and this gets sent down through all zone transfers
DNS Cookies
DoS on DNS is easy
After first request, set a cookie, add this to next queries
When present, allow large and often queries
Otherwise, small answers and rate limit