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

Richard Gibson <rgibson@dyn.com> Sun, 09 April 2017 23:04 UTC

Return-Path: <rgibson@dyn.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E68F127337 for <dnsop@ietfa.amsl.com>; Sun, 9 Apr 2017 16:04:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dyn.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9i0wkcdrzqJ for <dnsop@ietfa.amsl.com>; Sun, 9 Apr 2017 16:04:27 -0700 (PDT)
Received: from mail-ua0-x248.google.com (mail-ua0-x248.google.com [IPv6:2607:f8b0:400c:c08::248]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F18481242F5 for <dnsop@ietf.org>; Sun, 9 Apr 2017 16:04:26 -0700 (PDT)
Received: by mail-ua0-x248.google.com with SMTP id 20so12225280uag.14 for <dnsop@ietf.org>; Sun, 09 Apr 2017 16:04:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dyn.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G7sf2SvDxZ/UHnNzFM2ulgka6/aAOJ7juIjMPw2Q/5w=; b=1J/fs7FmLj4HJZuvQZlfoPD20RMKFvo1so5jeZ7fVE0sZ3fmq934a/Imo86EMN4sSR IIoNH4X4xEypr5xX1KvULjJUrLbvKGaA9kL7RV2ip2QJGMI3dVsjMJlVD8axh1av3Qlq ZcdJ/sHJSkeprF9w5xD3GFnxodH9/vTXIqo3E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G7sf2SvDxZ/UHnNzFM2ulgka6/aAOJ7juIjMPw2Q/5w=; b=cv6CU/W8JXcnK4rR43xWoqB0zyPzmmKFsidROvzwv49XGm+5u2pEHnZ0VqEwxmK1wn jJoGkDHF3cgS1RVK8UExlD8BnO1Ezf1J86i04J1BOAbosGlusBfVu4y9bZWkvMC+Zoy5 Gbpk7Br6Bf8IdkMprc3hSgiYuBfVs4vPteypgk8cPXj3TSccKSa5aAcTprkpFRVjKaOj 57+7DU/QAUl23qqHJ6ZGDmDli1oLOwXiZ98dPIcIgwZeFn81ny1O7LZ/e9Wcq8UCHqo0 Q0s+oz4paP7PbZ4u3FOqiIgWkdK0nng6SufzM0rmED/GM0sAEyap9kUPaSps1sHncF6Q fm9Q==
X-Gm-Message-State: AFeK/H1zLZWjo4oGN3biU3DNfqvK4gLFaBZYzpxQVDarE3dDoMLl/C3viSBv2vDoeAhz1wPdZmUr8xB7euvQNmcB
X-Received: by 10.159.52.17 with SMTP id q17mr19463751uab.83.1491779065926; Sun, 09 Apr 2017 16:04:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.81.82 with HTTP; Sun, 9 Apr 2017 16:04:05 -0700 (PDT)
In-Reply-To: <C420946D-0F31-4D32-A945-82B6E78B9133@powerdns.com>
References: <20170407181139.GB66383@isc.org> <CAC94RYaC4QfOwf-_3L6sb0roqjpNPKs78S=yVtwOMzLFCbJbxw@mail.gmail.com> <C420946D-0F31-4D32-A945-82B6E78B9133@powerdns.com>
From: Richard Gibson <rgibson@dyn.com>
Date: Sun, 9 Apr 2017 19:04:05 -0400
Message-ID: <CAC94RYaqTo0rDFiUKV3GUMhoSnGbBJCfc3oXWzS630QuJwR8Lg@mail.gmail.com>
To: Peter van Dijk <peter.van.dijk@powerdns.com>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary=f403045dce8e4ee9d0054cc3e141
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/wyBUs63Mk7TYaCgMTLze6nUEOXs>
Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Apr 2017 23:04:30 -0000

On Sun, Apr 9, 2017 at 3:56 PM, Peter van Dijk <peter.van.dijk@powerdns.com>
wrote:

> Thank you for taking the time for this.


My pleasure; this topic has frequently been on my mind over the past
several years. Thank you for drafting it.

*Section 3.1*
>>
>
>> This section calls for limiting the TTL of cached address records to the
>> lesser of the ANAME TTL and the TTL of the retrieved address records, but
>> section 3 requires servers to follow chained responses. Are the TTLs of
>> intermediate records in a chain supposed to be ignored?
>>
>
What was the response on this point?

What is the expected behavior when the target record set is empty, or
>> bogus, or when resolution fails?
>>
>
> Empty becomes empty. The common case will be ‘the ANAME target only has A,
> no AAAA’ which means the AAAA lookup encounters a valid ‘no data’.


> If resolution fails (i.e. runs into an actual SERVFAIL-like error
> condition, including ‘bogus’), we should also SERVFAIL. If the draft is
> unclear on this we should definitely fix that.
>

Right; I definitely think there should be text explicitly defining behavior
for timeouts, nonzero RCODEs, and bogus responses received when looking up
ANAME targets. Section 4 covers part of it (for recursive servers only),
but doesn't define how to determine when "resolution fails" or what to do
when not opting to use the accompanying records as a fallback, and there is
no guidance at all for authoritative servers.

*Section 3.2*
>>
>> The wording of this section could use some improvement. It seems to
>> prohibit secondary servers from resolving ANAME targets when they are
>> present at the same domain as address types... do I understand correctly?
>>
>
> Yes, that is correct. We went through a few iterations and thought
> exercises and this seemed like the optimal behaviour.


Dyn went another way with our ALIAS functionality, reserving same-domain
address record sets for fallback data to be used whenever target resolution
doesn't yield records of the appropriate type (including, perhaps
controversially, NXDOMAIN and NODATA empty responses). Assuming a secondary
server predating ANAME, the Dyn behavior would be slightly better when the
primary server is ignorant of that gap (i.e., the secondary would always
serve fallback data) and identical behavior when it is not (i.e., the
authoritative would pre-expand as the draft specifies in Section 5). It
also provides support for multi-type host names with single-type targets,
e.g. static AAAA records sharing a domain with an ALIAS targeting a name
providing only A records. Where it really shines, though, is in handling
error cases like those discussed above—it was very important to our
customers that they could prevent us from ever issuing cacheable negative
responses. What thought exercises took you in this direction?

Are such address records still subject to TTL decrementing (presumably
>> starting at the time of zone transfer)? And when only a single address
>> type
>> is present (e.g., just ANAME and A), does that still prevent resolution of
>> the ANAME target for the other type?
>>
>
> (1) Yes, they are still subject to TTL decrementing, but if the slave is
> not ANAME-aware, no decrementing will happen and the draft allows this, if
> we wrote it all down correctly.
> (2) Yes, when any address records are present, the ANAME is deemed to have
> already been expanded. If A is there and no AAAA, then this means that
> there is in fact no AAAA to be had.
>

I understand the motivation, but there's an interesting wrinkle with
respect to forward compatibility... what happens when a new address type is
added to the DNS? The assumption that pre-expansion of any address type
implies pre-expansion of all address types seems like it could lead to some
dramatic changes in behavior as primary servers, secondary servers,
resolvers, and targeted zones become aware of the new type in a nonuniform
fashion. Has any consideration been given to that concern?

On a related note, should recursive resolvers query for ANAME targets even
when they *don't* correspond to A or AAAA QTYPEs?

It is also mute on the use of DNSSEC for resolving ANAME target records,
>> but that should probably be covered somewhere.
>>
>
> This is an interesting topic actually. There are existing deployments of
> PowerDNS ALIAS (which of course is quite similar to ANAME) that use it
> instead of ‘CNAME to unsigned’ so they can sign the target addresses (that
> they get via a non-DNSSEC but still secure path). This draft should also
> allow that. If you have suggestions for a section on ANAME target resolving
> and DNSSEC, please let us know.


Addressing the above points to explicitly define behavior for bogus
responses will cover the functional requirements, so this will likely take
the form of MAY or SHOULD guidance for using DNSSEC when resolving ANAME
targets.