code: plan9front

Download patch

ref: 4bbb3b0b21edd81be37a0a6ad12c76a63d127bed
parent: 29e8ea26f2f9af2b9924e16dffd784bc5ae5685e
author: sl <sl@stanleylieber.com>
date: Fri Feb 19 21:29:55 EST 2021

/sys/src/cmd/ndb/dns.h:

---

To: 9front@9front.org
Date: Sun, 07 Feb 2021 14:56:39 +0100
From: kvik@a-b.xyz
Subject: Re: [9front] transient dns errors cause smtp failure
Reply-To: 9front@9front.org

I think I found a reason for DNS failing on known good domains.

/sys/src/cmd/ndb/dns.h:156,157
	/* tune; was 60*1000; keep it short */
	Maxreqtm=	8*1000,	/* max. ms to process a request */

So, 8 seconds is how much the resolver will bother with a request it
has been handed, before dropping it on the floor with little
explanation.

It seems quite possible that this is too short a timeout on a machine
during a spam queue run, which predictably stresses the compute and
network resources.

In turn, negative response caching might explain why a particular
unlucky domain would basically stop receiveing any mail for a while.

I'm dying to know if bumping this limit would clear up the queue of
such DNS errors.

---

[narrator: it did.]

--- a/sys/src/cmd/ndb/dns.h
+++ b/sys/src/cmd/ndb/dns.h
@@ -151,8 +151,8 @@
 	/* parallelism: tune; was 32; allow lots */
 	Maxactive=	250,
 
-	/* tune; was 60*1000; keep it short */
-	Maxreqtm=	8*1000,	/* max. ms to process a request */
+	/* tune; was 8*1000; that was too short */
+	Maxreqtm=	60*1000,	/* max. ms to process a request */
 
 	Notauthoritative = 0,
 	Authoritative,