What the heck is this??? "To: x_bind-user...@nospam.pz.podzone.net"
On Sun, Mar 20, 2011 at 10:13:29AM +, 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 Aaaa.aaa.aaa.aaa ;; ns0 (hidden)
> ns1 IN Abbb.bbb.bbb.bbb ;; ns1
> ns2 IN Accc.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/bi