You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
EDNS, Dynamic Updates, TSIG, DNAME, DNS Cookies & more
So far we've focussed on the simplest possible form of DNS that is
interoperable with today's internet. Over the past 3 decades however, a lot
has been added to DNS.
Items relevant for authoritative servers and resolvers:
EDNS: Extra fields carried in the additional section of a DNS message,
including arbitrary options. The main use of EDNS today is specifying a
larger supported UDP packet size, indicating DNSSEC support and carrying
Client Subnet information. Defined in RFC
6891.
EDNS Client Subnet: Convey (part) of client addresses to authoritative
resolvers. Defined in RFC 7871.
DNS Cookies: Lightweight transaction security mechanism RFC 7873
Relevant for authoritative servers:
Dynamic Updates: Transmitting changes to zones to master servers. Mostly
used by DHCP servers to publish names of hosts. Defined in RFC
2136
TSIG: Secret Key Transaction Authentication for DNS. A way to sign DNS
messages or a list of DNS messages with a secret key. Used to authenticate
AXFR requests and to guarantee zone integrity during AXFR. Defined in
RFC 2845.
Extended DNS (EDNS or EDNS(0))
EDNS is very much an enabling technology and it can't really be regarded as
optional anymore. It enables DNSSEC, DNS Cookies, EDNS Client Subnet as
well as larger UDP packets. It also expands on the 4-bit RCODE field of
un-extended DNS.
The EDNS content is attached to a pseudo-record called OPT in the additional
section of a message and an answer.
The following EDNS fields are always present:
Requestor's maximum UDP payload size
Extended RCODE (an additional 8 bits)
EDNS Version
DNSSEC OK bit (which indicates DNSSEC support from the requestor)
Yet another field called 'Z' which must be zero
In order to save size, the EDNS 'OPT' pseudo-record reuses existing resource
record fields to store its data. For example, the UDP payload size is stored
in the 16 bit class field, and the extended RCODE, version and flags hang
out in the TTL field.
Just like regular record types, the OPT pseudo-record can carry a payload.
This consists of 0 or more 'Type Length Value' tuples. The following types
are currently in common use, or will soon be:
NSID (3): Return the 'nameserver identifier' RFC
5001
EDNS Client Subnet (8): Convey part of client subnet RFC 6891.
RFC 7871 is a concise specification
that is completely applicable to 2018 DNS. Its implementation is highly
recommended.
Dynamic Updates (DNS UPDATE)
Defined in RFC 2136, DNS UPDATE is a
somewhat underused extension that allows a client to request an authoritative
server add or remove RR or RRSETs in a zone. While primarily useful for
allowing distributed management of a zone, a side benefit for authoritative
server implementors is effectively free support for new RR types as the burden
of supporting new types shifts to the client.
Dynamic Update access is generally limited by some combination of client IP
address, RR name and/or type, or message signature such as TSIG or more rarely
SIG(0). For example, on a trusted network clients may be allowed to update a
reverse entry based on their IP address. Over the internet controls using
stronger authentication like TSIG or SIG(0) should be employed.
On the wire DNS UPDATE uses the standard DNS message format with some
repurposing of the message body. Messages begin with a standard header
with the OPCODE set to UPDATE (5). The question section is repurposed to
specify the zone to update, answers becomes prerequisites, and the authority
section holds the updates themselves.
A question (name, type and class) of type SOA is used to specify the (single)
target zone's name and class.
Prerequisites
Prerequisites are constraints that must pass before any updates are processed.
All of the constraints apply to entire RRSETs as opposed to individual RRs.
Prerequisite failures are signalled by a response message's RCODE.
Prerequiste
Type
Class
Data
Failure RCODE
RRSET exists
RRSET's Type
ANY (255)
No
NXRRSET (8)
RRSET exists with data
RRSET's Type
RRSET's Class
Yes
NXRRSET (8)
RRSET does not exist
RRSET's Type
NONE (254)
No
YXRRSET (7)
Name is in use
ANY (255)
ANY (255)
No
NXDOMAIN (3)
Name is not in use
ANY (255)
NONE (254)
No
YXDOMAIN (6)
TTLs are not used in prerequisites and must be set to zero. Prerequisites without
data must include the RDLEN field set to zero.
Updates
Change
Type
Class
Data
Add an RR to an RRSET
RRSET Type
Zone's Class
Yes
Delete an RRSET
RRSET Type
ANY (255)
No
Delete all RRSETs at a name
ANY (255)
ANY (255)
No
Delete an RR from an RRSET
RRSET Type
NONE (254)
Yes
With the exception of adding an RR, TTLs are not used and must be set to zero.
Should adding an RR cause duplicate data, or should a type be a singleton type
the server will silently deduplicate the data. If a delete refers to something
that doesn't exist the server will silently ignore the change. As with
prerequisites changes that don't reference data must still include the RDLEN
field.