Follow-up.
tldr:
- The first argument is just an issue of wording.
- Authoritative servers or provisioning scripts that do ANAME processing
should honor the target address records TTL.
- Sibling address records should be used as a default if ANAME
processing fails.
On 11/9/18 6:54 PM, Richard Gibson wrote:
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.
It looks like there is a non-issue: The draft allows you to do ANAME
resolution however you want:
1. An anamifier script that updates a zone file before loading it into
the primary.
2. A tool that translates ANAME target lookups into Dynamic Update.
3. An authoritative server that implements ANAME resolution.
4. ...
The point is that we would like to standardize the ANAME resolution, and
what it means on the wire.
Richard makes a good point though that is: ANAME on zone transfers
should have no special logic.
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.
>>
non-transfer responses are responses for QTYPE != AXFR or IXFR.
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.
Richard and I discussed this. In order for me to understand the issue I
had to look this from the point of the resolver, that does ANAME resolution.
Suppose a resolver has an ANAME in its cache with a high TTL, say 3600,
but not the target A and AAAA records. It can do the lookup for the
targets. If successful, it will retrieve the A and/or AAAA records.
Let's say they have a short TTL, 60. They time out after a minute, but
the resolver can still use the ANAME record to do its own ANAME resolution.
In other words, if the resolver does ANAME resolution, the TTL of the
target address records are honored. Now what does that mean for the
authoritative side? What TTL should they use for the A and AAAA records
that have been expanded by ANAME? It would only be logical that the
authoritative side does the same.
This means that when adding A and AAAA records into the zone as a result
of ANAME processing, the TTL to use is at most that of the TTL of the
address target records. If you use a higher value, this will stretch the
TTL which is undesired.
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).
Perhaps a better word is "default". If a default is set it is used if
the ANAME processing resulted in a negative answer. If no default is
set, a negative answer is used as the final response. This allows for
both use cases.
I am in favor of specifying that sibling address records are used as a
default. If you don't want that functionality, then don't add sibling
address records. If you do want it: you have a way of doing so.
I am hesitant to accept an argument like "CNAME does it this way". We
are not trying to recreate CNAME logic here.
Best regards,
Matthijs
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
