unbound resolver requests requirements for packet filter

[Gerben Wierda]

I assume that is setting delay-close in unbind.conf? What is a reasonable number?

G

> On 28 Jan 2020, at 17:07, Simon Deziel via Unbound-users <unbound-users at lists.nlnetlabs.nl> wrote:
> 
> On 2020-01-28 10:46 a.m., Gerben Wierda via Unbound-users wrote:
>> [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.
> 
> 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