draft-ietf-dnsop-dnssec-roadblock-avoidance-01.txt   draft-ietf-dnsop-dnssec-roadblock-avoidance-02.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: March 06, 2015 Shinkuro Inc. Expires: January 02, 2016 CloudFlare
S. Krishnaswamy S. Krishnaswamy
Parsons Parsons
September 02, 2014 July 01, 2015
DNSSEC Roadblock Avoidance DNSSEC Roadblock Avoidance
draft-ietf-dnsop-dnssec-roadblock-avoidance-01.txt draft-ietf-dnsop-dnssec-roadblock-avoidance-02.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 March 06, 2015. This Internet-Draft will expire on January 02, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Implementation experiences . . . . . . . . . . . . . . . 3
1.3. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Detecting DNSSEC Non-Compilance . . . . . . . . . . . . . . . 4 3. Detecting DNSSEC Non-Compilance . . . . . . . . . . . . . . . 4
3.1. Determining DNSSEC support in neighboring recursive 3.1. Determining DNSSEC support in neighboring recursive
resolvers . . . . . . . . . . . . . . . . . . . . . . . . 4 resolvers . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Supports UDP answers . . . . . . . . . . . . . . . . 4 3.1.1. Supports UDP answers . . . . . . . . . . . . . . . . 5
3.1.2. Supports TCP answers . . . . . . . . . . . . . . . . 5 3.1.2. Supports TCP answers . . . . . . . . . . . . . . . . 5
3.1.3. Supports EDNS0 . . . . . . . . . . . . . . . . . . . 5 3.1.3. Supports EDNS0 . . . . . . . . . . . . . . . . . . . 5
3.1.4. Supports the DO bit . . . . . . . . . . . . . . . . . 5 3.1.4. Supports the DO bit . . . . . . . . . . . . . . . . . 6
3.1.5. Supports the AD bit . . . . . . . . . . . . . . . . . 6 3.1.5. Supports the AD bit . . . . . . . . . . . . . . . . . 6
3.1.6. Returns RRsig for signed answer . . . . . . . . . . . 6 3.1.6. Returns RRsig for signed answer . . . . . . . . . . . 6
3.1.7. Supports querying for DNSKEY records . . . . . . . . 6 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 . . . . . . . . . . 7
3.1.9. Supports negative answers with NSEC records . . . . . 7 3.1.9. Supports negative answers with NSEC records . . . . . 8
3.1.10. Supports negative answers with NSEC3 records . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.12. Permissive DNSSEC . . . . . . . . . . . . . . . . . . 8 3.1.12. Permissive DNSSEC . . . . . . . . . . . . . . . . . . 9
3.1.13. UDP size limits . . . . . . . . . . . . . . . . . . . 8 3.1.13. UDP size limits . . . . . . . . . . . . . . . . . . . 9
3.1.14. Supports Unknown RRtypes . . . . . . . . . . . . . . 8 3.1.14. Supports Unknown RRtypes . . . . . . . . . . . . . . 9
3.2. Direct Network Queries . . . . . . . . . . . . . . . . . 9 3.2. Direct Network Queries . . . . . . . . . . . . . . . . . 9
3.2.1. Support for Remote UDP Over Port 53 . . . . . . . . . 9 3.2.1. Support for Remote UDP Over Port 53 . . . . . . . . . 9
3.2.2. Support for Remote UDP With Fragmentation . . . . . . 9 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 . . . . . . . . 10
4. Aggregating The Results . . . . . . . . . . . . . . . . . . . 10 4. Aggregating The Results . . . . . . . . . . . . . . . . . . . 11
4.1. Resolver capability description . . . . . . . . . . . . . 10 4.1. Resolver capability description . . . . . . . . . . . . . 11
5. Roadblock Avoidance . . . . . . . . . . . . . . . . . . . . . 11 5. Roadblock Avoidance . . . . . . . . . . . . . . . . . . . . . 12
5.1. Partial Resolver Usage . . . . . . . . . . . . . . . . . 13 5.1. Partial Resolver Usage . . . . . . . . . . . . . . . . . 14
5.1.1. Known Insecure Lookups . . . . . . . . . . . . . . . 13 5.1.1. Known Insecure Lookups . . . . . . . . . . . . . . . 14
5.1.2. Partial NSEC/NSEC3 Support . . . . . . . . . . . . . 14 5.1.2. Partial NSEC/NSEC3 Support . . . . . . . . . . . . . 14
6. Start-Up and Network Connectivity Issues . . . . . . . . . . 14 6. Start-Up and Network Connectivity Issues . . . . . . . . . . 14
6.1. What To Do . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. What To Do . . . . . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 9. Normative References . . . . . . . . . . . . . . . . . . . . 15
10. Normative References . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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 today is hampered by network components that Deployment of DNSSEC validation is hampered by network components
make it difficult or sometimes impossible for validating resolvers to that make it difficult or sometimes impossible for validating
effectively obtain the DNSSEC data they need. This can occur for resolvers to effectively obtain the DNSSEC data they need. This can
many different reasons including occur for many different reasons including
o Because neighboring recursive resolvers are not fully DNSSEC o Because neighboring recursive resolvers and DNS proxies [RFC5625]
compliant are not fully DNSSEC compliant
o Because resolvers are not even DNSSEC aware o Because resolvers are not even DNSSEC aware
o Because "middle-boxes" active block/restrict outbound traffic to o Because "middle-boxes" active block/restrict outbound traffic to
the DNS port (53) either UDP and/or TCP . the DNS port (53) either UDP and/or TCP .
o Network component in path does not allow UDP fragments o Network component in path does not allow UDP fragments
o etc... o etc...
This document talks about ways a Host Validator can detect the state This document talks about ways a Host Validator can detect the state
of the network it is attached to, and ways to hopefully circumvent of the network it is attached to, and ways to hopefully circumvent
the problems associated with the network defects it discovers. The the problems associated with the network defects it discovers. The
tests described in this document may be performed on any validating tests described in this document may be performed on any validating
resolver to detect and prevent problems. While these recomendations resolver to detect and prevent problems. While these recomendations
are mainly aimed at Host Validators it it prudent to perform these are mainly aimed at Host Validators it it prudent to perform these
test from regular Validatating Resolvers before enabling just to make test from regular Validatating Resolvers before enabling just to make
sure things work. sure things work.
1.2. Notation There are situations where a host can not talk directy to a Resolver
the tests below do not address how to overcome that. In these
situations it is not uncommon to get results that are not consistent.
This mainly happens when there are DNS proxies/forwarders between the
user and the actual resolvers.
1.2. Implementation experiences
Multiple lessons learned from multiple implementations led to the
development of this document, including (in alphabetical order)
DNSSEC-Tools' DNSSEC-Check, DNSSEC_Resolver_Check, dnssec-trigger,
FCC_Grade.
Detecting non-support for specified DNSKEY algorithms and DS digiest
algorithms is outside the scope of this document sample test tool:
https://github.com/ogud/DNSSEC_ALG_Check.
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
before using an upstream recursive resolver. before using an upstream recursive resolver.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Goals 2. Goals
The result of this work is intended to show how a Host Validator can This document is intended to show how a Host Validator can detect the
detect the capabilities of a nearby recursive resolver, and work capabilities of a nearby recursive resolver, and work around any
around any problems that could potentially affect DNSSEC resolution. problems that could potentially affect DNSSEC resolution. This
This enables the Host Validator to make use of the caching enables the Host Validator to make use of the caching functionality
functionality of the recursive resolver, which is desirable in that of the recursive resolver, which is desirable in that it decreases
it decreases network traffic and improves response times. network traffic and improves response times.
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.
skipping to change at page 4, line 36 skipping to change at page 4, line 51
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
connectivity. connectivity.
NOTE: when performing these tests we also assume that the path is
clear of "DNS interfering" crapware/middle-boxes, like stupid
firewalls, proxies, forwarders. Presence of such crap can easily
make the recursive resolver look bad. It is beond the scope of the
docuent as how to test around the interferance.
3.1. Determining DNSSEC support in neighboring recursive resolvers 3.1. Determining DNSSEC support in neighboring recursive resolvers
Ideally, a Host Validator can make use of the caching present in Ideally, a Host Validator can make use of the caching present in
neighboring recursive resolvers. This section discusses the tests neighboring recursive resolvers. This section discusses the tests
that a neighboring recursive resolver MUST pass in order to be fully that a neighboring recursive resolver MUST pass in order to be fully
usable as a near-by DNS cache. usable as a near-by DNS cache.
Unless stated otherwise, all of the following tests SHOULD have the Unless stated otherwise, all of the following tests SHOULD have the
recursive flag set when sending out a query and SHOULD be sent over recursive flag set when sending out a query and SHOULD be sent over
UDP. Unless otherwise stated, the tests MUST NOT have the DO bit set UDP. Unless otherwise stated, the tests MUST NOT have the DO bit set
skipping to change at page 8, line 41 skipping to change at page 9, line 19
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-a.test.dnssec-tools.org. badsign-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
TBD Strictly speaking nothing other than using TCP can be used to
overcome this. Thus the host should use TCP fallback when UDP query
times out.
3.1.14. Supports Unknown RRtypes 3.1.14. Supports Unknown RRtypes
Purpose: Some DNS Resolvers/gateways only support some RRtypes. This Purpose: Some DNS Resolvers/gateways only support some RRtypes. This
causes problems for applications that need recently defined types. causes problems for applications that need recently defined types.
Pre-requisite: "Supports UDP or TCP". Pre-requisite: "Supports UDP or TCP".
Test: Send a request for recently defined type or unknown type in the Test: Send a request for recently defined type or unknown type in the
20000-22000 range, that resolves to a server that will return answer 20000-22000 range, that resolves to a server that will return answer
skipping to change at page 10, line 32 skipping to change at page 11, line 14
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 TBD This section will group and label certain common results
Resolvers are classified into following broad behaviors: Resolvers are classified into following broad behaviors:
Validator: The resolver passes all DNSSEC tests and had the AD bit Validator: The resolver passes all DNSSEC tests and had the AD bit
appropriately set. appropriately set.
DNSSEC Aware: The resolver passes all DNSSEC tests, but does not DNSSEC Aware: The resolver passes all DNSSEC tests, but does not
appropriately set the AD bit on answers, indicating it is not appropriately set the AD bit on answers, indicating it is not
validating. A Host Validator will function fine using this validating. A Host Validator will function fine using this
resolver as a forwarder. resolver as a forwarder.
skipping to change at page 11, line 25 skipping to change at page 12, line 7
TCP: TCP not available TCP: TCP not available
SlowBig: UDP is size limited but TCP fallback works SlowBig: UDP is size limited but TCP fallback works
NoBig: TCP not available and UDP is size limited NoBig: TCP not available and UDP is size limited
Permissive: Passes data known to fail validation Permissive: Passes data known to fail validation
5. Roadblock Avoidance 5. Roadblock Avoidance
[Editors note: the goal of this document is to tie the above tests The goal of this document is to tie the above tests and aggregations
and aggregations to avoidance practices; however right now the "tie" to avoidance practices; however the document does not specify exactly
part of this text is known to be weak. The goal of this document is how to do that.
specifically to improve this tie as work on this document progresses]
Once we have determined what level of support is available in the Once we have determined what level of support is available in the
neighboring network, we can determine what MUST be done in order to neighboring network, we can determine what MUST be done in order to
effectively act as a validating resolver. This section discusses effectively act as a validating resolver. This section discusses
some of the options available given the results from the previous some of the options available given the results from the previous
sections. sections.
The general fallback approach can be described by the following The general fallback approach can be described by the following
sequence: sequence:
skipping to change at page 14, line 4 skipping to change at page 14, line 31
It MAY be possible to use Non-DNSSEC Capable caching resolvers in It MAY be possible to use Non-DNSSEC Capable caching resolvers in
careful ways if maximum optimization is desired. This section careful ways if maximum optimization is desired. This section
describes some of the advanced techniques that could be used to use a describes some of the advanced techniques that could be used to use a
resolver in at least a minimal way. Most of the time this would be resolver in at least a minimal way. Most of the time this would be
unnecessary, except in the case where none of the resolvers are fully unnecessary, except in the case where none of the resolvers are fully
compliant and thus the choices would be to use them at least compliant and thus the choices would be to use them at least
minimally or not at all (and no caching benefits would be available). minimally or not at all (and no caching benefits would be available).
5.1.1. Known Insecure Lookups 5.1.1. Known Insecure Lookups
If a resolver is Non-DNSSEC Capable but a section of the DNS tree has If a resolver is Non-DNSSEC Capable but a section of the DNS tree has
been determined to be Provably Insecure [RFC4035], then queries to been determined to be Provably Insecure [RFC4035], then queries to
this section of the tree MAY be sent through Non-DNSSEC Capable this section of the tree MAY be sent through Non-DNSSEC Capable
caching resolver. caching resolver.
5.1.2. Partial NSEC/NSEC3 Support 5.1.2. Partial NSEC/NSEC3 Support
TBD This is real uncommon and only affects old resolvers, that also lack
support for Unknown types, rendering them mostly useless and to be
avoided.
6. Start-Up and Network Connectivity Issues 6. Start-Up and Network Connectivity Issues
A number of scenarios will produce either short-term or long-term A number of scenarios will produce either short-term or long-term
connectivity issues with respect to DNSSEC validation. Consider the connectivity issues with respect to DNSSEC validation. Consider the
following cases: following cases:
Time Synchronization: Time synchronization problems can occure Time Synchronization: Time synchronization problems can occure
when a device which has been off for a period of time and the when a device which has been off for a period of time and the
clock is no longer in close synchronization with "real time" or clock is no longer in close synchronization with "real time" or
skipping to change at page 15, line 4 skipping to change at page 15, line 32
all DNS requests failing. This is the most secure route, but all DNS requests failing. This is the most secure route, but
causes the most operational grief for users. causes the most operational grief for users.
Turn off DNSSEC support until the network proves to be usable. Turn off DNSSEC support until the network proves to be usable.
This allows the user to continue using the network, at the This allows the user to continue using the network, at the
sacrifice of security. It also allows for a denial of security- sacrifice of security. It also allows for a denial of security-
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
TBD
7. IANA Considerations
No IANA actions are require to support this document 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
performed thus the device MAY have a policy of action, like continue
or fail.
8. Security Considerations 7. 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.
9. Acknowledgments 8. IANA Considerations
Multiple lessons learned from multiple implementations led to the
development of this document, including (in alphabetical order)
DNSSEC-Tools' DNSSEC-Check, DNSSEC_Resolver_Check, dnssec-trigger,
FCC_Grade.
The following people contributed to portions of this document in some No IANA actions are required.
fashion: ....
10. Normative References 9. 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
152, RFC 5625, August 2009.
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
Olafur Gudmundsson Olafur Gudmundsson
Shinkuro Inc. CloudFlare
4922 Fairmont Av, Suite 250 San Francisco, CA 94107
Bethesda, MD 20814
USA USA
Email: ogud@ogud.com Email: ogud@ogud.com
Suresh Krishnaswamy Suresh Krishnaswamy
Parsons Parsons
7110 Samuel Morse Dr 7110 Samuel Morse Dr
Columbia, MD 21046 Columbia, MD 21046
US US
 End of changes. 33 change blocks. 
64 lines changed or deleted 88 lines changed or added

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