Re: [DNSOP] Fundamental ANAME problems

manu tman <> Mon, 05 November 2018 12:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F7A3128CFD for <>; Mon, 5 Nov 2018 04:25:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QhmUvtTtMjgZ for <>; Mon, 5 Nov 2018 04:25:50 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 056BA1298C5 for <>; Mon, 5 Nov 2018 04:25:50 -0800 (PST)
Received: by with SMTP id e11so8966924itl.5 for <>; Mon, 05 Nov 2018 04:25:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4+zkzby8BrVhi3xy/mXZjjgdHJcrZlzVrXSlKuQSikQ=; b=gU36vphlYqe/f49xSFCQBeIEQ6sZs64oTgjKHm+OFiZnU2Zn4pGVSXRbXn+UE+YL05 HhYEzRSbbI7ndH9iqnRpqjVCXhoYaqY+mAyOz9i0mUiPIEL/WEVFNnLAxdf+UzmXa9bd IkhtJ1NGNVrtpWc0VnPrZY9JXB4IduRZy7UvRWs3YKiq0GkP70Dv3WE15U1oDekK9oiA 2jKP9uAeGEbyNemTsApT05cX05NL30y7KCaH7msoghEnDlDTjfBPywjkgaE8UFt9cjYp ta4pYOccyp/2EFH8N6SYeJDlTXiR0SSdbHlqETe1maeBC0neXXLzqeKrfNWaKi8fibOa r2Ww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4+zkzby8BrVhi3xy/mXZjjgdHJcrZlzVrXSlKuQSikQ=; b=og0omm6lmRfg7W65h36NV01T84Z0bvACG/QxM0QHEVfMDYohkEPllEvJ1KRFsTs1pU +g0Ki+qL8K7iblAbPrFMgc4/nCbSZpz4Uq7nMDMjKn3+pJ1J+h7NKKz58232UJw4Zs4w eiOh6ZjkHOcPdzDEvnC10Qg3dCe07HawDZfh8B/elMgAqaNEc4tyVnEmvEU9w35XAfFb bC1VBF6/Xbi2OKsvI8PRpUuAgN55T2VaD8i2/zkGmEBSw4t9huI3kmYevlc2je4R3MQD E4HiCXC6BNO6x2sXHAO4Fs2sDGaVXuKgbIP67RUMg92cbMgrNplgPzAUjvpEPbT1OWZ/ DzaA==
X-Gm-Message-State: AGRZ1gIrO1t42vT5ld3neEAA6V88Wh21NytV510beWNExk8Pa1O1BdWc +kbSum8A36bSvsJvRkE87XSIzCBp8o8Py+nmtvg=
X-Google-Smtp-Source: AJdET5dd0GvnEi5F99k64mwM+NrSBiU1cY1Gbsx8efX5p63BUuHTIDt1Wl/4I52nhsb+utfFQ8a2CripNJF8R6VK/Ig=
X-Received: by 2002:a24:7fc8:: with SMTP id r191-v6mr6616110itc.107.1541420749151; Mon, 05 Nov 2018 04:25:49 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: manu tman <>
Date: Mon, 05 Nov 2018 19:25:37 +0700
Message-ID: <>
Cc:, dnsop <>,
Content-Type: multipart/alternative; boundary="00000000000033e87b0579e9fc15"
Archived-At: <>
Subject: Re: [DNSOP] Fundamental ANAME problems
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 05 Nov 2018 12:25:51 -0000

I like the ANAME idea and find it overall simple if what we are trying to
solve is CNAME at apex. If what is being solved is per service then it is
another story.
As much as I like it, I find the resolution at the auth nameserver a bad
thing for a couple of reasons.

As has been mentioned before:
1) it will add workload on the authoritative nameserver which so far was
mostly doing key/value lookups and now may need to either recurse or
forward to a recursor.
2) the resolution from such lookup will be wrong for resolver/ecs based
answers as you will now get an answer for the recursor at the authoritative
site instead of the client (recursor talking to the auth or ECS). While
doing per site ANAME resolution may make the answers a bit more accurate,
it will definitely not help with operations.

if someone want to do the chaining, I guess they could already do it with
some tooling on their side which will perform regular lookup and update
their zones so essentially making the ANAME resolution an out of band task.

If all that was required was to return an ANAME in the additional section,
it would be pretty straightforward to implement on the authoritative side
and add no complexity there neither workload (or very minimal).
On the recursor side, this will most likely heavily reuse the CNAME logic
and may not be that complex to implement (implementors may tell otherwise).

Recursors that understand ANAMES will be able to treat it as a CNAME and
follow the name chain just like for CNAME. If they don't, well nothing has
changed for them.
It may take time before it gets widely deployed, but it would be a simple
solution that could be easily implemented by the auth that are interested
in it, gets picked up as the recursors get upgraded and be backward
compatible during the transition phase.


On Mon, Nov 5, 2018 at 3:35 PM Måns Nilsson <>

> Subject: Re: [DNSOP] Fundamental ANAME problems Date: Fri, Nov 02, 2018 at
> 04:39:09PM +0000 Quoting Tony Finch (
> > It's really good to see more discussion about ANAME.
> I agree.
> > I think a resolver-side or client-side alternative (like the various
> > web-specific record types we have been discussing) is defintely soemthing
> > we should aim for in the long term, but that isn't what this work is
> > about.
> IMNSHO _any_ work on "fixing CNAMES at apex" that gets traction is
> a spanner in the works for what we seem to agree is a better solution.
> A interim fix will be deployed and stall every attempt at DTRT.
> I am well aware of "perfect being the enemy of good enough" but I'm not
> certain DNAME is "good enough".
> --
> Måns Nilsson     primary/secondary/besserwisser/machina
> MN-1334-RIPE           SA0XLR            +46 705 989668
> _______________________________________________
> DNSOP mailing list