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

From: "Peter van Dijk" <[email-masked]>
Date: Mon, 03 Jul 2017 11:23:01 +0200

Hello Jinmei,

apologies for the delay. Due to the length of your email I flagged it 
for later reading and then I got distracted by other things.

On 13 Apr 2017, at 22:27, 神明達哉 wrote:

> Overall I agree this is worth trying to achieve.  There is a clear
> need for the ability of defining an alias at a zone apex, and it will
> be nicer if we provide a standard-compliant and interoperable way for
> that.  I also agree that a long-term goal (hope) should deploy it in
> the resolver side even if it will take quite long (if not fail), so
> that authoritative server implementations can be kept lightweight and
> simple.

I do not envision a future in which all resolvers support it, so I fear 
auths that want it will need to do it, forever.

> I have one high-level concern in terms of the merit of providing a
> standard/interoperable version of 'alias'.  As already noted in the
> draft there are currently several proprietary mechanisms of 'alias',
> mainly to allow an alias at a zone apex.  In order for the standard
> version to be successful, it will have to be compatible with these
> existing ones as much as possible and as long as it doesn't break
> other DNS standards.

I’d like to agree, but if the existing implementations are not all the 
same, this is unfeasible.

> In that sense I see some disparity with the
> ALIAS record of Amazon Route53, one of the earliest (and probably
> largest) players of the idea:
> - Supporting other types of records than AAAA and A
> - Allowing different target names for different types

As I replied to John Levine, we do not feel this is prudent at this 
stage. Operational experience with ANAME, once standardised and 
deployed, would be a good basis for another draft that is more 
extensive, like having a type bitmap - this would support both these 
features.

> I don't know how critical these are for existing R53 ALIAS users, but
> depending on that ANAME may not be able to be successful in practice.

Outside of R53, most implementations appear to be similar. That’s a 
pretty decent installed base that we can try to convert!

> I also wonder whether it's okay to allow 'AAAA or A' and ANAME to
> coexist for the same owner name.  Shouldn't it be prohibited similar
> to that CNAME and other types can't coexist?

If A and/or AAAA coexist with ANAME, no ANAME expansion happens, as this 
is deemed to have already happened during provisioning or slaving etc.

> Some specific comments on the draft text follow:
>
> - Section 3
>
>    If the original query is for type A, and an RRset of type A exists 
> at
>    the final ANAME <target>, then that A RRset (with <owner> changed 
> to
>    match that of the ANAME RR), MUST be appended to the answer section
>    after the ANAME RRset.
>
>   What if the target name of ANAME does not exist (NXDOMAIN)?
>   Returning NXDOMAIN is quite likely to be a bad choice, since the
>   owner name of the query actually does exist.  It will be certainly
>   problematic if it's a zone apex.  So should it be translated into
>   NOERROR+NODATA?  Or something else?  Also, if the zone is signed,
>   what kind of proof should be returned?

The draft does not usefully cover this right now. Indeed returning 
NXDOMAIN would be wrong, so a NODATA-ish response would be right. The 
proof would consist of a signed NSEC(3) with a type bitmap containing 
ANAME, and if at the apex, also SOA, NS, perhaps MX, etc. A/AAAA would 
not be in the type bitmap.

> - Section 3.1
>
>    Address records cached locally MUST have a limited TTL.  The 
> initial
>    TTL for locally-cached address records MUST be set to the lesser of
>    the ANAME TTL and the TTL of the address records retrieved from the
>    ANAME <target>.  The local TTL MUST count down, just as it would in 
> a
>    conventional resolver cache.[...]
>
>   Should the local TTL count down, even if the initial value is from
>   the ANAME TTL?  I suspect that's not the intent, and if I'm correct
>   I think the current text is confusing and should clarify it.

Noted.

> - Section 3.2
>
>    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 been 
> pre-expanded
>    for zone transfer purposes.  When a zone is being transferred to a
>    secondary server, if any address record already exists at the same
>    node as an ANAME RR, then the ANAME RR MUST NOT be further expanded
>    by the authoritative server.
>
>   (I have a more fundamental concern about the coexistence as stated
>   above, but ignoring it in this context) I'm afraid this text talks
>   about something not explained before this point or not even
>   explained clearly anywhere in the draft.  I guess the "pre-expand"
>   means the following behavior described in section 3.3, but not
>   necessarily with RRSIGs:
>
>    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.
>
>   If my understanding is correct, the concept of population/pre-expand
>   behavior for zone transfer should be explicitly introduced before
>   the discussion in Section 3.2.

Also noted.

Thank you for your extensive review!

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: 神明達哉 <[email-masked]>
Date: Fri, 14 Jul 2017 11:12:31 -0700

At Mon, 03 Jul 2017 11:23:01 +0200,

> pretty decent installed base that we can try to convert!

I'm no by means an advocate of R53-ALIAS, but I suspect its deployment
base as an ALIAS variant is too big to ignore.  If we just keep
ignoring them with the wish of eventual conversion, I'm afraid it's
quite possible that we'll end up having two (or more) incompatible
variants, each has a non-negligible size of deployment.  IMO we should
more explicitly try to avoid that situation.  In that sense I'd like
to suggest contacting someone at Amazon to see if they are interested
in developing an interoperable standard version of ALIAS.

With such efforts and hopefully some hope to have the possibility of
having more compatible deployments, I have no problem with deferring
extensions itself.

--
JINMEI, Tatuya