draft-ietf-dnsext-dnsproxy-01.txt   draft-ietf-dnsext-dnsproxy-02.txt 
DNSEXT R. Bellis DNSEXT R. Bellis
Internet-Draft Nominet UK Internet-Draft Nominet UK
Intended status: BCP January 6, 2009 Intended status: BCP March 2, 2009
Expires: July 10, 2009 Expires: September 3, 2009
DNS Proxy Implementation Guidelines DNS Proxy Implementation Guidelines
draft-ietf-dnsext-dnsproxy-01 draft-ietf-dnsext-dnsproxy-02
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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 July 10, 2009. This Internet-Draft will expire on September 3, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
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 gateways 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. Label Compression . . . . . . . . . . . . . . . . . . . . 4 4.2. Label Compression . . . . . . . . . . . . . . . . . . . . 4
4.3. Unknown Resource Record Types . . . . . . . . . . . . . . 4 4.3. Unknown Resource Record Types . . . . . . . . . . . . . . 5
4.4. Packet Size Limits . . . . . . . . . . . . . . . . . . . . 5 4.4. Packet Size Limits . . . . . . . . . . . . . . . . . . . . 5
4.4.1. TCP Transport . . . . . . . . . . . . . . . . . . . . 5 4.4.1. TCP Transport . . . . . . . . . . . . . . . . . . . . 5
4.4.2. Extension Mechanisms for DNS (EDNS0) . . . . . . . . . 6 4.4.2. Extension Mechanisms for DNS (EDNS0) . . . . . . . . . 6
4.4.3. IP Fragmentation . . . . . . . . . . . . . . . . . . . 6 4.4.3. IP Fragmentation . . . . . . . . . . . . . . . . . . . 6
4.5. Secret Key Transaction Authentication for DNS (TSIG) . . . 7 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) . . . . . . . . . . . . . . . 8 5.2. Domain Name (DHCP Option 15) . . . . . . . . . . . . . . . 8
5.3. DHCP Leases . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. DHCP Leases . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6.1. Forgery Resilience . . . . . . . . . . . . . . . . . . . . 9 6.1. Forgery Resilience . . . . . . . . . . . . . . . . . . . . 9
6.2. Interface Binding . . . . . . . . . . . . . . . . . . . . 9 6.2. Interface Binding . . . . . . . . . . . . . . . . . . . . 10
6.3. Packet Filtering . . . . . . . . . . . . . . . . . . . . . 10 6.3. Packet Filtering . . . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Recent research ([SAC035], [DOTSE]) has found 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 gateways (and similar devices) contain DNS proxies which
incompatible in various ways with current DNS standards. are 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
maximum interoperability. maximum interoperability.
skipping to change at page 3, line 33 skipping to change at page 3, line 33
"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].
3. The Transparency Principle 3. The Transparency Principle
It is not considered practical for a simple DNS proxy to directly It is not considered practical for a simple DNS proxy to directly
implement all current and future DNS features. implement all current and future DNS features.
There are several reasons why this is the case: There are several reasons why this is the case:
o broadband routers usually have limited hardware resources o broadband gateways usually have limited hardware resources
o firmware upgrade cycles are long, and many users do not routinely o firmware upgrade cycles are long, and many users do not routinely
apply upgrades when they become available apply upgrades when they become available
o no-one knows what those future DNS features will be, nor how they o no-one knows what those future DNS features will be, nor how they
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
skipping to change at page 4, line 15 skipping to change at page 4, line 15
The role 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.
Except when required to enforce an active security or network policy
(such as maintaining a pre-authentication "walled garden"), end-users
SHOULD be able to send their DNS queries to specified upstream
resolvers. In this case, the proxy SHOULD NOT modify the packets in
any way except for modifying IP and TCP/UDP headers as required by
NAT.
4. Protocol Conformance 4. Protocol Conformance
4.1. Unexpected Flags and Data 4.1. Unexpected Flags and Data
The Transparency Principle above, when combined with Postel's The Transparency Principle above, when combined with Postel's
Robustness Principle [RFC0793], suggests that DNS proxies should not Robustness Principle [RFC0793], suggests that DNS proxies should not
arbitrarily reject or otherwise drop requests or responses based on arbitrarily reject or otherwise drop requests or responses based on
perceived non-compliance with standards. perceived non-compliance with standards.
For example, some proxies have been observed to drop any packet For example, some proxies have been observed to drop any packet
skipping to change at page 6, line 28 skipping to change at page 6, line 37
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.4.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 gateway'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 gateway, and then re-
fragmented (if necessary) as they're forwarded to the client fragmented (if necessary) as they're forwarded to the client
Option 1 above will cause compatibility problems with EDNS0 unless Option 1 above will cause compatibility problems with EDNS0 unless
the DNS client is configured to advertise an EDNS0 buffer size the DNS client is configured to advertise an EDNS0 buffer size
limited to 28 octets less than the MTU. Note that RFC 2671 does limited to 28 octets less than the MTU. Note that RFC 2671 does
recommend that the path MTU should be taken into account when using recommend that the path MTU should be taken into account when using
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 gateways SHOULD be capable of forwarding UDP packets up to
payload size of at least 4096 octets. a payload size of at least 4096 octets.
4.5. Secret Key Transaction Authentication for DNS (TSIG) 4.5. Secret Key Transaction Authentication for DNS (TSIG)
[RFC2845] defines TSIG, which is a mechanism for authenticating DNS [RFC2845] defines TSIG, which is a mechanism for authenticating DNS
requests and responses at the packet level. requests and responses at the packet level.
Any modifications made to the DNS portions of a TSIG-signed query or Any modifications made to the DNS portions of a TSIG-signed query or
response packet will cause a TSIG authentication failure. response packet (with the exception of the Query ID) will cause a
TSIG authentication failure.
DNS proxies MUST implement Section 4.7 of [RFC2845] and either DNS proxies MUST implement Section 4.7 of [RFC2845] and either
forward packets unchanged (as recommended above) or fully implement forward packets unchanged (as recommended above) or fully implement
TSIG. TSIG.
As per Section 4.3, DNS proxies SHOULD be capable of proxying packets As per Section 4.3, DNS proxies SHOULD be capable of proxying packets
containing TKEY [RFC2930] Resource Records. containing TKEY [RFC2930] Resource Records.
NB: any DNS proxy (such as those commonly found in WiFi hotspot NB: any DNS proxy (such as those commonly found in WiFi hotspot
"walled gardens") which transparently intercepts all DNS queries, and "walled gardens") which transparently intercepts all DNS queries, and
skipping to change at page 7, line 37 skipping to change at page 7, line 44
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.
5.1. Domain Name Server (DHCP Option 6) 5.1. Domain Name Server (DHCP Option 6)
Most routers default to supplying their own IP address in the DHCP Most gateways default to supplying their own IP address in the DHCP
"Domain Name Server" option [RFC2132]. The net result is that "Domain Name Server" option [RFC2132]. The net result is that
without explicit re-configuration many DNS clients will by default without explicit re-configuration many DNS clients will by default
send queries to the router's DNS proxy. This is understandable send queries to the gateway's DNS proxy. This is understandable
behaviour given that the correct upstream settings are not usually behaviour given that the correct upstream settings are not usually
known at boot time. known at boot time.
Most routers learn their own DNS settings via values supplied by an Most gateways learn their own DNS settings via values supplied by an
ISP via DHCP or PPP over the WAN interface. However whilst many ISP via DHCP or PPP over the WAN interface. However whilst many
routers do allow the end-user to override those values, some routers gateways do allow the end-user to override those values, some
only use those end-user supplied values to affect the proxy's own gateways only use those end-user supplied values to affect the
forwarding function, and do not offer these values via DHCP. proxy's own forwarding function, and do not offer these values via
DHCP.
When using such a device the only way to avoid using the DNS proxy is When using such a device the only way to avoid using the DNS proxy is
to hard-code the required values in the client operating system. to hard-code the required values in the client operating system.
This may be acceptable for a desktop system but it is inappropriate This may be acceptable for a desktop system but it is inappropriate
for mobile devices which are regularly used on many different for mobile devices which are regularly used on many different
networks. networks.
End users SHOULD be able to send their DNS queries directly to As per Section 3, end-users SHOULD be able to send their DNS queries
specified upstream resolvers, ideally without hard-coding those directly to specified upstream resolvers, ideally without hard-coding
settings in their stub resolver. those settings in their stub resolver.
It is therefore RECOMMENDED that routers SHOULD support end-user It is therefore RECOMMENDED that gateways SHOULD support end-user
configuration of values for the "Domain Name Server" DHCP option. configuration of values for the "Domain Name Server" DHCP option.
5.2. Domain Name (DHCP Option 15) 5.2. Domain Name (DHCP Option 15)
A significant amount of traffic to the DNS Root Name Servers is for A significant amount of traffic to the DNS Root Name Servers is for
invalid top-level domain names, and some of that traffic can be invalid top-level domain names, and some of that traffic can be
attributed to particular equipment vendors whose firmware defaults attributed to particular equipment vendors whose firmware defaults
this DHCP option to specific values. this DHCP option to specific values.
Since no standard exists for a "local" scoped domain name suffix it Since no standard exists for a "local" scoped domain name suffix it
skipping to change at page 8, line 35 skipping to change at page 8, line 44
empty, and that this option SHOULD NOT be sent to clients when no empty, and that this option SHOULD NOT be sent to clients when no
value is configured. value is configured.
5.3. DHCP Leases 5.3. DHCP Leases
It is noted that some DHCP servers in broadband gateways by default It is noted that some DHCP servers in broadband gateways by default
offer their own IP address for the "Domain Name Server" option (as offer their own IP address for the "Domain Name Server" option (as
describe above) but then automatically start offering the upstream describe above) but then automatically start offering the upstream
settings once they've been learnt over the WAN interface. settings once they've been learnt over the WAN interface.
In general this behaviour is desirable, but the effect for the end- In general this behaviour is highly desirable, but the effect for the
user is that the settings used depend on whether the DHCP lease was end-user is that the settings used depend on whether the DHCP lease
obtained before or after the WAN link was established. was obtained before or after the WAN link was established.
If the DHCP lease is obtained whilst the WAN link is down then the If the DHCP lease is obtained whilst the WAN link is down then the
DHCP client (and hence the DNS client) will not receive the correct DHCP client (and hence the DNS client) will not receive the correct
values until the DHCP lease is renewed. values until the DHCP lease is renewed.
Whilst no specific recommendations are given here, vendors may wish Whilst no specific recommendations are given here, vendors may wish
to give consideration to the length of DHCP leases, and whether some to give consideration to the length of DHCP leases, and whether some
mechanism for forcing a DHCP lease renewal (i.e. by toggling the LAN mechanism for forcing a DHCP lease renewal might be appropriate.
port link state whenever the WAN link state changes from DOWN to UP)
might be appropriate.
Another possibility is that the learnt upstream values might be Another possibility is that the learnt upstream values might be
persisted in non-volatile memory such that on reboot the same values persisted in non-volatile memory such that on reboot the same values
can be automatically offered via DHCP. However this does run the can be automatically offered via DHCP. However this does run the
risk that incorrect values are initially offered if the device is risk that incorrect values are initially offered if the device is
moved or connected to another ISP. moved or connected to another ISP.
Alternatively, the DHCP server might only issue very short (i.e. 60
second) leases while the WAN link is down, only reverting to more
typical lease lengths once the WAN link is up and the upstream DNS
servers are known. Indeed with such a configuration it may be
possible to avoid the need to implement a DNS proxy function in the
broadband gateway at all.
6. Security Considerations 6. Security Considerations
This document introduces no new protocols. However there are some This document introduces no new protocols. However there are some
security related recommendations for vendors that are listed here. security related recommendations for vendors that are listed here.
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.
skipping to change at page 9, line 29 skipping to change at page 9, line 43
NB: Changing the Query ID is acceptable and compatible with proxying NB: Changing the Query ID is acceptable and compatible with proxying
TSIG-signed packets since the TSIG signature calculation is based on TSIG-signed packets since the TSIG signature calculation is based on
the original message ID which is carried in the TSIG RR. 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.
It is strongly RECOMMENDED that DNS proxies follow the relevant It is strongly RECOMMENDED that DNS proxies follow the relevant
recommendations in [I-D.ietf-dnsext-forgery-resilience], particularly recommendations in [RFC5452], particularly those in Section 9.2
those in Section 9.2 relating to randomisation of Query IDs and relating to randomisation of Query IDs and source ports. This also
source ports. applies to source port selection within any NAT function.
If a DNS proxy is running on a broadband gateway with NAT that is If a DNS proxy is running on a broadband gateway with NAT that is
compliant with [RFC4787] then it SHOULD also follow the compliant with [RFC4787] then it SHOULD also follow the
recommendations for how long DNS state is kept from Section 10 of recommendations for how long DNS state is kept from Section 10 of
[I-D.ietf-dnsext-forgery-resilience] [RFC5452]
6.2. Interface Binding 6.2. Interface Binding
Some routers have been observed to have their DNS proxy listening on Some gateways 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 gateway SHOULD NOT by default be accessible from
the WAN interfaces of the device. the WAN interfaces of the device.
6.3. Packet Filtering 6.3. Packet Filtering
The Transparency and Robustness Principles are not entirely The Transparency and Robustness Principles are not entirely
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
skipping to change at page 10, line 35 skipping to change at page 10, line 45
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-02
Changed "router" to "gateway" throughout (David Oran)
Updated forgery resilience reference
Elaboration on bypassability (from Nicholas W.)
Elaboration on NAT source port randomisation (from Nicholas W.)
Mention of using short DHCP leases while the WAN link is down
(from Ralph Droms)
Further clarification on permissibility of altering QID when using
TSIG
draft-ietf-dnsproxy-01 draft-ietf-dnsproxy-01
Strengthened recommendations about truncation (from Shane Kerr) Strengthened recommendations about truncation (from Shane Kerr)
New TSIG text (with help from Olafur) New TSIG text (with help from Olafur)
Additional forgery resilience text (from Olafur) Additional forgery resilience text (from Olafur)
Compression support (from Olafur) Compression support (from Olafur)
Correction of text re: QID changes and compatibility with TSIG 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).
skipping to change at page 11, line 16 skipping to change at page 11, line 37
9. Acknowledgements 9. Acknowledgements
The author would particularly like to acknowledge the assistance of The author would particularly like to acknowledge the assistance of
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]
Hubert, B. and R. Mook, "Measures for making DNS more
resilient against forged answers",
draft-ietf-dnsext-forgery-resilience-10 (work in
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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 12, line 20 skipping to change at page 12, line 34
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, March 2005.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. 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.
[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More
Resilient against Forged Answers", RFC 5452, January 2009.
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>.
[SAC035] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on [SAC035] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on
Broadband Routers and Firewalls", September 2008, Broadband Routers and Firewalls", September 2008,
<http://www.icann.org/committees/security/sac035.pdf>. <http://www.icann.org/committees/security/sac035.pdf>.
 End of changes. 31 change blocks. 
49 lines changed or deleted 68 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/