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

Paul Wouters <> Fri, 07 April 2017 21:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D071E127B5A for <>; Fri, 7 Apr 2017 14:16:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cgQH5XWQYtid for <>; Fri, 7 Apr 2017 14:16:31 -0700 (PDT)
Received: from ( [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 88850127867 for <>; Fri, 7 Apr 2017 14:16:19 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 3w0C754tFKzDRF; Fri, 7 Apr 2017 23:16:17 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1491599777; bh=e2qYiuqH0eyLDebFePNTSu9i8bvSbBnaJ3Qopt3eXKI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=oroa4xpKelK3I4h8yCgRprOw8IT43S0j3OR9j0vVq4h/6AZr6n/4fddPLxAD0BzSI jnp7LcfC80csDfYx9bJwg9kibpXfuF53cpyy5QwaSfpdkX8sZPVywj7TQeEvCv4tuo qTPWhr9lz5Wgx/+j/WwvlpbaUQlYyOLzaFiRrh1M=
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id vCR2-LLtISXz; Fri, 7 Apr 2017 23:16:15 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Fri, 7 Apr 2017 23:16:15 +0200 (CEST)
Received: by (Postfix, from userid 1000) id 7D1D0559948; Fri, 7 Apr 2017 17:16:14 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 7D1D0559948
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7740B410929C; Fri, 7 Apr 2017 17:16:14 -0400 (EDT)
Date: Fri, 7 Apr 2017 17:16:14 -0400 (EDT)
From: Paul Wouters <>
To: Evan Hunt <>
In-Reply-To: <>
Message-ID: <>
References: <>
User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
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: Fri, 07 Apr 2017 21:16:54 -0000

On Fri, 7 Apr 2017, Evan Hunt wrote:

> Here's the new ANAME draft I mentioned last week.

I like this one a little better, but :)

    When an ANAME record is present at a DNS node and a query is received
    by an authoritative server for type A or AAAA, the authoritative
    server returns the ANAME RR in the answer section.

This is good, then it goes on with:

    Because not all querying resolvers understand ANAME, the
    authoritative server MUST also return address records, as described


    Authoritative servers implementing ANAME MUST be equipped to resolve
    the ANAME <target> on the querying resolver's behalf, either by
    sending queries to an external recursive resolver or by implementing
    recursive resolution logic internally, so that address records can be
    expanded when the ANAME <target> is in a separate zone from <owner>.

I guess I'm still not a fan of the AUTH server doing this. Moreover:

    When a recursive resolver sends a query of type A or AAAA and
    receives a response with an ANAME RRset in the answer section, it
    MUST re-query for the ANAME <target>.  This is necessary because, in
    some cases, the address received will be dependent on network
    topology and other considerations, and the resolver may find a
    different answer than the authoritative server did.

That opens up a whole can of worms :P We start with the problem of
"we need addresses at the APEX be non-static, but then you add logic
to support that and then it is not good enough for the job. AUTH servers
already know how to return split view answers with various
implementations based on geolocation, edns-subnet or what not.

Also, a resolver support ANAME sending a query to a forwarding resolver
might only receive the ANAME record back without anything else, and then
has to do all the ANAME chasing itself anyway. So why not just always
do that behaviour? So why not happy eyeball ANAME along with A/AAAA
queries. Old stuff gets somewhat risky and possibly outdated A/AAAA
records, and newer clients get the proper redirection.

But really, what it comes down to for me is that if you are adding logic
to the AUTH nameservers to synthesize ANAME into A/AAAA records, why bother
ever sending ANAME over the wire? Just let clients send A/AAAA and never
ask for ANAME. And have the AUTH server code that sees an ANAME in the
zone at the place of the QNAME for A/AAAA synthesize by doing the