Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

Florian Weimer <fweimer@redhat.com> Wed, 12 April 2017 08:21 UTC

Return-Path: <fweimer@redhat.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 8BCE3129ABE for <dnsop@ietfa.amsl.com>; Wed, 12 Apr 2017 01:21:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.923
X-Spam-Level:
X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 95zyXWHOv4p2 for <dnsop@ietfa.amsl.com>; Wed, 12 Apr 2017 01:21:15 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCCAA1270AC for <dnsop@ietf.org>; Wed, 12 Apr 2017 01:21:15 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 67C297F081; Wed, 12 Apr 2017 08:21:15 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 67C297F081
Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 67C297F081
Received: from oldenburg.str.redhat.com (ovpn-116-38.ams2.redhat.com [10.36.116.38]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6396C189AF; Wed, 12 Apr 2017 08:21:14 +0000 (UTC)
To: Evan Hunt <each@isc.org>
References: <20170407181139.GB66383@isc.org> <cc3bbc7a-3f48-2f7f-a3d9-3f752874fc00@redhat.com> <alpine.DEB.2.11.1704111641290.4393@grey.csi.cam.ac.uk> <alpine.LRH.2.20.999.1704111147390.8670@bofh.nohats.ca> <alpine.DEB.2.11.1704111928520.4393@grey.csi.cam.ac.uk> <763184bf-06ec-8320-07ff-9117b08cc509@redhat.com> <CC41BD92-4151-4A28-9D7D-EFF9978822A2@dotat.at> <fac97c1e-325a-e9ef-3681-c01782bb3c4e@redhat.com> <F5CDCCDF-615A-4A25-B98E-C8D34FE72CD0@dotat.at> <b4663aaa-dfb2-60d5-0a59-7b6410d927e6@redhat.com> <20170411204726.GB6670@isc.org>
Cc: Tony Finch <dot@dotat.at>, dnsop <dnsop@ietf.org>, Paul Wouters <paul@nohats.ca>
From: Florian Weimer <fweimer@redhat.com>
Message-ID: <03357a4d-74d8-bd97-a00b-9fd833fc3e4a@redhat.com>
Date: Wed, 12 Apr 2017 10:21:13 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <20170411204726.GB6670@isc.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 12 Apr 2017 08:21:15 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/hghnsjer5F_Olmpja6ssEu7dl50>
Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 12 Apr 2017 08:21:18 -0000

On 04/11/2017 10:47 PM, Evan Hunt wrote:
> On Tue, Apr 11, 2017 at 10:20:31PM +0200, Florian Weimer wrote:
>> And in order to accommodate them, we upgrade the DNS server
>> infrastructure across the Internet?
>
> Them, and web browser implementers who just don't want to use SRV.

SRV wouldn't work anyway because it is incompatible with existing name 
resolution interfaces anyway.

If you do not insist on using SRV, but something that is just an alias 
(like PTR, ANAME etc.) and processed in the client, it would be quite 
straightforward to put this into the stub resolver, and then all 
applications[*] would automatically get the addresses at the 
substitution name (SNAME).  Disallow multiple substitution names per 
owner name and their chaining (but chaining to CNAME would be okay), and 
I think it would just work.

But then DNS operators will worry about a 50% (from A/AAAA to 
A/AAAA/SNAME) to 150% (from A/AAAA to A/AAAA/SNAME plus A/AAAA at the 
SNAME) increase in query load.  (SRV would be worse because there could 
be multiple target names, all needing separate processing.)  Would that 
be acceptable?  I don't know.

In fact, Firefox already solved the issue in the client: If you enter 
the zone apex, and no address record exists, it automatically redirects 
to the www name in the zone.  Unfortunately, DNS operators broke that 
when they started rewriting NODATA responses, injecting ads into 
existing domains.  So you really have to have addresses at the zone apex 
these days.

Thanks,
Florian

[*] At least all applications which correctly deal with enterprise name 
lookup, which can involve NIS and LDAP, too, not just DNS.