PF PF rules for a DNS server

Hello FreeBSD fellows. I have an authoritative nameserver (PowerDNS) server running as: ns1.mydomain.com, hosting the DNS records of my domains, and communicating with my secondary/slave nameserver, for DNS record changes&updates.

I've implemented PF, however I'm not really sure if I managed to do it completely correct, so to be sure if these are correctly implemented rules for a DNS server, before I move it completely public, I'd like to ask your opinions on my rules.

Any feedback on these all?

Bash:
ext_if="re0"

int_services = "{22, www, https}"
out_services = "{ntp, www, https}"

icmp_types = "{ echoreq, unreach, timex }"
icmp6_types = "{ echoreq, unreach, timex, toobig, paramprob, neighbrsol }"

table <whitelist> persist file "/var/pf/whitelist.txt"

set limit { states 200000, frags 200000, src-nodes 100000, table-entries 350000 }
set loginterface $ext_if
set skip on lo
scrub in on $ext_if all fragment reassemble
antispoof quick for $ext_if

block in all
block in quick from no-route to any
block in quick from urpf-failed to any
block proto udp

pass quick inet proto icmp icmp-type $icmp_types
pass quick proto ipv6-icmp from any to any

# Whitelist
pass quick from <whitelist> to any flags any

pass in quick on $ext_if proto tcp to any port $int_services flags S/SA synproxy state
pass out quick on $ext_if proto { tcp udp } to any port $out_services

# DNS Inbound/Outbound
pass in quick on $ext_if proto { tcp, udp } from any to ($ext_if) port 53
pass out quick on $ext_if proto { tcp, udp } to any port 53

#Tracert
pass out quick on $ext_if inet proto udp from any to any port 33433 >< 33626

Thank you!
 
Code:
pass in quick on $ext_if proto { tcp, udp } from any to ($ext_if) port 53
pass out quick on $ext_if proto { tcp, udp } to any port 53
This seems fine. The outgoing rule could probably be further limited:
Code:
pass out quick on $ext_if proto { tcp udp } from ($ext_if) to any port 53
And outgoing might only go to your secondary/slave, unless it's also used as a recursive resolver for other hosts. If you have enabled recursion make sure you only accept recursive queries from your servers, don't allow anyone on the internet to send a recursive query to your DNS server (it can be abused to 'amplify' a D/DoS)

 
Thank you SirDice for your feedback; when I block outgoing 53; these happens (I use unbound running locally as resolv);
ping anywebsite.com fails
pkg upgrade fails
basically any hostname resolution fails.

Would you suggest having (first, block all);
block in all
block in quick from no-route to any
block in quick from urpf-failed to any


or (later block all);
block in quick from no-route to any
block in quick from urpf-failed to any
block in all
 
(I use unbound running locally as resolv)
Right, in that case you need to allow the outgoing DNS queries. But make sure your PowerDNS is configured to deny recursive queries and only answer authoritative ones. Because the outgoing DNS allow rule will also allow the responses to recursive queries from the Internet.
 
SirDice after your replies, I've investigated about denying recursive queries for PowerDNS, and read PowerDNS documentation states; "Recursion was removed from the Authoritative Server in version 4.1.0." (https://doc.powerdns.com/authoritative/guides/recursion.html), so the auth server doesn't know how to answer recursive queries.

Finally;
Do you think block in quick from no-route to any and block in quick from urpf-failed to any is really needed on a rented, remote, private dedicated server (by Hetzner) even in case of an-only-DNS server, and should "block in all" come before them, or better after?

Regards.
 
Do you think block in quick from no-route to any and block in quick from urpf-failed to any is really needed on a rented, remote, private dedicated server (by Hetzner) even in case of an-only-DNS server, and should "block in all" come before them, or better after?
block in all is really the only thing needed. Then only selectively allow certain incoming traffic. Anything that isn't strictly allowed would get blocked.

no-route doesn't make much sense, you have a default gateway, so everything is routable. urpf-failed is also not sensible, you only have one network interface.
 
Back
Top