draft-ietf-dnsext-dnsproxy-00.txt   draft-ietf-dnsext-dnsproxy-01.txt 
DNSEXT R. Bellis DNSEXT R. Bellis
Internet-Draft Nominet UK Internet-Draft Nominet UK
Intended status: BCP November 26, 2008 Intended status: BCP January 6, 2009
Expires: May 30, 2009 Expires: July 10, 2009
DNS Proxy Implementation Guidelines DNS Proxy Implementation Guidelines
draft-ietf-dnsext-dnsproxy-00 draft-ietf-dnsext-dnsproxy-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 30, 2009. This Internet-Draft will expire on July 10, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
This document provides guidelines for the implementation of DNS This document provides guidelines for the implementation of DNS
proxies, as found in broadband routers and other similar network proxies, as found in broadband routers and other similar network
devices. devices.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Transparency Principle . . . . . . . . . . . . . . . . . . 3 3. The Transparency Principle . . . . . . . . . . . . . . . . . . 3
4. Protocol Conformance . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Conformance . . . . . . . . . . . . . . . . . . . . . 4
4.1. Unexpected Flags and Data . . . . . . . . . . . . . . . . 4 4.1. Unexpected Flags and Data . . . . . . . . . . . . . . . . 4
4.2. Unknown Resource Record Types . . . . . . . . . . . . . . 4 4.2. Label Compression . . . . . . . . . . . . . . . . . . . . 4
4.3. Packet Size Limits . . . . . . . . . . . . . . . . . . . . 4 4.3. Unknown Resource Record Types . . . . . . . . . . . . . . 4
4.3.1. TCP Transport . . . . . . . . . . . . . . . . . . . . 5 4.4. Packet Size Limits . . . . . . . . . . . . . . . . . . . . 5
4.3.2. Extension Mechanisms for DNS (EDNS0) . . . . . . . . . 5 4.4.1. TCP Transport . . . . . . . . . . . . . . . . . . . . 5
4.3.3. IP Fragmentation . . . . . . . . . . . . . . . . . . . 6 4.4.2. Extension Mechanisms for DNS (EDNS0) . . . . . . . . . 6
4.4. Secret Key Transaction Authentication for DNS (TSIG) . . . 6 4.4.3. IP Fragmentation . . . . . . . . . . . . . . . . . . . 6
4.5. Secret Key Transaction Authentication for DNS (TSIG) . . . 7
5. DHCP's Interaction with DNS . . . . . . . . . . . . . . . . . 7 5. DHCP's Interaction with DNS . . . . . . . . . . . . . . . . . 7
5.1. Domain Name Server (DHCP Option 6) . . . . . . . . . . . . 7 5.1. Domain Name Server (DHCP Option 6) . . . . . . . . . . . . 7
5.2. Domain Name (DHCP Option 15) . . . . . . . . . . . . . . . 7 5.2. Domain Name (DHCP Option 15) . . . . . . . . . . . . . . . 8
5.3. DHCP Leases . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. DHCP Leases . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6.1. Forgery Resilience . . . . . . . . . . . . . . . . . . . . 8 6.1. Forgery Resilience . . . . . . . . . . . . . . . . . . . . 9
6.2. Interface Binding . . . . . . . . . . . . . . . . . . . . 9 6.2. Interface Binding . . . . . . . . . . . . . . . . . . . . 9
6.3. Packet Filtering . . . . . . . . . . . . . . . . . . . . . 9 6.3. Packet Filtering . . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 12
1. Introduction 1. Introduction
Recent research ([SAC035], [DOTSE]) has shown that many commonly-used Recent research ([SAC035], [DOTSE]) has found that many commonly-used
broadband routers (and similar devices) contain DNS proxies which are broadband routers (and similar devices) contain DNS proxies which are
incompatible in various ways with current DNS standards. incompatible in various ways with current DNS standards.
These proxies are usual simple DNS forwarders, but do not usually These proxies are usual simple DNS forwarders, but do not usually
have any caching capabilities. The proxy serves as a convenient have any caching capabilities. The proxy serves as a convenient
default DNS resolver for clients on the LAN, but relies on an default DNS resolver for clients on the LAN, but relies on an
upstream resolver (e.g. at an ISP) to perform recursive DNS lookups. upstream resolver (e.g. at an ISP) to perform recursive DNS lookups.
This documents describes the incompatibilities that have been This documents describes the incompatibilities that have been
discovered and offers guidelines to implementors on how to provide discovered and offers guidelines to implementors on how to provide
skipping to change at page 3, line 47 skipping to change at page 3, line 47
might be implemented might be implemented
o it would substantially complicate the configuration UI of the o it would substantially complicate the configuration UI of the
device device
Furthermore some modern DNS protocol extensions (see e.g. EDNS0, Furthermore some modern DNS protocol extensions (see e.g. EDNS0,
below) are intended to be used as "hop-by-hop" mechanisms. If the below) are intended to be used as "hop-by-hop" mechanisms. If the
DNS proxy is considered to be such a "hop" in the resolution chain DNS proxy is considered to be such a "hop" in the resolution chain
then for it to function correctly it would need to be fully compliant then for it to function correctly it would need to be fully compliant
with all such mechanisms. with all such mechanisms.
Research has shown that the more actively a proxy participates in the Research [SAC035] has shown that the more actively a proxy
DNS protocol then the more likely it is that it will somehow participates in the DNS protocol then the more likely it is that it
interfere with the flow of messages between the DNS client and the will somehow interfere with the flow of messages between the DNS
upstream recursive resolvers. client and the upstream recursive resolvers.
The task of the proxy SHOULD therefore be no more and no less than to The role of the proxy should therefore be no more and no less than to
receive DNS requests from clients on the LAN side, forward those receive DNS requests from clients on the LAN side, forward those
verbatim to one of the known upstream recursive resolvers on the WAN verbatim to one of the known upstream recursive resolvers on the WAN
side, and ensure that the whole response is returned verbatim to the side, and ensure that the whole response is returned verbatim to the
original client. original client.
It is RECOMMENDED that proxies should be as transparent as possible, It is RECOMMENDED that proxies should be as transparent as possible,
such that any "hop-by-hop" mechanisms or newly introduced protocol such that any "hop-by-hop" mechanisms or newly introduced protocol
extensions operate as if the proxy were not there. extensions operate as if the proxy were not there.
4. Protocol Conformance 4. Protocol Conformance
skipping to change at page 4, line 36 skipping to change at page 4, line 36
(CD) bits from DNSSEC [RFC4035]. This may be because [RFC1035] (CD) bits from DNSSEC [RFC4035]. This may be because [RFC1035]
originally specified that these unused "Z" flag bits "MUST" be zero. originally specified that these unused "Z" flag bits "MUST" be zero.
However these flag bits were always intended to be reserved for However these flag bits were always intended to be reserved for
future use, so refusing to proxy any packet containing these flags future use, so refusing to proxy any packet containing these flags
(now that uses for those flags have indeed been defined) is not (now that uses for those flags have indeed been defined) is not
appropriate. appropriate.
Therefore it is RECOMMENDED that proxies SHOULD ignore any unknown Therefore it is RECOMMENDED that proxies SHOULD ignore any unknown
DNS flags and proxy those packets as usual. DNS flags and proxy those packets as usual.
4.2. Unknown Resource Record Types 4.2. Label Compression
Compression of labels as per Section 4.1.4 of [RFC1035] is optional.
Proxies MUST forward packets regardless of the presence or absence of
compressed labels therein.
4.3. Unknown Resource Record Types
[RFC3597] requires that resolvers MUST handle Resource Records (RRs) [RFC3597] requires that resolvers MUST handle Resource Records (RRs)
of unknown type transparently. of unknown type transparently.
All requests and responses MUST be proxied regardless of the values All requests and responses MUST be proxied regardless of the values
of the QTYPE and QCLASS fields. of the QTYPE and QCLASS fields.
Similarly all responses MUST be proxied regardless of the values of Similarly all responses MUST be proxied regardless of the values of
the TYPE and CLASS fields of any Resource Record therein. the TYPE and CLASS fields of any Resource Record therein.
4.3. Packet Size Limits 4.4. Packet Size Limits
[RFC1035] specifies that the maximum size of the DNS payload in a UDP [RFC1035] specifies that the maximum size of the DNS payload in a UDP
packet is 512 octets. Where the required portions of a response packet is 512 octets. Where the required portions of a response
would not fit inside that limit the DNS server MUST set the would not fit inside that limit the DNS server MUST set the
"TrunCation" (TC) bit in the DNS response header to indicate that "TrunCation" (TC) bit in the DNS response header to indicate that
truncation has occurred. There are however two standard mechanisms truncation has occurred. There are however two standard mechanisms
(described below) for transporting responses larger than 512 octets. (described below) for transporting responses larger than 512 octets.
Many proxies have been observed to truncate all responses at 512 Many proxies have been observed to truncate all responses at 512
octets, and others at a packet size related to the WAN MTU, in either octets, and others at a packet size related to the WAN MTU, in either
case doing so without correctly setting the TC bit. case doing so without correctly setting the TC bit.
Other proxies have been observed to incorrectly remove the TC bit in Other proxies have been observed to incorrectly remove the TC bit in
server responses which correctly had the TC bit set by the server. server responses which correctly had the TC bit set by the server.
If a DNS response is truncated but the TC bit is not set then client If a DNS response is truncated but the TC bit is not set then client
failures may result, in particular a naive DNS client library might failures may result, in particular a naive DNS client library might
suffer crashes due to reading beyond the end of the data actually suffer crashes due to reading beyond the end of the data actually
received. received.
Therefore if a proxy must unilaterally truncate a response then the Since UDP packets larger than 512 octets are now expected in normal
proxy MUST set the TC bit. Similarly, proxies MUST NOT remove the TC operation, proxies SHOULD NOT truncate UDP packets that exceed that
bit from responses. size. See Section 4.4.3 for recommendations for packet sizes
exceeding the WAN MTU.
4.3.1. TCP Transport If a proxy must unilaterally truncate a response then the proxy MUST
set the TC bit. Similarly, proxies MUST NOT remove the TC bit from
responses.
4.4.1. TCP Transport
Should a UDP query fail because of truncation the standard fail-over Should a UDP query fail because of truncation the standard fail-over
mechanism is to retry the query using TCP, as described in section mechanism is to retry the query using TCP, as described in section
6.1.3.2 of [RFC1123] . 6.1.3.2 of [RFC1123] .
DNS proxies SHOULD therefore be prepared to receive and forward DNS proxies SHOULD therefore be prepared to receive and forward
queries over TCP. queries over TCP.
Note that it is unlikely that a client would send a request over TCP Note that it is unlikely that a client would send a request over TCP
unless it had already received a truncated UDP response. Some unless it had already received a truncated UDP response. Some
"smart" proxies have been observed to first forward a request "smart" proxies have been observed to first forward a request
received over TCP to an upstream resolver over UDP, only for the received over TCP to an upstream resolver over UDP, only for the
response to be truncated, causing the proxy to retry over TCP. Such response to be truncated, causing the proxy to retry over TCP. Such
behaviour increases network traffic and causes delay in DNS behaviour increases network traffic and causes delay in DNS
resolution since the initial UDP request is doomed to fail. resolution since the initial UDP request is doomed to fail.
Therefore whenever a proxy receives a request over TCP, the proxy Therefore whenever a proxy receives a request over TCP, the proxy
SHOULD forward the query over TCP and SHOULD NOT attempt the same SHOULD forward the query over TCP and SHOULD NOT attempt the same
query over UDP first. query over UDP first.
4.3.2. Extension Mechanisms for DNS (EDNS0) 4.4.2. Extension Mechanisms for DNS (EDNS0)
The Extension Mechanism for DNS [RFC2671] was introduced to allow the The Extension Mechanism for DNS [RFC2671] was introduced to allow the
transport of larger DNS packets over UDP and also to allow for transport of larger DNS packets over UDP and also to allow for
additional request and response flags. additional request and response flags.
A client may send an OPT Resource Record (OPT RR) in the Additional A client may send an OPT Resource Record (OPT RR) in the Additional
Section of a request to indicate that it supports a specific receive Section of a request to indicate that it supports a specific receive
buffer size. The OPT RR also includes the "DNSSEC OK" (DO) flag used buffer size. The OPT RR also includes the "DNSSEC OK" (DO) flag used
by DNSSEC to indicate that DNSSEC-related RRs should be returned to by DNSSEC to indicate that DNSSEC-related RRs should be returned to
the client. the client.
However some proxies have been observed to either reject (with a However some proxies have been observed to either reject (with a
FORMERR response code) or black-hole any packet containing an OPT RR. FORMERR response code) or black-hole any packet containing an OPT RR.
As per Section 4.1 proxies SHOULD NOT refuse to proxy such packets. As per Section 4.1 proxies SHOULD NOT refuse to proxy such packets.
4.3.3. IP Fragmentation 4.4.3. IP Fragmentation
Support for UDP packet sizes exceeding the WAN MTU depends on the Support for UDP packet sizes exceeding the WAN MTU depends on the
router's algorithm for handling fragmented IP packets. Several router's algorithm for handling fragmented IP packets. Several
options are possible: options are possible:
1. fragments are dropped 1. fragments are dropped
2. fragments are forwarded individually as they're received 2. fragments are forwarded individually as they're received
3. complete packets are reassembled on the router, and then re- 3. complete packets are reassembled on the router, and then re-
fragmented (if necessary) as they're forwarded to the client fragmented (if necessary) as they're forwarded to the client
skipping to change at page 6, line 38 skipping to change at page 7, line 5
EDNS0. EDNS0.
Also, whilst the EDNS0 specification allows for a buffer size of up Also, whilst the EDNS0 specification allows for a buffer size of up
to 65535 octets, most common DNS server implementations do not to 65535 octets, most common DNS server implementations do not
support a buffer size above 4096 octets. support a buffer size above 4096 octets.
Therefore it is RECOMMENDED (whichever of options 2 or 3 above is in Therefore it is RECOMMENDED (whichever of options 2 or 3 above is in
use) that routers SHOULD be capable of forwarding UDP packets up to a use) that routers SHOULD be capable of forwarding UDP packets up to a
payload size of at least 4096 octets. payload size of at least 4096 octets.
4.4. Secret Key Transaction Authentication for DNS (TSIG) 4.5. Secret Key Transaction Authentication for DNS (TSIG)
[RFC2845] defines TSIG, which is a hop-by-hop mechanism for [RFC2845] defines TSIG, which is a mechanism for authenticating DNS
authenticating DNS requests and responses at the packet level. requests and responses at the packet level.
Whilst it's not impossible for a simple DNS proxy to implement TSIG Any modifications made to the DNS portions of a TSIG-signed query or
directly it is not advised since parsing and validating received response packet will cause a TSIG authentication failure.
packets is a computationally intensive task, best left to full-
featured DNS clients.
DNS proxies SHOULD be transparent to TSIG signed packets. DNS proxies MUST implement Section 4.7 of [RFC2845] and either
forward packets unchanged (as recommended above) or fully implement
TSIG.
Similarly, as per Section 4.2, DNS proxies SHOULD be capable to As per Section 4.3, DNS proxies SHOULD be capable of proxying packets
proxying packets containing TKEY [RFC2930] Resource Records containing TKEY [RFC2930] Resource Records.
NB: any DNS proxy (such as those commonly found in WiFi hotspot
"walled gardens") which transparently intercepts all DNS queries, and
which returns unsigned responses to signed queries, will also cause
TSIG authentication failures.
5. DHCP's Interaction with DNS 5. DHCP's Interaction with DNS
Whilst this document is primarily about DNS proxies, most consumers Whilst this document is primarily about DNS proxies, most consumers
rely on DHCP [RFC2131] to obtain network configuration settings. rely on DHCP [RFC2131] to obtain network configuration settings.
Such settings include the client machine's IP address, subnet mask Such settings include the client machine's IP address, subnet mask
and default gateway, but also include DNS related settings. and default gateway, but also include DNS related settings.
It is therefore appropriate to examine how DHCP affects client DNS It is therefore appropriate to examine how DHCP affects client DNS
configuration. configuration.
skipping to change at page 8, line 47 skipping to change at page 9, line 20
6.1. Forgery Resilience 6.1. Forgery Resilience
Whilst DNS proxies are not usually full-feature resolvers they Whilst DNS proxies are not usually full-feature resolvers they
nevertheless share some characteristics with them. nevertheless share some characteristics with them.
Notwithstanding the recommendations above about transparency many DNS Notwithstanding the recommendations above about transparency many DNS
proxies are observed to pick a new Query ID for outbound requests to proxies are observed to pick a new Query ID for outbound requests to
ensure that responses are directed to the correct client. ensure that responses are directed to the correct client.
NB: Changing the Query ID is acceptable and compatible with proxying
TSIG-signed packets since the TSIG signature calculation is based on
the original message ID which is carried in the TSIG RR.
It has been standard guidance for many years that each DNS query It has been standard guidance for many years that each DNS query
should use a randomly generated Query ID. However many proxies have should use a randomly generated Query ID. However many proxies have
been observed picking sequential Query IDs for successive requests. been observed picking sequential Query IDs for successive requests.
DNS proxies SHOULD follow the relevant recommendations in It is strongly RECOMMENDED that DNS proxies follow the relevant
[I-D.ietf-dnsext-forgery-resilience], particularly those in Section recommendations in [I-D.ietf-dnsext-forgery-resilience], particularly
9.2 relating to randomisation of Query IDs and source ports. those in Section 9.2 relating to randomisation of Query IDs and
source ports.
NB: Changing the Query ID is incompatible with transparent proxying If a DNS proxy is running on a broadband gateway with NAT that is
of any TSIG records since the TSIG signature includes the Query ID. compliant with [RFC4787] then it SHOULD also follow the
It SHOULD be avoided wherever possible. recommendations for how long DNS state is kept from Section 10 of
[I-D.ietf-dnsext-forgery-resilience]
6.2. Interface Binding 6.2. Interface Binding
Some routers have been observed to have their DNS proxy listening on Some routers have been observed to have their DNS proxy listening on
both internal (LAN) and external (WAN) interfaces. In this both internal (LAN) and external (WAN) interfaces. In this
configuration it is possible for the proxy to be used to mount configuration it is possible for the proxy to be used to mount
reflector attacks as described in [RFC5358] reflector attacks as described in [RFC5358]
The DNS proxy in a router SHOULD NOT by default be accessible from The DNS proxy in a router SHOULD NOT by default be accessible from
the WAN interfaces of the device. the WAN interfaces of the device.
skipping to change at page 9, line 36 skipping to change at page 10, line 18
compatible with the Deep Packet Inspection features of security compatible with the Deep Packet Inspection features of security
appliances such as firewalls which are intended to protect systems on appliances such as firewalls which are intended to protect systems on
the inside of a network from rogue traffic. the inside of a network from rogue traffic.
However a clear distinction may be made between traffic that is However a clear distinction may be made between traffic that is
intrinsically malformed and that which merely contains unexpected intrinsically malformed and that which merely contains unexpected
data. data.
Examples of malformed packets which MAY be dropped include: Examples of malformed packets which MAY be dropped include:
o invalid compression pointers (i.e. those that run forward of the o invalid compression pointers (i.e. those that point outside of the
current packet offset, or which might cause a parsing loop). current packet, or which might cause a parsing loop).
o incorrect counts for the Question, Answer, Authority and o incorrect counts for the Question, Answer, Authority and
Additional Sections (although care should be taken where Additional Sections (although care should be taken where
truncation is a possibility). truncation is a possibility).
Since dropped packets will cause the client to repeatedly retransmit Since dropped packets will cause the client to repeatedly retransmit
the original request, it is RECOMMENDED that proxies SHOULD instead the original request, it is RECOMMENDED that proxies SHOULD instead
return a suitable DNS error response to the client (i.e. SERVFAIL) return a suitable DNS error response to the client (i.e. SERVFAIL)
instead of dropping the packet completely. instead of dropping the packet completely.
7. IANA Considerations 7. IANA Considerations
This document requests no IANA actions. This document requests no IANA actions.
8. Change Log 8. Change Log
draft-ietf-dnsproxy-01
Strengthened recommendations about truncation (from Shane Kerr)
New TSIG text (with help from Olafur)
Additional forgery resilience text (from Olafur)
Compression support (from Olafur)
Correction of text re: QID changes and compatibility with TSIG
draft-ietf-dnsproxy-00 draft-ietf-dnsproxy-00
Changed recommended DPI error to SERVFAIL (from Jelte) Changed recommended DPI error to SERVFAIL (from Jelte)
Changed example for invalid compression pointers (from Wouter). Changed example for invalid compression pointers (from Wouter).
Note about TSIG implications of changing Query ID (from Wouter). Note about TSIG implications of changing Query ID (from Wouter).
Clarified TC-bit text (from Wouter) Clarified TC-bit text (from Wouter)
Extra text about proxy bypass (Nicholas W.) Extra text about proxy bypass (Nicholas W.)
draft-bellis-dnsproxy-00 draft-bellis-dnsproxy-00
Initial draft Initial draft
skipping to change at page 10, line 30 skipping to change at page 11, line 19
Lisa Phifer of Core Competence. In addition the author is grateful Lisa Phifer of Core Competence. In addition the author is grateful
for the feedback from the members of the DNSEXT Working Group. for the feedback from the members of the DNSEXT Working Group.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-dnsext-forgery-resilience] [I-D.ietf-dnsext-forgery-resilience]
Hubert, B. and R. Mook, "Measures for making DNS more Hubert, B. and R. Mook, "Measures for making DNS more
resilient against forged answers", resilient against forged answers",
draft-ietf-dnsext-forgery-resilience-09 (work in draft-ietf-dnsext-forgery-resilience-10 (work in
progress), November 2008. progress), December 2008.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
skipping to change at page 11, line 22 skipping to change at page 12, line 12
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, September 2000. RR)", RFC 2930, September 2000.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003. (RR) Types", RFC 3597, September 2003.
[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.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
Nameservers in Reflector Attacks", BCP 140, RFC 5358, Nameservers in Reflector Attacks", BCP 140, RFC 5358,
October 2008. October 2008.
10.2. Informative References 10.2. Informative References
[DOTSE] Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband [DOTSE] Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband
Routers", February 2008, Routers", February 2008,
<http://www.iis.se/docs/Routertester_en.pdf>. <http://www.iis.se/docs/Routertester_en.pdf>.
skipping to change at page 12, line 4 skipping to change at line 546
Ray Bellis Ray Bellis
Nominet UK Nominet UK
Edmund Halley Road Edmund Halley Road
Oxford OX4 4DQ Oxford OX4 4DQ
United Kingdom United Kingdom
Phone: +44 1865 332211 Phone: +44 1865 332211
Email: ray.bellis@nominet.org.uk Email: ray.bellis@nominet.org.uk
URI: http://www.nominet.org.uk/ URI: http://www.nominet.org.uk/
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 34 change blocks. 
59 lines changed or deleted 103 lines changed or added

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