--- 1/draft-ietf-dnsop-no-response-issue-15.txt 2020-03-08 22:13:13.675966939 -0700 +++ 2/draft-ietf-dnsop-no-response-issue-16.txt 2020-03-08 22:13:13.731968362 -0700 @@ -1,18 +1,18 @@ Network Working Group M. Andrews Internet-Draft R. Bellis Intended status: Best Current Practice ISC Expires: September 9, 2020 March 8, 2020 A Common Operational Problem in DNS Servers - Failure To Communicate. - draft-ietf-dnsop-no-response-issue-15 + draft-ietf-dnsop-no-response-issue-16 Abstract The DNS is a query / response protocol. Failing to respond to queries, or responding incorrectly, causes both immediate operational problems and long term problems with protocol development. This document identifies a number of common kinds of queries to which some servers either fail to respond or else respond incorrectly. This document also suggests procedures for zone operators to apply to @@ -73,39 +73,39 @@ 3.2.6. DO=1 Handling . . . . . . . . . . . . . . . . . . . . 8 3.2.7. EDNS over TCP . . . . . . . . . . . . . . . . . . . . 8 4. Firewalls and Load Balancers . . . . . . . . . . . . . . . . 8 5. Scrubbing Services . . . . . . . . . . . . . . . . . . . . . 9 6. Whole Answer Caches . . . . . . . . . . . . . . . . . . . . . 10 7. Response Code Selection . . . . . . . . . . . . . . . . . . . 10 8. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Testing - Basic DNS . . . . . . . . . . . . . . . . . . . 11 8.1.1. Is The Server Configured For The Zone? . . . . . . . 11 8.1.2. Testing Unknown Types . . . . . . . . . . . . . . . . 12 - 8.1.3. Testing Header Bits . . . . . . . . . . . . . . . . . 12 - 8.1.4. Testing Unknown Opcodes . . . . . . . . . . . . . . . 14 + 8.1.3. Testing Header Bits . . . . . . . . . . . . . . . . . 13 + 8.1.4. Testing Unknown Opcodes . . . . . . . . . . . . . . . 15 8.1.5. Testing TCP . . . . . . . . . . . . . . . . . . . . . 15 - 8.2. Testing - Extended DNS . . . . . . . . . . . . . . . . . 15 + 8.2. Testing - Extended DNS . . . . . . . . . . . . . . . . . 16 8.2.1. Testing Minimal EDNS . . . . . . . . . . . . . . . . 16 - 8.2.2. Testing EDNS Version Negotiation . . . . . . . . . . 16 + 8.2.2. Testing EDNS Version Negotiation . . . . . . . . . . 17 8.2.3. Testing Unknown EDNS Options . . . . . . . . . . . . 17 8.2.4. Testing Unknown EDNS Flags . . . . . . . . . . . . . 18 8.2.5. Testing EDNS Version Negotiation With Unknown EDNS Flags . . . . . . . . . . . . . . . . . . . . . . . . 18 8.2.6. Testing EDNS Version Negotiation With Unknown EDNS Options . . . . . . . . . . . . . . . . . . . . . . . 19 8.2.7. Testing Truncated Responses . . . . . . . . . . . . . 20 8.2.8. Testing DO=1 Handling . . . . . . . . . . . . . . . . 20 8.2.9. Testing EDNS Version Negotiation With DO=1 . . . . . 21 - 8.2.10. Testing With Multiple Defined EDNS Options . . . . . 21 + 8.2.10. Testing With Multiple Defined EDNS Options . . . . . 22 8.3. When EDNS Is Not Supported . . . . . . . . . . . . . . . 22 9. Remediation . . . . . . . . . . . . . . . . . . . . . . . . . 22 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . 24 12.2. Informative References . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction The DNS [RFC1034], [RFC1035] is a query / response protocol. Failing to respond to queries, or responding incorrectly, causes both @@ -224,34 +224,40 @@ If a zone is delegated to a server, that server should respond to an SOA query for that zone with an SOA record. Failing to respond at all is always incorrect, regardless of the configuration of the server. Responding with anything other than an SOA record in the Answer section indicates a bad delegation. 3.1.2. Unknown / Unsupported Type Queries Some servers fail to respond to unknown or unsupported types. If a - server receives a query for a type that it doesn't recognize, or + server receives a query for a type that it doesn't recognise, or doesn't implement, it is expected to return the appropriate response - as if it did recognize the type but does not have any data for that + as if it did recognise the type but does not have any data for that type: either NOERROR, or NXDOMAIN. The exception to this are queries for Meta-RR types which may return NOTIMP. 3.1.3. DNS Flags Some servers fail to respond to DNS queries with various DNS flags set, regardless of whether they are defined or still reserved. At the time of writing there are servers that fail to respond to queries with the AD bit set to 1 and servers that fail to respond to queries with the last reserved flag bit set. + Servers should respond to such queries. If the server does not know + the meaning of a flag bit it must not copy it to the response + [RFC1035] Section 4.1.1. If the server does not understand the + meaning of a request it should reply with a FORMERR response with + unknown flags set to zero. + 3.1.3.1. Recursive Queries A non-recursive server is supposed to respond to recursive queries as if the RD bit is not set [RFC1034]. 3.1.4. Unknown DNS opcodes The use of previously undefined opcodes is to be expected. Since the DNS was first defined two new opcodes have been added, UPDATE and NOTIFY. @@ -264,26 +270,20 @@ 3.1.5. TCP Queries All DNS servers are supposed to respond to queries over TCP [RFC7766]. While firewalls should not block TCP connection attempts if they do they should cleanly terminate the connection by sending TCP RESET or sending ICMP/ICMPv6 Administratively Prohibited messages. Dropping TCP connections introduces excessive delays to the resolution process. - Whether a server accepts TCP connections can be tested by first - checking that it responds to UDP queries to confirm that it is up and - operating, then attempting the same query over TCP. An additional - query should be made over UDP if the TCP connection attempt fails to - confirm that the server under test is still operating. - 3.2. EDNS Queries EDNS queries are specified in [RFC6891]. 3.2.1. EDNS Queries - Version Independent Identifying servers that fail to respond to EDNS queries can be done by first confirming that the server responds to regular DNS queries, followed by a series of otherwise identical queries using EDNS, then making the original query again. A series of EDNS queries is needed @@ -304,55 +304,65 @@ 3.2.2. EDNS Queries - Version Specific Some servers respond correctly to EDNS version 0 queries but fail to respond to EDNS queries with version numbers that are higher than zero. Servers should respond with BADVERS to EDNS queries with version numbers that they do not support. Some servers respond correctly to EDNS version 0 queries but fail to set QR=1 when responding to EDNS versions they do not support. Such - answers are discarded or treated as requests. + answers responses may be discarded as invalid (as QR is not 1) or + treated as requests (when the source port of the original request was + port 53). 3.2.3. EDNS Options Some servers fail to respond to EDNS queries with EDNS options set. - Unknown EDNS options are supposed to be ignored by the server - [RFC6891], the original EDNS specification left this behaviour - undefined [RFC2671]. + The original EDNS specification left this behaviour undefined + [RFC2671], but the correct behaviour was clarified in [RFC6891]. + Unknown EDNS options are supposed to be ignored by the server. 3.2.4. EDNS Flags Some servers fail to respond to EDNS queries with EDNS flags set. Servers should ignore EDNS flags they do not understand and must not add them to the response [RFC6891]. 3.2.5. Truncated EDNS Responses Some EDNS aware servers fail to include an OPT record when a truncated response is sent. An OPT record is supposed to be included in a truncated response [RFC6891]. - Some EDNS aware server fail to honour the advertised EDNS buffer size - and send over-sized responses [RFC6891]. + Some EDNS aware servers fail to honour the advertised EDNS UDP buffer + size and send over-sized responses [RFC6891]. Servers must send UDP + responses no larger than the advertised EDNS UDP buffer size. 3.2.6. DO=1 Handling Some nameservers incorrectly only return an EDNS response when the DO - bit [RFC3225] is 1 in the query. Additionally some nameservers fail - to copy the DO bit to the response despite clearly supporting DNSSEC - by returning an RRSIG records to EDNS queries with DO=1. + bit [RFC3225] is 1 in the query. Servers that support EDNS should + always respond to EDNS requests with EDNS responses. + + Some nameservers fail to copy the DO bit to the response despite + clearly supporting DNSSEC by returning an RRSIG records to EDNS + queries with DO=1. 3.2.7. EDNS over TCP Some EDNS aware servers incorrectly limit the TCP response sizes to - the advertised UDP response size. + the advertised UDP response size. This breaks DNS resolution to + clients where the response sizes exceed the advertised UDP response + size despite the server and the client being capable of sending and + receiving larger TCP responses respectively. It effectively defeats + setting TC=1 in UDP responses. 4. Firewalls and Load Balancers Firewalls and load balancers can affect the externally visible behaviour of a nameserver. Tests for conformance should to be done from outside of any firewall so that the system is tested as a whole. Firewalls and load balancers should not drop DNS packets that they don't understand. They should either pass the packets or generate an appropriate error response. @@ -430,23 +440,26 @@ exhaustive set of attributes that must be considered include: RD, AD, CD, OPT record, DO, EDNS buffer size, EDNS version, EDNS options, and transport. 7. Response Code Selection Choosing the correct response code when responding to DNS queries is important. Response codes should be chosen considering how clients will handle them. - For unimplemented opcodes NOTIMP is the expected response code. For - example, a new opcode could change the message format by extending - the header or changing the structure of the records etc. + For unimplemented opcodes NOTIMP is the expected response code. + Note: Newly implemented opcodes may change the message format by + extending the header, changing the structure of the records, etc. + Servers are not expected to be able to parse these, and should + respond with a response code of NOTIMP rather than FORMERR (which + would be expected if there was a parse error with an known opcode). For unimplemented type codes, and in the absence of other errors, the only valid response is NoError if the qname exists, and NameError (NXDOMAIN) otherwise. For Meta-RRs NOTIMP may be returned instead. If a zone cannot be loaded because it contains unimplemented type codes that are not encoded as unknown record types according to [RFC3597] then the expected response is SERVFAIL as the whole zone should be rejected Section 5.2 [RFC1035]. If a zone loads then Section 4.3.2 [RFC1034] applies. @@ -487,23 +500,23 @@ This first set of tests cover basic DNS server behaviour and all servers should pass these tests. 8.1.1. Is The Server Configured For The Zone? Ask for the SOA record of the configured zone. This query is made with no DNS flag bits set and without EDNS. We expect the SOA record for the zone to be returned in the answer - section with the rcode set to NOERROR and the AA and QR bits to be - set in the response; RA may also be set [RFC1034]. We do not expect - an OPT record to be returned [RFC6891]. + section, the rcode to be set to NOERROR, and the AA and QR bits to be + set in the header; RA may also be set [RFC1034]. We do not expect an + OPT record to be returned [RFC6891]. Verify the server is configured for the zone: dig +noedns +noad +norec soa $zone @$server expect: status: NOERROR expect: the SOA record to be present in the answer section expect: flag: aa to be present expect: flag: rd to NOT be present expect: flag: ad to NOT be present @@ -522,24 +535,24 @@ faulty. The test should be repeated a number of times to eliminate the likelihood of a false positive due to packet loss. Ask for the TYPE1000 RRset at the configured zone's name. This query is made with no DNS flag bits set and without EDNS. TYPE1000 has been chosen for this purpose as IANA is unlikely to allocate this type in the near future and it is not in a range reserved for private use [RFC6895]. Any unallocated type code could be chosen for this test. - We expect no records to be returned in the answer section with the - rcode set to NOERROR and the AA and QR bits to be set in the - response; RA may also be set [RFC1034]. We do not expect an OPT - record to be returned [RFC6891]. + We expect no records to be returned in the answer section, the rcode + to be set to NOERROR, and the AA and QR bits to be set in the header; + RA may also be set [RFC1034]. We do not expect an OPT record to be + returned [RFC6891]. Check that queries for an unknown type work: dig +noedns +noad +norec type1000 $zone @$server expect: status: NOERROR expect: an empty answer section. expect: flag: aa to be present expect: flag: rd to NOT be present expect: flag: ad to NOT be present @@ -547,22 +560,22 @@ 8.1.3. Testing Header Bits 8.1.3.1. Testing CD=1 Queries Ask for the SOA record of the configured zone. This query is made with only the CD DNS flag bit set, all other DNS bits clear, and without EDNS. We expect the SOA record for the zone to be returned in the answer - section with the rcode set to NOERROR and the AA and QR bits to be - set in the response. We do not expect an OPT record to be returned. + section, the rcode to be set to NOERROR, and the AA and QR bits to be + set in the header. We do not expect an OPT record to be returned. If the server supports DNSSEC, CD should be set in the response [RFC4035] otherwise CD should be clear [RFC1034]. Check that queries with CD=1 work: dig +noedns +noad +norec +cd soa $zone @$server expect: status: NOERROR expect: the SOA record to be present in the answer section @@ -571,22 +584,22 @@ expect: flag: ad to NOT be present expect: the OPT record to NOT be present 8.1.3.2. Testing AD=1 Queries Ask for the SOA record of the configured zone. This query is made with only the AD DNS flag bit set and all other DNS bits clear and without EDNS. We expect the SOA record for the zone to be returned in the answer - section with the rcode set to NOERROR and the AA and QR bits to be - set in the response. We do not expect an OPT record to be returned. + section, the rcode to be set to NOERROR, and the AA and QR bits to be + set in the header. We do not expect an OPT record to be returned. The purpose of this query is to detect blocking of queries with the AD bit present, not the specific value of AD in the response. Check that queries with AD=1 work: dig +noedns +norec +ad soa $zone @$server expect: status: NOERROR expect: the SOA record to be present in the answer section expect: flag: aa to be present @@ -595,23 +608,23 @@ AD use in queries is defined in [RFC6840]. 8.1.3.3. Testing Reserved Bit Ask for the SOA record of the configured zone. This query is made with only the final reserved DNS flag bit set and all other DNS bits clear and without EDNS. We expect the SOA record for the zone to be returned in the answer - section with the rcode set to NOERROR and the AA and QR bits to be - set in the response; RA may be set. The final reserved bit must not - be set [RFC1034]. We do not expect an OPT record to be returned + section, the rcode to be set to NOERROR, and the AA and QR bits to be + set in the header; RA may be set. The final reserved bit must not be + set [RFC1034]. We do not expect an OPT record to be returned [RFC6891]. Check that queries with the last unassigned DNS header flag work and that the flag bit is not copied to the response: dig +noedns +noad +norec +zflag soa $zone @$server expect: status: NOERROR expect: the SOA record to be present in the answer section expect: MBZ to NOT be in the response (see below) @@ -623,22 +636,22 @@ MBZ (Must Be Zero) is a dig-specific indication that the flag bit has been incorrectly copied. See Section 4.1.1, [RFC1035] "Z Reserved for future use. Must be zero in all queries and responses." 8.1.3.4. Testing Recursive Queries Ask for the SOA record of the configured zone. This query is made with only the RD DNS flag bit set and without EDNS. We expect the SOA record for the zone to be returned in the answer - section with the rcode set to NOERROR and the AA, QR and RD bits to - be set in the response; RA may also be set [RFC1034]. We do not + section, the rcode to be set to NOERROR, and the AA, QR and RD bits + to be set in the header; RA may also be set [RFC1034]. We do not expect an OPT record to be returned [RFC6891]. Check that recursive queries work: dig +noedns +noad +rec soa $zone @$server expect: status: NOERROR expect: the SOA record to be present in the answer section expect: flag: aa to be present expect: flag: rd to be present @@ -658,28 +671,34 @@ expect: status: NOTIMP expect: opcode: 15 expect: all sections to be empty expect: flag: aa to NOT be present expect: flag: rd to NOT be present expect: flag: ad to NOT be present expect: the OPT record to NOT be present 8.1.5. Testing TCP + Whether a server accepts TCP connections can be tested by first + checking that it responds to UDP queries to confirm that it is up and + operating, then attempting the same query over TCP. An additional + query should be made over UDP if the TCP connection attempt fails to + confirm that the server under test is still operating. + Ask for the SOA record of the configured zone. This query is made with no DNS flag bits set and without EDNS. This query is to be sent using TCP. We expect the SOA record for the zone to be returned in the answer - section with the rcode set to NOERROR and the AA and QR bits to be - set in the response; RA may also be set [RFC1034]. We do not expect - an OPT record to be returned [RFC6891]. + section, the rcode to be set to NOERROR, and the AA and QR bits to be + set in the header; RA may also be set [RFC1034]. We do not expect an + OPT record to be returned [RFC6891]. Check that TCP queries work: dig +noedns +noad +norec +tcp soa $zone @$server expect: status: NOERROR expect: the SOA record to be present in the answer section expect: flag: aa to be present expect: flag: rd to NOT be present expect: flag: ad to NOT be present @@ -695,22 +714,22 @@ but fail to handle plain EDNS queries correctly so a plain EDNS query is not a good indicator of lack of EDNS support. 8.2.1. Testing Minimal EDNS Ask for the SOA record of the configured zone. This query is made with no DNS flag bits set. EDNS version 0 is used without any EDNS options or EDNS flags set. We expect the SOA record for the zone to be returned in the answer - section with the rcode set to NOERROR and the AA and QR bits to be - set in the response; RA may also be set [RFC1034]. We expect an OPT + section, the rcode to be set to NOERROR, and the AA and QR bits to be + set in the header; RA may also be set [RFC1034]. We expect an OPT record to be returned. There should be no EDNS flags present in the response. The EDNS version field should be 0 and there should be no EDNS options present [RFC6891]. Check that plain EDNS queries work: dig +nocookie +edns=0 +noad +norec soa $zone @$server expect: status: NOERROR expect: the SOA record to be present in the answer section @@ -723,24 +742,24 @@ enabled by default in BIND 9.11.0 (and later). 8.2.2. Testing EDNS Version Negotiation Ask for the SOA record of a zone the server is nominally configured to serve. This query is made with no DNS flag bits set. EDNS version 1 is used without any EDNS options or EDNS flags set. We expect the SOA record for the zone to NOT be returned in the answer section with the extended rcode set to BADVERS and the QR bit - to be set in the response; RA may also be set [RFC1034]. We expect - an OPT record to be returned. There should be no EDNS flags present - in the response. The EDNS version field should be 0 in the response - as no other EDNS version has as yet been specified [RFC6891]. + to be set in the header; RA may also be set [RFC1034]. We expect an + OPT record to be returned. There should be no EDNS flags present in + the response. The EDNS version field should be 0 in the response as + no other EDNS version has as yet been specified [RFC6891]. Check that EDNS version 1 queries work (EDNS supported): dig +nocookie +edns=1 +noednsneg +noad +norec soa $zone @$server expect: status: BADVERS expect: the SOA record to NOT be present in the answer section expect: an OPT record to be present in the additional section expect: EDNS Version 0 in response expect: flag: aa to NOT be present @@ -752,22 +771,22 @@ 8.2.3. Testing Unknown EDNS Options Ask for the SOA record of the configured zone. This query is made with no DNS flag bits set. EDNS version 0 is used without any EDNS flags. An EDNS option is present with a value that has not yet been assigned by IANA. We have picked an unassigned code of 100 for the example below. Any unassigned EDNS option code could have been choosen for this test. We expect the SOA record for the zone to be returned in the answer - section with the rcode set to NOERROR and the AA and QR bits to be - set in the response; RA may also be set [RFC1034]. We expect an OPT + section, the rcode to be set to NOERROR, and the AA and QR bits to be + set in the header; RA may also be set [RFC1034]. We expect an OPT record to be returned. There should be no EDNS flags present in the response. The EDNS version field should be 0 as EDNS versions other than 0 are yet to be specified and there should be no EDNS options present as unknown EDNS options are supposed to be ignored by the server [RFC6891] Section 6.1.2. Check that EDNS queries with an unknown option work (EDNS supported): dig +nocookie +edns=0 +noad +norec +ednsopt=100 soa $zone @$server @@ -779,22 +798,22 @@ expect: flag: aa to be present expect: flag: ad to NOT be present 8.2.4. Testing Unknown EDNS Flags Ask for the SOA record of the configured zone. This query is made with no DNS flag bits set. EDNS version 0 is used without any EDNS options. An unassigned EDNS flag bit is set (0x40 in this case). We expect the SOA record for the zone to be returned in the answer - section with the rcode set to NOERROR and the AA and QR bits to be - set in the response; RA may also be set [RFC1034]. We expect an OPT + section, the rcode to be set to NOERROR, and the AA and QR bits to be + set in the header; RA may also be set [RFC1034]. We expect an OPT record to be returned. There should be no EDNS flags present in the response as unknown EDNS flags are supposed to be ignored. The EDNS version field should be 0 and there should be no EDNS options present [RFC6891]. Check that EDNS queries with unknown flags work (EDNS supported): dig +nocookie +edns=0 +noad +norec +ednsflags=0x40 soa $zone @$server expect: status: NOERROR @@ -809,25 +828,25 @@ been incorrectly copied as per Section 6.1.4, [RFC6891]. 8.2.5. Testing EDNS Version Negotiation With Unknown EDNS Flags Ask for the SOA record of the configured zone. This query is made with no DNS flag bits set. EDNS version 1 is used without any EDNS options. An unassigned EDNS flag bit is set (0x40 in this case). We expect the SOA record for the zone to NOT be returned in the answer section with the extended rcode set to BADVERS and the QR bit - to be set in the response; RA may also be set [RFC1034]. We expect - an OPT record to be returned. There should be no EDNS flags present - in the response as unknown EDNS flags are supposed to be ignored. - The EDNS version field should be 0 as EDNS versions other than 0 are - yet to be specified and there should be no EDNS options present + to be set in the header; RA may also be set [RFC1034]. We expect an + OPT record to be returned. There should be no EDNS flags present in + the response as unknown EDNS flags are supposed to be ignored. The + EDNS version field should be 0 as EDNS versions other than 0 are yet + to be specified and there should be no EDNS options present [RFC6891]. Check that EDNS version 1 queries with unknown flags work (EDNS supported): dig +nocookie +edns=1 +noednsneg +noad +norec +ednsflags=0x40 soa \ $zone @$server expect: status: BADVERS expect: SOA record to NOT be present @@ -840,23 +859,23 @@ 8.2.6. Testing EDNS Version Negotiation With Unknown EDNS Options Ask for the SOA record of the configured zone. This query is made with no DNS flag bits set. EDNS version 1 is used. An unknown EDNS option is present. We have picked an unassigned code of 100 for the example below. Any unassigned EDNS option code could have been chosen for this test. We expect the SOA record for the zone to NOT be returned in the answer section with the extended rcode set to BADVERS and the QR bit - to be set in the response; RA may also be set [RFC1034]. We expect - an OPT record to be returned. There should be no EDNS flags present - in the response. The EDNS version field should be 0 as EDNS versions + to be set in the header; RA may also be set [RFC1034]. We expect an + OPT record to be returned. There should be no EDNS flags present in + the response. The EDNS version field should be 0 as EDNS versions other than 0 are yet to be specified and there should be no EDNS options present [RFC6891]. Check that EDNS version 1 queries with unknown options work (EDNS supported): dig +nocookie +edns=1 +noednsneg +noad +norec +ednsopt=100 soa \ $zone @$server expect: status: BADVERS @@ -870,44 +889,44 @@ 8.2.7. Testing Truncated Responses Ask for the DNSKEY records of the configured zone, which must be a DNSSEC signed zone. This query is made with no DNS flag bits set. EDNS version 0 is used without any EDNS options. The only EDNS flag set is DO. The EDNS UDP buffer size is set to 512. The intention of this query is to elicit a truncated response from the server. Most signed DNSKEY responses are bigger than 512 bytes. This test will not give a valid result if the zone is not signed. - We expect a response with the rcode set to NOERROR and the AA and QR - bits to be set, AD may be set in the response if the server supports - DNSSEC otherwise it should be clear; TC and RA may also be set - [RFC1035] [RFC4035]. We expect an OPT record to be present in the - response. There should be no EDNS flags other than DO present in the - response. The EDNS version field should be 0 and there should be no - EDNS options present [RFC6891]. + We expect a response, the rcode to be set to NOERROR, and the AA and + QR bits to be set, AD may be set in the response if the server + supports DNSSEC otherwise it should be clear; TC and RA may also be + set [RFC1035] [RFC4035]. We expect an OPT record to be present in + the response. There should be no EDNS flags other than DO present in + the response. The EDNS version field should be 0 and there should be + no EDNS options present [RFC6891]. If TC is not set it is not possible to confirm that the server correctly adds the OPT record to the truncated responses or not. dig +norec +dnssec +bufsize=512 +ignore dnskey $zone @$server expect: NOERROR expect: OPT record with version set to 0 8.2.8. Testing DO=1 Handling Ask for the SOA record of the configured zone, which does not need to be DNSSEC signed. This query is made with no DNS flag bits set. EDNS version 0 is used without any EDNS options. The only EDNS flag set is DO. We expect the SOA record for the zone to be returned in the answer - section with the rcode set to NOERROR and the AA and QR bits to be + section, the rcode to be set to NOERROR, and the AA and QR bits to be set in the response, AD may be set in the response if the server supports DNSSEC otherwise it should be clear; RA may also be set [RFC1034]. We expect an OPT record to be returned. There should be no EDNS flags other than DO present in the response which should be present if the server supports DNSSEC. The EDNS version field should be 0 and there should be no EDNS options present [RFC6891]. Check that DO=1 queries work (EDNS supported): dig +nocookie +edns=0 +noad +norec +dnssec soa $zone @$server @@ -920,26 +939,26 @@ expect: flag: aa to be present 8.2.9. Testing EDNS Version Negotiation With DO=1 Ask for the SOA record of the configured zone, which does not need to be DNSSEC signed. This query is made with no DNS flag bits set. EDNS version 1 is used without any EDNS options. The only EDNS flag set is DO. We expect the SOA record for the zone to NOT be returned in the - answer section with the rcode set to BADVERS; the QR bit and possibly - the RA bit to be set [RFC1034]. We expect an OPT record to be - returned. There should be no EDNS flags other than DO present in the - response which should be there if the server supports DNSSEC. The - EDNS version field should be 0 and there should be no EDNS options - present [RFC6891]. + answer section, the rcode to be set to NOERROR, ; the QR bit and + possibly the RA bit to be set [RFC1034]. We expect an OPT record to + be returned. There should be no EDNS flags other than DO present in + the response which should be there if the server supports DNSSEC. + The EDNS version field should be 0 and there should be no EDNS + options present [RFC6891]. Check that EDNS version 1, DO=1 queries work (EDNS supported): dig +nocookie +edns=1 +noednsneg +noad +norec +dnssec soa \ $zone @$server expect: status: BADVERS expect: SOA record to NOT be present expect: an OPT record to be present in the additional section expect: DO=1 to be present if the EDNS version 0 DNSSEC query test @@ -948,22 +967,22 @@ expect: flag: aa to NOT be present 8.2.10. Testing With Multiple Defined EDNS Options Ask for the SOA record of the configured zone. This query is made with no DNS flag bits set. EDNS version 0 is used. A number of defined EDNS options are present (NSID [RFC5001], DNS COOKIE [RFC7873], EDNS Client Subnet [RFC7871] and EDNS Expire [RFC7314]). We expect the SOA record for the zone to be returned in the answer - section with the rcode set to NOERROR and the AA and QR bits to be - set in the response; RA may also be set [RFC1034]. We expect an OPT + section, the rcode to be set to NOERROR, and the AA and QR bits to be + set in the header; RA may also be set [RFC1034]. We expect an OPT record to be returned. There should be no EDNS flags present in the response. The EDNS version field should be 0. Any of the requested EDNS options supported by the server and permitted server configuration may be returned [RFC6891]. Check that EDNS queries with multiple defined EDNS options work: dig +edns=0 +noad +norec +cookie +nsid +expire +subnet=0.0.0.0/0 \ soa $zone @$server