Re: [DNSOP] What should ANAME-aware servers do when target records are verifiably missing?

[Richard Gibson <[e-mail]>]

On 4/11/19 23:45, Matthew Pounsett wrote:
> On Thu, 11 Apr 2019 at 20:02, Richard Gibson
> <[e-mail]> 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).