Re: [DNSOP] Proposal for a new record type: SNI

Phillip Hallam-Baker <> Tue, 21 February 2017 00:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF24F1294A2 for <>; Mon, 20 Feb 2017 16:06:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5-htptqkzBIC for <>; Mon, 20 Feb 2017 16:06:39 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 02F71129415 for <>; Mon, 20 Feb 2017 16:06:39 -0800 (PST)
Received: by with SMTP id d128so8956443ybh.2 for <>; Mon, 20 Feb 2017 16:06:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=PnILmlbWl7wJ2d7UqxkxDc8fs/h+e61h5knVXF+qMUQ=; b=hHaQJofgQ+DxvS5M8lmN2gJeqiMrBtXESyFQVZnELpSB5ZkOhWUkVq6Juf18LIavBv frGomOtXR5QAGLB2afYn6dSPUCGwjo58R5mLk0uJ50CxgJnVU8qz/+AV27C2GEnnl+fQ FuT77BCFxMcYJm4knpNKUbPxRkxHiAnNFimC8trFJz10pIKNgI2uxyRwvOUSKrfTQLvJ FuJwHhNkzPekoIVYOPMr2/lujsxVo69Qq3J6lcYZqk4s5YB1EzthNkaHn7oHOhWN7CHt ONUXlUdl5E9bu7iX8KZavf87KpRtRH4voP1FHGUhvxhHTc3m9XVH5O8odNaajuT5LX9F AyfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=PnILmlbWl7wJ2d7UqxkxDc8fs/h+e61h5knVXF+qMUQ=; b=fyCnHVJt6N1L/8/yrVNNJFWIqZrr0rlZXNj59mEsEA0WCogvsq/hL8bK36/3QlTk5d aXiisXOKBQXSjJrxl3V4syKBReTt/tPdeXRz0N8VsjrBHbe+POrpAXX9Tn2EkW5E4ltJ jfh1OyvIJIurVXDUlo0FpyGq26apqdfFUFe2h20E+o6VQnjgtLbIcXMqfvj9nv7QDg1p +j+NXogq7cFGokqG/Qa+3ZQ44lCAeS0cFR3SmjaulfJr4QTqqmXAectirZddZOciAAlw 3RxNpw5c5BEImOJiqulSfJjMGQsLUt7LG2bklzRcr7S+mxB1rO1Mgmij1Ia1pY/6WkRo oKsQ==
X-Gm-Message-State: AMke39n6WItVB4SfUz/6tpnhh3S6R1XEPDzxnp2Uc2lJZiGZPbqXSaGnTRWY0/tA7QSOoNyMvrwbCjgjlrwp5A==
X-Received: by with SMTP id k83mr9734226ybk.130.1487635598199; Mon, 20 Feb 2017 16:06:38 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 20 Feb 2017 16:06:37 -0800 (PST)
In-Reply-To: <>
References: <> <20170217220309.9637.qmail@ary.lan> <> <alpine.OSX.2.20.1702172143530.94448@ary.qy> <> <alpine.OSX.2.20.1702182014260.99706@ary.qy> <> <> <>
From: Phillip Hallam-Baker <>
Date: Mon, 20 Feb 2017 19:06:37 -0500
X-Google-Sender-Auth: O4-txCQU2w2bw9wM8p-tTZbk34g
Message-ID: <>
To: Ben Schwartz <>
Content-Type: multipart/alternative; boundary="001a113d46ec62d0750548ff2704"
Archived-At: <>
Cc: Tony Finch <>, "" <>
Subject: Re: [DNSOP] Proposal for a new record type: SNI
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Feb 2017 00:06:41 -0000

On Mon, Feb 20, 2017 at 4:08 PM, Ben Schwartz <> wrote:

> On Mon, Feb 20, 2017 at 3:39 PM, Phillip Hallam-Baker <
>> wrote:
>> I really don't like the proposal at all. The idea of beginning the TLS
>> handshake in DNS is sound. But it is a completely new handshake and
>> authentication layer.
> What you're proposing does sound like a completely new handshake.  To be
> clear, this proposal makes no change to TLS.

​Well there is your problem. There is little point in doing this unless you
feed the result into the TLS handshake to follow. ​

Right now we have a bit of a mess with service discovery. We have a solid
>> proposal that makes sense written up as a standard
> Could you point me to which document you're referring to?

> and we have a lot of folk saying we should do something different, either
>> for legacy reasons or because they find it impure.
>> The solid proposal is as follows:
>> * Discover all services using SRV *without exception*
>> * Use TXT records to provide additional data *that is required for
>> discovery and binding*
>> * TXT records may be bound to the service definition, thus covering all
>> hosts or be bound to a specific host instance.
>> * Domain names used for services MAY use CNAME or DNAME. Domain names
>> that identify services MUST NOT.
> I'm not sure I understand this distinction.


 Domain names that identify

​A service is an abstract Internet service which may be provided by any
host chosen from group of hosts ​specified in an SRV record. A host is a
physical machine.

​SRV records map services to hosts.​
​A and AAAA records map hosts to IP addresses.​

> How many DNS and destination roundtrips does this require?  My impression
> is that SRV records have proven unpopular in part because they generally
> add a DNS roundtrip delay to each initial connection.

​One if it is done right.​

You are going to want to lock down your client to resolver DNS and you
might as well fix the protocol at the same time. That is why standardizing
on DNS-SD for everything is the way to go.