1 Internet Engineering Task Force (IETF) M. Andrews
2 Request for Comments: 8906 R. Bellis
3 BCP: 231 ISC
4 Category: Best Current Practice September 2020
5 ISSN: 2070-1721
6
7
8 A Common Operational Problem in DNS Servers: Failure to Communicate
9
10 Abstract
11
12 The DNS is a query/response protocol. Failing to respond to queries,
13 or responding incorrectly, causes both immediate operational problems
14 and long-term problems with protocol development.
15
16 This document identifies a number of common kinds of queries to which
17 some servers either fail to respond or respond incorrectly. This
18 document also suggests procedures for zone operators to apply to
19 identify and remediate the problem.
20
21 The document does not look at the DNS data itself, just the structure
22 of the responses.
23
24 Status of This Memo
25
26 This memo documents an Internet Best Current Practice.
27
28 This document is a product of the Internet Engineering Task Force
29 (IETF). It represents the consensus of the IETF community. It has
30 received public review and has been approved for publication by the
31 Internet Engineering Steering Group (IESG). Further information on
32 BCPs is available in Section 2 of RFC 7841.
33
34 Information about the current status of this document, any errata,
35 and how to provide feedback on it may be obtained at
36 https://www.rfc-editor.org/info/rfc8906.
37
38 Copyright Notice
39
40 Copyright (c) 2020 IETF Trust and the persons identified as the
41 document authors. All rights reserved.
42
43 This document is subject to BCP 78 and the IETF Trust's Legal
44 Provisions Relating to IETF Documents
45 (https://trustee.ietf.org/license-info) in effect on the date of
46 publication of this document. Please review these documents
47 carefully, as they describe your rights and restrictions with respect
48 to this document. Code Components extracted from this document must
49 include Simplified BSD License text as described in Section 4.e of
50 the Trust Legal Provisions and are provided without warranty as
51 described in the Simplified BSD License.
52
53 Table of Contents
54
55 1. Introduction
56 2. Consequences
57 3. Common Kinds of Queries That Result in No or Bad Responses
58 3.1. Basic DNS Queries
59 3.1.1. Zone Existence
60 3.1.2. Unknown/Unsupported Type Queries
61 3.1.3. DNS Flags
62 3.1.4. Unknown DNS Opcodes
63 3.1.5. TCP Queries
64 3.2. EDNS Queries
65 3.2.1. EDNS Queries: Version Independent
66 3.2.2. EDNS Queries: Version Specific
67 3.2.3. EDNS Options
68 3.2.4. EDNS Flags
69 3.2.5. Truncated EDNS Responses
70 3.2.6. DO=1 Handling
71 3.2.7. EDNS over TCP
72 4. Firewalls and Load Balancers
73 5. Packet Scrubbing Services
74 6. Whole Answer Caches
75 7. Response Code Selection
76 8. Testing
77 8.1. Testing: Basic DNS
78 8.1.1. Is the server configured for the zone?
79 8.1.2. Testing Unknown Types
80 8.1.3. Testing Header Bits
81 8.1.4. Testing Unknown Opcodes
82 8.1.5. Testing TCP
83 8.2. Testing: Extended DNS
84 8.2.1. Testing Minimal EDNS
85 8.2.2. Testing EDNS Version Negotiation
86 8.2.3. Testing Unknown EDNS Options
87 8.2.4. Testing Unknown EDNS Flags
88 8.2.5. Testing EDNS Version Negotiation with Unknown EDNS
89 Flags
90 8.2.6. Testing EDNS Version Negotiation with Unknown EDNS
91 Options
92 8.2.7. Testing Truncated Responses
93 8.2.8. Testing DO=1 Handling
94 8.2.9. Testing EDNS Version Negotiation with DO=1
95 8.2.10. Testing with Multiple Defined EDNS Options
96 8.3. When EDNS Is Not Supported
97 9. Remediation
98 10. Security Considerations
99 11. IANA Considerations
100 12. References
101 12.1. Normative References
102 12.2. Informative References
103 Acknowledgements
104 Authors' Addresses
105
106 1. Introduction
107
108 The DNS [RFC1034] [RFC1035] is a query/response protocol. Failing to
109 respond to queries or responding incorrectly causes both immediate
110 operational problems and long-term problems with protocol
111 development.
112
113 Failure to respond to a query is indistinguishable from packet loss
114 without doing an analysis of query-response patterns. Additionally,
115 failure to respond results in unnecessary queries being made by DNS
116 clients and introduces delays to the resolution process.
117
118 Due to the inability to distinguish between packet loss and
119 nameservers or middleboxes dropping Extension Mechanisms for DNS
120 (EDNS) [RFC6891] queries, packet loss is sometimes misclassified as
121 lack of EDNS support, which can lead to DNSSEC validation failures.
122
123 The existence of servers that fail to respond to queries results in
124 developers being hesitant to deploy new standards. Such servers need
125 to be identified and remediated.
126
127 The DNS has response codes that cover almost any conceivable query
128 response. A nameserver should be able to respond to any conceivable
129 query using them. There should be no need to drop queries because a
130 nameserver does not understand them.
131
132 Unless a nameserver is under attack, it should respond to all DNS
133 requests directed to it. When a nameserver is under attack, it may
134 wish to drop packets. A common attack is to use a nameserver as an
135 amplifier by sending spoofed packets. This is done because response
136 packets are bigger than the queries and large amplification factors
137 are available, especially if EDNS is supported. Limiting the rate of
138 responses is reasonable when this is occurring, and the client should
139 retry. However, this only works if legitimate clients are not being
140 forced to guess whether or not EDNS queries are accepted. As long as
141 there is still a pool of servers that don't respond to EDNS requests,
142 clients have no way to know if the lack of response is due to packet
143 loss, EDNS packets not being supported, or rate limiting due to the
144 server being under attack. Misclassification of server behaviour is
145 unavoidable when rate limiting is used until the population of
146 servers that fail to respond to well-formed queries drops to near
147 zero.
148
149 Nameservers should respond to queries even if the queried name is not
150 for any name the server is configured to answer for. Misconfigured
151 nameservers are a common occurrence in the DNS, and receiving queries
152 for zones that the server is not configured for is not necessarily an
153 indication that the server is under attack. Parent zone operators
154 are advised to regularly check that the delegating NS records are
155 consistent with those of the delegated zone and to correct them when
156 they are not (Section 4.2.2 of [RFC1034], Paragraph 3). Doing this
157 regularly should reduce the instances of broken delegations.
158
159 This document does not try to identify all possible errors nor does
160 it supply an exhaustive list of tests.
161
162 2. Consequences
163
164 Failure to follow the guidance in relevant DNS RFCs has multiple
165 adverse consequences. Some are caused directly by the non-compliant
166 behaviour and others as a result of workarounds forced on recursive
167 servers. Addressing known issues now will reduce future
168 interoperability issues as the DNS protocol continues to evolve and
169 clients make use of newly introduced DNS features. In particular,
170 the base DNS specification [RFC1034] [RFC1035] and the EDNS
171 specification [RFC6891], when implemented, need to be followed.
172
173 Some examples of known consequences include the following:
174
175 * The AD (Authenticated Data) bit in a response cannot be trusted to
176 mean anything, as some servers incorrectly copy the flag bit from
177 the request to the response [RFC1035] [RFC4035]. The use of the
178 AD bit in requests is defined in [RFC6840].
179
180 * Widespread non-response to EDNS queries has led to recursive
181 servers having to assume that EDNS is not supported and that
182 fallback to plain DNS is required, potentially causing DNSSEC
183 validation failures.
184
185 * Widespread non-response to EDNS options requires recursive servers
186 to decide whether to probe to see if it is the specific EDNS
187 option or the use of EDNS in general that is causing the non-
188 response. In the limited amount of time required to resolve a
189 query before the client times out, this is not possible.
190
191 * Incorrectly returning FORMERR to an EDNS option being present
192 leads to the recursive server not being able to determine if the
193 server is just broken in the handling of the EDNS option or if it
194 doesn't support EDNS at all.
195
196 * Mishandling of unknown query types has contributed to the
197 abandonment of the transition of the SPF type.
198
199 * Mishandling of unknown query types has slowed up the development
200 of DNS-Based Authentication of Named Entities (DANE) and resulted
201 in additional rules being specified to reduce the probability of
202 interacting with a broken server when making TLSA queries.
203
204 The consequences of servers not following the RFCs will only grow if
205 measures are not put in place to remove non-compliant servers from
206 the ecosystem. Working around issues due to non-compliance with RFCs
207 is not sustainable.
208
209 Most (if not all) of these consequences could have been avoided if
210 action had been taken to remove non-compliant servers as soon as
211 people were aware of them, i.e., to actively seek out broken
212 implementations and servers and inform their developers and operators
213 that they need to fix their servers.
214
215 3. Common Kinds of Queries That Result in No or Bad Responses
216
217 This section is broken down into Basic DNS requests and EDNS
218 requests.
219
220 3.1. Basic DNS Queries
221
222 3.1.1. Zone Existence
223
224 If a zone is delegated to a server, that server should respond to a
225 SOA query for that zone with an SOA record. Failing to respond at
226 all is always incorrect, regardless of the configuration of the
227 server. Responding with anything other than an SOA record in the
228 answer section indicates a bad delegation.
229
230 3.1.2. Unknown/Unsupported Type Queries
231
232 Some servers fail to respond to unknown or unsupported types. If a
233 server receives a query for a type that it doesn't recognise, or
234 doesn't implement, it is expected to return the appropriate response
235 as if it did recognise the type but does not have any data for that
236 type, i.e., either NOERROR or NXDOMAIN. The exceptions to this are
237 queries for Meta-RR types, which may return NOTIMP.
238
239 3.1.3. DNS Flags
240
241 Some servers fail to respond to DNS queries with various DNS flags
242 set, regardless of whether they are defined or still reserved. At
243 the time of writing, there are servers that fail to respond to
244 queries with the AD flag set to 1 and servers that fail to respond to
245 queries with the last reserved flag set.
246
247 Servers should respond to such queries. If the server does not know
248 the meaning of a flag, it must not copy it to the response
249 (Section 4.1.1 of [RFC1035]). If the server does not understand the
250 meaning of a request, it should reply with a FORMERR response with
251 unknown flags set to zero.
252
253 3.1.3.1. Recursive Queries
254
255 A non-recursive server is supposed to respond to recursive queries as
256 if the Recursion Desired (RD) bit is not set [RFC1034].
257
258 3.1.4. Unknown DNS Opcodes
259
260 The use of previously undefined opcodes is to be expected. Since the
261 DNS was first defined, two new opcodes have been added, UPDATE and
262 NOTIFY.
263
264 NOTIMP is the expected rcode to an unknown or unimplemented opcode.
265
266 | NOTE: while new opcodes will most probably use the current
267 | layout structure for the rest of the message, there is no
268 | requirement that anything other than the DNS header match.
269
270 3.1.5. TCP Queries
271
272 All DNS servers are supposed to respond to queries over TCP
273 [RFC7766]. While firewalls should not block TCP connection attempts,
274 those that do should cleanly terminate the connection by sending TCP
275 RESET or sending ICMP/ICMPv6 Administratively Prohibited messages.
276 Dropping TCP connections introduces excessive delays to the
277 resolution process.
278
279 3.2. EDNS Queries
280
281 EDNS queries are specified in [RFC6891].
282
283 3.2.1. EDNS Queries: Version Independent
284
285 Identifying servers that fail to respond to EDNS queries can be done
286 by first confirming that the server responds to regular DNS queries,
287 followed by a series of otherwise identical queries using EDNS, then
288 making the original query again. A series of EDNS queries is needed,
289 as at least one DNS implementation responds to the first EDNS query
290 with FORMERR but fails to respond to subsequent queries from the same
291 address for a period until a regular DNS query is made. The EDNS
292 query should specify a UDP buffer size of 512 bytes to avoid false
293 classification of not supporting EDNS due to response packet size.
294
295 If the server responds to the first and last queries but fails to
296 respond to most or all of the EDNS queries, it is probably faulty.
297 The test should be repeated a number of times to eliminate the
298 likelihood of a false positive due to packet loss.
299
300 Firewalls may also block larger EDNS responses, but there is no easy
301 way to check authoritative servers to see if the firewall is
302 misconfigured.
303
304 3.2.2. EDNS Queries: Version Specific
305
306 Some servers respond correctly to EDNS version 0 queries but fail to
307 respond to EDNS queries with version numbers that are higher than
308 zero. Servers should respond with BADVERS to EDNS queries with
309 version numbers that they do not support.
310
311 Some servers respond correctly to EDNS version 0 queries but fail to
312 set QR=1 when responding to EDNS versions they do not support. Such
313 responses may be discarded as invalid (as QR is not 1) or treated as
314 requests (when the source port of the original request was port 53).
315
316 3.2.3. EDNS Options
317
318 Some servers fail to respond to EDNS queries with EDNS options set.
319 The original EDNS specification left this behaviour undefined
320 [RFC2671], but the correct behaviour was clarified in [RFC6891].
321 Unknown EDNS options are supposed to be ignored by the server.
322
323 3.2.4. EDNS Flags
324
325 Some servers fail to respond to EDNS queries with EDNS flags set.
326 Servers should ignore EDNS flags they do not understand and must not
327 add them to the response [RFC6891].
328
329 3.2.5. Truncated EDNS Responses
330
331 Some EDNS-aware servers fail to include an OPT record when a
332 truncated response is sent. An OPT record is supposed to be included
333 in a truncated response [RFC6891].
334
335 Some EDNS-aware servers fail to honour the advertised EDNS UDP buffer
336 size and send oversized responses [RFC6891]. Servers must send UDP
337 responses no larger than the advertised EDNS UDP buffer size.
338
339 3.2.6. DO=1 Handling
340
341 Some nameservers incorrectly only return an EDNS response when the
342 DNSSEC OK (DO) bit [RFC3225] is 1 in the query. Servers that support
343 EDNS should always respond to EDNS requests with EDNS responses.
344
345 Some nameservers fail to copy the DO bit to the response despite
346 clearly supporting DNSSEC by returning an RRSIG records to EDNS
347 queries with DO=1. Nameservers that support DNSSEC are expected to
348 copy the DO bit from the request to the response.
349
350 3.2.7. EDNS over TCP
351
352 Some EDNS-aware servers incorrectly limit the TCP response sizes to
353 the advertised UDP response size. This breaks DNS resolution to
354 clients where the response sizes exceed the advertised UDP response
355 size despite the server and the client being capable of sending and
356 receiving larger TCP responses, respectively. It effectively defeats
357 setting TC=1 in UDP responses.
358
359 4. Firewalls and Load Balancers
360
361 Firewalls and load balancers can affect the externally visible
362 behaviour of a nameserver. Tests for conformance should to be done
363 from outside of any firewall so that the system is tested as a whole.
364
365 Firewalls and load balancers should not drop DNS packets that they
366 don't understand. They should either pass the packets or generate an
367 appropriate error response.
368
369 Requests for unknown query types are normal client behaviour and
370 should not be construed as an attack. Nameservers have always been
371 expected to be able to handle such queries.
372
373 Requests for unknown query classes are normal client behaviour and
374 should not be construed as an attack. Nameservers have always been
375 expected to be able to handle such queries.
376
377 Requests with unknown opcodes are normal client behaviour and should
378 not be construed as an attack. Nameservers have always been expected
379 to be able to handle such queries.
380
381 Requests with unassigned flags set (DNS or EDNS) are expected client
382 behaviour and should not be construed as an attack. The behaviour
383 for unassigned flags is to ignore them in the request and to not set
384 them in the response. Dropping DNS/EDNS packets with unassigned
385 flags makes it difficult to deploy extensions that make use of them
386 due to the need to reconfigure and update firewalls.
387
388 Requests with unknown EDNS options are expected client behaviour and
389 should not be construed as an attack. The correct behaviour for
390 unknown EDNS options is to ignore their presence when constructing a
391 reply.
392
393 Requests with unknown EDNS versions are expected client behaviour and
394 should not be construed as an attack. The correct behaviour for
395 unknown EDNS versions is to return BADVERS along with the highest
396 EDNS version the server supports. Dropping EDNS packets breaks EDNS
397 version negotiation.
398
399 Firewalls should not assume that there will only be a single response
400 message to a request. There have been proposals to use EDNS to
401 signal that multiple DNS messages be returned rather than a single
402 UDP message that is fragmented at the IP layer.
403
404 DNS, and EDNS in particular, are designed to allow clients to be able
405 to use new features against older servers without having to validate
406 every option. Indiscriminate blocking of messages breaks that
407 design.
408
409 However, there may be times when a nameserver mishandles messages
410 with a particular flag, EDNS option, EDNS version field, opcode, type
411 or class field, or combination thereof to the point where the
412 integrity of the nameserver is compromised. Firewalls should offer
413 the ability to selectively reject messages using an appropriately
414 constructed response based on all these fields while awaiting a fix
415 from the nameserver vendor. Returning FORMERR or REFUSED are two
416 potential error codes to return.
417
418 5. Packet Scrubbing Services
419
420 Packet scrubbing services are used to filter out undesired traffic,
421 including but not limited to denial-of-service traffic. This is
422 often done using heuristic analysis of the traffic.
423
424 Packet scrubbing services can affect the externally visible behaviour
425 of a nameserver in a similar way to firewalls. If an operator uses a
426 packet scrubbing service, they should check that legitimate queries
427 are not being blocked.
428
429 Packet scrubbing services, unlike firewalls, are also turned on and
430 off in response to denial-of-service attacks. One needs to take care
431 when choosing a scrubbing service.
432
433 Ideally, operators should run these tests against a packet scrubbing
434 service to ensure that these tests are not seen as attack vectors.
435
436 6. Whole Answer Caches
437
438 Whole answer caches take a previously constructed answer and return
439 it to a subsequent query for the same question. However, they can
440 return the wrong response if they do not take all of the relevant
441 attributes of the query into account.
442
443 In addition to the standard tuple of <qname,qtype,qclass>, a non-
444 exhaustive set of attributes that must be considered include: RD, AD,
445 CD, OPT record, DO, EDNS buffer size, EDNS version, EDNS options, and
446 transport.
447
448 7. Response Code Selection
449
450 Choosing the correct response code when responding to DNS queries is
451 important. Response codes should be chosen considering how clients
452 will handle them.
453
454 For unimplemented opcodes, NOTIMP is the expected response code.
455 Note: newly implemented opcodes may change the message format by
456 extending the header, changing the structure of the records, etc.
457 Servers are not expected to be able to parse these and should respond
458 with a response code of NOTIMP rather than FORMERR (which would be
459 expected if there was a parse error with a known opcode).
460
461 For unimplemented type codes, and in the absence of other errors, the
462 only valid response is NOERROR if the qname exists and NXDOMAIN
463 otherwise. For Meta-RRs, NOTIMP may be returned instead.
464
465 If a zone cannot be loaded because it contains unimplemented type
466 codes that are not encoded as unknown record types according to
467 [RFC3597], then the expected response is SERVFAIL, as the whole zone
468 should be rejected (Section 5.2 of [RFC1035]). If a zone loads, then
469 Section 4.3.2 of [RFC1034] applies.
470
471 If the server supports EDNS and receives a query with an unsupported
472 EDNS version, the correct response is BADVERS [RFC6891].
473
474 If the server does not support EDNS at all, FORMERR is the expected
475 error code. That said, a minimal EDNS server implementation requires
476 parsing the OPT records and responding with an empty OPT record in
477 the additional section in most cases. There is no need to interpret
478 any EDNS options present in the request, as unsupported EDNS options
479 are expected to be ignored [RFC6891]. Additionally, EDNS flags can
480 be ignored. The only part of the OPT record that needs to be
481 examined is the version field to determine if BADVERS needs to be
482 sent or not.
483
484 8. Testing
485
486 Testing is divided into two sections: "Basic DNS", which all servers
487 should meet, and "Extended DNS", which should be met by all servers
488 that support EDNS (a server is deemed to support EDNS if it gives a
489 valid EDNS response to any EDNS query). If a server does not support
490 EDNS, it should still respond to all the tests, albeit with error
491 responses.
492
493 These tests query for records at the apex of a zone that the server
494 is nominally configured to serve. All tests should use the same
495 zone.
496
497 It is advisable to run all of the tests below in parallel so as to
498 minimise the delays due to multiple timeouts when the servers do not
499 respond. There are 16 queries directed to each nameserver (assuming
500 no packet loss) testing different aspects of Basic DNS and Extended
501 DNS.
502
503 The tests below use dig from BIND 9.11.0 [ISC]. Replace $zone with
504 the name of the zone being used for testing. Replace $server with
505 the name or address of the server being tested.
506
507 When testing, recursive servers set RD=1 and choose a zone name that
508 is known to exist and is not being served by the recursive server.
509 The root zone (".") is often a good candidate, as it is DNSSEC
510 signed. RD=1, rather than RD=0, should be present in the responses
511 for all test involving the opcode QUERY. Non-authoritative answers
512 (AA=0) are expected when talking to a recursive server. AD=1 is only
513 expected if the server is validating responses and one or both AD=1
514 or DO=1 is set in the request, otherwise AD=0 is expected.
515
516 8.1. Testing: Basic DNS
517
518 This first set of tests cover Basic DNS server behaviour and all
519 servers should pass these tests.
520
521 8.1.1. Is the server configured for the zone?
522
523 Ask for the SOA record of the configured zone. This query is made
524 with no DNS flag bits set and without EDNS.
525
526 We expect the SOA record for the zone to be returned in the answer
527 section, the rcode to be set to NOERROR, and the Authoritative Answer
528 (AA) and Query/Response (QR) bits to be set in the header; the
529 Recursion Available (RA) bits may also be set [RFC1034]. We do not
530 expect an OPT record to be returned [RFC6891].
531
532 Verify the server is configured for the zone:
533
534 dig +noedns +noad +norec soa $zone @$server
535
536 expect: status: NOERROR
537 expect: the SOA record to be present in the answer section
538 expect: flag: aa to be present
539 expect: flag: rd to NOT be present
540 expect: flag: ad to NOT be present
541 expect: the OPT record to NOT be present
542
543 8.1.2. Testing Unknown Types
544
545 Identifying servers that fail to respond to unknown or unsupported
546 types can be done by making an initial DNS query for an A record,
547 making a number of queries for an unallocated type, then making a
548 query for an A record again. IANA maintains a registry of allocated
549 types [IANA-DNS].
550
551 If the server responds to the first and last queries but fails to
552 respond to the queries for the unallocated type, it is probably
553 faulty. The test should be repeated a number of times to eliminate
554 the likelihood of a false positive due to packet loss.
555
556 Ask for the TYPE1000 RRset at the configured zone's name. This query
557 is made with no DNS flag bits set and without EDNS. TYPE1000 has
558 been chosen for this purpose, as IANA is unlikely to allocate this
559 type in the near future and it is not in a range reserved for private
560 use [RFC6895]. Any unallocated type code could be chosen for this
561 test.
562
563 We expect no records to be returned in the answer section, the rcode
564 to be set to NOERROR, and the AA and QR bits to be set in the header;
565 RA may also be set [RFC1034]. We do not expect an OPT record to be
566 returned [RFC6891].
567
568 Check that queries for an unknown type work:
569
570 dig +noedns +noad +norec type1000 $zone @$server
571
572 expect: status: NOERROR
573 expect: an empty answer section.
574 expect: flag: aa to be present
575 expect: flag: rd to NOT be present
576 expect: flag: ad to NOT be present
577 expect: the OPT record to NOT be present
578
579 8.1.3. Testing Header Bits
580
581 8.1.3.1. Testing CD=1 Queries
582
583 Ask for the SOA record of the configured zone. This query is made
584 with only the CD DNS flag bit set, with all other DNS bits clear, and
585 without EDNS.
586
587 We expect the SOA record for the zone to be returned in the answer
588 section, the rcode to be set to NOERROR, and the AA and QR bits to be
589 set in the header. We do not expect an OPT record to be returned.
590
591 If the server supports DNSSEC, CD should be set in the response
592 [RFC4035]; otherwise, CD should be clear [RFC1034].
593
594 Check that queries with CD=1 work:
595
596 dig +noedns +noad +norec +cd soa $zone @$server
597
598 expect: status: NOERROR
599 expect: the SOA record to be present in the answer section
600 expect: flag: aa to be present
601 expect: flag: rd to NOT be present
602 expect: flag: ad to NOT be present
603 expect: the OPT record to NOT be present
604
605 8.1.3.2. Testing AD=1 Queries
606
607 Ask for the SOA record of the configured zone. This query is made
608 with only the AD DNS flag bit set, with all other DNS bits clear, and
609 without EDNS.
610
611 We expect the SOA record for the zone to be returned in the answer
612 section, the rcode to be set to NOERROR, and the AA and QR bits to be
613 set in the header. We do not expect an OPT record to be returned.
614 The purpose of this query is to detect blocking of queries with the
615 AD bit present, not the specific value of AD in the response.
616
617 Check that queries with AD=1 work:
618
619 dig +noedns +norec +ad soa $zone @$server
620
621 expect: status: NOERROR
622 expect: the SOA record to be present in the answer section
623 expect: flag: aa to be present
624 expect: flag: rd to NOT be present
625 expect: the OPT record to NOT be present
626
627 AD use in queries is defined in [RFC6840].
628
629 8.1.3.3. Testing Reserved Bit
630
631 Ask for the SOA record of the configured zone. This query is made
632 with only the final reserved DNS flag bit set, with all other DNS
633 bits clear, and without EDNS.
634
635 We expect the SOA record for the zone to be returned in the answer
636 section, the rcode to be set to NOERROR, and the AA and QR bits to be
637 set in the header; RA may be set. The final reserved bit must not be
638 set [RFC1034]. We do not expect an OPT record to be returned
639 [RFC6891].
640
641 Check that queries with the last unassigned DNS header flag work and
642 that the flag bit is not copied to the response:
643
644 dig +noedns +noad +norec +zflag soa $zone @$server
645
646 expect: status: NOERROR
647 expect: the SOA record to be present in the answer section
648 expect: MBZ to NOT be in the response (see below)
649 expect: flag: aa to be present
650 expect: flag: rd to NOT be present
651 expect: flag: ad to NOT be present
652 expect: the OPT record to NOT be present
653
654 MBZ (Must Be Zero) is a dig-specific indication that the flag bit has
655 been incorrectly copied. See Section 4.1.1 of [RFC1035]:
656
657 "Z Reserved for future use. Must be zero in all queries and
658 responses."
659
660 8.1.3.4. Testing Recursive Queries
661
662 Ask for the SOA record of the configured zone. This query is made
663 with only the RD DNS flag bit set and without EDNS.
664
665 We expect the SOA record for the zone to be returned in the answer
666 section, the rcode to be set to NOERROR, and the AA, QR and RD bits
667 to be set in the header; RA may also be set [RFC1034]. We do not
668 expect an OPT record to be returned [RFC6891].
669
670 Check that recursive queries work:
671
672 dig +noedns +noad +rec soa $zone @$server
673
674 expect: status: NOERROR
675 expect: the SOA record to be present in the answer section
676 expect: flag: aa to be present
677 expect: flag: rd to be present
678 expect: flag: ad to NOT be present
679 expect: the OPT record to NOT be present
680
681 8.1.4. Testing Unknown Opcodes
682
683 Construct a DNS message that consists of only a DNS header with
684 opcode set to 15 (currently not allocated), no DNS header bits set,
685 and empty question, answer, authority, and additional sections.
686
687 Check that new opcodes are handled:
688
689 dig +noedns +noad +opcode=15 +norec +header-only @$server
690
691 expect: status: NOTIMP
692 expect: opcode: 15
693 expect: all sections to be empty
694 expect: flag: aa to NOT be present
695 expect: flag: rd to NOT be present
696 expect: flag: ad to NOT be present
697 expect: the OPT record to NOT be present
698
699 8.1.5. Testing TCP
700
701 Whether a server accepts TCP connections can be tested by first
702 checking that it responds to UDP queries to confirm that it is up and
703 operating, then attempting the same query over TCP. An additional
704 query should be made over UDP if the TCP connection attempt fails to
705 confirm that the server under test is still operating.
706
707 Ask for the SOA record of the configured zone. This query is made
708 with no DNS flag bits set and without EDNS. This query is to be sent
709 using TCP.
710
711 We expect the SOA record for the zone to be returned in the answer
712 section, the rcode to be set to NOERROR, and the AA and QR bits to be
713 set in the header; RA may also be set [RFC1034]. We do not expect an
714 OPT record to be returned [RFC6891].
715
716 Check that TCP queries work:
717
718 dig +noedns +noad +norec +tcp soa $zone @$server
719
720 expect: status: NOERROR
721 expect: the SOA record to be present in the answer section
722 expect: flag: aa to be present
723 expect: flag: rd to NOT be present
724 expect: flag: ad to NOT be present
725 expect: the OPT record to NOT be present
726
727 The requirement that TCP be supported is defined in [RFC7766].
728
729 8.2. Testing: Extended DNS
730
731 The next set of tests cover various aspects of EDNS behaviour. If
732 any of these tests succeed (indicating at least some EDNS support),
733 then all of them should succeed. There are servers that support EDNS
734 but fail to handle plain EDNS queries correctly, so a plain EDNS
735 query is not a good indicator of lack of EDNS support.
736
737 8.2.1. Testing Minimal EDNS
738
739 Ask for the SOA record of the configured zone. This query is made
740 with no DNS flag bits set. EDNS version 0 is used without any EDNS
741 options or EDNS flags set.
742
743 We expect the SOA record for the zone to be returned in the answer
744 section, the rcode to be set to NOERROR, and the AA and QR bits to be
745 set in the header; RA may also be set [RFC1034]. We expect an OPT
746 record to be returned. There should be no EDNS flags present in the
747 response. The EDNS version field should be 0, and there should be no
748 EDNS options present [RFC6891].
749
750 Check that plain EDNS queries work:
751
752 dig +nocookie +edns=0 +noad +norec soa $zone @$server
753
754 expect: status: NOERROR
755 expect: the SOA record to be present in the answer section
756 expect: an OPT record to be present in the additional section
757 expect: EDNS Version 0 in response
758 expect: flag: aa to be present
759 expect: flag: ad to NOT be present
760
761 +nocookie disables sending an EDNS COOKIE option, which is otherwise
762 enabled by default in BIND 9.11.0 (and later).
763
764 8.2.2. Testing EDNS Version Negotiation
765
766 Ask for the SOA record of a zone the server is nominally configured
767 to serve. This query is made with no DNS flag bits set. EDNS
768 version 1 is used without any EDNS options or EDNS flags set.
769
770 We expect the SOA record for the zone to NOT be returned in the
771 answer section with the extended rcode set to BADVERS and the QR bit
772 to be set in the header; RA may also be set [RFC1034]. We expect an
773 OPT record to be returned. There should be no EDNS flags present in
774 the response. The EDNS version field should be 0 in the response, as
775 no other EDNS version has as yet been specified [RFC6891].
776
777 Check that EDNS version 1 queries work (EDNS supported):
778
779 dig +nocookie +edns=1 +noednsneg +noad +norec soa $zone @$server
780
781 expect: status: BADVERS
782 expect: the SOA record to NOT be present in the answer section
783 expect: an OPT record to be present in the additional section
784 expect: EDNS Version 0 in response
785 expect: flag: aa to NOT be present
786 expect: flag: ad to NOT be present
787
788 +noednsneg has been set, as dig supports EDNS version negotiation,
789 and we want to see only the response to the initial EDNS version 1
790 query.
791
792 8.2.3. Testing Unknown EDNS Options
793
794 Ask for the SOA record of the configured zone. This query is made
795 with no DNS flag bits set. EDNS version 0 is used without any EDNS
796 flags. An EDNS option is present with a value that has not yet been
797 assigned by IANA. We have picked an unassigned code of 100 for the
798 example below. Any unassigned EDNS option code could have been
799 chosen for this test.
800
801 We expect the SOA record for the zone to be returned in the answer
802 section, the rcode to be set to NOERROR, and the AA and QR bits to be
803 set in the header; RA may also be set [RFC1034]. We expect an OPT
804 record to be returned. There should be no EDNS flags present in the
805 response. The EDNS version field should be 0, as EDNS versions other
806 than 0 are yet to be specified, and there should be no EDNS options
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
807 present, as unknown EDNS options are supposed to be ignored by the
808 server (Section 6.1.1 of [RFC6891]).
809
810 Check that EDNS queries with an unknown option work (EDNS supported):
811
812 dig +nocookie +edns=0 +noad +norec +ednsopt=100 soa $zone @$server
813
814 expect: status: NOERROR
815 expect: the SOA record to be present in the answer section
816 expect: an OPT record to be present in the additional section
817 expect: OPT=100 to NOT be present
818 expect: EDNS Version 0 in response
819 expect: flag: aa to be present
820 expect: flag: ad to NOT be present
821
822 8.2.4. Testing Unknown EDNS Flags
823
824 Ask for the SOA record of the configured zone. This query is made
825 with no DNS flag bits set. EDNS version 0 is used without any EDNS
826 options. An unassigned EDNS flag bit is set (0x40 in this case).
827
828 We expect the SOA record for the zone to be returned in the answer
829 section, the rcode to be set to NOERROR, and the AA and QR bits to be
830 set in the header; RA may also be set [RFC1034]. We expect an OPT
831 record to be returned. There should be no EDNS flags present in the
832 response, as unknown EDNS flags are supposed to be ignored. The EDNS
833 version field should be 0, and there should be no EDNS options
834 present [RFC6891].
835
836 Check that EDNS queries with unknown flags work (EDNS supported):
837
838 dig +nocookie +edns=0 +noad +norec +ednsflags=0x40 soa $zone @$server
839
840 expect: status: NOERROR
841 expect: the SOA record to be present in the answer section
842 expect: an OPT record to be present in the additional section
843 expect: MBZ not to be present
844 expect: EDNS Version 0 in response
845 expect: flag: aa to be present
846 expect: flag: ad to NOT be present
847
848 MBZ (Must Be Zero) is a dig-specific indication that a flag bit has
849 been incorrectly copied, as per Section 6.1.4 of [RFC6891].
850
851 8.2.5. Testing EDNS Version Negotiation with Unknown EDNS Flags
852
853 Ask for the SOA record of the configured zone. This query is made
854 with no DNS flag bits set. EDNS version 1 is used without any EDNS
855 options. An unassigned EDNS flag bit is set (0x40 in this case).
856
857 We expect the SOA record for the zone to NOT be returned in the
858 answer section with the extended rcode set to BADVERS and the QR bit
859 to be set in the header; RA may also be set [RFC1034]. We expect an
860 OPT record to be returned. There should be no EDNS flags present in
861 the response, as unknown EDNS flags are supposed to be ignored. The
862 EDNS version field should be 0, as EDNS versions other than 0 are yet
863 to be specified, and there should be no EDNS options present
864 [RFC6891].
865
866 Check that EDNS version 1 queries with unknown flags work (EDNS
867 supported):
868
869 dig +nocookie +edns=1 +noednsneg +noad +norec +ednsflags=0x40 soa \
870 $zone @$server
871
872 expect: status: BADVERS
873 expect: SOA record to NOT be present
874 expect: an OPT record to be present in the additional section
875 expect: MBZ not to be present
876 expect: EDNS Version 0 in response
877 expect: flag: aa to NOT be present
878 expect: flag: ad to NOT be present
879
880 8.2.6. Testing EDNS Version Negotiation with Unknown EDNS Options
881
882 Ask for the SOA record of the configured zone. This query is made
883 with no DNS flag bits set. EDNS version 1 is used. An unknown EDNS
884 option is present. We have picked an unassigned code of 100 for the
885 example below. Any unassigned EDNS option code could have been
886 chosen for this test.
887
888 We expect the SOA record for the zone to NOT be returned in the
889 answer section with the extended rcode set to BADVERS and the QR bit
890 to be set in the header; RA may also be set [RFC1034]. We expect an
891 OPT record to be returned. There should be no EDNS flags present in
892 the response. The EDNS version field should be 0, as EDNS versions
893 other than 0 are yet to be specified, and there should be no EDNS
894 options present [RFC6891].
895
896 Check that EDNS version 1 queries with unknown options work (EDNS
897 supported):
898
899 dig +nocookie +edns=1 +noednsneg +noad +norec +ednsopt=100 soa \
900 $zone @$server
901
902 expect: status: BADVERS
903 expect: SOA record to NOT be present
904 expect: an OPT record to be present in the additional section
905 expect: OPT=100 to NOT be present
906 expect: EDNS Version 0 in response
907 expect: flag: aa to NOT be present
908 expect: flag: ad to NOT be present
909
910 8.2.7. Testing Truncated Responses
911
912 Ask for the DNSKEY records of the configured zone, which must be a
913 DNSSEC signed zone. This query is made with no DNS flag bits set.
914 EDNS version 0 is used without any EDNS options. The only EDNS flag
915 set is DO. The EDNS UDP buffer size is set to 512. The intention of
916 this query is to elicit a truncated response from the server. Most
917 signed DNSKEY responses are bigger than 512 bytes. This test will
918 not give a valid result if the zone is not signed.
919
920 We expect a response, the rcode to be set to NOERROR, and the AA and
921 QR bits to be set. AD may be set in the response if the server
922 supports DNSSEC; otherwise it should be clear; TC and RA may also be
923 set [RFC1035] [RFC4035]. We expect an OPT record to be present in
924 the response. There should be no EDNS flags other than DO present in
925 the response. The EDNS version field should be 0, and there should
926 be no EDNS options present [RFC6891].
927
928 If TC is not set, it is not possible to confirm that the server
929 correctly adds the OPT record to the truncated responses or not.
930
931 dig +norec +dnssec +bufsize=512 +ignore dnskey $zone @$server
932 expect: NOERROR
933 expect: OPT record with version set to 0
934
935 8.2.8. Testing DO=1 Handling
936
937 Ask for the SOA record of the configured zone, which does not need to
938 be DNSSEC signed. This query is made with no DNS flag bits set.
939 EDNS version 0 is used without any EDNS options. The only EDNS flag
940 set is DO.
941
942 We expect the SOA record for the zone to be returned in the answer
943 section, the rcode to be set to NOERROR, and the AA and QR bits to be
944 set in the response. AD may be set in the response if the server
945 supports DNSSEC, otherwise it should be clear; RA may also be set
946 [RFC1034]. We expect an OPT record to be returned. There should be
947 no EDNS flags other than DO present in the response, which should be
948 present if the server supports DNSSEC. The EDNS version field should
949 be 0, and there should be no EDNS options present [RFC6891].
950
951 Check that DO=1 queries work (EDNS supported):
952
953 dig +nocookie +edns=0 +noad +norec +dnssec soa $zone @$server
954
955 expect: status: NOERROR
956 expect: the SOA record to be present in the answer section
957 expect: an OPT record to be present in the additional section
958 expect: DO=1 to be present if an RRSIG is in the response
959 expect: EDNS Version 0 in response
960 expect: flag: aa to be present
961
962 8.2.9. Testing EDNS Version Negotiation with DO=1
963
964 Ask for the SOA record of the configured zone, which does not need to
965 be DNSSEC signed. This query is made with no DNS flag bits set.
966 EDNS version 1 is used without any EDNS options. The only EDNS flag
967 set is DO.
968
969 We expect the SOA record for the zone NOT to be returned in the
970 answer section, the extended rcode to be set to BADVERS, and the QR
971 bit to be set in the header; RA may also be set [RFC1034]. We expect
972 an OPT record to be returned. There should be no EDNS flags other
973 than DO present in the response, which should be there if the server
974 supports DNSSEC. The EDNS version field should be 0, and there
975 should be no EDNS options present [RFC6891].
976
977 Check that EDNS version 1, DO=1 queries work (EDNS supported):
978
979 dig +nocookie +edns=1 +noednsneg +noad +norec +dnssec soa \
980 $zone @$server
981
982 expect: status: BADVERS
983 expect: SOA record to NOT be present
984 expect: an OPT record to be present in the additional section
985 expect: DO=1 to be present if the EDNS version 0 DNSSEC query test
986 returned DO=1
987 expect: EDNS Version 0 in response
988 expect: flag: aa to NOT be present
989
990 8.2.10. Testing with Multiple Defined EDNS Options
991
992 Ask for the SOA record of the configured zone. This query is made
993 with no DNS flag bits set. EDNS version 0 is used. A number of
994 defined EDNS options are present (NSID [RFC5001], DNS COOKIE
995 [RFC7873], EDNS Client Subnet [RFC7871], and EDNS Expire [RFC7314]).
996
997 We expect the SOA record for the zone to be returned in the answer
998 section, the rcode to be set to NOERROR, and the AA and QR bits to be
999 set in the header; RA may also be set [RFC1034]. We expect an OPT
1000 record to be returned. There should be no EDNS flags present in the
1001 response. The EDNS version field should be 0. Any of the requested
1002 EDNS options supported by the server and permitted server
1003 configuration may be returned [RFC6891].
1004
1005 Check that EDNS queries with multiple defined EDNS options work:
1006
1007 dig +edns=0 +noad +norec +cookie +nsid +expire +subnet=0.0.0.0/0 \
1008 soa $zone @$server
1009
1010 expect: status: NOERROR
1011 expect: the SOA record to be present in the answer section
1012 expect: an OPT record to be present in the additional section
1013 expect: EDNS Version 0 in response
1014 expect: flag: aa to be present
1015 expect: flag: ad to NOT be present
1016
1017 8.3. When EDNS Is Not Supported
1018
1019 If EDNS is not supported by the nameserver, we expect a response to
1020 each of the above queries. That response may be a FORMERR error
1021 response, or the OPT record may just be ignored.
1022
1023 Some nameservers only return an EDNS response when a particular EDNS
1024 option or flag (e.g., DO=1) is present in the request. This
1025 behaviour is not compliant behaviour and may hide other incorrect
1026 behaviour from the above tests. Retesting with the triggering
1027 option/flag present will expose this misbehaviour.
1028
1029 9. Remediation
1030
1031 Nameserver operators are generally expected to test their own
1032 infrastructure for compliance to standards. The above tests should
1033 be run when new systems are brought online and should be repeated
1034 periodically to ensure continued interoperability.
1035
1036 Domain registrants who do not maintain their own DNS infrastructure
1037 are entitled to a DNS service that conforms to standards and
1038 interoperates well. Registrants who become aware that their DNS
1039 operator does not have a well-maintained or compliant infrastructure
1040 should insist that their service provider correct issues and switch
1041 providers if they do not.
1042
1043 In the event that an operator experiences problems due to the
1044 behaviour of nameservers outside their control, the above tests will
1045 help in narrowing down the precise issue(s), which can then be
1046 reported to the relevant party.
1047
1048 If contact information for the operator of a misbehaving nameserver
1049 is not already known, the following methods of communication could be
1050 considered:
1051
1052 * the RNAME of the zone authoritative for the name of the
1053 misbehaving server
1054
1055 * the RNAME of zones for which the offending server is authoritative
1056
1057 * administrative or technical contacts listed in the registration
1058 information for the parent domain of the name of the misbehaving
1059 server or for zones for which the nameserver is authoritative
1060
1061 * the registrar or registry for such zones
1062
1063 * DNS-specific, operational fora (e.g., mailing lists)
1064
1065 Operators of parent zones may wish to regularly test the
1066 authoritative nameservers of their child zones. However, parent
1067 operators can have widely varying capabilities in terms of
1068 notification or remediation depending on whether they have a direct
1069 relationship with the child operator. Many Top-Level Domain (TLD)
1070 registries, for example, cannot directly contact their registrants
1071 and may instead need to communicate through the relevant registrar.
1072 In such cases, it may be most efficient for registrars to take on the
1073 responsibility for testing the nameservers of their registrants,
1074 since they have a direct relationship.
1075
1076 When notification is not effective at correcting problems with a
1077 misbehaving nameserver, parent operators can choose to remove NS
1078 record sets (and glue records below) that refer to the faulty server
1079 until the servers are fixed. This should only be done as a last
1080 resort and with due consideration, as removal of a delegation can
1081 have unanticipated side effects. For example, other parts of the DNS
1082 tree may depend on names below the removed zone cut, and the parent
1083 operator may find themselves responsible for causing new DNS failures
1084 to occur.
1085
1086 10. Security Considerations
1087
1088 Testing protocol compliance can potentially result in false reports
1089 of attempts to attack services from Intrusion Detection Services and
1090 firewalls. All of the tests are well-formed (though not necessarily
1091 common) DNS queries. None of the tests listed above should cause any
1092 harm to a protocol-compliant server.
1093
1094 Relaxing firewall settings to ensure EDNS compliance could
1095 potentially expose a critical implementation flaw in the nameserver.
1096 Nameservers should be tested for conformance before relaxing firewall
1097 settings.
1098
1099 When removing delegations for non-compliant servers, there can be a
1100 knock-on effect on other zones that require these zones to be
1101 operational for the nameservers addresses to be resolved.
1102
1103 11. IANA Considerations
1104
1105 This document has no IANA actions.
1106
1107 12. References
1108
1109 12.1. Normative References
1110
1111 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
1112 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
1113 <https://www.rfc-editor.org/info/rfc1034>.
1114
1115 [RFC1035] Mockapetris, P., "Domain names - implementation and
1116 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
1117 November 1987, <https://www.rfc-editor.org/info/rfc1035>.
1118
1119 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC",
1120 RFC 3225, DOI 10.17487/RFC3225, December 2001,
1121 <https://www.rfc-editor.org/info/rfc3225>.
1122
1123 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1124 Rose, "Protocol Modifications for the DNS Security
1125 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
1126 <https://www.rfc-editor.org/info/rfc4035>.
1127
1128 [RFC6840] Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and
1129 Implementation Notes for DNS Security (DNSSEC)", RFC 6840,
1130 DOI 10.17487/RFC6840, February 2013,
1131 <https://www.rfc-editor.org/info/rfc6840>.
1132
1133 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
1134 for DNS (EDNS(0))", STD 75, RFC 6891,
1135 DOI 10.17487/RFC6891, April 2013,
1136 <https://www.rfc-editor.org/info/rfc6891>.
1137
1138 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA
1139 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
1140 April 2013, <https://www.rfc-editor.org/info/rfc6895>.
1141
1142 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
1143 D. Wessels, "DNS Transport over TCP - Implementation
1144 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
1145 <https://www.rfc-editor.org/info/rfc7766>.
1146
1147 12.2. Informative References
1148
1149 [IANA-DNS] IANA, "Domain Name System (DNS) Parameters",
1150 <https://www.iana.org/assignments/dns-parameters/>.
1151
1152 [ISC] "Internet Systems Consortuim", <https://www.isc.org/>.
1153
1154 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
1155 RFC 2671, DOI 10.17487/RFC2671, August 1999,
1156 <https://www.rfc-editor.org/info/rfc2671>.
1157
1158 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
1159 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September
1160 2003, <https://www.rfc-editor.org/info/rfc3597>.
1161
1162 [RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option",
1163 RFC 5001, DOI 10.17487/RFC5001, August 2007,
1164 <https://www.rfc-editor.org/info/rfc5001>.
1165
1166 [RFC7314] Andrews, M., "Extension Mechanisms for DNS (EDNS) EXPIRE
1167 Option", RFC 7314, DOI 10.17487/RFC7314, July 2014,
1168 <https://www.rfc-editor.org/info/rfc7314>.
1169
1170 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W.
1171 Kumari, "Client Subnet in DNS Queries", RFC 7871,
1172 DOI 10.17487/RFC7871, May 2016,
1173 <https://www.rfc-editor.org/info/rfc7871>.
1174
1175 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
1176 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
1177 <https://www.rfc-editor.org/info/rfc7873>.
1178
1179 Acknowledgements
1180
1181 The contributions of Matthew Pounsett and Tim Wicinski are gratefully
1182 acknowledged.
1183
1184 Authors' Addresses
1185
1186 M. Andrews
1187 Internet Systems Consortium
1188 PO Box 360
1189 Newmarket, NH 03857
1190 United States of America
1191
1192 Email: marka@isc.org
1193
1194
1195 Ray Bellis
1196 Internet Systems Consortium
1197 PO Box 360
1198 Newmarket, NH 03857
1199 United States of America
1200
1201 Email: ray@isc.org
1202
present, as unknown EDNS options are supposed to be ignored by the server (Section 6.1.1 of [RFC6891]).
present, as unknown EDNS options are supposed to be ignored by the server (Section 6.1.12 of [RFC6891]).