Re: [Http-srv] New Version Notification for draft-bellis-dnsop-http-record-00.txt

"Patrik Fältström " <paf@frobbit.se> Sun, 04 November 2018 14:26 UTC

Return-Path: <paf@frobbit.se>
X-Original-To: http-srv@ietfa.amsl.com
Delivered-To: http-srv@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D011200D7 for <http-srv@ietfa.amsl.com>; Sun, 4 Nov 2018 06:26:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.721
X-Spam-Level:
X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=frobbit.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObKayHkfnxh2 for <http-srv@ietfa.amsl.com>; Sun, 4 Nov 2018 06:26:15 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ECCF120072 for <http-srv@ietf.org>; Sun, 4 Nov 2018 06:26:14 -0800 (PST)
Received: from [192.71.80.208] (vpn-client-208.netnod.se [192.71.80.208]) by mail.frobbit.se (Postfix) with ESMTPSA id A7832238D3; Sun, 4 Nov 2018 15:26:10 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=frobbit.se; s=mail; t=1541341571; bh=GQ496vTds6jP0662xaNl8hd5yeixoWvnCXH6fojduQE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=W/KiBIuX2xmw0XeCB+0j5RL7VNqqtLXsxEuLp0VInKqLaJQF2x5/r+5j4GDa19CBQ yngEpWXQgXG6ZYnxfCEYNNyLzQ7sqwIId7RASzL6p5TxfalCtZZFgnJIf0WOGDfgtX Aq+n1ar1e9aAxR3MrzRc3v0eBUfeDvUFWqcb9J60=
From: Patrik Fältström <paf@frobbit.se>
To: Ray Bellis <ray@bellis.me.uk>
Cc: http-srv@ietf.org
Date: Sun, 04 Nov 2018 18:26:07 +0400
X-Mailer: MailMate (1.12.1r5552)
Message-ID: <8A0C4539-D8C4-49D6-83F2-9A1276E3193D@frobbit.se>
In-Reply-To: <0399ba42-3dbe-3b08-b594-66787cbf791c@bellis.me.uk>
References: <154126453938.10172.13155139604600467727.idtracker@ietfa.amsl.com> <0399ba42-3dbe-3b08-b594-66787cbf791c@bellis.me.uk>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_B7E56BC7-AC2E-41A0-ACF4-8E0160DA2BAA_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/http-srv/3nzJ_hslAJvPzj4n61wAMtOHWd8>
Subject: Re: [Http-srv] New Version Notification for draft-bellis-dnsop-http-record-00.txt
X-BeenThere: http-srv@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Using DNS SRV Records with HTTP <http-srv.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-srv>, <mailto:http-srv-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/http-srv/>
List-Post: <mailto:http-srv@ietf.org>
List-Help: <mailto:http-srv-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-srv>, <mailto:http-srv-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Nov 2018 14:26:17 -0000

Well, to be honest, that have been my proposal as that is what "sort of happens" in the "web space" today, but I have left it open for the people doing "the web" to tell me what they want so I can update the RFC with more specific instructions.

It could be the other way around, that the base domain name is kept and both address bar and DN in the cert is validated, but the change is what I have heard is interesting because of CERT issues. That the DN is to match the URI in the RDATA and not the QNAME.

I tried to make the definition of the RR generic enough to be able to handle both cases (or even a middle of the road solution). The key here was to:

1. Not have the actual record at the apex so that the admin portion can be delegated and that way more easily managed

2. Explicitly give a URI instead of just a domain name so that the first HTTP request do not have to be to a HTTP (without path) and then redirect to a HTTPS and then to whatever is the path to use. Instead directly to whatever URI is to be used.

   paf

On 4 Nov 2018, at 17:22, Ray Bellis wrote:

> Last night, when the submission system re-opened, I published a new draft describing a proposed "HTTP" DNS resource record.
>
> It's intended to be general purpose and (eventually) replace all use of CNAME for the HTTP protocol, but it is also specifically also designed to resolve the CNAME at the Apex issues.
>
> More info below.
>
> Ray
>
> -------- Forwarded Message --------
> Subject: New Version Notification for draft-bellis-dnsop-http-record-00.txt
> Date: Sat, 03 Nov 2018 10:02:19 -0700
> From: internet-drafts@ietf.org
> To: Ray Bellis <ray@isc.org>
>
>
> A new version of I-D, draft-bellis-dnsop-http-record-00.txt
> has been successfully submitted by Ray Bellis and posted to the
> IETF repository.
>
> Name:		draft-bellis-dnsop-http-record
> Revision:	00
> Title:		A DNS Resource Record for HTTP
> Document date:	2018-11-04
> Group:		Individual Submission
> Pages:		5
> URL: https://www.ietf.org/internet-drafts/draft-bellis-dnsop-http-record-00.txt
> Status: https://datatracker.ietf.org/doc/draft-bellis-dnsop-http-record/
> Htmlized: https://tools.ietf.org/html/draft-bellis-dnsop-http-record-00
> Htmlized: https://datatracker.ietf.org/doc/html/draft-bellis-dnsop-http-record
>
>
> Abstract:
>    This document specifies an "HTTP" resource record type for the DNS to
>    facilitate the lookup of the server hostname of HTTP(s) URIs.  It is
>    intended to replace the use of CNAME records for this purpose, and in
>    the process provides a solution for the inability of the DNS to allow
>    a CNAME to be placed at the apex of a domain name.
>
> -- 
> Http-srv mailing list
> Http-srv@ietf.org
> https://www.ietf.org/mailman/listinfo/http-srv