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

From: Ray Bellis <[email-masked]>
Date: Sun, 4 Nov 2018 20:22:22 +0700

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: [email-masked]
To: Ray Bellis <[email-masked]>

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.

---

From: "Patrik Fältström" <[email-masked]>
Date: Sun, 04 Nov 2018 18:26:07 +0400

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
>
> 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:
> -- 
> Http-srv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-srv

---

From: Tony Finch <[email-masked]>
Date: Mon, 5 Nov 2018 18:24:50 +0000

Ray Bellis <[email-masked]> 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.

I'm keen to see this succeed :-)

I would like multiple HTTP records to be allowed at the same name, to
support multiple providers or regions etc. As I understand it, you would
like to keep this draft within the requirements for an expert review RR
type allocation, which I think means no special demands about number of
RRs in an RRset.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southeast Iceland: Cyclonic 4 or 5, becoming easterly or northeasterly 6 to
gale 8, occasionally severe gale 9 later in west. Moderate or rough, becoming
very rough later in west. Showers then rain. Good, occasionally poor.

---

From: Ray Bellis <[email-masked]>
Date: Tue, 6 Nov 2018 07:47:03 +0700

> I'm keen to see this succeed :-)

Great! :)

> type allocation, which I think means no special demands about number of

It's not called out in the draft yet, but multiple RRs should be 
expected to work just the same as if there were multiple A or AAAA records.

Ray