Re: Master ns on internal lan

2011-03-22 Thread Joseph S D Yao
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/bind-users


Master ns on internal lan

2011-03-20 Thread x_bind-users_x
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.

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


Re: Master ns on internal lan

2011-03-20 Thread Torinthiel
On 03/20/11 11:13, 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:
 
[cut]
 
 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.

And solving your main problem will probably solve this as well.


 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.

try putting this in config:
on main:
zone mydomain.net {
type master;
...
allow-transfer { ns0.mydomain.net; };
also-notify { ns0.mydomain.net; };
}

on ns0:
zone mydomain.net {
type slave;
...
allow-notify { main.mydomain.net; };
allow-transfer { ns1.mydomain.net; ns2.mydomain.net; };
also-notify { ns1.mydomain.net; ns2.mydomain.net; }
}


on ns1/2:
zone mydomain.net {
type slave;
...
allow-notify { ns0.mydomain.net; };
}

The allow-notify makes slave servers to accept notify messages from
someone that's not listed as master in SOA. Putting this on ns1/2 will
probably solve your first issue, with ns0 not completely hidden.

also-notify makes bind send notify messages to those servers. Probably
also-notify on ns0 is not needed, as ns1/2 are listed in zone as NS. But
on main it will be neeed, as ns0 is not listed as NS for your domain.

If you want to put ns1 at SOA as master, then you'd also need notify no
at ns1 (so it won't send notifies at all), and notify-to-soa yes at ns0
(so it will send notify to ns1).

Oh, and I really hope ns0.mydomain.net has static IP address even though
it has ADSL. If no, you can either use ip/length or (even better) use
TSIG keys as authentication.

Regards,
 Torinthiel



signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users