< draft-dempsky-dnscurve-00.txt   draft-dempsky-dnscurve-01.txt >
Network Working Group M. Dempsky Network Working Group M. Dempsky
Internet-Draft OpenDNS, Inc. Internet-Draft OpenDNS, Inc.
Intended status: Standards Track August 26, 2009 Intended status: Standards Track February 26, 2010
Expires: February 27, 2010 Expires: August 30, 2010
DNSCurve: Link-level security for the Domain Name System DNSCurve: Link-Level Security for the Domain Name System
draft-dempsky-dnscurve-00 draft-dempsky-dnscurve-01
Abstract
This document describes DNSCurve, a protocol extension that adds
link-level security to the Domain Name System (DNS).
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 37
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 February 27, 2010. This Internet-Draft will expire on August 30, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document describes DNSCurve, a protocol extension that adds described in the BSD License.
link-level security to the Domain Name System (DNS).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Base-32 encoding . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Base-32 Encoding . . . . . . . . . . . . . . . . . . . . . . . 4
4. Encoding public keys in name server names . . . . . . . . . . . 5 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Nonce generation . . . . . . . . . . . . . . . . . . . . . . . 5 4. Encoding Public Keys in Name Server Names . . . . . . . . . . 5
6. DNSCurve expanded formats . . . . . . . . . . . . . . . . . . . 6 5. Nonce Generation . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Streamlined format . . . . . . . . . . . . . . . . . . . . 6 6. DNSCurve Expanded Formats . . . . . . . . . . . . . . . . . . 6
6.2. TXT format . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Streamlined Format . . . . . . . . . . . . . . . . . . . . 6
7. UDP and TCP . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. TXT Format . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Security considerations . . . . . . . . . . . . . . . . . . . . 9 7. UDP and TCP . . . . . . . . . . . . . . . . . . . . . . . . . 8
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. Normative references . . . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
DNSCurve adds link-level security to the Domain Name System (DNS). DNSCurve adds link-level security to the Domain Name System (DNS).
It includes a key distribution mechanism compatible with today's name It includes a key distribution mechanism compatible with today's name
server software and registry services, and two packet formats: a server software and registry services, and two packet formats: a
simple streamlined format requiring minimal packet overhead and a simple streamlined format requiring minimal space and processing
mostly backwards-compatible format intended for use with strict overhead and a mostly backwards-compatible format intended for use
firewalls and DNS proxies. with strict firewalls and DNS proxies.
DNSCurve packets include a cryptographic MAC to provide integrity and DNSCurve packets include a cryptographic MAC (aka authenticator) to
availability. Clients can be confident that verified responses came provide integrity and availability. Clients can be confident that
from the appropriate server and were not forged by a blind or even verified responses came from the appropriate server and were not
sniffing attacker, while servers can be confident that responses will forged by a blind or even sniffing attacker, while servers can be
not be replayed against other unintended clients. Additionally, confident that responses will not be replayed against other
DNSCurve packets are encrypted to provide some confidentiality. unintended clients. Additionally, DNSCurve packets are encrypted to
provide some confidentiality.
1.1. Terminology
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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Overview 2. Overview
DNSCurve uses Curve25519XSalsa20Poly1305, a particular combination of DNSCurve uses Curve25519XSalsa20Poly1305, a particular combination of
the Curve25519, Salsa20, and Poly1305 primitives as described in the Curve25519, Salsa20, and Poly1305 primitives as described in
[naclcrypto]. In particular, it is a cryptosystem featuring 256-bit [naclcrypto]. In particular, it is a cryptosystem featuring 256-bit
public and secret keys, 192-bit nonces, and 128-bit authenticators. public and secret keys, 192-bit nonces, and 128-bit authenticators.
Each DNSCurve client and server has a secret key and a corresponding Each DNSCurve client and server has a secret key and a corresponding
public key. DNSCurve servers distribute their public keys by public key. DNSCurve servers distribute their public keys by
encoding them in name server names embedded in standard DNS NS encoding them in name server names embedded in standard DNS NS
records. DNSCurve clients distribute their public keys by including records (as described in Section 4), while DNSCurve clients
them in their query packets. distribute their public keys by including them in their query
packets. (Additional mechanisms for key distribution like DNSSEC's
trust anchors and DLV are possible, but not defined by this
document.)
When a DNSCurve client is about to send a DNS query to a name server, When a DNSCurve client is about to send a DNS query to a name server,
if the name contains a DNSCurve public key, it can instead use this if the client knows a DNSCurve public key for that name server, it
public key along with its own secret key and a nonce to protect its MAY instead use that public key along with its own DNSCurve secret
query in a "cryptographic box" as described in [naclcrypto]. The key and a nonce to protect its query in a "cryptographic box" as
client then encodes this cryptographic box along with the nonce and described in [naclcrypto]. The client then encodes this
its own public key as an expanded DNSCurve query packet, which it cryptographic box along with the nonce and its own public key as an
sends to the DNSCurve server. expanded DNSCurve query packet, which it sends to the DNSCurve server
instead of the original DNS query.
Upon receiving a DNS query packet, a DNSCurve name server first Upon receiving a DNS query packet, a DNSCurve name server should
checks if it appears to be an expanded DNSCurve query packet. If first treat the packet as a DNSCurve query packet by extracting the
not, then it responds normally. Otherwise, it extracts the client's client's DNSCurve public key, nonce, and boxed query and trying to
DNSCurve public key, nonce, and boxed query, and attempts to open the open the box using the extracted public key and its own secret key.
box using the public key and nonce and its own secret key. If this However, if this fails (i.e., the packet is not formatted as an
fails (i.e., the authenticator is invalid), then the packet is not an expanded DNSCurve query packet or the box's authenticator is
expanded DNSCurve query packet, and the server responds as a normal invalid), then the server responds to the packet as a normal DNS
DNS query. packet.
Otherwise, if the unboxing succeeds, then the server discovers the Assuming the unboxing succeeds, then the server discovers the
client's original query packet. To send a response, the server client's original query packet. To send a response, the server
chooses a nonce extension to append to the client-chosen nonce, and chooses a nonce extension to append to the client-chosen nonce, and
protects its response packet in a cryptographic box using the same protects its response packet in a cryptographic box using the extend
keys and the extended nonce. The server then encodes this nonce and same keys used to unbox the client's DNS query. The server
cryptographic box as an expanded DNSCurve response packet, which it then encodes this cryptographic box as an expanded DNSCurve response
sends to the DNSCurve client. packet, which it sends to the DNSCurve client instead of the original
DNS response.
Meanwhile, the DNSCurve client waits for an expanded DNSCurve Meanwhile, the DNSCurve client waits for an expanded DNSCurve
response packet. If it receives a non-DNSCurve response packet, an response packet. If it receives a non-DNSCurve response packet, an
expanded DNSCurve response packet with an invalid nonce (i.e., not an expanded DNSCurve response packet with an invalid nonce (i.e., not an
extension of its original nonce) or an invalid cryptographic box extension of its original nonce) or an invalid cryptographic box
(i.e., cannot be opened using the same keys and the extended nonce), (i.e., cannot be opened using the same keys and the extended nonce),
then it discards the packet and continues waiting. Once it receives then it discards the packet and continues waiting. Once it receives
a valid expanded DNSCurve response packet, it opens the cryptographic a valid expanded DNSCurve response packet, it opens the cryptographic
box to discover the server's original DNS response. box to discover the server's original DNS response.
3. Base-32 encoding 3. Base-32 Encoding
Sometimes DNSCurve communicates arbitrary byte strings inside domain Sometimes DNSCurve communicates arbitrary byte strings inside domain
names. While the DNS protocol is 8-bit safe for names and labels names. While the DNS protocol is 8-bit safe for names and labels
(except for case-insensitive handling of ASCII alphabetic (except for case-insensitive handling of ASCII alphabetic
characters), many tools have trouble with arbitrary characters in characters), many tools have trouble with arbitrary characters in
domain names, in particular domain registrar software. To cope with domain names, in particular domain registrar software. To cope with
this limitation, DNSCurve encodes byte strings using a set of safe this limitation, DNSCurve encodes byte strings using a set of safe
alphanumeric characters. alphanumeric characters.
In DNSCurve's base-32 encoding, a byte string is interpreted as a In DNSCurve's base-32 encoding, a byte string is interpreted as a
skipping to change at page 5, line 25 skipping to change at page 5, line 32
| {0x88} | "84" | | {0x88} | "84" |
| {0x9f,0x0b} | "zw20" | | {0x9f,0x0b} | "zw20" |
| {0x17,0xa3,0xd4} | "rs89f" | | {0x17,0xa3,0xd4} | "rs89f" |
| {0x2a,0xa9,0x13,0x7e} | "b9b71z1" | | {0x2a,0xa9,0x13,0x7e} | "b9b71z1" |
| {0x7e,0x69,0xa3,0xef,0xac} | "ycu6urmp" | | {0x7e,0x69,0xa3,0xef,0xac} | "ycu6urmp" |
| {0xe5,0x3b,0x60,0xe8,0x15,0x62} | "5zg06nr223" | | {0xe5,0x3b,0x60,0xe8,0x15,0x62} | "5zg06nr223" |
| {0x72,0x3c,0xef,0x3a,0x43,0x2c,0x8f} | "l3hygxd8dt31" | | {0x72,0x3c,0xef,0x3a,0x43,0x2c,0x8f} | "l3hygxd8dt31" |
| {0x17,0xf7,0x35,0x09,0x41,0xe4,0xdc,0x01} | "rsxcm44847r30" | | {0x17,0xf7,0x35,0x09,0x41,0xe4,0xdc,0x01} | "rsxcm44847r30" |
+-------------------------------------------+------------------+ +-------------------------------------------+------------------+
4. Encoding public keys in name server names 4. Encoding Public Keys in Name Server Names
DNSCurve public keys are encoded in name server names as a 54-byte DNSCurve public keys are encoded in name server names as a 54-byte
label consisting of the magic string "uz5" followed by the first 51 label consisting of the magic string "uz5" followed by the first 51
bytes of the base-32 encoding of the public key. (Curve25519 public bytes of the base-32 encoding of the public key. (Curve25519 public
keys are actually 255-bit integers in little-endian, so the 52nd byte keys are actually 255-bit integers in little-endian, so the 52nd byte
of the base-32 encoding will always be "0".) of the base-32 encoding will always be "0".)
When a DNSCurve client is searching a name server name for a DNSCurve When a DNSCurve client is searching a name server name for a DNSCurve
public key, it MUST check every label for an encoded public key. If public key, it MUST check every label for an encoded public key. If
multiple public keys are found, the left-most label MUST be chosen. multiple public keys are found, the left-most label MUST be chosen.
String comparison with "uz5" MUST be performed case-insensitively. String comparison with "uz5" MUST be performed case-insensitively.
5. Nonce generation 5. Nonce Generation
For every request, DNSCurve clients generate a 96-bit nonce, and for For every request, DNSCurve clients generate a 96-bit nonce, and for
every response, DNSCurve servers generate a 96-bit nonce extension. every response, DNSCurve servers generate a 96-bit nonce extension.
Nonces MUST be unique for distinct packets for the same client-server Nonces MUST be unique for distinct packets for the same client-server
key pair. A simple way to achieve this is to choose a unique nonce key pair. A simple way to achieve this is to choose a unique nonce
for each packet and for each retransmission. Additionally, servers for each packet and for each retransmission. Additionally, servers
MUST use a non-zero nonce extension (because nonces are zero extended MUST use a non-zero nonce extension (because nonces are zero extended
in query packets). Clients and servers may otherwise generate nonces in query packets). However, subject to these constraints, clients
however they choose. and servers may generate nonces however they choose.
Two recommended ways to generate a 96-bit nonce or nonce extension Two recommended ways to generate a 96-bit nonce or nonce extension
are are
1. a 64-bit counter (starting at 1) followed by a 32-bit random 1. a 64-bit counter (starting at 1) followed by a 32-bit random
number and number and
2. a 64-bit timestamp (e.g., nanoseconds since 1970) followed by a 2. a 64-bit timestamp (e.g., nanoseconds since 1970) followed by a
32-bit random number. 32-bit random number.
In either case the 64-bit value MUST NOT decrease even if the In either case the 64-bit value MUST NOT decrease even if the
software restarts or the system clock jumps backwards. software restarts or the system clock jumps backwards.
If multiple clients or multiple servers share a DNSCurve secret key, If multiple clients or multiple servers share a DNSCurve secret key,
then they MUST make sure no two separate clients or servers generate then they MUST make sure no two separate clients or servers generate
the same nonce. A simple way to achieve this is to use nonce the same nonce. A simple way to achieve this is to use nonce
separation; e.g., one server uses only even nonces and the other uses separation; e.g., if two servers share a DNSCurve key pair, one
only odd nonces. server could use only even nonces and the other could use only odd
nonces.
6. DNSCurve expanded formats 6. DNSCurve Expanded Formats
DNSCurve defines two expanded formats: "streamlined" and "TXT". Each DNSCurve defines two expanded formats: "streamlined" and "TXT". Each
includes a format for expanded queries and a format for expanded includes a format for expanded queries and a format for expanded
responses. DNSCurve clients may send DNSCurve expanded queries using responses. DNSCurve clients may send DNSCurve expanded queries using
whichever format it chooses, but they are encouraged to use the whichever format it chooses, but they are encouraged to use the
streamlined format when possible. A DNSCurve server MUST support streamlined format when possible. A DNSCurve server MUST support
DNSCurve expanded queries in either format and MUST send expanded DNSCurve expanded queries in either format and MUST send expanded
responses using the corresponding format. responses using the corresponding format.
6.1. Streamlined format 6.1. Streamlined Format
An expanded query packet in streamlined format has the following An expanded query packet in streamlined format has the following
bytes: bytes:
o 8 bytes: the magic string "Q6fnvWj8". o 8 bytes: the magic string "Q6fnvWj8".
o 32 bytes: the client's DNSCurve public key. o 32 bytes: the client's DNSCurve public key.
o 12 bytes: a client-selected nonce for this packet. o 12 bytes: a client-selected nonce for this packet.
skipping to change at page 7, line 13 skipping to change at page 7, line 22
o 12 bytes: the client's nonce. o 12 bytes: the client's nonce.
o 12 bytes: a server-selected nonce extension. o 12 bytes: a server-selected nonce extension.
o A cryptographic box containing the original DNS response packet. o A cryptographic box containing the original DNS response packet.
Note that this streamlined response format does not repeat the Note that this streamlined response format does not repeat the
client's query name, and in particular does not repeat the client's client's query name, and in particular does not repeat the client's
public key. However, it does repeat the client's nonce. public key. However, it does repeat the client's nonce.
6.2. TXT format 6.2. TXT Format
The "TXT" format receives its name from the fact that expanded query The "TXT" format receives its name from the fact that expanded query
and response packets in this format appear to casual inspection to be and response packets in this format appear to casual inspection to be
standard DNS packets with two possible exceptions: 1) the query name standard DNS packets with two possible exceptions: 1) the query name
exceed 255 bytes and 2) the total packet may exceed 512 bytes. may exceed 255 bytes and 2) the total packet may exceed 512 bytes.
When encoding an expanded query packet in TXT format, a DNSCurve When encoding an expanded query packet in TXT format, a DNSCurve
client MUST create a DNS standard query packet with the AA, TC, RD, client MUST create a DNS standard query packet with the AA, TC, RD,
RA, Z, and RCODE bits cleared, a single entry in the question RA, Z, and RCODE bits cleared, a single entry in the question
section, and no records in the answer, authority records, or section, and no records in the answer, authority, or additional
additional records sections. The one question MUST be an Internet records sections. The one question MUST ask for Internet-class TXT
class question for TXT records for the query name constructed from records for the query name constructed from the concatenation of the
the concatenation of the following labels: following labels:
o One or more labels, each label before the last being exactly 50 o One or more labels, each label except the last being exactly 50
bytes, the last label being at most 50 bytes. The concatenation bytes, with the last label being at most 50 bytes. The
of these labels is the base-32 encoding of a 96-bit client- concatenation of these labels is the base-32 encoding of a 96-bit
selected nonce for this packet followed by a cryptographic box client-selected nonce for this packet followed by a cryptographic
containing the original DNS query packet. box containing the original DNS query packet.
o One 54-byte label: the client's DNSCurve public key, encoded as o One 54-byte label: the client's DNSCurve public key, encoded as
described in Section 4, except with the magic string "x1a" instead described in Section 4, except with the magic string "x1a" instead
of "uz5". of "uz5".
o Zero or more additional labels specifying the name of the zone o Zero or more additional labels specifying the name of the zone
served by this server; i.e., the owner name of the relevant NS served by this server; i.e., the owner name of the relevant NS
record. record.
A DNSCurve server SHOULD be lenient in decoding expanded query A DNSCurve server SHOULD be lenient in decoding expanded query
skipping to change at page 8, line 32 skipping to change at page 8, line 41
then tries again through TCP. Servers are not required to support then tries again through TCP. Servers are not required to support
TCP if no responses are above 512 bytes; clients are permitted to try TCP if no responses are above 512 bytes; clients are permitted to try
TCP only if the server has explicitly indicated truncation. TCP only if the server has explicitly indicated truncation.
DNSCurve does not require TCP support from servers that were not DNSCurve does not require TCP support from servers that were not
already supporting TCP. If the original DNS response packet is at already supporting TCP. If the original DNS response packet is at
most 512 bytes then the server is permitted to send the expanded most 512 bytes then the server is permitted to send the expanded
response packet as a UDP packet. DNSCurve clients are required to response packet as a UDP packet. DNSCurve clients are required to
set aside a 4096-byte buffer for receiving a UDP response packet. set aside a 4096-byte buffer for receiving a UDP response packet.
If the original DNS response packet is above 512 bytes then it is If the original DNS response packet is larger than 512 bytes then it
replaced by an explicitly truncated packet and the truncated packet is replaced by an explicitly truncated packet and the truncated
is protected by DNSCurve. In this case the client tries again by packet is protected by DNSCurve. In this case the client tries again
TCP, sending its DNSCurve query packet through TCP and receiving the by TCP, sending its DNSCurve query packet through TCP and receiving
DNSCurve response through TCP. the DNSCurve response through TCP.
TCP is considerably more expensive for clients and servers than UDP TCP is considerably more expensive for clients and servers than UDP
is, and TCP has no protection against denial of service, so server is, and TCP has no protection against denial of service, so server
administrators are advised to stay below 512 bytes if possible. administrators are advised to stay below 512 bytes if possible.
DNSCurve adds some denial-of-service protection for UDP but cannot do DNSCurve adds some denial-of-service protection for UDP but cannot do
anything to help TCP. anything to help TCP.
If a protected DNS query includes an EDNS0 OPT record, then the If a protected DNS query includes an EDNS0 OPT record, then the
payload size field refers to how large the original DNS response payload size field refers to how large the original DNS response
packet can be before encoding as a DNSCurve response packet. Clients packet can be before encoding as a DNSCurve response packet. Clients
MUST reduce the payload size they advertise to account for overhead MUST reduce the payload size they advertise to account for overhead
from encoding the response as an expanded response packet. If a from encoding the response as an expanded response packet. If a
server builds a response within the payload size limit, but cannot server builds a response within the payload size limit, but then
fit the encoded response in 4096 bytes, then it MAY silently discard cannot fit the encoded response in 4096 bytes, it MAY silently
the response. discard the response.
8. Security considerations Even when DNSCurve transactions take place over UDP, they may still
be vulnerable to denial-of-service attacks due to spoofed IP
fragments if response packets are large enough to require IP
fragmentation. Therefore, servers SHOULD try to keep response
packets within the path's MTU limits.
8. Security Considerations
The security of the Curve25519XSalsa20Poly1305 cryptosystem and its The security of the Curve25519XSalsa20Poly1305 cryptosystem and its
underlying cryptographic primitives is discussed in [naclcrypto]. In underlying cryptographic primitives is discussed in [naclcrypto]. In
summary, it is designed to meet the standard notions of privacy and summary, it is designed to meet the standard notions of privacy and
third-party unforgeability for a public-key authenticated-encryption third-party unforgeability for a public-key authenticated-encryption
scheme using nonces. scheme using nonces.
DNSCurve only provides link-level security between a client-server DNSCurve only provides link-level security between a client-server
pair. It does not attempt to ensure end-to-end security for queries pair. It does not attempt to ensure end-to-end security for queries
and responses relayed by untrusted DNS proxies and caches. and responses relayed by untrusted DNS proxies and caches.
9. IANA considerations DNSCurve clients are free to choose whether or not to use DNSCurve on
a per query basis; e.g., a client may decide to fallback to standard
DNS after a few failed DNSCurve queries. Of course, DNSCurve cannot
make any security guarantees for transactions that do not use
DNSCurve, so clients are encouraged to use DNSCurve if possible.
DNSCurve adds some confidentiality by encrypting DNS packet contents
but does not attempt to hide the length of the original DNS packet
nor the source or destination of the packet. Additionally, the TXT
format requires clients to reveal the zone they are querying.
9. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
10. Normative references 10. Acknowledgements
The DNSCurve protocol was first introduced by Dan Berstein. Thanks
also to Adam Langley and George Barwood for their contributions to
early DNSCurve implementations.
Much thanks for feedback regarding this draft from George Barwood,
Sjoerd Langkemper and Nikos Mavrogiannopoulos.
11. References
11.1. 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.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[naclcrypto] [naclcrypto]
Bernstein, D., "Cryptography in NaCl", March 2009. Bernstein, D., "Cryptography in NaCl", March 2009.
11.2. Informative References
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
Author's Address Author's Address
Matthew Dempsky Matthew Dempsky
OpenDNS, Inc. OpenDNS, Inc.
199 Fremont St, Fl 12 410 Townsend St, Suite 250
San Francisco, CA 94105-6629 San Francisco, CA 94107
US US
Phone: +1 415 680 3742 Phone: +1 415 680 3742
Email: matthew@dempsky.org Email: matthew@dempsky.org
 End of changes. 32 change blocks. 
95 lines changed or deleted 142 lines changed or added

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