draft-ietf-dnsop-no-response-issue-20.txt | draft-ietf-dnsop-no-response-issue-21.txt | |||
---|---|---|---|---|
Network Working Group M. Andrews | Network Working Group M. Andrews | |||
Internet-Draft R. Bellis | Internet-Draft R. Bellis | |||
Intended status: Best Current Practice ISC | Intended status: Best Current Practice ISC | |||
Expires: October 9, 2020 April 7, 2020 | Expires: October 15, 2020 April 13, 2020 | |||
A Common Operational Problem in DNS Servers - Failure To Communicate | A Common Operational Problem in DNS Servers - Failure To Communicate | |||
draft-ietf-dnsop-no-response-issue-20 | draft-ietf-dnsop-no-response-issue-21 | |||
Abstract | Abstract | |||
The DNS is a query / response protocol. Failing to respond to | The DNS is a query / response protocol. Failing to respond to | |||
queries, or responding incorrectly, causes both immediate operational | queries, or responding incorrectly, causes both immediate operational | |||
problems and long term problems with protocol development. | problems and long term problems with protocol development. | |||
This document identifies a number of common kinds of queries to which | This document identifies a number of common kinds of queries to which | |||
some servers either fail to respond or else respond incorrectly. | some servers either fail to respond or else respond incorrectly. | |||
This document also suggests procedures for zone operators to apply to | This document also suggests procedures for zone operators to apply to | |||
skipping to change at page 1, line 40 ¶ | skipping to change at page 1, line 40 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on October 9, 2020. | This Internet-Draft will expire on October 15, 2020. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2020 IETF Trust and the persons identified as the | Copyright (c) 2020 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 35 ¶ | skipping to change at page 2, line 35 ¶ | |||
3.2.3. EDNS Options . . . . . . . . . . . . . . . . . . . . 7 | 3.2.3. EDNS Options . . . . . . . . . . . . . . . . . . . . 7 | |||
3.2.4. EDNS Flags . . . . . . . . . . . . . . . . . . . . . 7 | 3.2.4. EDNS Flags . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.2.5. Truncated EDNS Responses . . . . . . . . . . . . . . 8 | 3.2.5. Truncated EDNS Responses . . . . . . . . . . . . . . 8 | |||
3.2.6. DO=1 Handling . . . . . . . . . . . . . . . . . . . . 8 | 3.2.6. DO=1 Handling . . . . . . . . . . . . . . . . . . . . 8 | |||
3.2.7. EDNS over TCP . . . . . . . . . . . . . . . . . . . . 8 | 3.2.7. EDNS over TCP . . . . . . . . . . . . . . . . . . . . 8 | |||
4. Firewalls and Load Balancers . . . . . . . . . . . . . . . . 8 | 4. Firewalls and Load Balancers . . . . . . . . . . . . . . . . 8 | |||
5. Packet Scrubbing Services . . . . . . . . . . . . . . . . . . 9 | 5. Packet Scrubbing Services . . . . . . . . . . . . . . . . . . 9 | |||
6. Whole Answer Caches . . . . . . . . . . . . . . . . . . . . . 10 | 6. Whole Answer Caches . . . . . . . . . . . . . . . . . . . . . 10 | |||
7. Response Code Selection . . . . . . . . . . . . . . . . . . . 10 | 7. Response Code Selection . . . . . . . . . . . . . . . . . . . 10 | |||
8. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 8. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
8.1. Testing - Basic DNS . . . . . . . . . . . . . . . . . . . 11 | 8.1. Testing - Basic DNS . . . . . . . . . . . . . . . . . . . 12 | |||
8.1.1. Is The Server Configured For The Zone? . . . . . . . 12 | 8.1.1. Is The Server Configured For The Zone? . . . . . . . 12 | |||
8.1.2. Testing Unknown Types . . . . . . . . . . . . . . . . 12 | 8.1.2. Testing Unknown Types . . . . . . . . . . . . . . . . 12 | |||
8.1.3. Testing Header Bits . . . . . . . . . . . . . . . . . 13 | 8.1.3. Testing Header Bits . . . . . . . . . . . . . . . . . 13 | |||
8.1.4. Testing Unknown Opcodes . . . . . . . . . . . . . . . 15 | 8.1.4. Testing Unknown Opcodes . . . . . . . . . . . . . . . 15 | |||
8.1.5. Testing TCP . . . . . . . . . . . . . . . . . . . . . 15 | 8.1.5. Testing TCP . . . . . . . . . . . . . . . . . . . . . 15 | |||
8.2. Testing - Extended DNS . . . . . . . . . . . . . . . . . 16 | 8.2. Testing - Extended DNS . . . . . . . . . . . . . . . . . 16 | |||
8.2.1. Testing Minimal EDNS . . . . . . . . . . . . . . . . 16 | 8.2.1. Testing Minimal EDNS . . . . . . . . . . . . . . . . 16 | |||
8.2.2. Testing EDNS Version Negotiation . . . . . . . . . . 17 | 8.2.2. Testing EDNS Version Negotiation . . . . . . . . . . 17 | |||
8.2.3. Testing Unknown EDNS Options . . . . . . . . . . . . 17 | 8.2.3. Testing Unknown EDNS Options . . . . . . . . . . . . 17 | |||
8.2.4. Testing Unknown EDNS Flags . . . . . . . . . . . . . 18 | 8.2.4. Testing Unknown EDNS Flags . . . . . . . . . . . . . 18 | |||
8.2.5. Testing EDNS Version Negotiation With Unknown EDNS | 8.2.5. Testing EDNS Version Negotiation With Unknown EDNS | |||
Flags . . . . . . . . . . . . . . . . . . . . . . . . 18 | Flags . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
8.2.6. Testing EDNS Version Negotiation With Unknown EDNS | 8.2.6. Testing EDNS Version Negotiation With Unknown EDNS | |||
Options . . . . . . . . . . . . . . . . . . . . . . . 19 | Options . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
8.2.7. Testing Truncated Responses . . . . . . . . . . . . . 20 | 8.2.7. Testing Truncated Responses . . . . . . . . . . . . . 20 | |||
8.2.8. Testing DO=1 Handling . . . . . . . . . . . . . . . . 20 | 8.2.8. Testing DO=1 Handling . . . . . . . . . . . . . . . . 21 | |||
8.2.9. Testing EDNS Version Negotiation With DO=1 . . . . . 21 | 8.2.9. Testing EDNS Version Negotiation With DO=1 . . . . . 21 | |||
8.2.10. Testing With Multiple Defined EDNS Options . . . . . 22 | 8.2.10. Testing With Multiple Defined EDNS Options . . . . . 22 | |||
8.3. When EDNS Is Not Supported . . . . . . . . . . . . . . . 22 | 8.3. When EDNS Is Not Supported . . . . . . . . . . . . . . . 22 | |||
9. Remediation . . . . . . . . . . . . . . . . . . . . . . . . . 22 | 9. Remediation . . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 | |||
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 | 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 | |||
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 | 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 | |||
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
13.1. Normative References . . . . . . . . . . . . . . . . . . 24 | 13.1. Normative References . . . . . . . . . . . . . . . . . . 24 | |||
13.2. Informative References . . . . . . . . . . . . . . . . . 25 | 13.2. Informative References . . . . . . . . . . . . . . . . . 25 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
1. Introduction | 1. Introduction | |||
skipping to change at page 3, line 29 ¶ | skipping to change at page 3, line 29 ¶ | |||
to respond to queries, or responding incorrectly, causes both | to respond to queries, or responding incorrectly, causes both | |||
immediate operational problems and long term problems with protocol | immediate operational problems and long term problems with protocol | |||
development. | development. | |||
Failure to respond to a query is indistinguishable from packet loss | Failure to respond to a query is indistinguishable from packet loss | |||
without doing an analysis of query-response patterns. Additionally | without doing an analysis of query-response patterns. Additionally | |||
failure to respond results in unnecessary queries being made by DNS | failure to respond results in unnecessary queries being made by DNS | |||
clients, and introduces delays to the resolution process. | clients, and introduces delays to the resolution process. | |||
Due to the inability to distinguish between packet loss and | Due to the inability to distinguish between packet loss and | |||
nameservers dropping EDNS [RFC6891] queries, packet loss is sometimes | nameservers or middle boxes dropping EDNS [RFC6891] queries, packet | |||
misclassified as lack of EDNS support which can lead to DNSSEC | loss is sometimes misclassified as lack of EDNS support which can | |||
validation failures. | lead to DNSSEC validation failures. | |||
The existence of servers which fail to respond to queries results in | The existence of servers which fail to respond to queries results in | |||
developers being hesitant to deploy new standards. Such servers need | developers being hesitant to deploy new standards. Such servers need | |||
to be identified and remediated. | to be identified and remediated. | |||
The DNS has response codes that cover almost any conceivable query | The DNS has response codes that cover almost any conceivable query | |||
response. A nameserver should be able to respond to any conceivable | response. A nameserver should be able to respond to any conceivable | |||
query using them. There should be no need to drop queries because a | query using them. There should be no need to drop queries because a | |||
nameserver does not understand them. | nameserver does not understand them. | |||
Unless a nameserver is under attack, it should respond to all DNS | Unless a nameserver is under attack, it should respond to all DNS | |||
requests directed to it. When a nameserver is under attack it may | requests directed to it. When a nameserver is under attack it may | |||
wish to drop packets. A common attack is to use a nameserver as an | wish to drop packets. A common attack is to use a nameserver as an | |||
amplifier by sending spoofed packets. This is done because response | amplifier by sending spoofed packets. This is done because response | |||
packets are bigger than the queries and large amplification factors | packets are bigger than the queries and large amplification factors | |||
are available especially if EDNS is supported. Limiting the rate of | are available especially if EDNS is supported. Limiting the rate of | |||
responses is reasonable when this is occurring and the client should | responses is reasonable when this is occurring and the client should | |||
retry. This however only works if legitimate clients are not being | retry. This however only works if legitimate clients are not being | |||
forced to guess whether EDNS queries are accepted or not. While | forced to guess whether EDNS queries are accepted or not. As long as | |||
there is still a pool of servers that don't respond to EDNS requests, | there are still a pool of servers that don't respond to EDNS | |||
clients have no way to know if the lack of response is due to packet | requests, clients have no way to know if the lack of response is due | |||
loss, or EDNS packets not being supported, or rate limiting due to | to packet loss, or EDNS packets not being supported, or rate limiting | |||
the server being under attack. Misclassification of server behaviour | due to the server being under attack. Misclassification of server | |||
is unavoidable when rate limiting is used until the population of | behaviour is unavoidable when rate limiting is used until the | |||
servers which fail to respond to well-formed queries drops to near | population of servers which fail to respond to well-formed queries | |||
zero. | drops to near zero. | |||
Nameservers should respond to queries even if the queried name is not | Nameservers should respond to queries even if the queried name is not | |||
for any name the server is configured to answer for. Misconfigured | for any name the server is configured to answer for. Misconfigured | |||
nameservers are a common occurrence in the DNS and receiving queries | nameservers are a common occurrence in the DNS and receiving queries | |||
for zones that the server is not configured for is not necessarily an | for zones that the server is not configured for is not necessarily an | |||
indication that the server is under attack. Parent zone operators | indication that the server is under attack. Parent zone operators | |||
are advised to regularly check that the delegating NS records are | are advised to regularly check that the delegating NS records are | |||
consistent with those of the delegated zone and to correct them when | consistent with those of the delegated zone and to correct them when | |||
they are not [RFC1034], Section 4.4.2, Paragraph 3. Doing this | they are not [RFC1034], Section 4.4.2, Paragraph 3. Doing this | |||
regularly should reduce the instances of broken delegations. | regularly should reduce the instances of broken delegations. | |||
This document does not try to identify all possible errors nor does | This document does not try to identify all possible errors nor does | |||
it supply an exhaustive list of tests. | it supply an exhaustive list of tests. | |||
2. Consequences | 2. Consequences | |||
Failure to follow the relevant DNS RFCs has multiple adverse | Failure to follow the relevant DNS RFCs has multiple adverse | |||
consequences. Some are caused directly from the non-compliant | consequences. Some are caused directly by the non-compliant | |||
behaviour and others as a result of work-arounds forced on recursive | behaviour and others as a result of work-arounds forced on recursive | |||
servers. Addressing known issues now will reduce future | servers. Addressing known issues now will reduce future | |||
interoperability issues as the DNS protocol continues to evolve and | interoperability issues as the DNS protocol continues to evolve and | |||
clients make use of newly-introduced DNS features. In particular the | clients make use of newly-introduced DNS features. In particular the | |||
base DNS specification [RFC1034], [RFC1035] and the EDNS | base DNS specification [RFC1034], [RFC1035] and the EDNS | |||
specification [RFC6891], when implemented, need to be followed. | specification [RFC6891], when implemented, need to be followed. | |||
Some examples of known consequences include: | Some examples of known consequences include: | |||
o The AD flag bit in a response cannot be trusted to mean anything | o The AD (Authenticated Data) bit in a response cannot be trusted to | |||
as some servers incorrectly copy the flag bit from the request to | mean anything as some servers incorrectly copy the flag bit from | |||
the response [RFC1035], [RFC4035]. The use of the AD flag bit in | the request to the response [RFC1035], [RFC4035]. The use of the | |||
requests is defined in [RFC6840]. | AD bit in requests is defined in [RFC6840]. | |||
o Widespread non-response to EDNS queries has lead to recursive | o Widespread non-response to EDNS queries has led to recursive | |||
servers having to assume that EDNS is not supported and that | servers having to assume that EDNS is not supported and that | |||
fallback to plain DNS is required, potentially causing DNSSEC | fallback to plain DNS is required, potentially causing DNSSEC | |||
validation failures. | validation failures. | |||
o Widespread non-response to EDNS options, requires recursive | o Widespread non-response to EDNS options, requires recursive | |||
servers to have to decide whether to probe to see if it is the | servers to have to decide whether to probe to see if it is the | |||
EDNS option or just EDNS that is causing the non response. In the | specific EDNS option or the use of EDNS in general that is causing | |||
limited amount of time required to resolve a query before the | the non response. In the limited amount of time required to | |||
client times out this is not possible. | resolve a query before the client times out this is not possible. | |||
o Incorrectly returning FORMERR to an EDNS option being present, | o Incorrectly returning FORMERR to an EDNS option being present, | |||
leads to the recursive server not being able to determine if the | leads to the recursive server not being able to determine if the | |||
server is just broken in the handling of the EDNS option or | server is just broken in the handling of the EDNS option or | |||
doesn't support EDNS at all. | doesn't support EDNS at all. | |||
o Mishandling of unknown query types has contributed to the | o Mishandling of unknown query types has contributed to the | |||
abandonment of the transition of the SPF type. | abandonment of the transition of the SPF type. | |||
o Mishandling of unknown query types has slowed up the development | o Mishandling of unknown query types has slowed up the development | |||
skipping to change at page 6, line 10 ¶ | skipping to change at page 6, line 10 ¶ | |||
doesn't implement, it is expected to return the appropriate response | doesn't implement, it is expected to return the appropriate response | |||
as if it did recognise 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 | type: either NOERROR, or NXDOMAIN. The exception to this are queries | |||
for Meta-RR types which may return NOTIMP. | for Meta-RR types which may return NOTIMP. | |||
3.1.3. DNS Flags | 3.1.3. DNS Flags | |||
Some servers fail to respond to DNS queries with various 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 | set, regardless of whether they are defined or still reserved. At | |||
the time of writing there are servers that fail to respond to queries | 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 AD flag set to 1 and servers that fail to respond to queries | |||
with the last reserved flag bit set. | with the last reserved flag set. | |||
Servers should respond to such queries. If the server does not know | 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 | the meaning of a flag it must not copy it to the response [RFC1035] | |||
[RFC1035] Section 4.1.1. If the server does not understand the | Section 4.1.1. If the server does not understand the meaning of a | |||
meaning of a request it should reply with a FORMERR response with | request it should reply with a FORMERR response with unknown flags | |||
unknown flags set to zero. | set to zero. | |||
3.1.3.1. Recursive Queries | 3.1.3.1. Recursive Queries | |||
A non-recursive server is supposed to respond to recursive queries as | A non-recursive server is supposed to respond to recursive queries as | |||
if the RD bit is not set [RFC1034]. | if the RD bit is not set [RFC1034]. | |||
3.1.4. Unknown DNS opcodes | 3.1.4. Unknown DNS opcodes | |||
The use of previously undefined opcodes is to be expected. Since the | The use of previously undefined opcodes is to be expected. Since the | |||
DNS was first defined two new opcodes have been added, UPDATE and | DNS was first defined two new opcodes have been added, UPDATE and | |||
skipping to change at page 11, line 36 ¶ | skipping to change at page 11, line 36 ¶ | |||
These tests query for records at the apex of a zone that the server | These tests query for records at the apex of a zone that the server | |||
is nominally configured to serve. All tests should use the same | is nominally configured to serve. All tests should use the same | |||
zone. | zone. | |||
It is advisable to run all of the tests below in parallel so as to | It is advisable to run all of the tests below in parallel so as to | |||
minimise the delays due to multiple timeouts when the servers do not | minimise the delays due to multiple timeouts when the servers do not | |||
respond. There are 16 queries directed to each nameserver (assuming | respond. There are 16 queries directed to each nameserver (assuming | |||
no packet loss) testing different aspects of Basic DNS and Extended | no packet loss) testing different aspects of Basic DNS and Extended | |||
DNS. | DNS. | |||
The tests below use dig from BIND 9.11.0. | The tests below use dig from BIND 9.11.0 [ISC]. Replace $zone with | |||
the name of the zone being used for testing. Replace $server with | ||||
the name or address of the server being tested. | ||||
When testing recursive servers set RD=1 and choose a zone name that | When testing recursive servers set RD=1 and choose a zone name that | |||
is know to exist and is not being served by the recursive server. | is known to exist and is not being served by the recursive server. | |||
The root zone (".") is often a good candidate as it is DNSSEC signed. | The root zone (".") is often a good candidate as it is DNSSEC signed. | |||
RD=1, rather than RD=0, should be present in the responses for all | RD=1, rather than RD=0, should be present in the responses for all | |||
test involving the opcode QUERY. Non-authoritative answers (AA=0) | test involving the opcode QUERY. Non-authoritative answers (AA=0) | |||
are expected when talking to a recursive server. AD=1 is only | are expected when talking to a recursive server. AD=1 is only | |||
expected if the server is validating responses and one or both AD=1 | expected if the server is validating responses and one or both AD=1 | |||
or DO=1 is set in the request otherwise AD=0 is expected. | or DO=1 is set in the request otherwise AD=0 is expected. | |||
8.1. Testing - Basic DNS | 8.1. Testing - Basic DNS | |||
This first set of tests cover basic DNS server behaviour and all | This first set of tests cover basic DNS server behaviour and all | |||
skipping to change at page 24, line 8 ¶ | skipping to change at page 24, line 20 ¶ | |||
until the servers are fixed. This should only be done as a last | until the servers are fixed. This should only be done as a last | |||
resort and with due consideration, as removal of a delegation can | resort and with due consideration, as removal of a delegation can | |||
have unanticipated side effects. For example, other parts of the DNS | have unanticipated side effects. For example, other parts of the DNS | |||
tree may depend on names below the removed zone cut, and the parent | tree may depend on names below the removed zone cut, and the parent | |||
operator may find themselves responsible for causing new DNS failures | operator may find themselves responsible for causing new DNS failures | |||
to occur. | to occur. | |||
10. Security Considerations | 10. Security Considerations | |||
Testing protocol compliance can potentially result in false reports | Testing protocol compliance can potentially result in false reports | |||
of attempts to break services from Intrusion Detection Services and | of attempts to attack services from Intrusion Detection Services and | |||
firewalls. All of the tests are well-formed (though not necessarily | firewalls. All of the tests are well-formed (though not necessarily | |||
common) DNS queries. None of the tests listed above should cause any | common) DNS queries. None of the tests listed above should cause any | |||
harm to a protocol-compliant server. | harm to a protocol-compliant server. | |||
Relaxing firewall settings to ensure EDNS compliance could | Relaxing firewall settings to ensure EDNS compliance could | |||
potentially expose a critical implementation flaw in the nameserver. | potentially expose a critical implementation flaw in the nameserver. | |||
Nameservers should be tested for conformance before relaxing firewall | Nameservers should be tested for conformance before relaxing firewall | |||
settings. | settings. | |||
When removing delegations for non-compliant servers there can be a | When removing delegations for non-compliant servers there can be a | |||
skipping to change at page 25, line 26 ¶ | skipping to change at page 25, line 39 ¶ | |||
Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, | Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, | |||
April 2013, <https://www.rfc-editor.org/info/rfc6895>. | April 2013, <https://www.rfc-editor.org/info/rfc6895>. | |||
[RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and | [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and | |||
D. Wessels, "DNS Transport over TCP - Implementation | D. Wessels, "DNS Transport over TCP - Implementation | |||
Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, | Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, | |||
<https://www.rfc-editor.org/info/rfc7766>. | <https://www.rfc-editor.org/info/rfc7766>. | |||
13.2. Informative References | 13.2. Informative References | |||
[ISC] "Internet Systems Consortuim", <https://www.isc.org/>. | ||||
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", | [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", | |||
RFC 2671, DOI 10.17487/RFC2671, August 1999, | RFC 2671, DOI 10.17487/RFC2671, August 1999, | |||
<https://www.rfc-editor.org/info/rfc2671>. | <https://www.rfc-editor.org/info/rfc2671>. | |||
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record | [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record | |||
(RR) Types", RFC 3597, DOI 10.17487/RFC3597, September | (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September | |||
2003, <https://www.rfc-editor.org/info/rfc3597>. | 2003, <https://www.rfc-editor.org/info/rfc3597>. | |||
[RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option", | [RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option", | |||
RFC 5001, DOI 10.17487/RFC5001, August 2007, | RFC 5001, DOI 10.17487/RFC5001, August 2007, | |||
End of changes. 20 change blocks. | ||||
37 lines changed or deleted | 41 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |