Responses inline.
On 11/9/18 11:39, Tony Finch wrote:
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.
I am advocating for the special behavior of ANAME be limited to
processing of non-transfer queries (i.e., explicitly excluding AXFR and
IXFR). For example: ANAME-aware authoritative servers MAY attempt
sibling replacement in response to address or ANY queries and SHOULD add
records to the additional section in response to address or ANAME
queries; ANAME-aware resolvers SHOULD do both. But all authoritative
servers should agree that the sibling records—including their original
TTLs—are a non-special part of zone contents for the purposes of transfers.
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.
I hope the above clarifies... my TTL concerns relate not to resolvers,
but to authoritative servers. In particular, I take issue with the
"/Sibling address records are committed to the zone/" and "/Sibling
address records are served from authoritative servers with a fixed TTL/"
text, which stretches the TTL of one or more RRSets along the target
name's resolution chain.
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.
CNAME does not allow for siblings, and therefore its processing is
incapable of replacing functional records with an empty RRSet. Further,
clients are required to understand CNAME and can therefore always
identify at which domain name an issue lies (and in particular that it
is not the queried name).
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.
When the target goes away, there is no longer anything to replace the
sibling records, which are not zombies but rather part of the zone
contents and always issued by authoritative servers with their original
TTL (just like every other record, including the ANAME itself). Only if
there are no sibling records could an authoritative server issue a
NODATA response, and if a /resolver/ cannot successfully resolve an
ANAME target to non-expired records, then it should re-resolve the
requested RRSet anyway—it will get from upstream either refreshed
fallbacks or a NODATA, and in either case then has a response for its
own client.
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 :-)
A system that complicated would /have/ to be non-standard, but I think
you're reading too much into my use of the term "fallback". It's not a
specification of special treatment, but rather the absence of such that
gives ANAME sibling records that status... they're what to serve when
nothing replaces them (i.e., the current semantics of every record in
every zone that is not itself occluded by a delegation).
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
