Skip to main content

Extension Mechanisms for DNS (EDNS0)

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.

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.
   Full list can be viewed from here.
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 txt

You can specify DNS resolver also by using below command –
          $dig +short txt @resolver-address

The output should look something like this –
" sent EDNS buffer size 4096"
" 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

For more detail about EDNS packet size testing, visit

Popular posts from this blog

Availability of 5 GHz WLAN Channels in India under unlicensed band

Availability of 5 GHz WLAN Channels in India under unlicensed band  In India, Wireless Planning and Coordination Wing of Department of Telecom, under Ministry of Communication takes care of licensing of radio frequencies.  In the latest National Frequency allocation plan 2018 (, Government of India (GoI), exempted the licensing requirements of the following radio frequency ranges for wireless usage and a gazette notification has also published for this (  -- 1.  5150-5250 2. 5250-5350 3. 5470-5725 4. 5725-5875 References

Identity PSK ( iPSK)

With the evolution of IoT (Internet of Things), devices that connect wirelessly have increased many folds. From webcams, Smartwatches, fitness bands, firestick, Alexa, Google Home, and many more.., everything is going wireless for connectivity and so does the security threat. The main concern with IoT devices is the unavailability of the full wireless protocol stack (and in the majority of devices, support of 802.1x is not available). So, previously we only have the WPA-PSK option for connecting the IoT devices.  In WPA*-PSK (WPA or WPA2) WLAN, a Pre-Shared Key (PSK) is configured and distributed to all the clients that connect to the WLAN. This leads to PSK leakage, and it can be accessible to unauthorized users (due to the nature of common PSK across all the devices).  Therefore, there was a need to provision unique PSK or Multiple PSK per SSID. Identity-PSKs are unique pre-shared keys created for clients/groups on the same WLAN. Features of iPSK:-   1.Unique PSK for individual Cli

Summary report of APNIC 55 (APRICOT 2023) Meeting held in Manila, Philippines

APNIC Logo The APNIC 55 meeting was held in Manila, Philippines from 20th Feb to 02nd March 2023. The meeting was hosted by PhNOG, The Philippine Network Operators Group (PhNOG) and supported by DOST- Advanced Science and Technology Institute. Every year, APNIC conferences are held twice, the first of each year is held in conjunction with APRICOT and the second one is a standalone conference. The last such meeting held in India was in 2012, APNIC 33 (which was in conjunction with APRICOT 2012).  APNIC 55 meeting was unique in multiple senses –  i. Firstly, because of the possibility of potential hijack [1] [2][3] of the APNIC Executive Council by Cloud Innovation Ltd. / Larus foundation / NRS, the same organizations which have dragged AFRINIC (RIR for African Continent) into the Mauritius supreme court and at one point nearly halted the AFRINIC operations by getting its bank accounts frozen (over 25 lawsuits have been filed against AFRINIC by Cloud Innovation Ltd.). Number