I haven't reviewed the full draft yet, but am happy to see some people
echoing my sentiments from earlier versions [1]. I particularly wanted
to agree with some statements from Bob Harold.
On 11/2/18 15:20, Bob Harold wrote:
Another option to give users is a non-updating fallback A record, that
could point to a web redirect. That saves all the hassle of updates.
YES! This means a slightly worse fallback-only experience for users
behind ANAME-ignorant resolvers that query against ANAME-ignorant
authoritatives (the introduction of ANAME awareness to /either/
component allowing an opportunity to provide better address records by
chasing the ANAME target), but provides a dramatic reduction in the
amount of necessary XFR traffic. And even more importantly, it forces
TTL stretching to be an explicit decision on the part of those
administrators who choose to perform manual target resolution and update
their zones to use them as fallback records (as they would do now to
approximate ANAME anyway), rather than an inherent and enduring aspect
of the functionality.
Treating ANAME-sibling address records as fallback data also supports
better behavior for dealing with negative results from resolving ANAME
targets (NODATA, NXDOMAIN, signature verification failure, response
timeout, etc.)—serve the fallbacks.
My preference would be a *NAME record that specifies which record
types it applies to. So one could delegate A and AAAA at apex to a
web provider, MX to a mail provider, etc. That would also be valuable
at non-apex names. But I am happy to support ANAME as part of the
solution.
I agree on both counts (arbitrary type-specificity and deferment to a
later date).
[1]: https://www.ietf.org/mail-archive/web/dnsop/current/msg21722.html
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
