Internet Engineering Task Force W. Krecicki
Internet-Draft Internet Systems Consortium
Intended status: Standards Track October 19, 2015
Expires: April 21, 2016
Stateless DNS Encryption
draft-krecicki-dprive-dnsenc-01
Abstract
The DNS is the last common Internet protocol that has no encryption
scheme and therefore provides no privacy to the users. This document
proposes an extensible mechanism providing encryption of DNS queries
and responses with method for secure retrieval and verification of
validity of encryption keys. It is independent of the underlying
transport protocol.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2016.
Copyright Notice
Copyright (c) 2015 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Krecicki Expires April 21, 2016 [Page 1]
Internet-Draft Stateless DNS Encryption October 2015
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Communication process . . . . . . . . . . . . . . . . . . . . 3
2.1. Key retrieval . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Query creation . . . . . . . . . . . . . . . . . . . . . 4
2.2.1. Method 1 . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2. Method 2 . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Query processing . . . . . . . . . . . . . . . . . . . . 7
2.4. Response creation . . . . . . . . . . . . . . . . . . . . 7
2.5. Response processing . . . . . . . . . . . . . . . . . . . 8
3. Data types . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. NSK record . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. Wire format . . . . . . . . . . . . . . . . . . . . . 8
3.1.2. Presentation format . . . . . . . . . . . . . . . . . 10
3.2. DNSENC option . . . . . . . . . . . . . . . . . . . . . . 11
4. Encryption schemes . . . . . . . . . . . . . . . . . . . . . 11
4.1. Asymmetric schemes . . . . . . . . . . . . . . . . . . . 11
4.2. Symmetric schemes . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6.1. NSK RR type . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. DNSENC EDNS option . . . . . . . . . . . . . . . . . . . 12
6.3. ENCRYPT OpCode . . . . . . . . . . . . . . . . . . . . . 12
6.4. BADCRYPT RCODE . . . . . . . . . . . . . . . . . . . . . 13
6.5. DNSENC encryption schemes registry . . . . . . . . . . . 13
7. Normative References . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
The Domain Name System protocol is specified in [RFC1034] and
[RFC1035]. DNS messages are unencrypted and therefore prone to
eavesdropping. Although it's considered only metadata, there is a
lot of information that can be leaked, as explained by [RFC7626].
The DNS protocol is very lightweight - the queries are usually less
than 100 bytes long and the responses are usually less than 1000
bytes (even with DNSSEC). Existing transport encryption schemes such
as TLS for TCP or DTLS for UDP give a huge and unnecessary overhead
both in the amount of data sent and retrieved and in the number of
packets exchanged between client and server.
Krecicki Expires April 21, 2016 [Page 2]
Internet-Draft Stateless DNS Encryption October 2015
In DNSENC the query is encrypted using asymmetric cryptography with a
securely retrieved key and the response is encrypted using symmetric
encryption with a one-time key provided with the query. The DNSENC
protocol is uses standard DNS features and does not requires any
additional external mechanisms such as a PKI/CA system.
The DNSENC communication can be split into three phases:
o first the client retrieves public key for the server that is
stored in DNS and is DNSSEC signed; this key can then be cached,
o the client creates the query, adds a random response encryption
key and encrypts the query with the server's public key,
o the server decrypts the message, prepares the response and
encrypts it with the key provided by client.
It has to be noted that for a resolver to bootstrap itself, it has to
perform a clear text query to retrieve keys for DNSENC encryption.
As this query can be for information from the root zone, no sensitive
information is leaked.
In an usual case DNSENC will add no additional round-trips to
communication, besides the query for root zone servers' NSK record.
The message size overhead is around 140 bytes for encapsulation
(NOTE: that's using method described in Section 2.2.1), the maximum
amount of overhead for encryption depends on the method used and
varies from 16 bytes for AES to 512 bytes for RSA.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Communication process
2.1. Key retrieval
To communicate securely with a server, a client first needs to
retrieve the server's public key for asymmetric encryption. This key
is stored in an NSK RR described in Section 3.1. The NSK RRset might
contain multiple records. The key retrieval process is different for
authoritative servers and for recursive servers.
For authoritative servers a NSK RRset SHOULD be present at a
delegation point in the parent zone. If a NSK RRset is present at
the delegation point, the name server MUST return both the NSK RRset
Krecicki Expires April 21, 2016 [Page 3]
Internet-Draft Stateless DNS Encryption October 2015
and its associated RRSIG RR(s) in the Authority section along with
the NS RRset. This reduces the number of round-trips and allows all
communication with the child zone's servers to be encrypted.
All NSK RRsets MUST be signed with DNSSEC, and NSK RRsets MUST NOT
appear at a zone's apex.
example.com. 86400 IN NS a.iana-servers.net.
example.com. 86400 IN NS b.iana-servers.net.
example.com. 86400 IN NSK (...)
example.com. 86400 IN NSK (...)
example.com. 86400 IN RRSIG NSK (...)
For recursive servers and in cases where it is not possible to put
the NSK RRset for an authoritative server at a delegation point, the
NSK RRset SHOULD be present in the reverse DNS record of servers' IP
address, as described in [RFC3152], [RFC1033] and [RFC2317]. The
client MUST retrieve this RRset from the server it wants to query.
This RRset MUST be DNSSEC signed. For authoritative servers this
method is only a fallback and client MUST try to retrieve the key at
a delegation point first.
5.2.0.192.in-addr.arpa. 86400 IN NSK (...)
If the record is not signed the client MUST NOT use the key provided.
(TODO enforce encryption, protection against downgrade attack).
As there might be multiple NSK RRs in the RRSet it is the client
responsibility to choose the highest priority RR that has both query
and response schemes supported by the client.
2.2. Query creation
-----------------------------------------------
NOTE: two alternatives are currently under discussion. Both are
fully compatible with the DNS protocol. The first one is kind of a
kludge but has better chances to be compatible with not-fully-
protocol-compliant forwarders (although it still requires support for
EDNS). The second solution is cleaner but might not work with some
forwarders as the packet is not a regular DNS QUERY. The author
prefers the first method.
-----------------------------------------------
After choosing an encryption scheme, the client generates a random
response encryption key (symmetrical, eg. AES) and prepares a
Krecicki Expires April 21, 2016 [Page 4]
Internet-Draft Stateless DNS Encryption October 2015
regular DNS query with an NSK record containing the response
encryption scheme and key in the ADDITIONAL section, eg:
+-----------------------------------------+
Header | OPCODE=QUERY, ID=997, QR=QUERY |
+-----------------------------------------+
Question | QTYPE=A, QCLASS=IN, QNAME=EXAMPLE.COM |
+-----------------------------------------+
Answer | <empty> |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | . NSK IN NSK-RR |
+-----------------------------------------+
It has to be noted that this packet is never sent on the wire in raw
form, so records in the ADDITIONAL section have no impact on
compatibility with non-conforming forwarders.
2.2.1. Method 1
This message is encrypted using chosen query encryption key and
packed, along with encryption key ID, in a DNSENC OPTION, as
described in Section 3.2. A new query is created with:
o the query id copied from the encrypted message
o a <nonce>.dnsenc.arpa. TXT query in QUERY section, where <nonce>
is a random label that guarantees that should the response be
cached by a forwarder, it will not be reused for any other client.
o empty ANSWER and AUTHORITY sections
o a DNSENC OPTION in ADDITIONAL section
eg.:
Krecicki Expires April 21, 2016 [Page 5]
Internet-Draft Stateless DNS Encryption October 2015
+-----------------------------------------+
Header | OPCODE=QUERY, ID=997, QR=QUERY |
+-----------------------------------------+
Question | QTYPE=TXT, QCLASS=IN, |
| QNAME=<nonce>.dnsenc.arpa |
+-----------------------------------------+
Answer | <empty> |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | EDNS0 OPT OPTION-CODE=DNSENC |
\ OPTION-DATA=DNSENC-PAYLOAD \
| |
+-----------------------------------------+
...and sent to server. The response encryption key is stored on
client along its identifier for decryption.
2.2.2. Method 2
This message is encrypted using query encryption key and packed
inside a query withi the OPCODE set to ENCRYPT:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| ENCRYPT | Z | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ENCRYPTED PAYLOAD LENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RESERVED |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RESERVED |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RESERVED |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ENCRYPTION KEY ID |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ ENCRYPTED PAYLOAD /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
i...and sent to server. The response encryption key is stored on
client along its identifier for decryption.
Krecicki Expires April 21, 2016 [Page 6]
Internet-Draft Stateless DNS Encryption October 2015
2.3. Query processing
When a server supporting DNSENC receives a query for any name in the
"dnsenc.arpa." domain it MUST immediately look in ADDITIONAL section
for DNSENC OPTION. If the DNSENC OPTION is missing the server MUST
respond with a status of REFUSED. The DNSENC OPTION is then decoded.
If the server does not have a key with identifier provided in query
or the decryption failed the server MUST respond with BADCRYPT
response. If the data contained in the decrypted packet is invalid
or the query ID is not the same as the encapsulating packet query ID
the server MUST respond with FORMERR response.
A server that does not support DNSENC should respond with REFUSED
response code, although old implementations not supporting [RFC6891]
might return FORMERR.
A forwarder/proxy MUST pass the message untouched (along with the
DNSENC OPTION in the ADDITIONAL section) - as described in [RFC5625].
A forwarder/proxy MUST NOT cache a result for anything within
"dnsenc.arpa." domain.
2.4. Response creation
-----------------------------------------------
NOTE: this section describes creating the response for a query
described in Section 2.2.1, the method for creating a response for a
query described in Section 2.2.2 is analogous but will be described
here iff WG decides to go ahead with this method.
-----------------------------------------------
After decryption, the NSK record from the query is saved and the
query is processed normally. When the response is ready, a regular
DNS response packet is created. This packet is encrypted using
previously saved response encryption key sent by client and stored
along with the response encryption key ID (to keep the response in
the same format as query) in a DNSENC OPTION. A new response packet
is created with:
o the query ID same as in encrypted packet
o the QUESTION section copied from original query
o an empty ANSWER and AUTHORITY sections
o a DNSENC Option in EDNS(0) OPT RR in the ADDITIONAL section
containing the encrypted respose to the "real" query.
Krecicki Expires April 21, 2016 [Page 7]
Internet-Draft Stateless DNS Encryption October 2015
eg.
+-----------------------------------------+
Header | OPCODE=QUERY, ID=997, QR=RESPONSE |
+-----------------------------------------+
Question | QTYPE=TXT, QCLASS=IN, |
| QNAME=<nonce>.dnsenc.arpa |
+-----------------------------------------+
Answer | <empty> |
+-----------------------------------------+
Authority | <empty> |
+-----------------------------------------+
Additional | EDNS0 OPT OPTION-CODE=DNSENC |
\ OPTION-DATA=DNSENC-PAYLOAD \
| |
+-----------------------------------------+
This is then sent back to the client.
2.5. Response processing
TODO
3. Data types
3.1. NSK record
The NSK RR consist of priority field, key identifier, server names
for which the key can be used (wildcard '*' is supported, empty value
means all servers for the zone), query encryption scheme
(asymmetrical, eg. rsaes-oaep-2048), query key data and possible
response encryption schemes. If the server provides multiple NSK
records, it is the client's responsibility to choose the highest
priority NSK that has query and response encryption schemes supported
by client.
3.1.1. Wire format
The NSK RR has following format:
Krecicki Expires April 21, 2016 [Page 8]
Internet-Draft Stateless DNS Encryption October 2015
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| KEY IDENTIFIER |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PRIORITY | RESERVED |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ APPLICABLE NS NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ENCRYPTION SCHEME |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| KEY LENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ KEY DATA /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NUMBER OF RESPONSE ENCRYPTION SCHEMES |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RESPONSE ENCRYPTION SCHEME 1 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RESPONSE ENCRYPTION SCHEME 2 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ ... +
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RESPONSE ENCRYPTION SCHEME N |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
KEY IDENTIFIER 32-bit key identifier, unique for server
PRIORITY 8-bit key priority as preferred by server
APPLICABLE NS NAME a <domain-name> of NSes that use this
key. This allows for different NSes for
a zone to use different keysets (eg. when
the secondary is operated by different
entity than primary). This field might
contain wildcard symbol '*' at any place
(including as a part of a single label -
eg. 'ns*.foo*bar.example.com'), which
matches zero or more characters and can
cross label boundaries ('ns*.example.com'
Krecicki Expires April 21, 2016 [Page 9]
Internet-Draft Stateless DNS Encryption October 2015
matches 'ns.example.com',
'ns1.example.com' and
'ns1.foobar.example.com'), single '*'
means any.
ENCRYPTION SCHEME 16-bit identifier of the encryption
scheme, as defined in [TBD IANA REGISTRY]
KEY DATA encryption key - raw binary data
RESPONSE ENCRYPTION SCHEMES list of 16-bit identifiers of response
encryption schemes, as defined in [TBD
IANA REGISTRY], in order of server
preference from most preferred
For NSK records retrieved by a resolver as described in Section 2.1
ENCRYPTION SCHEME describes the scheme used by client to encrypt the
query, which MUST be an asymmetric one. RESPONSE ENCRYPTION SCHEMES
MUST contain at least one scheme, and all encryption schemes MUST be
symmetric.
For NSK records sent in the ADDITIONAL section of a query and used by
the server to encrypt response:
o PRIORITY MUST be set to 0
o APPLICABLE NS NAME MUST be empty
o ENCRYPTION SCHEME MUST be symmetric and be one from the list of
RESPONSE ENCRYPTION SCHEMES in a NSK record with key used to
encrypt this query.
o KEY DATA MUST be a one-time, random key
o RESPONSE ENCRYPTION SCHEMES MUST be empty
3.1.2. Presentation format
All numerical fields are presented in decimal form, query key data is
base64 encoded, encryption scheme can be represented as a number or
as a name, fields are in the same order as in wire format, eg:
Krecicki Expires April 21, 2016 [Page 10]
Internet-Draft Stateless DNS Encryption October 2015
example.com. 86400 IN NSK (896417428 ; identifier
10 ; priority
ns*.example.com ; applicable NS name
1 ; query encryption
; scheme
"bnJfZnJlZV9wYWdlcyAyMTU2NjgKbnJf
YWxsb2NfYmF0Y2ggNDE1OQpucl9pbmFj
dGl2ZV9hbm9uIDM1NzczNwpucl9hY3Rp
IDQ4OTAwMQpucl9kaXJ0eSAxMTUKbnJf
ZCAwCg==" ; query key, b64 encoded
32769 aes-256 ; response encryption
; schemes
)
3.2. DNSENC option
The encrypted packet is transmitted as an EDNS(0) option, with
OPTION-CODE set to DNSENC (value of [TBD]). The wire format of
OPTION-DATA for this option is:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| KEY IDENTIFIER |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ ENCRYPTED PAYLOAD /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The length of the encrypted payload is determined by the OPTION-
LENGTH field
4. Encryption schemes
This document defines basic encryption schemes to be used for query
and response encryption. Those schemes SHOULD be implemented by all
servers and clients.
4.1. Asymmetric schemes
TBD: RSAES-1024-EOAP, ECC as a default?
Krecicki Expires April 21, 2016 [Page 11]
Internet-Draft Stateless DNS Encryption October 2015
4.2. Symmetric schemes
TBD: AES-256
5. Security Considerations
The security of this protocol is based deeply on DNSSEC [RFC4033].
Protection against downgrade attack requires wide adoption of DNSSEC.
6. IANA Considerations
NOTE: as for now no actions with IANA has been taken.
6.1. NSK RR type
This document defines a new DNS Resource Record Type, named "NSK".
The IANA has assigned a code point from the "Resource Record (RR)
TYPEs" sub-registry of the "Domain Name System (DNS) Parameters"
registry for this record.
TYPE Value Meaning Reference
----- ------ -------------------------- -----------
NSK TBD Name Server Key [this document]
6.2. DNSENC EDNS option
This document defines a new EDNS option, named "DNSENC". The IANA
has assigned a code point from the "DNS EDNS0 Option Codes (OPT)"
sub-registry of the "Domain Name System (DNS) Parameters" registry
for this option. NOTE: this is required only for Section 2.2.1.
Value Name Status Reference
------- -------- --------- ----------------
[TBD] DNSENC Standard [this document]
6.3. ENCRYPT OpCode
This document defines a new DNS OPCODE, named "ENCRYPT". The IANA
has assigned a code point from the "DNS OpCodes" sub-registry of the
"Domain Name System (DNS) Parameters" registry for this opcode.
NOTE: this is required only for Section 2.2.2.
OpCode Name Reference
----- --------------------- --------------------------
TBD ENCRYPT [this document]
Krecicki Expires April 21, 2016 [Page 12]
Internet-Draft Stateless DNS Encryption October 2015
6.4. BADCRYPT RCODE
This document defines a new DNS RCODE, named "BADCRYPT". The IANA
has assigned a code point from the "DNS RCODEs" sub-registry of the
"Domain Name System (DNS) Parameters" registry for this opcode.
OpCode Name Description Reference
----- ------------ ------------------------- -------------------
TBD BADCRYPT Encryption error [this document]
6.5. DNSENC encryption schemes registry
The IANA has created and maintains a sub-registry (the "DNSENC
encryption schemes" registry) of the "Domain Name System (DNS)
Parameters" registry. The initial values for this registry are
below.
An "Expert Review" [RFC5226] is required for the assignment of new
scheme value (TBD: Expert or IETF? We should have a proper
definition of an encryption scheme).
This registry holds a set of 16-bit values identifying an encryption
scheme. First bit of first octet is set to 0 for asymmetric
encryption schemes, 1 for symmetric encryption schemes. First nibble
of second octet is set to 0xf for experimental or vendor-specific
schemes.
The initial assignments in this registry are:
Octet 1 Octet 2 Algorithm Reference
------- ------- ------------------------ ---------------
0x00 0x00 Reserved [this document]
0x00 0x01 RSAES-2048-OAEP [this document]
0x00 0x02 RSAES-4096-OAEP [this document]
0x80 0x00 Reserved [this document]
0x80 0x01 AES-256 [this document]
0x80 0x01 AES-512 [this document]
.... 0xf. experimental
or vendor-specific
7. Normative References
[RFC1033] Lottor, M., "Domain Administrators Operations Guide", RFC
1033, DOI 10.17487/RFC1033, November 1987,
<http://www.rfc-editor.org/info/rfc1033>.
Krecicki Expires April 21, 2016 [Page 13]
Internet-Draft Stateless DNS Encryption October 2015
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-
ADDR.ARPA delegation", BCP 20, RFC 2317, DOI 10.17487/
RFC2317, March 1998,
<http://www.rfc-editor.org/info/rfc2317>.
[RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, DOI
10.17487/RFC3152, August 2001,
<http://www.rfc-editor.org/info/rfc3152>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP
152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
<http://www.rfc-editor.org/info/rfc5625>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/
RFC6891, April 2013,
<http://www.rfc-editor.org/info/rfc6891>.
[RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
DOI 10.17487/RFC7626, August 2015,
<http://www.rfc-editor.org/info/rfc7626>.
Krecicki Expires April 21, 2016 [Page 14]
Internet-Draft Stateless DNS Encryption October 2015
Author's Address
Witold Krecicki
Internet Systems Consortium
950 Charter Street
Redwood City, CA 94063
USA
Email: wpk@isc.org
URI: http://www.isc.org
Krecicki Expires April 21, 2016 [Page 15]