Re: Hyperlocal recursive servers questions

2024-12-27 Thread Grant Taylor via bind-users

On 12/27/24 15:40, Roberto Braga wrote:

For this, I must use 2 servers:


I agree that you should use two servers.  But I also believe you could 
do what you're doing with one server, one OS image, and maybe even one 
instance of BIND.


The first, like Recursive DNS itself, is what clients will use to 
configure DNS.


The second, as a copy of root, must be consulted to the first if it does 
not have a cache.


Forming a hyperlocal recursive DNS composed of 1 computer with the 
address that clients will use as DNS and 1 computer with the root copy 
(slave of the root servers).


Why not have a copy of the root zone on the same recursive server that 
clients use?


You can easily include secondary copies of the root zone in the 
recursive DNS server itself.


There may be some room for discussion on if this should be done or not. 
But I've not had any problems including root on my personal recursive 
servers for years.


If you do want to have some separation, you can use separate views in 
the same daemon.


If you want more separation, you can have separate daemons on the same 
system.


The scheme below is working, but I would like someone more experienced 
who can review and identify if I'm doing it correctly, if there are 
flaws or how I can improve this structure... Thank you.


The biggest thing that I see is that you have two cascaded single points 
of failure.  If either of them goes offline, say for patching, your 
entire user base is without recursive DNS service.


I would suggest configuring both servers identically; zones, same mirror 
copy of root, same named.conf values.


I would also encourage you to explore VRRP (likely via keepalived) to 
have the two IPs that clients are configured to use be able to float 
back and forth between the two identical systems.  Each IP should have 
an affinity to one system but also be able to be hosted by the other system.


Yes, clients should fall back to the secondary DNS server if the primary 
is unreachable.  However I've seen some really bad failure modes with 
this.  And all of these failure modes can be avoided if the surviving / 
online server simply adds the down / offline server's service (virtual) 
IP (VIP) to it.  That way clients still see both IPs as online and usable.


To use the VRRP technique properly you will need a management IP for 
each server and a service / virtual IP (VIP) for each server, so a total 
of four IPs.


With this technique, either server can be offline for maintenance and 
clients will have full functionality using either IP.


As Greg suggested, explore "mirror" zones instead of a secondary zone 
transfer of the root zone.


I would also encourage you to read about and consider a local instance 
of the AS112 Project wherein you also have mirror copies of some 
infrastructure zones to help keep DNS internet background radiation 
contained in your environment.


Link - AS112 Project
 - https://www.as112.net/

Note, just because you have a local copy of the root zone doesn't mean 
that you will be able to resolve names without an Internet connection. 
The root zone is just a very small subset of the names on the internet.


Some additional comments on your config:

 - Why are you disabling query name minimization?  That has privacy 
implications?  Is that an optimization for your configuration?


 - You may want allow-query-cache { ... };

 - You might want to define an ACL and place your IP networks therein. 
That way you can reference that ACL name in your allow-* statements. 
This helps ensure that you don't miss and update to the duplicated data 
in the future.


 - Check out empty-zones-enable, empty-server, and empty-contact.

 - Checkout server-id, version, and minimal-responses.

 - Seeing as how you're not showing any authoritative zones, it might 
not matter.  But it's really nice to have rndc capability to have BIND / 
named alter / reload some things on the fly.




--
Grant. . . .
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Hyperlocal recursive servers questions

2024-12-27 Thread Greg Choules via bind-users
Hi Roberto.
Instead of defining "." as type "static-stub" you should define it as type
"mirror". This shows you how:
https://bind9.readthedocs.io/en/v9.18.32/reference.html#namedconf-statement-type%20mirror

Cheers, Greg

On Fri, 27 Dec 2024 at 21:41, Roberto Braga 
wrote:

> Hello, if you could help me review this situation, I would appreciate it.
>
> It is necessary to configure a server that all clients in the blocks below
> must use as a recursive DNS.
>
> For this, I must use 2 servers:
>
> The first, like Recursive DNS itself, is what clients will use to
> configure DNS.
>
> The second, as a copy of root, must be consulted to the first if it does
> not have a cache.
>
> Forming a hyperlocal recursive DNS composed of 1 computer with the address
> that clients will use as DNS and 1 computer with the root copy (slave of
> the root servers).
>
> The blocks are:
> 201.31.238.0/28 (passed on to customers using CGNAT);
> 2804:a8:c4ad::/56 (passed to clients directly, 1 /64 block for each
> client);
>
> The client must use as DNS server: 201.31.238.9 and 2804:a8:c4ad:d1::9
>
> The scheme below is working, but I would like someone more experienced who
> can review and identify if I'm doing it correctly, if there are flaws or
> how I can improve this structure... Thank you.
>
> *First server configuration (Recursive DNS):*
>
> *file /etc/bind/named.conf.options:*
> options {
> directory "/var/cache/bind";
> dnssec-validation auto;
> auth-nxdomain no;
> qname-minimization disabled;
> listen-on { 201.31.238.9; 127.0.0.1; };
> listen-on-v6 { 2804:a8:c4ad:d1::9; ::1; fe80::a00:27ff:fe7a:d1a7;
> };
> recursion yes;
>
> allow-query {
> 127.0.0.0/8;
> 201.31.238.0/28;
> ::1;
> 2804:a8:c4ad::/56;
> };
>
> allow-recursion {
> 127.0.0.0/8;
> 201.31.238.0/28;
> ::1;
> 2804:a8:c4ad::/56;
> };
> };
>
> *file /etc/bind/named.conf.default-zones:*
> // prime the server with knowledge of the root servers
> //zone "." {
> //  type hint;
> //  file "/usr/share/dns/root.hints";
> //};
>
> zone "." {
> type static-stub;
> server-addresses { 201.31.238.7; 2804:a8:c4ad:d1::7; };
> };
>
>
> // be authoritative for the localhost forward and reverse zones, and for
> // broadcast zones as per RFC 1912
>
> zone "localhost" {
> type master;
> file "/etc/bind/db.local";
> };
>
> zone "127.in-addr.arpa" {
> type master;
> file "/etc/bind/db.127";
> };
>
> zone "0.in-addr.arpa" {
> type master;
> file "/etc/bind/db.0";
> };
>
> zone "255.in-addr.arpa" {
> type master;
> file "/etc/bind/db.255";
> };
>
>
> *Configuration of the second server (DNS acting as a copy of the root):*
>
>
> *file /etc/bind/named.conf.options:*
> options {
>allow-query {
> 127.0.0.0/8;
> 201.31.238.0/28;
> ::1;
> 2804:a8:c4ad::/56;
> };
>
> allow-recursion {
> 127.0.0.0/8;
> 201.31.238.0/28;
> ::1;
> 2804:a8:c4ad::/56;
> };
> };
>
>
> *file /etc/bind/named.conf.default-zones:*
>
> // prime the server with knowledge of the root servers
>
> //zone "." {
> //  type hint;
> //  file "/usr/share/dns/root.hints";
> //};
>
>
> zone "." {
> type slave;
> file "rootzone.db";
> notify no;
> masters {
> 199.9.14.201; # b.root-servers.net
> 192.33.4.12; # c.root-servers.net
> 199.7.91.13; # d.root-servers.net
> 192.5.5.241; # f.root-servers.net
> 192.112.36.4; # g.root-servers.net
> 193.0.14.129; # k.root-servers.net
> 192.0.47.132; # xfr.cjr.dns.icann.org
> 192.0.32.132; # xfr.lax.dns.icann.org
> 2001:500:200::b; # b.root-servers.net
> 2001:500:2::c; # c.root-servers.net
> 2001:500:2d::d; # d.root-servers.net
> 2001:500:2f::f; # f.root-servers.net
> 2001:500:12::d0d; # g.root-servers.net
> 2001:7fd::1; # k.root-servers.net
> 2620:0:2830:202::132; # xfr.cjr.dns.icann.org
> 2620:0:2d0:202::132; # xfr.lax.dns.icann.org
> };
> };
>
>
>
> // be authoritative for the localhost forward and reverse zones, and for
> // broadcast zones as per RFC 1912
>
> zone "localhost" {
> type master;
> file "/etc/bind/db.local";
> };
>
> zone "127.in-addr.arpa" {
> type master;
> file "/etc/bind/db.127";
> };
>
> zone "0.in-addr.arpa" {
> type master;
> file "/etc/bind/db.0";
> };
>
> zone "255.in-addr.arpa" {
> type master;
> file "/etc/bind/db.255";
> };
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this l