unbound resolver requests requirements for packet filter

[Simon Deziel]

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

On 2020-02-01 10:37 a.m., Gerben Wierda wrote:
> 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
>