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:
Relevant for authoritative servers:
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:
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:
RFC 7871 is a concise specification that is completely applicable to 2018 DNS. Its implementation is highly recommended.
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.
Zone
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.
...