On 11/9/18 05:03, Matthijs Mekking wrote:
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.
Agreed.
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.
If folks have some suggested text, please should send it along.
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
"ANAME processing can never replace something with nothing" should also
be mentioned in the document.
Mr Gibson also mentioned this:
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.
I think that should be discussed.
thanks Matthijs,
tim
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
