Resolving RFC1918 addresses on recursive, caching servers

[Greg Rivers]

On Friday, November 10, 2017 10:27:53 Mark Andrews wrote:
> Just slave the zones on the recursive servers.   When you forward that server does
> all the recursion and returns the answer to you.  If you do use forwarding for RFC 1918
> zones use “forward only;” as you really don’t want talk to the AS112 servers.
> 
> RFC 1918 reverse support really is easy.  You slave the zones at the top of the
> part of the name space you are using (10.in-addr.arpa, 16.172.in-addr.arpa …
> 31.172.in-addr.arpa, 168.192.in-addr.arpa) and follow delegations from them to
> deeper zones.
>
Stub zones work well for that too, e.g.:

// Referrals to our RFC 1918 masters.
zone "10.in-addr.arpa" { type stub; file "/etc/namedb/slave/10.db"; masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "16.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.16.db"; masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "17.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.17.db"; masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "18.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.18.db"; masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "19.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.19.db"; masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "20.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.20.db"; masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "21.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.21.db"; masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "22.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.22.db"; masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "23.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.23.db"; masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "24.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.24.db"; masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "25.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.25.db"; masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "26.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.26.db"; masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "27.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.27.db"; masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "28.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.28.db"; masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "29.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.29.db"; masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "30.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.30.db"; masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "31.172.in-addr.arpa" { type stub; file "/etc/namedb/slave/172.31.db"; masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };
zone "168.192.in-addr.arpa" { type stub; file "/etc/namedb/slave/192.168.db"; masters { xxx.xxx.xxx.xxx; yyy.yyy.yyy.yyy; }; };

With stub zones, you only slave the NS records, not the whole zones.

> People over use forward zones.
>
I've found that to be the case as well.

-- 
Greg Rivers