IETF Logo Mail Archive

Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

JW <jw@pcthink.com> Tue, 18 September 2018 20:02 UTC

Return-Path: <jw@pcthink.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51317130E60 for <dnsop@ietfa.amsl.com>; Tue, 18 Sep 2018 13:02:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 CHBv-jJh0NGC for <dnsop@ietfa.amsl.com>; Tue, 18 Sep 2018 13:02:46 -0700 (PDT)
Received: from atl4mhob04.registeredsite.com (atl4mhob04.registeredsite.com [209.17.115.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2620B120072 for <dnsop@ietf.org>; Tue, 18 Sep 2018 13:02:45 -0700 (PDT)
Received: from mailpod.hostingplatform.com (atl4qobmail01pod6.registeredsite.com [10.30.71.209]) by atl4mhob04.registeredsite.com (8.14.4/8.14.4) with ESMTP id w8IK2hCr011294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <dnsop@ietf.org>; Tue, 18 Sep 2018 16:02:43 -0400
Message-Id: <201809182002.w8IK2hCr011294@atl4mhob04.registeredsite.com>
Received: (qmail 21988 invoked by uid 0); 18 Sep 2018 20:02:43 -0000
X-TCPREMOTEIP: 73.251.233.169
X-Authenticated-UID: jw@pcthink.com
Received: from unknown (HELO ?10.2.1.116?) (jw@pcthink.com@73.251.233.169) by 0 with ESMTPA; 18 Sep 2018 20:02:42 -0000
SavedFromEmail: jw@pcthink.com
Date: Tue, 18 Sep 2018 16:02:38 -0400
In-Reply-To: <E6B75E85-EC60-42BA-B941-3A700D693A46@isc.org>
Importance: normal
From: JW <jw@pcthink.com>
To: Mark Andrews <marka@isc.org>, Mukund Sivaraman <muks@mukund.org>
Cc: jw@pcthink.com, "dnsop@ietf.org WG" <dnsop@ietf.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_1373900457380430"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/CIwBepvMLO0LKjXv0pTsM03WI_0>
Subject: Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Sep 2018 20:02:49 -0000

-------- Original message --------From: Mark Andrews <marka@isc.org>
> I would also expect a relatively large client population using SRV records> given the rate Firefox and Chrome browsers are upgraded.  SRV lookups> work for lots ofother protocols.  SRV records also make it through> firewalls and IDS today.
>

Hi Mark,
I agree SRV is the obvious choice for a greenfield protocol but there is HTTP code sprinkled /everywhere/.  I can't imagine all those forgotten scripts, lonely IOT devices, and troubleshooting guides are going to be as easy to solve as updating chrome and firefox.
Whatever the solution, I feel it should be as transparent to the client as possible.  CNAME would fit this bill but the negative impact is largely unknown.
Perhaps defining a set of default protocols for SRV where it could simulate a CNAME-like response if https/http SRV records are found?
/John
>
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, > NSW 2117, Australia
> PHONE: +61 2 9871 4742              > INTERNET: marka@isc.org

v2.23.0 | Report a Bug | By Email