Simon Lyall wrote:

Does anyone know the current correct way to blackhole queries for rfc1918 reverses using Bind9?

Do you really want to black-hole them or answer them? Personally, I'd be inclined to just create dummy zones: zone "168.192.in-addr.arpa" { type master; file "rfc1918.zone"; }; zone "16.172.in-addr.arpa" { type master; file "rfc1918.zone"; }; zone "17.172.in-addr.arpa" { type master; file "rfc1918.zone"; }; zone "18.172.in-addr.arpa" { type master; file "rfc1918.zone"; }; zone "19.172.in-addr.arpa" { type master; file "rfc1918.zone"; }; zone "20.172.in-addr.arpa" { type master; file "rfc1918.zone"; }; zone "21.172.in-addr.arpa" { type master; file "rfc1918.zone"; }; zone "22.172.in-addr.arpa" { type master; file "rfc1918.zone"; }; zone "23.172.in-addr.arpa" { type master; file "rfc1918.zone"; }; zone "24.172.in-addr.arpa" { type master; file "rfc1918.zone"; }; zone "25.172.in-addr.arpa" { type master; file "rfc1918.zone"; }; zone "26.172.in-addr.arpa" { type master; file "rfc1918.zone"; }; zone "27.172.in-addr.arpa" { type master; file "rfc1918.zone"; }; zone "28.172.in-addr.arpa" { type master; file "rfc1918.zone"; }; zone "29.172.in-addr.arpa" { type master; file "rfc1918.zone"; }; zone "30.172.in-addr.arpa" { type master; file "rfc1918.zone"; }; zone "31.172.in-addr.arpa" { type master; file "rfc1918.zone"; }; zone "10.in-addr.arpa" { type master; file "rfc1918.zone"; }; rfc1918.zone should be basically empty: $TTL 86400 @ SOA ns . 1 86400 86400 3000000 86400 NS ns ns A 127.0.0.1 (The NS & A records are basically to stop BIND complaining.) That config should give NXDOMAIN answers for any RFC 1918 reverse map entries. If you really want to black-hole the queries, you could use forward zones pointing to the discard port. In your named.conf: zone "168.192.in-addr.arpa" { type forward; forward-only; forwarders { 127.0.01:9; }; }; and so-on for all the other RFC 1928 reverse map zones. Then make sure your discard (UDP port 9) service properly drops packets on the floor -- either enable the discard service in inetd, or use packet filters to drop the packets on the floor before the OS attempts to deliver them to a service. Note that doing this does mean that context information is held by the name server for every query, in expectation of an answer, i.e. it's still doing a full forward of the query. For this reason, I wouldn't recommend this if your getting seriously heavy loads of RFC 1918 PTR queries. The other advantage of using dummy zones is that the queries actually get answered, which means they shouldn't be retried. IMAO, it's the best way to deal with the problem. -- don