DNS Background
The Domain Name
System Protocol was first designed in 1980s and after that various features has
been added while maintaining the compatibility with earlier versions of the
protocol.
DNS Packet was restricted
to UDP 512 bytes in the early releases while keeping in mind the minimum MTU size
is of 576 bytes in IPv4. This has been done to check the issues of packet drops,
fragmentation and others.
This packet size
limit of 512 bytes also led to limit the number of root servers to 13 (A to M).
In 1999, Paul Vixie
proposed extending DNS to allow new flags and Response Codes, and to provide
support for longer responses which should also be backward compatible with
previous implementation.
Mechanism
Due
to limitation of space in DNS header, no new flags can be added in it. EDNS add
information to DNS message in the form of pseudo-RRs included in the
‘additional data’ section of DNS message. This section exist both in Request
and Response.
The
pseudo-RR introduce for this are of type OPT.
As
pseudo-RRs, OPT type RRs never appear in any zone file; they exist only in
messages, fabricated by the DNS participants.
The
mechanism is backward compatible, because older DNS responders ignore any RR of
the unknown OPT type in a request and a newer DNS responder never includes an
OPT in a response unless there was one in the request. The presence of the OPT
in the request signifies a newer requester that knows what to do with an OPT in
the response.
The OPT pseudo-record provides space for up to
16 flags and it extends the space for the response code. The overall size of
the UDP packet and the version number (at present 0) are contained in the OPT
record. A variable length data field allows further information to be registered
in future versions of the protocol. The original DNS protocol provided two
label types, which are defined by the first two bits in DNS packets: 00
(standard label) and 11 (compressed label). EDNS introduces the label type 01
as extended label. The lower 6 bits of the first byte may be used
to define up to 63 new extended labels.
Requirement of EDNS
EDNS is
essential for the implementation of DNSSEC.
DNS Header
ID – 16 bit field
QR – A 1 bit field that specifies
whether this message is a query (0), or a response (1).
Opcode -- A four bit field that specifies
kind of query in this message.
AA -- Authoritative Answer
TC -- Truncation - Specifies that this
message was truncated.
RD – Recursion Desired
RA – Recursion Available
Z – Reserved for future use
RCODE – Response Code – 4 bit field. After
implementation of EDNS, RCODE list has been extended and 4 additional bytes has
been added which has been placed in Additional Information Section. This led to
extend the value of Response Code from 16 to 65535. The value have the
following meaning
0 – No Error Condition
1 -- Format error - The name server was unable to interpret the query.
2 -- Server failure - The name server was unable to process this query due to a problem with the name server.
3 - Name Error - Meaningful only for responses from an authoritative name server, this code signifies that the domain name referenced in the query does not exist.
4 - Not Implemented - The name server does not support the requested kind of query.
5 -Refused - The name server refuses to perform the specified operation for policy
reasons.
QDCOUNT – 16 bit field. Specifies number of entries in the question
section.
ANCOUNT – 16 bit field. Specifies number of
resource records in the answer section. 65535 different Resource records are
possible.
For EDNS, OPT pseudo-RR
is used whose RR type is 41.
An OPT record does not carry any DNS data. It is used only to contain control information pertaining to the question-and-answer sequence of a specific transaction. OPT RRs MUST NOT be cached, forwarded, or stored in or loaded from master files.
The OPT RR MAY be placed anywhere within the additional data section. When an OPT RR is included within any DNS message, it MUST be the only OPT RR in that message. If a query message with more than one OPT RR is received, a FORMERR (RCODE=1) MUST be returned.
NSCOUNT – 16 bit field. Specifies number of
Name Server Resource Record in the authority record section.
ARCOUNT – 16 bit field. Specifies number of
RRs in the additional record section.
EDNS Support in Resolvers
Now question arises how
you will check whether your resolver/caching dns server supports larger dns
packets or not?
By default
implementation of various firewalls block DNS packet of size larger than 512
bytes (Cisco ASA blocks such packets).
To check EDNS implementation
support in your resolver, use below mentioned dig command –
$
dig +short rs.dns-oarc.net txt
You can specify DNS
resolver also by using below command –
$dig
+short rs.dns-oarc.net txt @resolver-address
The output should look
something like this –
rst.x4001.rs.dns-oarc.net.
rst.x3985.x4001.rs.dns-oarc.net.
rst.x4023.x3985.x4001.rs.dns-oarc.net.
"192.168.1.1 sent
EDNS buffer size 4096"
"192.168.1.1 DNS
reply size limit is at least 4023 bytes"
To check EDNS packet
sixe support by nslookup utility, use following command –
cmd> nslookup
–type=TXT rs.dns-oarc.net.
For more detail about EDNS
packet size testing, visit
https://www.dns-oarc.net/oarc/services/replysizetest/