draft-ietf-dnsop-dnssec-roadblock-avoidance-02.txt   draft-ietf-dnsop-dnssec-roadblock-avoidance-03.txt 
DNSOP W. Hardaker DNSOP W. Hardaker
Internet-Draft Parsons Internet-Draft Parsons
Intended status: Best Current Practice O. Gudmundsson Intended status: Best Current Practice O. Gudmundsson
Expires: January 02, 2016 CloudFlare Expires: September 22, 2016 CloudFlare
S. Krishnaswamy S. Krishnaswamy
Parsons Parsons
July 01, 2015 March 21, 2016
DNSSEC Roadblock Avoidance DNSSEC Roadblock Avoidance
draft-ietf-dnsop-dnssec-roadblock-avoidance-02.txt draft-ietf-dnsop-dnssec-roadblock-avoidance-03.txt
Abstract Abstract
This document describes problems that a DNSSEC aware resolver/ This document describes problems that a DNSSEC aware resolver/
application might run into within a non-compliant infrastructure. It application might run into within a non-compliant infrastructure. It
outline potential detection and mitigation techniques. The scope of outline potential detection and mitigation techniques. The scope of
the document is to create a shared approache to detect and overcome the document is to create a shared approache to detect and overcome
network issues that a DNSSEC software/system may face. network issues that a DNSSEC software/system may face.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 January 02, 2016. This Internet-Draft will expire on September 22, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Implementation experiences . . . . . . . . . . . . . . . 3 1.2. Implementation experiences . . . . . . . . . . . . . . . 4
1.3. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Detecting DNSSEC Non-Compilance . . . . . . . . . . . . . . . 4 3. Detecting DNSSEC Non-Compilance . . . . . . . . . . . . . . . 5
3.1. Determining DNSSEC support in neighboring recursive 3.1. Determining DNSSEC support in neighboring recursive
resolvers . . . . . . . . . . . . . . . . . . . . . . . . 5 resolvers . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Supports UDP answers . . . . . . . . . . . . . . . . 5 3.1.1. Supports UDP answers . . . . . . . . . . . . . . . . 5
3.1.2. Supports TCP answers . . . . . . . . . . . . . . . . 5 3.1.2. Supports TCP answers . . . . . . . . . . . . . . . . 6
3.1.3. Supports EDNS0 . . . . . . . . . . . . . . . . . . . 5 3.1.3. Supports EDNS0 . . . . . . . . . . . . . . . . . . . 6
3.1.4. Supports the DO bit . . . . . . . . . . . . . . . . . 6 3.1.4. Supports the DO bit . . . . . . . . . . . . . . . . . 6
3.1.5. Supports the AD bit . . . . . . . . . . . . . . . . . 6 3.1.5. Supports the AD bit DNSKEY algorithm 5 . . . . . . . 7
3.1.6. Returns RRsig for signed answer . . . . . . . . . . . 6 3.1.6. Returns RRsig for signed answer . . . . . . . . . . . 7
3.1.7. Supports querying for DNSKEY records . . . . . . . . 7 3.1.7. Supports querying for DNSKEY records . . . . . . . . 7
3.1.8. Supports querying for DS records . . . . . . . . . . 7 3.1.8. Supports querying for DS records . . . . . . . . . . 8
3.1.9. Supports negative answers with NSEC records . . . . . 8 3.1.9. Supports negative answers with NSEC records . . . . . 8
3.1.10. Supports negative answers with NSEC3 records . . . . 8 3.1.10. Supports negative answers with NSEC3 records . . . . 8
3.1.11. Supports queries where DNAME records lead to an 3.1.11. Supports queries where DNAME records lead to an
answer . . . . . . . . . . . . . . . . . . . . . . . 8 answer . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.12. Permissive DNSSEC . . . . . . . . . . . . . . . . . . 9 3.1.12. Permissive DNSSEC . . . . . . . . . . . . . . . . . . 9
3.1.13. UDP size limits . . . . . . . . . . . . . . . . . . . 9 3.1.13. UDP size limits . . . . . . . . . . . . . . . . . . . 9
3.1.14. Supports Unknown RRtypes . . . . . . . . . . . . . . 9 3.1.14. Supports Unknown RRtypes . . . . . . . . . . . . . . 9
3.2. Direct Network Queries . . . . . . . . . . . . . . . . . 9 3.2. Direct Network Queries . . . . . . . . . . . . . . . . . 10
3.2.1. Support for Remote UDP Over Port 53 . . . . . . . . . 9 3.2.1. Support for Remote UDP Over Port 53 . . . . . . . . . 10
3.2.2. Support for Remote UDP With Fragmentation . . . . . . 10 3.2.2. Support for Remote UDP With Fragmentation . . . . . . 10
3.2.3. Support for Outbound TCP Over Port 53 . . . . . . . . 10 3.2.3. Support for Outbound TCP Over Port 53 . . . . . . . . 11
3.3. Support for DNSKEY and DS combinations . . . . . . . . . 11
4. Aggregating The Results . . . . . . . . . . . . . . . . . . . 11 4. Aggregating The Results . . . . . . . . . . . . . . . . . . . 11
4.1. Resolver capability description . . . . . . . . . . . . . 11 4.1. Resolver capability description . . . . . . . . . . . . . 12
5. Roadblock Avoidance . . . . . . . . . . . . . . . . . . . . . 12 5. Roadblock Avoidance . . . . . . . . . . . . . . . . . . . . . 12
5.1. Partial Resolver Usage . . . . . . . . . . . . . . . . . 14 5.1. Partial Resolver Usage . . . . . . . . . . . . . . . . . 15
5.1.1. Known Insecure Lookups . . . . . . . . . . . . . . . 14 5.1.1. Known Insecure Lookups . . . . . . . . . . . . . . . 15
5.1.2. Partial NSEC/NSEC3 Support . . . . . . . . . . . . . 14 5.1.2. Partial NSEC/NSEC3 Support . . . . . . . . . . . . . 15
6. Start-Up and Network Connectivity Issues . . . . . . . . . . 14 6. Start-Up and Network Connectivity Issues . . . . . . . . . . 15
6.1. What To Do . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. What To Do . . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Quick Test . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7.1. Test negative answers Algorithm 5 . . . . . . . . . . . . 16
9. Normative References . . . . . . . . . . . . . . . . . . . . 15 7.2. Test Algorithm 8 . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 7.3. Test Algorithm 13 . . . . . . . . . . . . . . . . . . . . 17
7.4. Really fails when DNSSEC does not validate . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Normative References . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
This document describes problems with DNSSEC ([RFC4034], [RFC4035]) This document describes problems with DNSSEC ([RFC4034], [RFC4035])
deployment due to non-compliant infrastructure. It poses potential deployment due to non-compliant infrastructure. It poses potential
detection and mitigation techniques. detection and mitigation techniques.
1.1. Background 1.1. Background
Deployment of DNSSEC validation is hampered by network components Deployment of DNSSEC validation is hampered by network components
that make it difficult or sometimes impossible for validating that make it difficult or sometimes impossible for validating
resolvers to effectively obtain the DNSSEC data they need. This can resolvers to effectively obtain the DNSSEC data they need. This can
occur for many different reasons including occur for many different reasons including
skipping to change at page 3, line 49 skipping to change at page 4, line 12
This mainly happens when there are DNS proxies/forwarders between the This mainly happens when there are DNS proxies/forwarders between the
user and the actual resolvers. user and the actual resolvers.
1.2. Implementation experiences 1.2. Implementation experiences
Multiple lessons learned from multiple implementations led to the Multiple lessons learned from multiple implementations led to the
development of this document, including (in alphabetical order) development of this document, including (in alphabetical order)
DNSSEC-Tools' DNSSEC-Check, DNSSEC_Resolver_Check, dnssec-trigger, DNSSEC-Tools' DNSSEC-Check, DNSSEC_Resolver_Check, dnssec-trigger,
FCC_Grade. FCC_Grade.
Detecting non-support for specified DNSKEY algorithms and DS digiest Detecting full non-support for specified DNSKEY algorithms and DS
algorithms is outside the scope of this document sample test tool: digiest algorithms is outside the scope of this document but the
https://github.com/ogud/DNSSEC_ALG_Check. document provides information on how to do that, see sample test
tool: https://github.com/ogud/DNSSEC_ALG_Check This document will
test compliance with Algorithm 5, 7 and Algorithm 13 with DS digest
algorithm 1 and 2.
1.3. Notation 1.3. Notation
When we talk about a "Host Validator", this can either be a library When we talk about a "Host Validator", this can either be a library
that an application has linked in or an actual validating resolver that an application has linked in or an actual validating resolver
running on the same machine. running on the same machine.
A variant of this is a "Validating Forwarding Resolver", which is a A variant of this is a "Validating Forwarding Resolver", which is a
resolver that is configured to use upstream Resolvers if possible. resolver that is configured to use upstream Resolvers if possible.
Validating Forward Resolver needs to perform the same set of tests Validating Forward Resolver needs to perform the same set of tests
skipping to change at page 4, line 39 skipping to change at page 5, line 5
A Host Validator has two choices: it can wait to determine that it A Host Validator has two choices: it can wait to determine that it
has problems with a recursive resolver based on the results that it has problems with a recursive resolver based on the results that it
is getting from real-world queries issued to it, or it can is getting from real-world queries issued to it, or it can
proactively test for problems (Section Section 3) to build a work proactively test for problems (Section Section 3) to build a work
around list ahead of time (Section Section 5). There are pros and around list ahead of time (Section Section 5). There are pros and
cons to both of these paths that are application specific, and this cons to both of these paths that are application specific, and this
document does not attempt to provide guidance about whether proactive document does not attempt to provide guidance about whether proactive
tests should or should not be used. Either way, DNSSEC roadblock tests should or should not be used. Either way, DNSSEC roadblock
avoidance techniques ought to be used when needed and if possible. avoidance techniques ought to be used when needed and if possible.
Note: The same tests can be used for a recursive resovler to check if
its upstream connections hinder DNSSEC validation.
This document specifies two sets of tests to perform a comprehensive
one and a fast one. The fast one will detect most common problems,
thus if the fast one passes then the comprensive MAY be exectued as
well.
3. Detecting DNSSEC Non-Compilance 3. Detecting DNSSEC Non-Compilance
A Host Validator may choose to determine early-on what bottlenecks A Host Validator may choose to determine early-on what bottlenecks
exist that may hamper its ability to perform DNSSEC look-ups. This exist that may hamper its ability to perform DNSSEC look-ups. This
section outlines tests that can be done to test certain features of section outlines tests that can be done to test certain features of
the surrounding network. the surrounding network.
NOTE: when performing these tests against an address, we make the NOTE: when performing these tests against an address, we make the
following assumtption about that address: It is a unicast address or following assumtption about that address: It is a unicast address or
an anycast cluster where all servers have identical configuration and an anycast cluster where all servers have identical configuration and
skipping to change at page 6, line 31 skipping to change at page 7, line 5
in the outgoing query. in the outgoing query.
SUCCESS: A DNS response was received that contains the DO bit set. SUCCESS: A DNS response was received that contains the DO bit set.
Note: this only tests that the resolver sets the DO bit in the Note: this only tests that the resolver sets the DO bit in the
response. Later checks will determine if the DO bit was actually response. Later checks will determine if the DO bit was actually
made use of. Some resolvers successfully pass this test because they made use of. Some resolvers successfully pass this test because they
simply copy the unknown flags into the response. Don't worry, simply copy the unknown flags into the response. Don't worry,
they'll fail the later tests. they'll fail the later tests.
3.1.5. Supports the AD bit 3.1.5. Supports the AD bit DNSKEY algorithm 5
Purpose: This tests whether the resolver is a validating resolver. Purpose: This tests whether the resolver is a validating resolver.
Pre-requisite: "Supports the DO bit". Pre-requisite: "Supports the DO bit".
Test: Send a request to the resolver under test for an A record for a Test: Send a request to the resolver under test for an A record for a
known existing domain in a DNSSEC signed zone which is verifiable to known existing domain in a DNSSEC signed zone which is verifiable to
a configured trust anchor, such as www.dnssec-tools.org using the a configured trust anchor, such as www.dnssec-tools.org using the
root's published DNSKEY or DS record as a trust anchor. Set the DO root's published DNSKEY or DS record as a trust anchor. Set the DO
bit in the outgoing query. bit in the outgoing query.
SUCCESS: A DNS response was received that contains the AD bit set. SUCCESS: A DNS response was received that contains the AD bit set.
BONUS: As AD is set this resolver supports Algorithm 5 RSASHA1
3.1.6. Returns RRsig for signed answer 3.1.6. Returns RRsig for signed answer
Purpose: This tests whether a resolver will properly return RRSIG Purpose: This tests whether a resolver will properly return RRSIG
records when the DO bit is set. records when the DO bit is set.
Pre-requisite: "Supports the DO bit". Pre-requisite: "Supports the DO bit".
Test: Send a request to the resolver under test for an A record for a Test: Send a request to the resolver under test for an A record for a
known existing domain in a DNSSEC signed zone, such as www.dnssec- known existing domain in a DNSSEC signed zone, such as www.dnssec-
tools.org. Set the DO bit in the outgoing query. tools.org. Set the DO bit in the outgoing query.
skipping to change at page 8, line 30 skipping to change at page 8, line 47
failure, but a bad test. failure, but a bad test.
3.1.10. Supports negative answers with NSEC3 records 3.1.10. Supports negative answers with NSEC3 records
Purpose: This tests whether a resolver properly returns NSEC3 records Purpose: This tests whether a resolver properly returns NSEC3 records
([RFC5155]) for a non-existing domain in a DNSSEC signed zone. ([RFC5155]) for a non-existing domain in a DNSSEC signed zone.
Pre-requisite: "Supports the DO bit." Pre-requisite: "Supports the DO bit."
Test: Send a request to the resolver under test for an A record which Test: Send a request to the resolver under test for an A record which
is known to be non-existent, such as non-existent.nsec3-ns.test is known to be non-existent, such as non-existent.nsec3-
.dnssec-tools.org. Set the DO bit in the outgoing query. ns.test.dnssec-tools.org. Set the DO bit in the outgoing query.
SUCCESS: A DNS response was received that contains an NSEC3 record. SUCCESS: A DNS response was received that contains an NSEC3 record.
Bonus: If the AD bit is set, this validator supports algorithm 7
RSASHA1-NSEC3-SHA1
Note: The query issued in this test MUST be sent to a NSEC3 signed Note: The query issued in this test MUST be sent to a NSEC3 signed
zone. Getting back appropriate NSEC records does not indicate a zone. Getting back appropriate NSEC records does not indicate a
failure, but a bad test. failure, but a bad test.
3.1.11. Supports queries where DNAME records lead to an answer 3.1.11. Supports queries where DNAME records lead to an answer
Purpose: This tests whether a resolver can query for an A record in a Purpose: This tests whether a resolver can query for an A record in a
zone with a known DNAME referral for the record's parent. zone with a known DNAME referral for the record's parent.
Test: Send a request to the resolver under test for an A record which Test: Send a request to the resolver under test for an A record which
skipping to change at page 9, line 12 skipping to change at page 9, line 32
answer section. An RRSIG MUST also be received in the answer section answer section. An RRSIG MUST also be received in the answer section
that covers the DNAME record. that covers the DNAME record.
3.1.12. Permissive DNSSEC 3.1.12. Permissive DNSSEC
Purpose: To see if a validating resolver is ignoring DNSSEC Purpose: To see if a validating resolver is ignoring DNSSEC
validation failures. validation failures.
Pre-requisite: Supports the AD bit. Pre-requisite: Supports the AD bit.
Test: ask for data from a broken DNSSEC delegation such as Test: ask for data from a broken DNSSEC delegation such as badsign-
badsign-a.test.dnssec-tools.org. a.test.dnssec-tools.org.
SUCCESS: A reply with the Rcode set to SERVFAIL SUCCESS: A reply with the Rcode set to SERVFAIL
3.1.13. UDP size limits 3.1.13. UDP size limits
Strictly speaking nothing other than using TCP can be used to Strictly speaking nothing other than using TCP can be used to
overcome this. Thus the host should use TCP fallback when UDP query overcome this. Thus the host should use TCP fallback when UDP query
times out. times out.
3.1.14. Supports Unknown RRtypes 3.1.14. Supports Unknown RRtypes
skipping to change at page 10, line 43 skipping to change at page 11, line 18
network. network.
Test: A DNS request is sent over TCP to a known distant authoritative Test: A DNS request is sent over TCP to a known distant authoritative
server for a record known to be within that server's authoritative server for a record known to be within that server's authoritative
data. Example: send a query to the address of ns1.dnssec-tools.org data. Example: send a query to the address of ns1.dnssec-tools.org
for the www.dnssec-tools.org/A record. for the www.dnssec-tools.org/A record.
SUCCESS: A DNS response was received that contains an a A record in SUCCESS: A DNS response was received that contains an a A record in
the answer section. the answer section.
Note: an implementation can used the local resolvers for determining Note: an implementation can use the local resolvers for determining
the address of the name server that is authoritative for the given the address of the name server that is authoritative for the given
zone. The recursive bit MAY be set for this request, but does not zone. The recursive bit MAY be set for this request, but does not
need to be. need to be.
3.3. Support for DNSKEY and DS combinations
Purpose: These tests can check if an algorithm combinations are
supported.
Pre-requesitive: At least one of above tests has returned AD bit
proving upstream is validating
Test: A DNS request is sent over UDP to the resolver under tests for
a known combination of the DS number (N) and DNSKEY number (M) of the
form ds-N.alg-M-nsec.dnssec-test.org, for example ds-2.alg-13-
nsec.dnssec-test.org TXT or ds-4.alg-13-nsec3.dnssec-test.org TXT.
SUCCESS: a DNS respose is received with AD bit set with TXT record in
the answer section.
BONUS: AD in response to the exaples above demonstrates support for
Algorihtm 13 and the two DS algoritm(s) with both NSEC and NSEC3
Note: for algorithms 6 and 7 NSEC is not defined thus query for alg-
M-nsec3 is requried, simlarly NSEC3 is not defined for algorithms 1,
3 and 5. Furthermore algorithms 2, 4, 9, 11 do not have definitions
to sign zones.
4. Aggregating The Results 4. Aggregating The Results
Some conclusions can be drawn from the results of the above tests in Some conclusions can be drawn from the results of the above tests in
an "aggregated" form. This section defines some labels to assign to an "aggregated" form. This section defines some labels to assign to
a resolver under test given the results of the tests run against a resolver under test given the results of the tests run against
them. them.
4.1. Resolver capability description 4.1. Resolver capability description
This section will group and label certain common results This section will group and label certain common results
skipping to change at page 15, line 38 skipping to change at page 16, line 33
service attack if a man-in-the-middle can convince a device that service attack if a man-in-the-middle can convince a device that
DNSSEC is impossible. DNSSEC is impossible.
6.1. What To Do 6.1. What To Do
If Host Validator detects that DNSSEC resolution is not possible it If Host Validator detects that DNSSEC resolution is not possible it
SHOULD warn user. In the case there is no user no reporting can be SHOULD warn user. In the case there is no user no reporting can be
performed thus the device MAY have a policy of action, like continue performed thus the device MAY have a policy of action, like continue
or fail. or fail.
7. Security Considerations 7. Quick Test
The quick tests defined below make the following assumption that the
questions are asked of a real resolver and the only real question is:
"how complete is the DNSSEC support?". This quick test as been
implemented in few programs developed at IETF hackthons at IETF-91
and IETF-92. The programs use a common grading method, for each
question that returns expected answer the resolver gets a point. If
the AD bit is set as expected the resolver gets a second point.
7.1. Test negative answers Algorithm 5
Query: realy-doesnotexist.dnssec-test.org. A
Answer: RCODE= NXDOMAIN, Empty Answer, Authority: NSEC proof
7.2. Test Algorithm 8
Query: alg-8-nsec3.dnssec-test.org. SOA
Answer: RCODE= 0, Answer: SOA record
7.3. Test Algorithm 13
Query: alg-13-nsec.dnssec-test.org. SOA
Answer: RCODE= 0, Answer: SOA record
7.4. Really fails when DNSSEC does not validate
Query: dnssec-failed.org. SOA
Answer: RCODE=SERVFAIL, empty answer, and authority, AD=0
8. Security Considerations
This document discusses problems that may occur while deploying the This document discusses problems that may occur while deploying the
secure DNSSEC protocol and what mitigation's can be used to help secure DNSSEC protocol and what mitigation's can be used to help
detect and mitigate these problems. Following these suggestions will detect and mitigate these problems. Following these suggestions will
result in a more secure DNSSEC operational environment than if DNSSEC result in a more secure DNSSEC operational environment than if DNSSEC
was simply disabled when it fails to perform as expected. was simply disabled when it fails to perform as expected.
8. IANA Considerations 9. IANA Considerations
No IANA actions are required. No IANA actions are required.
9. Normative References 10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, March 2005.
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
Security (DNSSEC) Hashed Authenticated Denial of Security (DNSSEC) Hashed Authenticated Denial of
Existence", RFC 5155, March 2008. Existence", RFC 5155, March 2008.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP
152, RFC 5625, August 2009. 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
<http://www.rfc-editor.org/info/rfc5625>.
Authors' Addresses Authors' Addresses
Wes Hardaker Wes Hardaker
Parsons Parsons
P.O. Box 382 P.O. Box 382
Davis, CA 95617 Davis, CA 95617
US US
Email: ietf@hardakers.net Email: ietf@hardakers.net
 End of changes. 30 change blocks. 
40 lines changed or deleted 122 lines changed or added

This html diff was produced by rfcdiff 1.44. The latest version is available from http://tools.ietf.org/tools/rfcdiff/