Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt

Richard Gibson <> Mon, 22 January 2018 19:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 406021277BB for <>; Mon, 22 Jan 2018 11:04:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.03
X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OC33AhyjgPjr for <>; Mon, 22 Jan 2018 11:04:41 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D1EE4126D45 for <>; Mon, 22 Jan 2018 11:04:24 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id w0MIuium088468 for <>; Mon, 22 Jan 2018 19:04:21 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=corp-2017-10-26; bh=zzJiF5GvX46noXSWTBtdr2Gnw+xjFxNiqY2BrpDtG9E=; b=KlyfM6JXQ4xQjFhOKCh01GO2XhiynD2/Y/Ebp+zxKCPSWNW/lQoDFItcFNq2lc3zUTOz aN8Mmed6brC3Nu0Q6hRXfhdU4Y6R0ibjgS0x1JdQoT2ZKJvyfY0AlDD3GdchtIcNTYcg 2InYtvSWS/5VwyxT9t4VJiMnjC6GrqoOT163lUbIl5RiDKSMpShtMi6aCgK9ypLXbhbC eNkFAVTTuPeQcGl2npmGUAffzcLCrKh8YLw/Mu0sG0NNpNCs+UL2vbfwr1bZqGMZu7is gwS5ru4utJfgAKa7o64nnAkTmwsVBVkAvQ0jk3nAcw3lZzRc68niiTxvvXW70q1ESu03 6A==
Received: from ( []) by with ESMTP id 2fnngtr4ye-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <>; Mon, 22 Jan 2018 19:04:21 +0000
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id w0MIxKkS032617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <>; Mon, 22 Jan 2018 18:59:20 GMT
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id w0MIxK9n012344 for <>; Mon, 22 Jan 2018 18:59:20 GMT
Received: from [] (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 22 Jan 2018 10:59:19 -0800
To: "" <>
References: <>
From: Richard Gibson <>
Message-ID: <>
Date: Mon, 22 Jan 2018 13:59:18 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------FBDED2CFA7FE5D5048642C31"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8782 signatures=668655
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801220262
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.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: Mon, 22 Jan 2018 19:04:45 -0000

Comments on the latest ANAME draft:

In Section 3.1, "records retrieved during ANAME <> resolution" looks 
like a typo. Should "<>" be "<target>"?

Also in Section 3.1, the first five paragraphs could be more explicit 
about resolving and adding address records instead of specifically A 
and/or AAAA (other than as examples).

Also in Section 3.1, the final paragraph will result in universal 
SERVFAIL responses if an ANAME target is in a misconfigured signed zone, 
even if the zone containing the ANAME is _not_ signed (and a 
corresponding traffic spike from ANAME-ignorant resolvers).

In Section 4, "resolution fails" should be better defined. Specifically, 
may resolvers use server-provided records if their own query results in 

I think zone transfer considerations merit their own section, rather 
than being buried in and mixed with DNSSEC in 3.3. And because of those 
considerations, I consider it a mistake to prohibit secondary servers 
from resolving ANAME targets when there are address records at the same 
node as is required by Section 3.2. Behavior in error cases, including 
those stemming from ANAME-ignorant participants, seems to be much more 
preferable if such address records are treated as fallback data occluded 
during healthy operation:

 1. *ANAME-ignorant primary, ANAME-aware secondary*: The secondary will
    have access to fallback data from the zone, but will only include it
    in responses when its own ANAME target resolution fails. The
    secondary can thus provide better answers to ANAME-ignorant clients
    when responses for the ANAME target are tailored.
 2. *ANAME-aware primary, ANAME-ignorant secondary*: Including expanded
    records in the transferred zone data results in stretching ANAME
    TTLs and failing to update anything until secondary refresh, but
    /not/ including them would almost completely suppress ANAME
    functionality. I think the tradeoffs here need further analysis;
    more on that below.
 3. *Address-including zone, address-lacking target*: An ALIAS-aware
    server will be able to locally resolve answers from the target name
    for address types that it has (e.g., A), while still providing
    nonempty answers from the zone for those it lacks (e.g., AAAA). At
    least Oracle [Dyn] customers actually prefer such behavior, as I
    mentioned in .
    But note that it requires authoritative servers to override NODATA
    responses to ANAME target resolution, changing the last two
    paragraphs of Section 3.1.
 4. *Address-ignorant primary, address-aware secondary*: Assuming that a
    new address record has been defined that the primary does not know
    of, the secondary will be able to include locally-resolved data for
    it, whether or not zone data includes the new type. In cases where
    the zone data just hasn't been updated, this behavior is better than
    assuming it has been pre-expanded to an empty set.
 5. *Address-aware primary, address-ignorant secondary*: Assuming that a
    new address record has been defined which the primary knows of but
    the secondary does not, the transferred zone data should include
    pre-expanded answers of the type so the secondary has them available
    for its responses (since it doesn't know to look them up on its
    own). This informs the question from case 2 above, but does not
    completely resolve it (see below).
 6. And layering DNSSEC on top of the above (i.e., assuming the
    ANAME-containing zone is signed), *ANAME-aware secondary without a
    zone-signing private key*: I agree that there is no reason for a
    secondary to respond with data that it cannot sign, but it should
    still include signed (fallback) data that ANAME-aware clients will
    attempt to override with local resolution. But how is the XFR server
    to know if the XFR client can add valid signatures?

Regarding zone transfers in which the secondary server is ignorant of 
ANAME altogether, or the inclusion of a new address type, it seems clear 
that primary servers capable of pre-expansion should do so. But in my 
mental model, there's a distinction between static in-zone fallback data 
and data that was resolved upstream (the latter subject to TTL 
decrementing and local refreshes, the former not), and ANAME-aware zone 
transfers should preserve the distinction even though resolution 
responses won't. There's also the practical matter of zone serial, which 
controls zone transfers but SHOULD NOT be updated by changes in non-zone 
data like ALIAS target answers.

With all that in mind, I think ANAME will need to update the definition 
of AXFR and IXFR, and IXFR in particular is likely to give ANAME a hard 

    @     SOA serial=<N> ; PROBLEM 1!
           ; Use of an already-known serial (since static zone contents
    have not changed).
           ; This may confuse ANAME-ignorant servers into ignoring the
    XFR altogether.
    @     SOA serial=<N> ; PROBLEM 2!
           ; This is a putative ANAME-enhanced IXFR of serial N to serial N.
           ; But at this point, it is indistinguishable from an AXFR of
    a degenerate single-record zone.
    aname A ; removed ANAME expansion
    aname A ; PROBLEM 3!
           ; ANAME-ignorant servers must remove *all* previous ANAME
    target expansions, but those are independent of serial.
           ; The servers may fail when asked to delete a nonexistent RR.
    @     SOA serial=<N>
    aname A ; new ANAME expansion
    @     SOA serial=<N>

I guess the above could be mitigated somewhat via a signal indicating 
ANAME-awareness in the client, but that probably means AXFR of an 
unchanged serial for ANAME-ignorant clients, which is a) incredibly 
wasteful and inefficient, and b) /still/ not guaranteed to succeed as 
far as I know.

There's also a similar problem for instructing secondary servers to 
switch away from UDP—we essentially have to lie about having serial N+1 
in the single-SOA UDP response, or else they will consider theirselves 
already up-to-date and not even bother retrying.

On 01/12/2018 12:25 AM, wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
>          Title           : Address-specific DNS Name Redirection (ANAME)
>          Authors         : Evan Hunt
>                            Peter van Dijk
>                            Anthony Eden
> 	Filename        : draft-ietf-dnsop-aname-01.txt
> 	Pages           : 12
> 	Date            : 2018-01-11
> Abstract:
>     This document defines the "ANAME" DNS RR type, to provide similar
>     functionality to CNAME, but only redirects type A and AAAA queries.
>     Unlike CNAME, an ANAME can coexist with other record types.  The
>     ANAME RR allows zone owners to redirect queries for apex domain names
>     in a standards compliant manner.
> The IETF datatracker status page for this draft is:
> There are also htmlized versions available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> DNSOP mailing list