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

Phillip Hallam-Baker <> Tue, 21 February 2017 02:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 147D412959C for <>; Mon, 20 Feb 2017 18:08:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.596
X-Spam-Status: No, score=-2.596 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 9lFKaaAET-0Y for <>; Mon, 20 Feb 2017 18:08:39 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5D14C12959E for <>; Mon, 20 Feb 2017 18:08:39 -0800 (PST)
Received: by with SMTP id l19so57953557ywc.2 for <>; Mon, 20 Feb 2017 18:08:39 -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=MsrYD+p8pBirQH8O9mmwuQidf5LudmUDS12ytAzPFhs=; b=F+jZy67WaSR5bGV67ucPj4ArFhM/3H1lT6PACVff3XMju+D0wWV5nshOuD06b8kpTj 7xH6XNmXaeJfPwxDrGfh/9FUMm5qSevOGp5Tc7Br9t1zbp9JwWO3XBnuzzV79jOxPbPl Xz6IieJ/1WtkzJV/hjO3FT/5QmhIArfVkfb9cjO8W3TiIqJTtC4iNbu8T4cEiJ/Qt5DE XU15PUCO/RwRvJFjyTeOT/VD7sOjqAF1RgrDJ+25Yr2n8Vjr5iKN2MrWIsXgymRwh41W yZ4osmyAn8OSDZU33NjKvKsOgk725mhFJZYCr5Io5T1rHF3oBPl2SOGYmCvM9EBkHC/H 9M1w==
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=MsrYD+p8pBirQH8O9mmwuQidf5LudmUDS12ytAzPFhs=; b=QX1cQDAvkOBUZJxxEWudmC6k0V7NnJpu7FZ4/XPhuVXPUgM0HUT9Na8RnHJNTYDdhr Xmsez+g6g2LCoQF+lEm2naQoOdm1V+qFI542lP8gbvEvR6UXetk2CnUr7LCTdkA60oJx P//7oxv4C515kSRoinGOw2Ea8N4WzALN9nrv9FUBekjnbNfdoEKLqYU1mPdFBCKN+3EC SK00sgzH32I0A9Ia4Tpb8tEf1+cnnfB+2lEtbWwPC2fuIjE9g18+AlTSuawAqmH51T4Y N52tuKmes9slYjCTMcLHyYPCJCFd0o4FaeiZE4XfifdE8WEneVLpyg5T+S3bhIas99E9 vdcw==
X-Gm-Message-State: AMke39kWDc7jvnIXx1UQYfUgsy275Szh7r+9kBsDR6TiqdkNqcgTxUhwFmdXijYO1cNxfWDo39QoAcWNzvH+rQ==
X-Received: by with SMTP id z186mr17876601ywb.340.1487642918574; Mon, 20 Feb 2017 18:08:38 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 20 Feb 2017 18:08: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 21:08:37 -0500
X-Google-Sender-Auth: qbzAU1zvqgahdNbXdRpB0z1RBgc
Message-ID: <>
To: Mark Andrews <>
Content-Type: multipart/alternative; boundary=001a114c6c9cb6e27b054900dbdb
Archived-At: <>
Cc: Ben Schwartz <>, 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 02:08:41 -0000

On Mon, Feb 20, 2017 at 8:42 PM, Mark Andrews <> wrote:

> Zero if it is done right.  We can easily extend the DNS to say
> "Fetch the additional record for the SRV records before answering"
> if you have this EDNS option present or just have the server do it
> without the option.  There is nothing preventing a recursive server
> just doing this today.

​+1 Actually that is what I was assuming.

If we are using the current DNS protocol then all we need to do is to
program the DNS servers to intelligently add the necessary additional RRs.

Alternatively, if we are doing DNS over QUIC then we could tweak the
protocol so that this is the default.​

If the SRV prefix is _http._tcp or _https._tcp then the recursive
> server SHOULD fetch any missing additional address records for the
> SRV server including CNAME records if the server name maps to a
> CNAME and add them to the addtional section prior to returning the
> response.  You could even just do this for all SRV lookups.

​Yup. The only catch is that we all need to do discovery the same way. That
is why SRV+TXT as specified in RFC6763 is the way to go​

> A RFC saying something like this would solve the SRV issue over the
> long term a recursive servers get replaced.  Unfortunately brower
> vendors don't seem to want to say "yes, we will add SRV support if
> you change the DNS to do this".

I don't think they are interested in SRV just for SRV. But SRV for this
plus SNI encryption could be enough.

We could also fix up some sort of backwards compatibility scheme. A DNS
server that knows that is http over port 80 can
convert A/AAAA records as needed.

If we are dealing with a trusted DNS resolver chosen by the relying party
that is constant, we can do things like advertise 'next generation

> And if they have a issue with the prefix one can allocate a new TYPE(s)
> for class IN that does the same as SRV records but is for http and https.
> Service to address can be done with a single lookup and can include the
> TLSA records as well.

I would prefer to specify the security policy in an accompanying prefixed
TXT record because I need more than TLSA provides.