unbound resolver requests requirements for packet filter

[Simon Deziel]

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