On 11/9/18 4:27 AM, Richard Gibson wrote:
I have finally reviewed the latest draft directly, and like the overall
direction but have a small number of issues (however, the issues
theirselves are somewhat fundamental). They broadly break down into
concerns about zone transfers and TTL stretching, and ultimately seem to
stem from a disagreement with my position that the proper conception of
ANAME sibling address records is as fallback data to be used in cases
where ANAME target resolution fails or is never attempted.
First, I am troubled by the requirement that ANAME forces the zone into
a dynamic zone. That a primary master would dynamically replace sibling
records on its own, update the zone serial, and then propagate that
dynamic data via zone transfer overrides user conception about the state
of a zone, induces undesirable churn between authoritative nameservers,
/and/ stretches the TTLs of ANAME targets on downstream servers by the
amount of time between successive updates. These consequences are just
too much for what is supposed to be a low-impact feature. Anyone willing
to opt-in to them should be updating the ANAME sibling address records
on their own, not forcing authoritative server implementations to choose
between taking on that dirty work or being labeled noncompliant.
It seems that everyone thinks that the latest ANAME draft requires DNS
UPDATE. This is just a use case that Tony provides and would help him in
his daily operations. However, it is not required to do so: ANAME
resolution can also happen by updating the zone file before loading it
into the primary server. Or it may happen in the authority server if
people desire to implement it there.
I think the draft should be updated to make that absolutely clear. The
draft should standardize how ANAME resolution is done, and what it means
to have ANAME and sibling address records in the zone for address rtype
(A, AAAA, ...) and ANAME query lookup.
The customer does not care about the address records, other than it may
want to provide a default address. So in their provisioning dashboard
they will only add a domain name that represents their CDN or whatever.
The DNS provider will perform ANAME resolution somewhere between where
the customer provides the ANAME and hands out the addresses to the DNS
client.
Second, and relatedly, I think the TTLs of replacement records
established for non-transfer responses are too high. Respecting the TTL
of every record in a chain that starts with the ANAME requires the TTL
of final replacement records to be no higher than the minimum TTL
encountered over the chain, potentially /reduced/ nondeterministically
to mitigate query bunching. I would therefore add language encouraging
resolvers synthesizing those records to engage in best-effort
determination of original TTLs by (e.g., by directly querying
authoritative servers and refreshing at 50% remaining), but *requiring*
them to decrement TTLs of records for which they are not authoritative.
I agree, the TTL language in this document is not ready and needs more
discussion.
And finally, back on the question of what ANAME sibling address records
actually represent, I think that NXDOMAIN and NODATA results should be
treated as errors for the purposes of ANAME sibling replacement. This
position can be justified on both practical and principled
grounds—replacing functional records with an empty RRSet is undesirable
for DNS users (or at least the sample of them that are Oracle+Dyn
customers), and could inappropriately stretch the maximum specified
ANAME sibling TTL (on the ANAME record itself) to the SOA MINIMUM value
(which is doubly bad, because it results in extended caching of the
/least/ valuable state). And adding insult to injury, resolvers in
general will not even have the SOA, and will need to perform more
lookups in order to issue a proper negative response of their own. Let's
please just eliminate all of that by specifying that ANAME processing
can never replace something with nothing.
+1
Best regards,
Matthijs
P.S. There is a typographical error in Appendix D; "RRGIG" should be
"RRSIG".
P.P.S. I think it has been discussed before, but this document should
also introduce and use a new "Address RTYPE" registry or subregistry,
rather than forever constraining ANAME exclusively to A and AAAA.
On 11/2/18 17:00, Richard Gibson wrote:
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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
