What the heck is this??? "To: x_bind-user...@nospam.pz.podzone.net"
On Sun, Mar 20, 2011 at 10:13:29AM +0000, x_bind-user...@nospam.pz.podzone.net wrote: > Hi, > > I'm trying to figure out how to configure my nameservers so that the > master can reside on an internal LAN *only* address. > > I already have it configured such that the master is (almost) hidden > while residing on a public IP. So I should present that first: > > ns0.mydomain.net - Gateway/firewall, public IP (ADSL) + internal LAN. > > ns1.mydomain.net - Public nameserver. > > ns2.mydomain.net - Public nameserver. > > Host ns0 serves DNS for the internal LAN, as well as acting master for > ns1/ns2. > > I have glue records at the registry for ns1 & ns2. The zone file > configured on ns0 looks something like this: > > @ IN SOA ns0 hostmaster ( > ... > ) > @ IN NS ns1 > @ IN NS ns2 > ns0 IN A aaa.aaa.aaa.aaa ;; ns0 (hidden) > ns1 IN A bbb.bbb.bbb.bbb ;; ns1 > ns2 IN A ccc.ccc.ccc.ccc ;; ns2 > ... > > On the master (ns0) named.conf is as follows: > > options { > listen-on { any; }; > allow-recursion { 127.0.0.1; lan; }; > allow-query { 127.0.0.1; lan; }; > allow-transfer { 127.0.0.1; ns1; ns2; }; > ... > }; > zone "mydomain.net" { > type master; > file "/etc/bind/db.mydomain.net"; > allow-query { any; }; > }; > > On the slaves (ns1/ns2) named.conf is as follows: > > zone "mydomain.net" { > type slave; > file "/var/cache/bind/db.mydomain.net"; > masters { aaa.aaa.aaa.aaa; }; > allow-query { any; }; > }; > > As you can see, ns0 isn't quite totally hidden - it shows up in the > SOA record. I tried using ns1 in the SOA but then ns1/ns2 failed to > update correctly when the zone file was updated on ns0. I never > figured that out and don't see it as a big deal from a privacy POV but > I accept that probably it's not optimally configured. > > Now on to my question. ;-) > > Ideally I would like to manage the zones on a main internal server, > which would serve the internal LAN (including an internal-only zone) > as well as somehow keeping the public slaves up to date. Part reason > for this is a policy to shift all internal services onto the LAN and > away from the DMZ. > > This is the plan: > > main.mydomain.net - Internal LAN only. > > ns0.mydomain.net - Gateway/firewall, public IP (ADSL) + internal LAN. > > ns1.mydomain.net - Public nameserver. > > ns2.mydomain.net - Public nameserver. > > main acts as master for ns0 slave. (and serves dns for the lan) > > ns0 acts as master for ns1/ns2 slaves. (and serves dns for the dmz) > > This is the problem, I cannot see how to configure the SOA and conf > files such that zone updates will be notified main -> ns0 -> ns1/ns2. > > Any advice or pointers on how to acheive that would be greatly > appreciated. Thanks in advance. - Charlie. Have a separate internal subdomain. Put ns0 and main in that internal subdomain, where they're not visible to the outside. In each domain, list only the name servers that you want to be used by the widest network - e.g., the public Internet, or your company, or your group. I mention below what to do for the smaller groups. Take ns0 and main out of the SOA record. I know that it's not strictly per RFC, but where I don't have dynamic DNS (e.g. ALL external domains) I use a non-existent "no-ddns.my.domain." in the SOA record, to say "none of your business". If the name servers to be NOTIFY'd are not explicitly named in the domain - and even if they are - put them in an also-notify {}; clause in the domain or view. Remember that if it's in the domain then any servers listed in the view are not seen; and if its in the view, then any servers listed in options {}; are not seen. If you're in an internal group, say, the internal LAN where ns0 is visible and ns1 and ns2 are not directly reachable, then you must make then findable by your recursively resolving name servers. Ideally, you will have two or more name servers whose entire job is resolving, that are not authoritative name servers for any domain. On those name servers, you forward queries for the domain under discussion to the unlisted internal name server that nonetheless IS authoritative for the domain. In less ideal circumstances, the internal recursively resolving name server is in fact the internal authoritative name server, and no forwarding needs to be done. I believe that is what you have described. Apologies if my brain at this late hour has not hit everything I had intended to. -- /*********************************************************************\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*********************************************************************/ _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users