[dns-operations] DNS .com/.net resolution problems in the Asia/Pacific region

Vladimír Čunát vladimir.cunat+ietf at nic.cz
Wed Jul 19 06:03:07 UTC 2023


On 18/07/2023 23.53, Viktor Dukhovni wrote:
> On Tue, Jul 18, 2023 at 10:25:01PM +0200, Ondřej Surý wrote:
>> It’s exactly like the serve-stale. The inception of the protocol
>> change is driven by this isolated incident. That’s not a proper
>> design, that’s slapping more bandaids on the camel.
> I don't even see a "protocol change" here.  A bogus (possibly forged)
> answer arrived from server A, perhaps server B should be tried.

I agree that at least one retry to a different IP seems nice before 
returning SERVFAIL, similarly to the case of reply not coming (in 
time).  I thought popular resolvers do something like that already.  But 
as mentioned, it's better to be careful about the overall amount of 
retries (which is not trivial to balance really).

As for papering over issues, ideally most problems would not be solved 
as response to "internet breaking" for common users, though I'd 
generally try to avoid adding workarounds.  Serious deployments should 
have monitoring to detect such problems, or possibly even approaches 
like this (though I'm not so sure): 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/

--Vladimir | knot-resolver.cz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20230719/8d802511/attachment.html>


More information about the dns-operations mailing list