target

On Tue, Apr 2, 2019 at 6:03 PM Tony Finch <dot@dotat.at> wrote:

WRT loop detection, it is much easier if the additional section in the
response from the resolver contains the chain(s). The draft doesn't
specify that at the moment; maybe it should.

Why is it easier? I would think some people may even want to hide the
chain, even though it doesn't exactly hide the provider behind the
final IP.
On Wed, 10 Apr 2019 at 16:43, Richard Gibson
<richard.j.gibson@oracle.com> wrote:

The first problem is for the owner of the ANAME-containing zone, for whom the upstream misconfiguration will result in downtime and be extended by caching to the MINIMUM value from their SOA, which in many cases will be one to three orders of magnitude greater than the TTL of the ANAME itself.

I think I'm missing something here.  If, for example, the TTL of the
ANAME is 1 hour, what mechanism results in caching holding onto a
negative answer for a broken target name for a minimum of 10 hours,
and to 40 days?
example.com.  3600  IN    SOA  ns.example.net. hostmaster.example.net. 1 (
                                  7200   ; REFRESH
                                  3600   ; RETRY
                                 86400   ; EXPIRE
                                  3600  ); MINIMUM
example.com.    60  IN  ANAME  example.invalid.
example.com.    60  IN      A  192.0.2.1

example.com. A
Both of these problems can be addressed by allowing/recommending/requiring ANAME-aware servers to preserve ANAME siblings when resolution of ANAME targets results in NXDOMAIN or NODATA responses, rather than replacing them with an empty RRSet... which, to be honest, seems to be always-undesirable behavior anyway—if anyone can think of a scenario where it would be beneficial to dynamically remove ANAME siblings, please share it.

I feel like this is creating an even bigger potential problem.  What
happens when the owner of the ANAME target legitimately wants that
name to go away, but some other zone owner is leaving an ANAME in
place pointing to that now-nonexistent name?  Continuing to serve the
sibling records indefinitely seems like serve-stale gone horribly
wrong.

On Thu, 11 Apr 2019 at 20:02, Richard Gibson
<richard.j.gibson@oracle.com> wrote:

The first problem is for the owner of the ANAME-containing zone, for whom the upstream misconfiguration will result in downtime and be extended by caching to the MINIMUM value from their SOA, which in many cases will be one to three orders of magnitude greater than the TTL of the ANAME itself.

[snip]

But this suffers from both of the problems I have been complaining about—the resolver does not necessarily have the zone SOA, possibility necessitating an inline lookup, and per RFC 2308 the negative response will be cached according to values from the SOA that are unrelated to and far exceed the TTL of the ANAME.

Ah, I see the confusion.  You're using definitive statements such as
"will" when what you actually mean is "may."   There's no specific
mechanism that causes the client to cache the negative response "for
one to three orders of magnitude greater than the TTL of the ANAME."
And, the TTL of the SOA doesn't necessarily "far exceed" the TTL of
the ANAME.  You're just presupposing that will be a common
configuration?
I think we're still talking about misconfigurations here, and
designing a protocol around people who misconfigure their DNS at the
expense of people who configure it properly seems like a bad path to
take.
Both of these problems can be addressed by allowing/recommending/requiring ANAME-aware servers to preserve ANAME siblings when resolution of ANAME targets results in NXDOMAIN or NODATA responses, rather than replacing them with an empty RRSet... which, to be honest, seems to be always-undesirable behavior anyway—if anyone can think of a scenario where it would be beneficial to dynamically remove ANAME siblings, please share it.

Yes, I can think of a case where it would be beneficial to remove
ANAME siblings: when the target of the ANAME is removed from the DNS.
In such a configuration, the owner of the ANAME will be able to see that clients are using its static sibling records rather than its target (and therefore that they are getting no benefit from the ANAME), and can react accordingly. If your concern is excess queries for the ANAME target, then this seems no different from e.g. CNAME—the owner of the target can issue long-lived negative responses while performing whatever other exploration and/or mitigation they deem fit.

If the target of the ANAME disappears, the owner of the ANAME will
similarly be able to recognize the problem and deal with it.  If the
administrator of the name owning the ANAME is concerned about downtime
due to misconfigurations by the target, then that administrator can
either select a different target (presumably by selecting a different
service provider)
or set their TTLs appropriately to not be subject to
the potential issue you identified above.
However, if the spec requires preserving the target in the DNS despite
the administrator of the target zone removing it, then that is a path
for abuse by the administrator of the zone containing the ANAME, and
the owner of the target will have no recourse.  This is what I meant
by my reference to serve-stale.