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

From: [email-masked]
Date: Thu, 11 Jan 2018 21:25:39 -0800

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:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-aname-01
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-aname-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-aname-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Bob Harold <[email-masked]>
Date: Fri, 12 Jan 2018 10:20:55 -0500

> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-aname-01
One minor typo:  "AANME" once in section 5 should be "ANAME"

-- 
Bob Harold

---

From: Richard Gibson <[email-masked]>
Date: Mon, 22 Jan 2018 13:59:18 -0500

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 
NODATA or NXDOMAIN?

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
    https://www.ietf.org/mail-archive/web/dnsop/current/msg20061.html .
    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 
time:

    @     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 192.0.2.1 ; removed ANAME expansion
    aname A 192.0.2.2 ; 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 192.0.2.1 ; 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, [email-masked] wrote:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Ddnsop-2Daname_&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=RTkkehWDtp4BTCTzFokAZCDAuCd_w3pUmKgrZI930wg&s=ulCMqQ4wONLJG9KK0IQABDgOA2c8Re-qj7QjvlccUmM&e=
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Ddnsop-2Daname-2D01&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=RTkkehWDtp4BTCTzFokAZCDAuCd_w3pUmKgrZI930wg&s=lIM4rArEf1_3WZ-wc0OAMjrrQl7oPojbWnL5c-sWvyE&e=
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Ddnsop-2Daname-2D01&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=RTkkehWDtp4BTCTzFokAZCDAuCd_w3pUmKgrZI930wg&s=zH9k0X0QisCnWUvpbFOYTUIPo-OXmY8eds60z-VhPyE&e=
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Ddnsop-2Daname-2D01&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=RTkkehWDtp4BTCTzFokAZCDAuCd_w3pUmKgrZI930wg&s=dz9gowqhmuf5y-hhYE1mO53PxoJnMye_-MjScoWpsJQ&e=
>
>
> https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=RTkkehWDtp4BTCTzFokAZCDAuCd_w3pUmKgrZI930wg&s=KOnatQo8HbAQv2xzq5uohkI5K0barAUuYdIu9PMd_7Q&e=
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=RTkkehWDtp4BTCTzFokAZCDAuCd_w3pUmKgrZI930wg&s=GiCIMlFzleSHBbNYaGcNmJZBGJ5cSZIsI9BMUp2y8qI&e=

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 25 Jan 2018 22:05:24 +0000

I asked some questions about the -00 of this draft back in October which
I don't think were addressed:

  https://mailarchive.ietf.org/arch/msg/dnsop/Pc8iGemfjO2FsNV-MNd5n6eKvUc/?qid=c250bacc5206b035878ddcb9036b9e53

I'll try to ask them again based on the current text:

>    The initial
>    TTL for locally-cached address records MUST be set to the minimum of
>    the ANAME TTL and the TTLs of the intermediate and address records
>    retrieved during ANAME <> resolution.

Why does the draft mandate initial TTL behavior?  The important aspect
would seem to be how long the data can be kept in cache, not what the
(initial) TTL value is.  As I noted in the previous message, Unbound's
cache-max-ttl works that way and I think it has some nice properties.

Also in this new text I'm not sure what to make of "intermediate and address
records." If "and" is truly intentional in this phrase then I think
intermediate should be better defined, or examples given.

>    Address records with expired TTLs MUST NOT be used to answer
>    address queries until refreshed by sending a new query to the ANAME
>    <target>.
> 
>  [...]
> 
>    If resolution of the ANAME <target> yields no address records due to
>    some other failure, and the query was for a specific address type,
>    the response MUST include the ANAME record and set the RCODE to
>    SERVFAIL.

If the authoritative server has address records, which then expire, and
cannot be refreshed, I read this as saying the later response must be
SERVFAIL.

That seems in contradiction with the ideas of draft-serve-stale which says
"stale bread is better than no bread" and "Several major recursive resolver
operations currently use stale data for answers in some way ...  Their
collective operational experience is that it provides significant benefit
with minimal downside."

> In this case, the master server MUST respect the TTLs of the address records,

Suggest s/master/primary/ to be consistent with previous text.

DW

> On Jan 11, 2018, at 9:25 PM, [email-masked] wrote:
> 
> 
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Evan Hunt <[email-masked]>
Date: Thu, 25 Jan 2018 23:27:01 +0000

> cache-max-ttl works that way and I think it has some nice properties.

I'm not sure I understand the distinction you're making. When you first
cache something, its TTL represents the length of time that data can be
kept in the cache, and it counts down from there to zero. That's what
I meant by the initial TTL.

> intermediate should be better defined, or examples given.

Suppose ANAME (TTL 3600) points to a CNAME (TTL 30) which points to a CNAME
(TTL 5) which points to an A (TTL 86400).  The response would contain ANAME
with TTL 3600 and, because of the intermediate CNAME, A with TTL 5.

Suggestions welcome for a clearer way to phrase this.

> cannot be refreshed, I read this as saying the later response must be

For A or AAAA queries, that is the intent. An explicit query for type ANAME
would still be answered.

> collective operational experience is that it provides significant benefit

This seems like a job for the resolver, not the auth server.  In the long
term my hope is that resolvers will implement ANAME, chase the answers
themselves, and then decide whether to serve stale records or not.
However, I guess we can relax this requirement if the auth server is
configured for serve-stale.

--
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 25 Jan 2018 23:51:30 +0000

> On Jan 25, 2018, at 3:27 PM, Evan Hunt <[email-masked]> wrote:
> 

As an example, consider an ANAME record with TTL 3600 and a corresponding
AAAA record with TTL 86400.

I'm suggesting its just as acceptable to return the AAAA record with TTL counting
down from 86400, but after 3600 seconds it is ejected/marked stale/whatever from
the ANAME-implementing authoritative server.

Unbound does that with its cache-max-ttl setting.

If you do it this way then the consumers of the data (including ANAME-unaware
clients) get to cache it for the original TTL.  

> Suggestions welcome for a clearer way to phrase this.

I now notice that intermediate is sort of defined at the end of section 3.  Perhaps
that is sufficient.  I guess we don't have a good collective term for CNAME/DNAME/ANAME yet.

> configured for serve-stale.

It seems to me that ANAME gives auth servers resolver-like properties, so why
wouldn't that apply there as well?

DW

---

From: Evan Hunt <[email-masked]>
Date: Fri, 26 Jan 2018 02:44:51 +0000

> AAAA record with TTL 86400.

You'd want the AAAA to expire no later than the ANAME did, because the
ANAME might have been updated to point to some other name by then.

> I'm suggesting its just as acceptable to return the AAAA record with TTL
> counting down from 86400, but after 3600 seconds it is ejected/marked
> stale/whatever from the ANAME-implementing authoritative server.
> 
> If you do it this way then the consumers of the data (including
> ANAME-unaware clients) get to cache it for the original TTL.  

That's exactly what I'm trying to prevent.

With an ANAME-aware resolver, the address returned by the auth is ignored,
the resolver chases the answer for itself, and records are all cached with
their original TTLs.  The ANAME answer and the target answers expire when
they should, just as with a CNAME now.  In your example, the ANAME expires
after 3600 seconds, so we re-query to refresh it. If it's changed, then we
follow it to get a new AAAA, but if it hasn't changed, then since we already
have the AAAA cached, there's no need to chase it again.

But with an ANAME-unaware resolver, it asked for an address, got one, and
will cache it for whatever TTL you sent it. If your ANAME has a one-hour
TTL, then you wouldn't want to send a higher TTL than that; you'd just
overriding the ANAME TTL.

> It seems to me that ANAME gives auth servers resolver-like properties, so
> why wouldn't that apply there as well?

Yes, fair point. I'll try to come up with text to address this.

---

From: Stefan Bühler <[email-masked]>
Date: Fri, 26 Jan 2018 12:54:59 +0100

Hi!

I have concerns about the resolver replacing A/AAAA records in signed
zones as it breaks validation.

If a resolver understanding ANAME is queried using the DO=1 flag it
shouldn't touch the A/AAAA records, because it already knows the
requestor would through them away.

This also means a caching resolver should store the original A/AAAA
records (and not the ones resolved through ANAME) in the cache.

With this change I don't think it makes sense to say "a resolver MUST
re-query", I'd use "a resolver SHOULD re-query if it didn't use ECS and
the query didn't use DO=1".  But I'd add "a resolver MUST include ANAME
RRset in respones to queries for A/AAAA".

cheers,
Stefan

---

From: Bjørn Mork <[email-masked]>
Date: Fri, 26 Jan 2018 13:51:38 +0100

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>?

I believe this needs to be discussed in the light of the RFC2181
wording:

 |   The domain name used as the value of a NS resource record, or part of
 |   the value of a MX resource record must not be an alias. 

Is the ANAME owner an alias?

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.

>    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>.

>    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"?

>    Because not all querying resolvers understand ANAME, the
>    authoritative server MUST also return address records, as described
>    below.
..
>    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?

There is also an exception for DNSSEC signing failures, where the server
is allowed to return only the ANAME.  I guess the "as described below"
can be interpreted as a condition for the MUST, but I believe the
exceptions should be made clear along with the requirement.  Or at least
make it clear that exceptions will follow.  E.g:

  "...MUST also return address records, except as noted below"

But if A or AAAA aren't really required after all, then why pretend they
are?

> 3.2.  Coexistence with other types
> 
>    If the zone is configured with an A or AAAA RRset at the same DNS
>    node as ANAME, then the ANAME is considered to have already been
>    expanded.  If during query processing any address records are found
>    at the same node as an ANAME RR, then the ANAME RR MUST NOT be
>    further expanded by the authoritative server.
> 
>    ANAME MUST NOT coexist with CNAME or any other RR type that restricts
>    the types with which it can itself coexist.
> 
>    Like other types, ANAME MUST NOT exist below a DNAME, but it can
>    coexist at the same node; in fact, the two can be used cooperatively
>    to redirect both the owner name (via ANAME) and everything under it
>    (via DNAME).
> 
>    ANAME can freely coexist at the same owner name with any other RR
>    type.

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.

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

> 
> 3.3.  DNSSEC signing
> 
>    If the zone in which the ANAME resides is DNSSEC-signed, and if the
>    server has access to its private zone-signing key, then the A and
>    AAAA RRsets MUST be signed, either in advance when populating the A/
>    AAAA answers for the ANAME records, or "on the fly" when responding
>    to a query.
> 
>    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:

 |   For each authoritative RRset in a signed zone, there MUST be at least
 |   one RRSIG record that meets the following requirements:
 |    ...

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.

>    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.

> 
>    Implementers MAY allow address records associated with the ANAME to
>    be populated and signed by the primary server, then sent along with
>    their RRSIGs to secondaries via zone transfer.  In this case, the
>    master server MUST respect the TTLs of the address records, MUST
>    refresh the address records by re-resolving the ANAME <target> when
>    their TTLs expire, SHOULD respond to address queries with TTLs that
>    count down as they would when answering from a normal DNS cache, and
>    MUST inform secondary servers via DNS NOTIFY they need to refresh the
>    zone when address records have been updated.  A secondary server
>    SHOULD store address records and associated RRSIGs supplied via zone
>    transfer in such a way that their TTLs will count down, as they would
>    in a normal DNS cache, and ultimately trigger a zone refresh query
>    upon reaching zero.  When a secondary server is responding to an
>    address query, it SHOULD answer with the reduced TTL, but when
>    responding to a zone transfer request, it MUST answer with the
>    original TTL received from the primary.
> 
>    If this address record expansion and signing during zone transfer is
>    not supported, then every authoritative server providing ANAME
>    responses in a signed zone SHOULD have access to the private zone-
>    signing key for that zone.  Deployment of ANAME in signed zones where
>    address records cannot be signed due to lack of access to the private
>    zone-signing key is NOT RECOMMENDED.

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.

>    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?

> 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.

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'?

Bjørn

---

From: Evan Hunt <[email-masked]>
Date: Fri, 26 Jan 2018 20:09:42 +0000

> zones as it breaks validation.

What do you mean by "the resolver" in this case?

> requestor would through them away.

It doesn't *know*. DO=1 doesn't mean the client is validating; it means the
client understands RRSIG.

The draft already advises that ANAME will break validation unless the
validator is ANAME-aware or the auth server has access to the zone's
private key and can sign responses on the fly. (This suggests to me that
the use of ANAME in signed zones will probably be limited at first.)

> records (and not the ones resolved through ANAME) in the cache.

Certainly.

> the query didn't use DO=1".

I'm sorry, I'm not getting this. Please explain further, particularly
with an expansion of the word "it"?

> But I'd add "a resolver MUST include ANAME

Yes, I'd been assuming it would. If I forgot to mention it in the
draft, I'll fix that.

---

From: Evan Hunt <[email-masked]>
Date: Fri, 26 Jan 2018 22:09:34 +0000

> 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.)

> 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.

> multiple ANAMEs.  E.g using more than one CDN provider for a given

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.

> Is this a MUST, SHOULD or "may occasionally do"?

MUST, thanks.

> Aren't these requirments conflicting?

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

> AFAICS, they are generic and not modified in any way by the introduction

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

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.

> 'internal network' anyway.

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.

> 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.

> These rules should not depend on the zone being signed or not.

Noted, I'll consider this.

> 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.

> 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?

>     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.

---

From: Tony Finch <[email-masked]>
Date: Tue, 30 Jan 2018 18:56:09 +0000

I have read through the draft. I like it a lot and I really want this
feature! I've quoted bits of it below (indented) and added my comments
and questions. Warning, this is nearly 1400 words...

1.  Introduction

Is it worth explicitly mentioning the case of subdomains such as
`department.example.edu` that have an MX and a web site at the same
domain?

2.  The ANAME Resource Record

Thinking out loud, I quite like the idea of relaxing this requirement,
but then I imagine what happens to the unlucky resolver that is
presented with a huge ANAME RRset...

3.  Authoritative Server Behavior

Should the intro to this section say that the auth server is expected
to cache the address records, not resolve them each time?

I think this auth section needs to be split into separate sections for
primary and secondary authoritative servers: primary servers do ANAME
target address record lookups (and have DNSSEC private keys for signed
zones); secondary servers passively receive ANAME + address records
via AXFR/IXFR, and do no lookups or signing.

In the secondary case, the cache logic is a bit different. The
upstream primary is responsible for implementing the TTL logic, but it
only needs to notify the secondaries when the records actually change.

3.1.  Address records returned with ANAME

Can we make this a SHOULD NOT to allow for authoritative service to
continue working during an outage (serve-stale)?

I think it might be clearer if this paragraph is moved up to the start
of section 3.1 following the A and AAAA paras. You can then tie it
more directly to the presence/absence wording for each addr type.

It would be nice to allow for serve-stale here too.

I think this should be conditional on whether the server is primary or
secondary wrt this zone. (The "already present" case sort of implies
secondary, but I think the difference should be more explicit.)

In the primary case I wonder if it would make sense for the server to
include the address records in the zone's persistent storage. It's
mildly tricky, tho, because:

(a) The server needs to distinguish between the case where it is
loading from a master file and it really is the primary, or it's
loading a master file that has been provisioned by some other system
that expands ANAME (i.e. it looks like a trad primary but it's
functionally a secondary that just isn't using AXFR/IXFR),

(b) What if the server starts off with a zone that lacks ANAME address
records, but they get subsequently added by an UPDATE?

(c) When it is loading a zone without ANAME address records, how does
it know that it is supposed to be a primary and resolve the ANAME
target, or that it ought to behave like a secondary but the ANAME
resolver found no records at the target?

(d) A primary that supports ANAME and ECS may need to persist the ECS
metadata in the zone file, and if that is the case there should be a
presentation format for ECS options and associated variant RRsets.
This is a horrible can of worms.

>From the server config / ops point of view it probably makes sense to
have a `resolve-aname-addresses` option which defaults to `on` for a
master/primary zone and off for a slave/secondary zone.

   Like other types, ANAME MUST NOT exist below a DNAME,

Should this mention occlusion?

3.3.  DNSSEC signing

I think it would be better if this is a MUST NOT - either the server
is a primary and has the signing keys, or it's a secondary that
receives pre-re-signed address records from a primary.

   Implementers MAY allow address records associated with the ANAME to
   be populated and signed by the primary server, then sent along with
   their RRSIGs to secondaries via zone transfer.

I would upgrade this to a SHOULD - servers can skip this if they don't
support zone transfers.

   zone when address records have been updated.

Does this mean that there should be a NOTIFY every TTL? And when the
secondary refreshes the zone and finds there has been no change, it
can start counting down the TTL again?

   A secondary server
   upon reaching zero.

I think a secondary server can know it needs to perform this special
countdown behaviour because the address records are next to an ANAME.

   If this address record expansion and signing during zone transfer is
   not supported, then every authoritative server providing ANAME
   responses in a signed zone SHOULD have access to the private zone-
   signing key for that zone.

Yes - or, in the terminology I am using, without signed zone
transfers, every authoritative server has to act as a primary.

I think this needs changing for DNSSEC. Suggestion:

If the resolver is responding to a client with DO=1 and CD=0 and the
answer is signed, then it must return the authoritatively signed
address records to the client.

If the client queries with DO=0 or CD=1 or the answer is unsigned,
then the resolver can return its own version of the ANAME target
address records.

(In all cases the value of the AD bit in the query does not matter.)

In practice nowadays I think the majority of resolver clients (i.e.
stubs) have DO=0 - clearly it'll be good to get ANAME out the door
before end-user DNSSEC becomes a lot more common :-)

5.  Examples

   A query for example.com/AANME would receive only the ANAME in the

Typo!

6.  Operational Considerations

   When a zone containing ANAME records is transferred to a secondary
   server, the ANAME records are transferred, but the A or AAAA records
   retrieved from the ANAME <target> may not be.

In this case, in my primary/secondary split model, the secondary would
have to do the equivalent of flipping the `resolve-aname-addresses`
setting.

7.  Implementation Status

Maybe I should write a thing to periodically UPDATE a zone with
address records from an ANAME target (in my copious spare time) :-)

8.  Security Considerations

   An authoritative server which implements ANAME resolves address
   queries on behalf of its clients, either internally or by querying an
   external resolver.  This resolution must be allowed to take place
   regardless of whether the client would ordinarily have been permitted
   by local policy to send recursive queries.

I think this should be cross-referenced from earlier, because it's an
implementation requirement rather than just a consideration.

...

That's all for now, I think!

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Lundy, Fastnet, Irish Sea: Southwest 5 or 6, veering west 6 to gale 8.
Moderate or rough, becoming very rough or high in Lundy and Fastnet. Rain with
fog patches then showers. Moderate or good, occasionally very poor.

---

From: Tony Finch <[email-masked]>
Date: Wed, 31 Jan 2018 04:35:38 +0000

I realised that the primary/secondary split I talked about in my previous message turned out to be the wrong idea. There were lots of complicating issues that made it clear that auth server ANAME behaviour does not cleanly follow the traditional primary/secondary split.

Instead I think the split should be between active ANAMEs, where an auth server fetches address records from the target, and passive ANAMEs, where the server just uses the addresses it got from the master file or zone transfer etc.

A server can be active if it has the private signing keys or if the zone is unsigned. It has to be passive if the zone is signed and it lacks keys. It doesn’t matter how the zone contents are provided to the server.

I still think it would be helpful to have separate sections in the spec for active and passive auth servers.

This active/passive split could also be extended to recursive servers, tho the logic is a bit different. (See previous message for details.) I don’t know whether or not it makes sense to have auth servers be similarly sensitive to DO and CD.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at

---

From: Tony Finch <[email-masked]>
Date: Wed, 31 Jan 2018 17:00:48 +0000

I've been pondering DNSSEC and additional data.

I think it's currently the case for additional section processing in
general that if (say) an AAAA RRset isn't present, then nothing is
added to the additional section. I think it would be better to add an
NSEC(3) proof of nonexistence if the relevant zone is signed.

The ANAME draft is consistent with traditional behaviour. I vaguely wonder
if it would be worth encouraging additional section PNEs, or if it would
be wedging too much into the spec.

One reason not to beef it up in this way is that, as currently written,
ANAME generally doesn't require two upstream queries for one incoming
query - if the other address type isn't cached the server can just omit
it. The exception is a dynamic signed PNE where the server has to ensure
the type bitmap is correct.

On the other hand, if it is beefed up then an ANAME query effectively
becomes the mythical one-message A+AAAA query. I dunno if this counts in
favour or against :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Hebrides, Bailey, Fair Isle, Faeroes, Southeast Iceland: Cyclonic at first in
Fair Isle, otherwise northerly or northwesterly 6 to gale 8, occasionally
severe gale 9. Very rough or high. Squally wintry showers. Good, occasionally
poor.