Richard Gibson <richard.j.gib...@oracle.com> wrote:
>
> First, I am troubled by the requirement that ANAME forces the zone into a
> dynamic zone.
I don't see how it is possible to implement ANAME without some form of
dymamic behaviour, either by UPDATEs on the primary, or on-demand
substitution on the secondaries, or some combination of the two.
> 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'm not sure I understand which TTLs you are worried about here. What are
"non-transfer responses"? There's certainly some rewording needed to make
it more clear, but the TTLs returned by resolvers that do sibling address
record substitution are decremented in the usual way, and resolvers make
no attempt to determine the original TTLs.
It isn't possible to require a resolver to query authoritative servers
directly.
> 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),
Maybe so, but that's what happens with CNAME records.
> 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).
That's a very good point, thank you.
> Let's please just eliminate all of that by specifying that ANAME
> processing can never replace something with nothing.
So when the target goes away, you would prefer to leave behind zombie
address records, and stretch their TTL indefinitely? If the zone admin is
given only a target hostname (just like a CNAME) they don't have any
alternative addresses to use when the target goes away. So the options are
to copy the target by deleting the addresses, or ignore the target and
leave the addresses to rot.
I'm inclined to say that fallback records should remain a non-standard
feature. The semantics can be that when you see the target go AWOL, delete
the ANAME and its siblings, and replace them with the fallback records
that were specified by some other means. You can apply the same logic to
CNAMEs too, if you want :-)
> P.S. There is a typographical error in Appendix D; "RRGIG" should be "RRSIG".
Thanks.
> 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.
The -01 draft specified a registry but I dropped that from -02 because I
was not sure if it should include X25, ISDN, NSAP, ATMA, the ILNP types,
the Nimrod types, etc. And now I realise that it needs a lot more thought
about what will happen to interoperability when the registry changes.
Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/
a fair, free and open society
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
