[A better way with real logging to ask the same question again, which remains unanswered so far]
When my resolver goed hunting for a DNS answer (using root servers and all that) I encounter the following in my pf log:
00:04:57.722885 rule 4.murus.inbound.0/0(match): block in on en0: 204.61.216.50.53 > 192.168.2.66.6664: 5714*- 2/5/15 A 204.61.216.50, RRSIG (1472)
00:00:00.000029 rule 4.murus.inbound.0/0(match): block in on en0: 204.61.216.50 > 192.168.2.66: ip-proto-17
00:00:00.069544 rule 4.murus.inbound.0/0(match): block in on en0: 204.61.216.50.53 > 192.168.2.66.32401: 7062*- 2/5/17 A 192.82.134.30, RRSIG (1472)
00:00:00.000028 rule 4.murus.inbound.0/0(match): block in on en0: 204.61.216.50 > 192.168.2.66: ip-proto-17
00:00:00.001607 rule 4.murus.inbound.0/0(match): block in on en0: 204.61.216.50.53 > 192.168.2.66.20016: 45941*- 2/5/17 A 199.180.180.63, RRSIG (1472)
00:00:00.000026 rule 4.murus.inbound.0/0(match): block in on en0: 204.61.216.50 > 192.168.2.66: ip-proto-17
This is the default block rule that is triggered. I wonder if this is legit answer traffic (not spoofed or anything; I think not spoofed) based on request from my resolvers and clients and if so, what I must do not to block it in pf.
G
Those look like delayed/slow answers from the upstream NS. Maybe those
answers are coming back too later and pf already expired the UDP
connection state associated with the initial query? If so, try to bump
the timeout and see if that helps. The trace also shows those are big
answers so they get fragmented. Unless you changed the default, pf
should reassemble those without problem.
HTH,
Simon
I assume that is setting delay-close in unbind.conf? What is a reasonable number?
G
That setting is for unbound to wait for the answers longer before
closing the socket. What I recommended bumping are pf's timeouts [1].
1: https://man.openbsd.org/pf.conf#set_14
That setting is for unbound to wait for the answers longer before
closing the socket. What I recommended bumping are pf's timeouts [1].
I have no idea what reasonable values are. Double udp.{first,single,multiple}?
g
The default values are decent IMHO so I'd recommend investigating why
the upstream NS is so slow to reply.
If that's not possible/fixable, you can bump timeouts on your side,
doubling is a good starting point. It's possible that after changing
those firewall settings you will notice that Unbound's sockets are gone
by the time the reply shows up, because they timed out too. delay-close
may then be a useful kludge.
Your initial pflog dump showed 204.61.216.50. Anyway, for quad9, since
they are an open resolver, they depend on the responsiveness of the
upstream NSes that may be slow themselves and they don't have their
caches hot for this domain?
If you want to use forwarders, you could also try the other big players
like Cloudflare and Google.
Simon