On 4/11/19 23:45, Matthew Pounsett wrote:
On Thu, 11 Apr 2019 at 20:02, Richard Gibson
<richard.j.gib...@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 am indeed claiming that will be a common configuration, and I have
access to data supporting that claim from existing use of Oracle+Dyn
ALIAS functionality. Also, please note that those "will" statements are
properly understood in the context of the examples they are describing.
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.
You're pretty much making my point... it is a bad path to design a
protocol around people who misconfigure their [ANAME-targeted] DNS at
the expense of people who configure [ANAMEs with static sibling records]
properly.
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.
That would take the ANAME-owning domain offline, rather than supporting
it with its static A and/or AAAA records. How exactly is that beneficial?
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)
It seems awfully insensitive to bake into a protocol an unnecessary
requirement of its users for all-or-nothing commitment to external
service providers.
or set their TTLs appropriately to not be subject to
the potential issue you identified above.
At the unnecessary expense of reducing cache lifetime (and therefore
undesired traffic) for /all/ negative responses, rather than just those
associated with the ANAME.
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.
The spec requires nothing like "preserving the target in the DNS", with
or without my proposed changes. The abuse path you mention is already
present with CNAME, and mitigable by owners of ANAME targets in exactly
the same way—increase negative caching TTL (and unlike the above, this
is a scenario where it /would/ make sense to increase it broadly rather
than for specific RRSets).
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
