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/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
