As nice and clean the HTTP record draft is, without specifying how to do
expansion of the record into address records it is not going to solve
the CNAME-at-the-apex problem that DNS providers have, and we will stick
with the proprietary solutions (this may solve a different use case though).
Best regards,
Matthijs
On 03-11-18 18:04, Ray Bellis wrote:
On 21/09/2018 20:12, Dan York wrote:
I do think this is a path we need to go. We need *something* like
CNAME at the apex. Either CNAME itself or something that works in the
same way but might have a different name.
I agree, and earlier today (well, yesterday, now) I wrote it up:
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.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
