unbound resolver requests requirements for packet filter

[Gerben Wierda]

> On 3 Feb 2020, at 21:08, Simon Deziel <simon at sdeziel.info> wrote:
> 
> 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

> 
> 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
>> 
>