Signaling That an Authoritative DNS server offers DoT
draft-levine-dprive-signal-01
The information below is for an old version of the document |
Document |
Type |
|
Active Internet-Draft (individual)
|
|
Last updated |
|
2019-11-04
|
|
Stream |
|
(None)
|
|
Intended RFC status |
|
(None)
|
|
Formats |
|
pdf
htmlized
bibtex
|
Stream |
Stream state |
|
(No stream defined) |
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
I-D Exists
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group J. Levine
Internet-Draft Taughannock Networks
Intended status: Informational November 4, 2019
Expires: May 7, 2020
Signaling That an Authoritative DNS server offers DoT
draft-levine-dprive-signal-01
Abstract
DNS resolvers that wish to use DNS over TLS to authoritative servers
(ADoT) need some way to tell whether server offers DoT. This
document describes some ways that a server might signal that it uses
DoT.
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 https://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 May 7, 2020.
Copyright Notice
Copyright (c) 2019 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
(https://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.
Levine Expires May 7, 2020 [Page 1]
Internet-Draft ADoT signalling November 2019
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. General observations . . . . . . . . . . . . . . . . . . . . 2
3. Signaling methods . . . . . . . . . . . . . . . . . . . . . . 3
3.1. EDNS0 option . . . . . . . . . . . . . . . . . . . . . . 3
3.2. DNSKEY flags . . . . . . . . . . . . . . . . . . . . . . 3
3.3. Other DNS records . . . . . . . . . . . . . . . . . . . . 3
3.4. SRV records . . . . . . . . . . . . . . . . . . . . . . . 3
3.5. DANE TLSA . . . . . . . . . . . . . . . . . . . . . . . . 4
3.6. Special server names . . . . . . . . . . . . . . . . . . 4
4. References - Normative . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
The Domain Name System[RFC1034] [RFC1035] uses a directed presumably
acyclic graph of servers to provide authoritative answers to queries.
The link from one server to the next is provided by an NS record in
the zone on the upper server that points to the lower server. For
zones signed with DNSSEC, the upper server zone contains DS records
that contain hashes of signing keys in DNSKEY records in the zone on
the lower server.
2. General observations
Depending on your threat model it may be a problem if an intermediate
party can intercept the signal and force a DoT client to use
unencrypted DNS.
The probe query would generally use query minimization to limit
leakage of the requested name. Even so, if a server handles many
zones, this leaks the name of the zone being probed.
Some zones have servers run by multiple operators. (The DNS root is
a well known example.) It is possible that some of the servers will
offer ADoT and some will not. Some of the schemes below handle per-
server signals, some don't.
In several of the following schemes, the client probes the server to
see whether it offers ADoT. In those cases, the client presumably
remembers what servers it's probed so there's only one probe per
server.
Levine Expires May 7, 2020 [Page 2]
Internet-Draft ADoT signalling November 2019
3. Signaling methods
This is a working list of possible signaling methods. Just because
they're in the list doesn't mean that anyone thinks they're a good
idea.
3.1. EDNS0 option
We define a new EDNS0 option edns-adot. The client sends an edns-
adot option in its request, and the server responds with a value of 0
or 1 to say whether it supports ADoT. The option could be served by
the upper level server along with the NS records, which avoids the
extra probe, or by the lower level server.
This is easy to implement, but since the OPT isn't signed, it's
Show full document text