[Driu] Alternate resource record?
Ray Bellis <email@example.com> Tue, 21 August 2018 17:08 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8985D130FDE for <firstname.lastname@example.org>; Tue, 21 Aug 2018 10:08:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([126.96.36.199]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8z4FnZWyY9NL for <email@example.com>; Tue, 21 Aug 2018 10:08:07 -0700 (PDT)
Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.8.131.52]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64CD3130F76 for <DRIU@ietf.org>; Tue, 21 Aug 2018 10:08:04 -0700 (PDT)
Received: from 82-69-21-132.dsl.in-addr.zen.co.uk ([184.108.40.206]:64017 helo=Barbaras-MacBook-Pro.local) by hydrogen.portfast.net ([220.127.116.11]:465) with esmtpsa (fixed_plain:firstname.lastname@example.org) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1fsA8O-0006N5-Ke (Exim 4.72) for DRIU@ietf.org (return-path <email@example.com>); Tue, 21 Aug 2018 18:08:00 +0100
From: Ray Bellis <firstname.lastname@example.org>
Date: Tue, 21 Aug 2018 18:08:02 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
Content-Type: text/plain; charset="utf-8"; format="flowed"
Subject: [Driu] Alternate resource record?
List-Id: "DNS Resolver Identification and Use \(DRIU\)." <driu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/driu>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/driu>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Aug 2018 17:08:22 -0000
Thanks for creating the mailing list. As mentioned at the side-meeting in Montreal, I strongly believe that the way forward should be a new RR that is specific for the use of HTTP(s) (c.f. MX for SMTP) and that would be automatically looked up by recursive resolvers and returned in answers [*] This recursive lookup step would give this record the equivalent performance to CNAME whilst avoiding the complexities (and failings) of SRV or ANAME. I'd like to write that up in a draft, but to do so I'd like to co-author with HTTP specialists to ensure that any such RR has the fields they deem necessary without the extra ones that SRV has that we heard are not desirable (specifically port numbers and load-balancing / weighting). Who'd be up for helping with this? Ray Bellis ISC Research Fellow [*] one caveat - the look-up would have to be optional in the specification because making it mandatory would prevent the use of the RR Expert Review process which doesn't allow for the assignment of RRs with mandatory server side processing.