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 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. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
