Internet Engineering Task Force (IETF) Phillip Hallam-Baker
Internet-Draft Comodo Group Inc.
Intended Status: Standards Track May 9, 2014
Expires: November 10, 2014
Private-DNS
draft-hallambaker-privatedns-00
Abstract
This document describes Private DNS, a transport security mechanism
for the DNS protocol. The mechanism may be employed to secure
communication between a client and its resolver or between a resolver
and an authoritative server.
Service binding including key exchange is effected using the JSON
Service Connect (JCX) Protocol. DNS protocol messages are wrapped in
a new framing 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."
Copyright Notice
Copyright (c) 2014 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Hallam-Baker November 10, 2014 [Page 1]
Internet-Draft Private DNS May 2014
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Related Work . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 3
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Service Connection . . . . . . . . . . . . . . . . . . . 4
2.1.1. Example: Public Resolver . . . . . . . . . . . . . . 5
2.1.2. Example: Hybrid Resolver . . . . . . . . . . . . . . 6
2.2. Query Protocol Binding . . . . . . . . . . . . . . . . . 10
2.2.1. Message Binding. . . . . . . . . . . . . . . . . . . 11
2.2.2. Query Protocol Example . . . . . . . . . . . . . . . 11
2.2.3. Authentication Conformance . . . . . . . . . . . . . 14
2.2.4. Handling Multiple Requests . . . . . . . . . . . . . 15
3. Service Connection and Key Exchangee . . . . . . . . . . . . . 15
3.1. UDP Binding . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . 16
4. Security Considerationsns . . . . . . . . . . . . . . . . . . 16
4.1. Confidentialityty . . . . . . . . . . . . . . . . . . . . 16
4.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. Access . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Acnowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Hallam-Baker November 10, 2014 [Page 2]
Internet-Draft Private DNS May 2014
1. Introduction.
Recent events have required urgent consideration of privacy concerns
in Internet protocols. In particular the lack of confidentiality
controls in the DNS [RFC1035] protocol is of considerable concern.
This document describes Private-DNS, a security enhancement for the
DNS protocol that meets the principal use cases and requirements set
out in [I-D.hallambaker-dnse]. This enhancement provides for
encryption and authentication of the DNS protocol messages.
Private-DNS makes use of the JSON Service Connect (JCX) Protocol [I-
D.hallambaker-wsconnect] and introduces a new framing protocol.
1.1. Related Work
The proposal approach compliments the integrity controls provided by
DNSSEC [RFC4033]. While both provide integrity controls, the controls
provided by DNSSEC are based on digital signatures while this
proposal provides controls based on a Message Authentica Code
technique.
Like the Omnibroker protocol [I-D.hallambaker-omnibroker], this
proposal is built on JCX [I-D.hallambaker-wsconnect] but offers a low
level interface to the DNS protocol alone as opposed to a high level
interface to generalized discovery services. A client would use the
DNSE-JX interface in cases where retrieval of specific DNS resource
records is required. The OmniBroker protocol would be used in cases
where the client delegates the choice of discovery strategy to the
OmniBroker service.
1.2. Terminology
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [RFC2119]
1.3. Defined Terms
[[These terms are deliberately left blank here or else we will spend
time wordsmithing the defined term definitions rather than looking at
the protocol.]
Hallam-Baker November 10, 2014 [Page 3]
Internet-Draft Private DNS May 2014
Authoritative DNS Server
Caching Recursive Resolver
DNS
DNS Client
Recursive Resolver
Stub Resolver
2. Architecture
PRIVATE-DNS has two parts
* Service Connection
* DNS message encapsulation
In PRIVATE-DNS, the service connection is provided by the existing
[I-D.hallambaker-wsconnect] proposal. The DNS message encapsulation
is new and supports encryption and authentication of the DNS protocol
messages.
To make use of PRIVATE-DNS a client first establishes a connection to
a DNS server (resolver or authoritative) using the connection
protocol. Once a client has established a connection it MAY use it to
make as many queries as desired until either the connection context
expires or is cancelled by the service.
The Service Connection and Query Service MAY be operated on the same
host or on separate hosts.
2.1. Service Connection
The service connection mechanism is responsible for establishing a
connection context between a client and a service. The connection
context comprises:
* A security context (opaque identifier, key, algorithm choice)
between the client and the connection service
* One or more query host connection contexts, each
comprisingNetwork connection description (IP address, Port,
Protocol, transport)Security Context (opaque identifier, key,
algorithm choice) between the client and the query host
The PRIVATE-DNS proposal is designed on the assumption that Service
Connection transactions are relatively infrequent and thus the
efficiency of the Service Connection protocol is not a major concern.
Hallam-Baker November 10, 2014 [Page 4]
Internet-Draft Private DNS May 2014
Accordingly the Service Connection protocol is implemented as a
JSON/REST Web Service over HTTP. While of an efficient encoding (e.g.
[I-D.hallambaker-jsonbcd] would permit a more efficient
implementation of the protocol using UDP, such an approach would be
vulnerable to Denial of Service attacks against the service unless
appropriate countermeasures were taken. For example use of a 'cookie'
approach to prove the validity of the purported request source
address.
A service connection MAY return a host connection set that includes
multiple protocol and/or transport options. This has the important
consequence that it allows new message formats or a transition to an
entirely new protocol to be effected by simply defining a new
identifier.
A distinction is drawn between a connection to a service and a
connection to a host. A connection to a host is a relationship to a
specific instance of a service with a distinct IP address. A
connection to a service is a relationship to a set of hosts. This
distinction is an important one for Denial of Service mitigation. A
DNS service need not publish the same network connection description
to every client. This permits a service to mitigate DoS attacks by
filtering query requests by IP address, a strategy that is greatly
enhanced by the large address space of IPv6.
Different configurations of the Service Connection service allow a
DNS service to meet different combinations of security requirements.
For example the Public Resolver described in [U-PUBLIC] would not
require authentication of the client to the service but this would be
required for the Subscriber, Private and Hybrid Resolvers described
in [U-SUBSCRIBER], [U-PRIVATE] and [U-HYBRID].].
2.1.1. Example: Public Resolver
Following the use case [[U-PUBLIC] described in [I-D.hallambaker-
dnse], Alice buys a laptop for her personal use at home. To ensure
the privacy of her DNS connection she selects example.com, a public
resolver that provides DNS service without requiring any form of
subscription or registration.
During the initial configuration process, the machine uses the local
DNS advertised in the DCHP configuration for the first and last time
for discovery of the Service Connection Service of example.com.
Having discovered a Service Connection Service, the client requests a
service provider for the PRIVATE-DNS service by establishing a TLS
connection to indicated server. The server returns a TLS Certificate
that meets the authentication criteria of the client. Once the TLS
connection is established, an anonymous client connection is
established.
Hallam-Baker November 10, 2014 [Page 5]
Internet-Draft Private DNS May 2014
POST /.well-known/sxs-connect/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Host: localhost:8080
Content-Length: 226
Expect: 100-continue
{
"BindRequest": {
"Service": ["private-dns-resolver"],
"Encryption": ["A128CBC",
"A256CBC",
"A128GCM",
"A256GCM"],
"Authentication": ["HS256",
"HS384",
"HS512",
"HS256T128"]}}
Since the example.com service does not require authentication, the
request is granted immediately and the necessary host connection
parameters returned immediately:
HTTP/1.1 OK Success
Content-Length: 578
Date: Fri, 09 May 2014 20:58:44 GMT
Server: Microsoft-HTTPAPI/2.0
{
"TicketResponse": {
"Status": 200,
"StatusDescription": "Success",
"Cryptographic": [],
"Service": [{
"Service": "private-dns-resolver",
"Name": "localhost",
"Port": 9090,
"Priority": 100,
"Weight": 100,
"Transport": "UDP",
"Cryptographic": {
"Secret": "
SwVyt3p_tkMeneeYtqnw5g",
"Encryption": "A128CBC",
"Authentication": "HS256T128",
"Ticket": "
bH0q4n8XQOWbjStHsVCzAzS3fbkV2mbx-HUC8Bxw7r31HXcXRvPp4xWORxSo98N4
M6uklYZEEC5OvlYBQ0kETabpBz7-dYo7nYCD6yCFlvE"}}]}}
Hallam-Baker November 10, 2014 [Page 6]
Internet-Draft Private DNS May 2014
2.1.2. Example: Hybrid Resolver
Following the use case [U-HYBRID], Alice decides to use her personal
computer for work under her employer's 'Bring Your Own Device'
program. Alice needs access to multiple services within her
employer's intranet.
Her system administrator issues her an account name [TBS], a one time
use PIN [TBS] and the DNS address of the service connection service
byod.example.net. Having established a TLS connection as before, the
client makes an initial request:
Hallam-Baker November 10, 2014 [Page 7]
Internet-Draft Private DNS May 2014
POST /.well-known/sxs-connect/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Host: localhost:8080
Content-Length: 352
Expect: 100-continue
{
"OpenPINRequest": {
"Encryption": ["A128CBC",
"A256CBC",
"A128GCM",
"A256GCM"],
"Authentication": ["HS256",
"HS384",
"HS512",
"HS256T128"],
"Account": "alice",
"Service": ["private-dns-resolver"],
"Domain": "example.com",
"HaveDisplay": false,
"Challenge": "
YBr17dBu_lSDm4vY66rNBQ"}}
The server provides a challenge for verifying the one time use PIN.
HTTP/1.1 OK Success
Content-Length: 501
Date: Fri, 09 May 2014 20:58:44 GMT
Server: Microsoft-HTTPAPI/2.0
{
"OpenPINResponse": {
"Status": 200,
"StatusDescription": "Success",
"Challenge": "
_eIhopTZAfkQR-mW6Y1IPg",
"ChallengeResponse": "
qRNgrSFhP3g6j-h8vlsIXN8rB5zn8qxgrqRcSFAiT_Q",
"Cryptographic": {
"Secret": "
3RWt4aRqQUA2o82GCz8BXA",
"Encryption": "A128CBC",
"Authentication": "HS256",
"Ticket": "
QZnH_9rlynU2SorpMeVwuJ8CDVnMhye4lmCXVGKGBedFCApDByEtvYMiOYB5Cseh
ApY9xc7uFOrVPi9zyrMIrcbFFUCRU6HRPxfPxWgvcmZpVZJli_GKg9eHiyy5osEU
AAPKUwJEGY1TXGf0xDYdaw"}}}
Having obtained the challenge value from the service, the client
resends the initial request, having authenticated it this time under
Hallam-Baker November 10, 2014 [Page 8]
Internet-Draft Private DNS May 2014
the challenge and one time PIN:
POST /.well-known/sxs-connect/ HTTP/1.1
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Session: Value=bqbwaF3dLBxEvMeGiYeatBCtZLmdIRGleGhEYmmnkaw;
Id=QZnH_9rlynU2SorpMeVwuJ8CDVnMhye4lmCXVGKGBedFCApDByEtvYMiOYB5
CsehApY9xc7uFOrVPi9zyrMIrcbFFUCRU6HRPxfPxWgvcmZpVZJli_GKg9eHiyy
5osEUAAPKUwJEGY1TXGf0xDYdaw
Host: localhost:8080
Content-Length: 137
Expect: 100-continue
{
"TicketRequest": {
"Service": ["private-dns-resolver"],
"ChallengeResponse": "
mIr09oenHdiMji5i-sTX66KKzP_eXQAd6WXIgF3Y4uc"}}
The server returns a set of host connections for the requested
services. The scope of the PRIVATE-DNS service is limited to the
domain tree *.example.net:
Hallam-Baker November 10, 2014 [Page 9]
Internet-Draft Private DNS May 2014
HTTP/1.1 OK Success
Content-Length: 858
Date: Fri, 09 May 2014 20:58:44 GMT
Server: Microsoft-HTTPAPI/2.0
{
"TicketResponse": {
"Status": 200,
"StatusDescription": "Success",
"Cryptographic": [{
"Protocol": "sxs-connect",
"Secret": "
fIRiC7by_MNNyuam0f8yDQ",
"Encryption": "A128CBC",
"Authentication": "HS256",
"Ticket": "
W76CJuIWZVig0OQVT6eldIl02d4e-Zgv9YrYnTAPgNNIbdeN_2FY30KUwiRPjh2i
r-NWiZ2FICQ4ATi2r9oktpMSEeyPRFppvHE6tnPFe9U"}],
"Service": [{
"Service": "private-dns-resolver",
"Name": "localhost",
"Port": 9090,
"Priority": 100,
"Weight": 100,
"Transport": "UDP",
"Cryptographic": {
"Secret": "
Y1klIDYuNfyCIMiqWbQi2w",
"Encryption": "A128CBC",
"Authentication": "HS256T128",
"Ticket": "
w_aLDzTjGjHiEDeOFDypBlGfY8a9xdTOnIdAgr2SjyFA3A2T8nVOwwacB9NW4qh9
xmLLgDYNyFvNIwTxxJH2ER0HU95VyjNMyrSAAj1zfM8"}}]}}
2.2. Query Protocol Binding
The Query Protocol Binding is designed to efficiently support the
following features:
* Encryption
* Prevent use in an Denial of Service attack.
* Authentication
* Multiple DNS queries and responses per PRIVATE-DNS Query [[*]
* Multiple packet responses [[*]
Hallam-Baker November 10, 2014 [Page 10]
Internet-Draft Private DNS May 2014
The features marked [[*] are not essential for the purpose of meeting
the privacy requirements but considerably improve the efficiency and
flexibility of the DNS protocol. In particular the ability to make
multiple DNS queries in a single transaction over UDP transport
enables the use of novel discovery techniques without impact on
performance.
While the privacy requirements may be met through use of encryption
alone, any encoding that does not provide authentication of requests
allows a service to be used as an attack vector in a denial of
service attack on third parties.
The Query Protocol Binding wraps the [RFC1035] message structure
rather than eliminating parts that are redundant. For example, the
Query Protocol Binding Transaction ID which has a minimum length of
128 bits supplements rather than replaces the DNS message transaction
ID of 16 bytes.
2.2.1. Message Binding.
To ensure access to the DNS service in any network circumstance where
the protocol is intentionally blocked, two message transports are
specified:
UDP transport
The prefered transport providing low latency service.
HTTP Web Service
In a typical network environment where a MTU of at least 1280 bytes
is supported, the UDP transport supports DNS request messages of at
least 1100 bytes and responses of at least 18000 bytes.
Both transport bindings are specified in [I-D.hallambaker-wsconnect].
2.2.2. Query Protocol Example
Having established a connection to a Private-DNS service, the client
from the first example performs a DNS query:
www.example.com ? A
2.2.2.1. Key Derrivation
[TBS at the moment there is no key derrivation function specified and
the same key is used for encryption and authentication. This is a
weak approach architecturally as a compromise of one algorithm puts
the other at risk and should be fixed. Rather than use k as the key
we should use MAC ("encrypt", k) and MAC ("decrypt", k) or something
similar. However doing that right requires consulting past RFCs to
Hallam-Baker November 10, 2014 [Page 11]
Internet-Draft Private DNS May 2014
find the right derrivation function.]
Ticket value is:
6c 7d 2a e2 7f 17 40 e5 9b 8d 2b 47 b1 50 b3 03
34 b7 7d b9 15 da 66 f1 f8 75 02 f0 1c 70 ee bd
f5 1d 77 17 46 f3 e9 e3 15 8e 47 14 a8 f7 c3 78
33 ab a4 95 86 44 10 2e 4e be 56 01 43 49 04 4d
a6 e9 07 3e fe 75 8a 3b 9d 80 83 eb 20 85 96 f1
Master key is:
4b 05 72 b7 7a 7f b6 43 1e 9d e7 98 b6 a9 f0 e6
Authentication key is TBS (Master)
4b 05 72 b7 7a 7f b6 43 1e 9d e7 98 b6 a9 f0 e6
Encryption key is TBS (Master)
4b 05 72 b7 7a 7f b6 43 1e 9d e7 98 b6 a9 f0 e6
2.2.2.2. Request
The DNS Request is: [TBS this is a placeholder]
;; QUESTION SECTION:
example.com. IN A
In hex:
24 1a 01 00 00 01 00 00 00 00 00 00 03 77 77 77
07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00
01
The plaintext payload is
Segment(0)
Type code: 12
Segment length: 00 21
Data:
24 1a 01 00 00 01 00 00 00 00 00 00 03 77 77 77
07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00
01
Note that in a real world example, the request SHOULD be padded to a
fixed value (e.g. 1100 bytes) to prevent traffic analysis disclosing
the message contents. for illustrative purposes, a mimimal padding is
applied:
Hallam-Baker November 10, 2014 [Page 12]
Internet-Draft Private DNS May 2014
The request has the transaction ID which doubles as the
initialization vector of the encryption algorithm and ticket
identifier prepended and the MAC value appended:
Transaction ID: 10 (= 16 bytes)
23 bd d7 5e c0 eb a7 4d 85 92 fd 94 e0 05 85 a7
Ticket: 50 (= 80 bytes)
6c 7d 2a e2 7f 17 40 e5 9b 8d 2b 47 b1 50 b3 03
34 b7 7d b9 15 da 66 f1 f8 75 02 f0 1c 70 ee bd
f5 1d 77 17 46 f3 e9 e3 15 8e 47 14 a8 f7 c3 78
33 ab a4 95 86 44 10 2e 4e be 56 01 43 49 04 4d
a6 e9 07 3e fe 75 8a 3b 9d 80 83 eb 20 85 96 f1
Encrypted Data: 00 30 (= 48 bytes)
4c 16 ae b8 e1 8d f7 cf ab f1 d6 e7 d0 07 52 bc
96 ec a0 df f1 a9 bf fd e2 5c 7c 13 88 31 62 13
fc c3 a4 12 44 25 6a a2 6a fa 97 f7 57 97 fd ce
MAC: 10 (= 16 bytes)
a7 25 0b df 5a 10 bf ac 39 99 b7 6c 19 d2 1d e8
2.2.2.3. Response
The recursive resolver locates the records and returns the response.
The DNS Response is [TBS this is a placeholder]
;; ANSWER SECTION:
example.com. 38400 IN A 192.168.1.20
;; AUTHORITY SECTION:
example.com. 38400 IN NS ns1.example.com.
;; ADDITIONAL SECTION:
ns1.example.com. 38400 IN A 192.168.1.28
In hex:
24 1a 81 80 00 01 00 03 00 00 00 00 03 77 77 77
06 67 6f 6f 67 6c 65 03 63 6f 6d 00 00 01 00 01
c0 0c 00 05 00 01 00 05 28 39 00 12 03 77 77 77
01 6c 06 67 6f 6f 67 6c 65 03 63 6f 6d 00 c0 2c
00 01 00 01 00 00 00 e3 00 04 42 f9 59 63 c0 2c
00 01 00 01 00 00 00 e3 00 04 42 f9 59 68
The plaintext payload is the DNS response plus the MAC value of the
request. This response is small enough to fit into a single packet.
Hallam-Baker November 10, 2014 [Page 13]
Internet-Draft Private DNS May 2014
Segment(0)
Type code: 04
Segment length: 00 20
Data:
a7 25 0b df 5a 10 bf ac 39 99 b7 6c 19 d2 1d e8
24 93 b5 09 df 3d 91 27 98 23 10 99 25 b1 45 9e
Segment(1)
Type code: 12
Segment length: 00 5e
Data:
24 1a 81 80 00 01 00 03 00 00 00 00 03 77 77 77
06 67 6f 6f 67 6c 65 03 63 6f 6d 00 00 01 00 01
c0 0c 00 05 00 01 00 05 28 39 00 12 03 77 77 77
01 6c 06 67 6f 6f 67 6c 65 03 63 6f 6d 00 c0 2c
00 01 00 01 00 00 00 e3 00 04 42 f9 59 63 c0 2c
00 01 00 01 00 00 00 e3 00 04 42 f9 59 68
The plaintext is encrypted and the transaction identifier and MAC
values added. Note that in a multiple packet response, each response
has its own MAC value:
Transaction ID: 10 (= 16 bytes)
cd 36 4b 64 e0 c2 e7 52 90 a4 75 60 a2 af dc 13
Index: 01
Max Index: 01
Clear Response: 00 c8 (= 200)
Encrypted Data: 00 90 (= 144 bytes)
59 9a a7 57 56 df 19 28 fe ea c2 e2 60 36 0c aa
fb 43 dd d0 94 02 9a f8 d9 d8 75 d4 13 11 d5 18
08 05 02 e4 43 10 3f 92 63 ec b7 8c 81 9e 70 40
b4 00 e6 26 39 45 67 d4 1e 1b 87 11 e9 70 83 ee
7e ac 43 02 8e 54 b5 b7 5a 07 44 6f 5f 31 9d 6a
bf 8f d8 22 ba 12 06 8a 36 3a 72 71 3e a7 f2 21
bb 0c c6 44 57 c3 4a 56 0f 1e ec e5 68 c6 08 ff
21 b1 4a 07 04 5c 12 62 2b 3b 14 34 83 56 55 72
03 d9 af 1e 7d 0b be ad 40 4f 98 32 ae 65 3c 43
MAC: 10 (= 16 bytes)
e6 52 62 72 55 4b 95 be da a5 11 5a cd 2e a8 9b
2.2.3. Authentication Conformance
A Private-DNS server MUST authenticate queries. In the case that the
UDP binding is used, a server MUST NOT make any response should the
verification step fail. This requirement ensures that a Private-DNS
service cannot be used to attack other systems in a Denial of Service
attack through use of packets with forged source addresses.
Hallam-Baker November 10, 2014 [Page 14]
Internet-Draft Private DNS May 2014
A service MAY provide an error response in the case that a request
using the Web Service binding fails as the TCP/IP connection startup
provides an adequate protection against source address forgery.
2.2.4. Handling Multiple Requests
A Private-DNS service MUST accept requests that contain multiple
requests. Where multiple requests are presented, each request in the
transaction MUST have a unique DNS Transaction ID.
A Private-DNS service MAY limit the number of responses provided.
Responses to requests MAY be returned in any order.
3. Service Connection and Key Exchangee
The Service Connection is established using [I-D.hallambaker-
wsconnect]. The service identifiers for PRIVATE-DNS are as follows:
Service Identifier
PRIVATE-DNS
Two host connection bindings are defined:
UDP Binding
The UDP binding described in [!I-D.hallambaker-wsconnect] is
the preferred host binding. The UDP binding allows most queries
to be completed in a single round trip with no mandatory
delays.
HTTP Binding
A HTTP binding is specified for use as a last resort in
situations where the UDP transport is not available.
3.1. UDP Binding
The prefered host connection type is to use the message encapsulation
format
Protocol
DNS
Presentation
PRIVATE-DNS-P
Transport
UDP
Note that the omission of version numbers in the on-the-wire data
structures is intentional. Use of the message encapsulation requires
that the parties have previously established a host connection
comprising the network and security parameters required to
Hallam-Baker November 10, 2014 [Page 15]
Internet-Draft Private DNS May 2014
communicate. The choice of message encapsulation including the
protocol version is defined in the host connection.
In the DNS protocol requests and responses use the same message
structure. The encapsulation uses different structures for requests
and responses but the payload of each structure is a sequence of
[RFC1035] messages.
3.2. HTTP Binding
Under certain network conditions attempts to reach the PRIVATE-DNS
service may fail due to constraints imposed by firewalls or through
attempted censorship. Under these conditions, HTTP [RFC2616] MAY be
used as an alternative transport as follows:
Protocol
DNS
Presentation
POST
Content-Type
application/private-dns-p
Transport
HTTP
A PRIVATE-DNS service offered in this fashion MUST support HTTP/1.1
or higher. The transaction is performed as a POST request with the
MIME content type application/private-dns-p.p.
4. Security Considerationsns
The broad security requirements for Private-DNS are set out in [I-
D.hallambaker-dnse].
In due course this section will explain which of the security
requirements is met and under which circumstances.
4.1. Confidentialityty
4.2. Integrity
4.3. Access
5. IANA Considerations
6. Acnowledgements
Hallam-Baker November 10, 2014 [Page 16]
Internet-Draft Private DNS May 2014
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.hallambaker-omnibroker] Hallam-Baker, P, "OmniBroker Protocol",
Internet-Draft draft-hallambaker-omnibroker-07, 21 January
2014.
[RFC2616] Fielding, R.,Gettys, J.,Mogul, J.,Frystyk, H.,Masinter,
L.,Leach, P.,Berners-Lee, T., "Hypertext Transfer Protocol
-- HTTP/1.1", RFC 2616, June 1999.
[I-D.hallambaker-jsonbcd] Hallam-Baker, P, "Binary Encodings for
JavaScript Object Notation: JSON-B, JSON-C, JSON-D",
Internet-Draft draft-hallambaker-jsonbcd-01, 21 January
2014.
[I-D.hallambaker-dnse] Hallam-Baker, P, "Private-DNS", Internet-
Draft draft-hallambaker-dnse-00, 21 March 2014.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, 1 November 1987.
[RFC4033] Arends, R.,Austein, R.,Larson, M.,Massey, D.,Rose, S.,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[I-D.hallambaker-wsconnect] Hallam-Baker, P, "JSON Service Connect
(JCX) Protocol", Internet-Draft draft-hallambaker-
wsconnect-05, 21 January 2014.
Author's Address
Phillip Hallam-Baker
Comodo Group Inc.
philliph@comodo.com
Hallam-Baker November 10, 2014 [Page 17]