<div dir="auto"><div><br><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Nov 27, 2025, 2:12 PM Peter Thomassen <<a href="mailto:peter@desec.io">peter@desec.io</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Of course. I think the issue here is that the reproducible switching between existence and non-existence, while there is a also caching, is very unlikely to be the result the zone maintainer had in mind.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">This makes sense alright.  It does seem like it may not result in the outcome the zone owner wants.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It's not "invalid", protocol-wise, but it's probably "wrong" anyway (in the bug sense).<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">That's the distinction I was looking to draw alright.  </div><div dir="auto"><br></div><div dir="auto">If this truly causes problems for a resolver, that seems a different problem as this exact behavior can happen (much less frequently) with any nameserver, due to changes made within a zone.   In the face of conflicting cacheable responses, I assume (I have not implemented a resolver myself) a resolver has to choose the more recent response on the assumption the zone may have changed.  </div><div dir="auto"><br></div><div dir="auto">Gavin</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>