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

"Peter van Dijk" <> Wed, 12 April 2017 19:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9EDBB129649 for <>; Wed, 12 Apr 2017 12:07:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Jw642gUx1FM2 for <>; Wed, 12 Apr 2017 12:07:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8D20212955F for <>; Wed, 12 Apr 2017 12:06:59 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by (Postfix) with ESMTPSA id D1432C1B96; Wed, 12 Apr 2017 21:06:57 +0200 (CEST)
From: "Peter van Dijk" <>
To: dnsop <>
Date: Wed, 12 Apr 2017 21:06:56 +0200
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
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: <>
Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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