Re: [DNSOP] Minimum viable ANAME

Paul Wouters <> Wed, 19 September 2018 16:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 137F1130E17 for <>; Wed, 19 Sep 2018 09:38:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=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 Ks3Kj3AJ-kh7 for <>; Wed, 19 Sep 2018 09:38:15 -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 083F5130E12 for <>; Wed, 19 Sep 2018 09:38:15 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 42Flsc2JRXzF13 for <>; Wed, 19 Sep 2018 18:38:12 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1537375092; bh=lT5+1XIEjcP7C6C80O1aBw35J+k63e+WdskESMkjabk=; h=Date:From:To:Subject:In-Reply-To:References; b=lZ37+Aw0x4DxBymqqB/cs8rGUz4cBEGRI1DyT1exqXalZ7lh0AxVv3S6MtQCy2wH9 nyph9uw+/YTVdZFXEd9vi3eYYktWAyMTBiiXmY2oxXfk6gZxWsroua5LYLDWXAbjf6 ycudm+Ouuco64VKAITydPIedbc0Meto2s7Qfih2k=
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id JcfOB0LgfzVs for <>; Wed, 19 Sep 2018 18:38:10 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS for <>; Wed, 19 Sep 2018 18:38:09 +0200 (CEST)
Received: by (Postfix, from userid 1000) id EAA415602C5; Wed, 19 Sep 2018 12:38:08 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 EAA415602C5
Received: from localhost (localhost []) by (Postfix) with ESMTP id E0232424DCCA for <>; Wed, 19 Sep 2018 12:38:08 -0400 (EDT)
Date: Wed, 19 Sep 2018 12:38:08 -0400 (EDT)
From: Paul Wouters <>
To: dnsop <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <>
Subject: Re: [DNSOP] Minimum viable ANAME
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: Wed, 19 Sep 2018 16:38:18 -0000

On Wed, 19 Sep 2018, Paul Vixie wrote:

> Tony Finch wrote:
>>  Anthony Eden<>  wrote:
>>>  FWIW, there's still always
>>  I get the impression that a lot of the objection to the current ANAME
>>  draft is that it specifies that auth servers do ANAME target lookups and
>>  record substitution; your draft says the same thing. I think those
>>  objections are reasonable, but I don't think the problem lookups are
>>  particularly important (or even helpful).
> +1.

4.  Security Considerations

    To function properly with DNSSEC-aware resolvers, authoritative name
    servers MUST sign the materialized records produced by the ALIAS

    Implementors MAY either materialize A and AAAA records offline and
    sign the resulting records at that time, or sign the resulting
    materialized records at request time.

This is not a proper Security Consideration section. Please see
What is described here is a fundamental flaw in this proposal.

That fact is even more clear by the MAY in that section, which basically
says "you can address this security issue or not, whatever"

A mechanism could be designed that is more generally usable.

Forcing a authoritative servers to do DNS lookups is asking for trouble.
Some deployments combine auth+recursive and such a server now needs a
working resolv.conf, and one that cannot point to itself. Clearly this
is going to break stuff. We have known for decades that combining
authoritative plus recursive was a bad idea, yet here it is again
glueing these two parts together so the auth server needs resolving
code. The place to do anything is on the resolver, the authoritative
server should just serve blobs.

Synthesizing (here called "materialising" ?) records is awful. It does
not work with offline DNSSEC signers, and if we want to solve this
properly, we can do so easilly with a solution that does not have
this limitation.

The design goals of a solution in this space should be:

- Fully supports DNSSEC
- Does not require AUTH server changes other then supporting a new
   RRTYPE presentation / wire format and/or serving a new RRTYPE as
   Additional Data.
- All optimization work is done on the resolver. If this includes
   'rewriting' A/AAAA records, DNSSEC proofs MUST be included for
   stub clients doing validation.

for example, why not serve an ALIAS record as additional data to A/AAAA
queries? Then resolvers that dont support this are as bad of as now.
Resolvers supporting this, will pick up the ALIAS, resolve it, put those
A/AAAA records in cache, and serve any clients asking for these A/AAAA
with the A/AAAA, ALIAS and target A/AAAA records.