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

"Peter van Dijk" <peter.van.dijk@powerdns.com> Wed, 12 April 2017 19:07 UTC

Return-Path: <peter.van.dijk@powerdns.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 9EDBB129649 for <dnsop@ietfa.amsl.com>; Wed, 12 Apr 2017 12:07:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Jw642gUx1FM2 for <dnsop@ietfa.amsl.com>; Wed, 12 Apr 2017 12:07:01 -0700 (PDT)
Received: from shannon.7bits.nl (shannon.7bits.nl [89.188.0.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D20212955F for <dnsop@ietf.org>; Wed, 12 Apr 2017 12:06:59 -0700 (PDT)
Received: from [192.168.137.1] (unknown [82.168.30.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id D1432C1B96; Wed, 12 Apr 2017 21:06:57 +0200 (CEST)
From: "Peter van Dijk" <peter.van.dijk@powerdns.com>
To: dnsop <dnsop@ietf.org>
Date: Wed, 12 Apr 2017 21:06:56 +0200
Message-ID: <31563125-4123-4A63-873F-65A30D17DE27@powerdns.com>
In-Reply-To: <03357a4d-74d8-bd97-a00b-9fd833fc3e4a@redhat.com>
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> <03357a4d-74d8-bd97-a00b-9fd833fc3e4a@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.6r5347)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/C-k5wXedfYCEkFDFH4tjhTwpl-k>
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 19:07:06 -0000

On 12 Apr 2017, at 10:21, Florian Weimer wrote:

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

Which browsers tend to avoid as far as I know, but it’s besides the 
point - browsers are not doing SRV and we have to accept that.

> 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 that’s a forklift upgrade of -end user stations-.

> 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.

I don’t know either - I do know the draft does not require anyone 
(except the auth operator who decides to use ANAME) to do more queries 
than they are doing now.

> 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.

They solved the issue for ‘CNAME at apex’, which is not the only use 
case for ANAME.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/