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

Evan Hunt <each@isc.org> Fri, 26 January 2018 22:09 UTC

Return-Path: <each@isc.org>
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 3D7A712711D for <dnsop@ietfa.amsl.com>; Fri, 26 Jan 2018 14:09:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 YulcOYNybC39 for <dnsop@ietfa.amsl.com>; Fri, 26 Jan 2018 14:09:36 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6991200E5 for <dnsop@ietf.org>; Fri, 26 Jan 2018 14:09:36 -0800 (PST)
Received: from bikeshed.isc.org (bikeshed.isc.org [149.20.48.19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 493703AB075; Fri, 26 Jan 2018 22:09:34 +0000 (UTC)
Received: by bikeshed.isc.org (Postfix, from userid 10292) id 30C09216C1C; Fri, 26 Jan 2018 22:09:34 +0000 (UTC)
Date: Fri, 26 Jan 2018 22:09:34 +0000
From: Evan Hunt <each@isc.org>
To: Bjørn Mork <bjorn@mork.no>
Cc: dnsop@ietf.org
Message-ID: <20180126220934.GB7808@isc.org>
References: <151573473976.18703.16142464801623244164@ietfa.amsl.com> <87o9lg3hr9.fsf@miraculix.mork.no>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <87o9lg3hr9.fsf@miraculix.mork.no>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/u4yMKnFQgjKoiPybHdtnhGWcNek>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.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: Fri, 26 Jan 2018 22:09:39 -0000

On Fri, Jan 26, 2018 at 01:51:38PM +0100, Bjørn Mork wrote:
> Is there a need to explictly modify MX and NS records, allowing them to
> point to an ANAME?  Or is this already covered by the mandatory A or
> AAAA records for the ANAME <owner>?

It certainly would be reasonable for MX. I have feelings of unease
about NS, but I'm not sure whether they're well-founded. (I'd welcome
further discussion on this topic, if anyone has thoughts.)

> Should there be a section dealing with using an ANAME owner as a
> target of other RRs?  This could probably be made very simple by saying
> that an ANAME owner is allowed wherever an A or AAAA owner is.

Yes, that would be a reasonable way to put it, with maybe a carve-out for
NS.  I'm going to wait for further discussion, either here or with my
co-authors, before I try to revise the text, though.

> >    Only one ANAME <target> can be defined per <owner>.  An ANAME RRset
> >    MUST NOT contain more than one resource record.
> 
> Is there a technical reason for this?  I can easily see usecases for
> multiple ANAMEs.  E.g using more than one CDN provider for a given
> <owner>.

I can see use cases for it too, but it leads to a rapid combinatoric
explosion in complexity. Which A/AAAA records do you return if you can't
get all of them? How do you signal that your response is incomplete?  We
decided to dodge the issue; it's complicated enough already. And after all
people do get along with CNAMEs, and those can't be multiple either.

> >    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.
> 
> Is this a MUST, SHOULD or "may occasionally do"?

MUST, thanks.

> 
> >    Because not all querying resolvers understand ANAME, the
> >    authoritative server MUST also return address records, as described
> >    below.
> ..
> >    If resolution of the ANAME <target> yields no address records due to
> >    NODATA or NXDOMAIN, then the authoritative server MUST return only
> >    the ANAME record.  If the query was for a specific address type, then
> >    the response MUST also include the SOA as in a normal NODATA
> >    response, along with NSEC or NSEC3 if applicable.
> 
> Aren't these requirments conflicting?

The exceptions were meant to be covered by "as described below", but I'll
clarify this.

> > 3.2.  Coexistence with other types
> 
> Is it really necessary to summarize the CNAME and DNAME rules here?
> AFAICS, they are generic and not modified in any way by the introduction
> of ANAME.

Admittedly there's nothing here that you couldn't deduce by reading other
RFCs, but I think it improves the spec to be clear and explicit about how
this new alias record fits in with existing rules for other alias records.

> Maybe include the one ANAME per RRset restriction in this section, if
> that is kept?

I prefer to have such limitations specified along with the RR format.  I
don't mind repeating the admonition, but this section is about coexistence
with other types, so it doesn't seem like a good fit here.

> >    If the server does not have access to the private zone-signing key
> >    then it MAY return unsigned address records, but this is NOT
> >    RECOMMENDED
> 
> 'NOT RECOMMENDED' is too weak here.  The section conflicts with RFC4035:
> [...]
> Suggested alternative text
> 
>     The server MUST NOT return unsigned address records.
> 
> 
> >          unless every resolver with access to the zone is known to
> >    support ANAME (as might be the case in a split-horizon deployment
> >    where ANAME records are only served to an internal network with its
> >    own resolvers).
> 
> I fail to see the relevance of this. You don't need an RFC to tell you
> what you can do on your private network.  Although I guess an 'internal
> network with its onw resolvers' using a CDN to provide service might
> exist, I find this example really confusing.  It looks like a bad excuse
> for the RFC4035 violation.  Which nobody is going to care about on your
> 'internal network' anyway.
> 
> I suggest removing this.

We were trying to address an existing use case. Your point is well taken
that internal networks can violate specifications if they want to, but we
wanted to address the concerns of people with existing deployments.

> >    Validating resolvers which do not yet implement ANAME will not be
> >    able to validate the A and AAAA responses included with an ANAME
> >    response unless those responses are validly signed by a DNSKEY at the
> >    apex of the zone in which the ANAME resides.  Passing along the
> >    RRSIGs associated with the original A and AAAA RRsets from the ANAME
> >    <target> will not be sufficient for DNSSEC validation.
> 
> Does this say anything useful at all? There is nothing ANAME specific
> here. I suggest removing this as well.
> 
> The "which do not yet implement ANAME" is confusing at best.  Resolvers
> having implemented ANAME will be equally unable to validate unsigned A
> and AAAA responses included with an ANAME response.

It's meant to explain the reasoning behind the requirement, which some
other readers found confusing. To put it more correctly, validating
resolvers which don't implement ANAME won't know that they shouldn't bother
validating these addresses, so validation will fail unless the signatures
are replaced by the ANAME zone.  I'll try to clarify.

> I agree with Richard Gibson that the zone transfer considerations merit
> their own section. This has nothing to do with DNSSEC.
> 
> The synthesized A and AAAA RRs are treated as authoritative dynamic
> records, and DNSSEC, serial number calculation, zone transfers etc
> should simply follow the normal rules for such records. Please don't
> define rules allowing slaves to serve different content for the same
> serial number.
> 
> The TTL handling rules also need to be split out of the DNSSEC section.
> These rules should not depend on the zone being signed or not.

Noted, I'll consider this.

> >    When ANAME is present in a signed DNS node and address records exist
> >    at the ANAME <target>, the type bit map in the NSEC [RFC4034] or
> >    NSEC3 [RFC5155] record for that node MUST include bits for A and/or
> >    AAAA as well as ANAME.  This is for the benefit of validating
> >    resolvers not implementing ANAME which may use a signed proof of
> >    nonexistence for type A and AAAA to prevent address queries from
> >    being resolved.  The type bit map SHOULD only include address types
> >    which are known to exist at the <target>.
> 
> This is confusing.  Won't the type bitmap have to be correct for *any*
> validating reolver, including those implementing ANAME? Or are they
> supposed to modify it? If so, how?

Again, this is meant to explain the reasoning behind the requirement.  If
the bit map indicates the absence of A/AAAA but the resolver is
ANAME-aware, then it won't matter - we'll chase the ANAME target and get
the answer we wanted, the same as with CNAME.  But if the resolver is *not*
ANAME-aware, we don't want it to look at a cached NSEC, see the missing A
and AAAA bits, and decide not to send a query.

> > 4.  Recursive Server Behavior
> > 
> >    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.  (This
> >    requirement MAY be relaxed if both the ANAME <owner> and <target> are
> >    validly signed and provably in the same zone.)
> > 
> >    If resolution fails -- for example, due to the local resolver being
> >    nonfunctional or the ANAME <target> zone being unreachable -- then
> >    the resolver MAY use the address records that were included in the
> >    authoritative response as a fallback.  Otherwise, these records MUST
> >    NOT be cached or returned.
> 
> This section needs a DNSSEC discussion.  It seems to be written under
> the assumption that a recursive server can modify the answer.  This is
> bogus, and you should know that.

I must have phrased it badly, but I'm not sure how to improve it because
I don't see where you're seeing that assumption?

> Please solve the following problems:
> 
>  1) authoritative server answers an A query with with NSEC, ANAME, A,
>     and valid RRSIGs for all three RRsets.  The recursive server
>     implements ANAME and does further processing of it, replacing the A
>     RRset.  What RRSIGs should it send to clients setting 'DO'?
>     
>  2) autoritative server answers an A query with NSEC + ANAME with valid
>     RRSIGs, but no A or AAAA RRsets.  The recursive server implements
>     ANAME and does further processing of it, adding an A RRset to the
>     answer.  What RRSIGs should it send to clients setting 'DO'?

Some thought required, I'll come back to this.

Thanks very much for the comments.

-- 
Evan Hunt -- each@isc.org
Internet Systems Consortium, Inc.