On 28.06.12 08:21, Mark Andrews wrote:
I would set up 10.in-addr.arpa which is slaved on all internal
nameservers and delegate the /24's as required. 10.in-addr.arpa
won't change much and will be cheaper in the long run than using a
stub zone.
Just to add that you may need delegation NS record
On 26.06.12 11:07, Brad Bendily wrote:
Personally, I'd rather edit 1 file, than hundreds of different files.
and when you make a mistake in one file, you will f*ck up everything
instead of one /24 subnet
I can add the DNS entry and IP address and reload the service. No trying to
figure out
I would set up 10.in-addr.arpa which is slaved on all internal
nameservers and delegate the /24's as required. 10.in-addr.arpa
won't change much and will be cheaper in the long run than using a
stub zone.
In message <4feb2a8a.4050...@imperial.ac.uk>, Phil Mayers writes:
> On 27/06/12 15:30, nex6
On 27/06/12 15:30, nex6 wrote:
so, you *should* have a larger 10.x.x.x zone? *and* smaller
10.x.x.0/24 zones? so i am assuming the workflow would be in this
case, records go in the smaller zones, and the larger zone is the
catchall to prevent leakage?
It is good practice, and polite, to preven
* Phil Mayers [2012-06-27 14:29:38 +0100]:
> On 26/06/12 17:25, nex6 wrote:
> >* Phil Mayers [2012-06-26 16:54:55 +0100]:
> >
> >
> >I am not going to be editing files by hand, we actually have a tool. I am
> >more
> >concerned about best practices, and how to fix the mess.
> >
> >eg, say w
On 26/06/12 17:25, nex6 wrote:
* Phil Mayers [2012-06-26 16:54:55 +0100]:
I am not going to be editing files by hand, we actually have a tool. I am more
concerned about best practices, and how to fix the mess.
eg, say we have about 500 vlans (/24s) and say only 350 have reverse zones.
from wh
* Phil Mayers [2012-06-26 16:54:55 +0100]:
I am not going to be editing files by hand, we actually have a tool. I am more
concerned about best practices, and how to fix the mess.
eg, say we have about 500 vlans (/24s) and say only 350 have reverse zones.
from what I understand its best to just
ssage-
From: nex6 [mailto:b...@borg1911.com]
Sent: Tuesday, June 26, 2012 10:43 AM
To: Brad Bendily
Cc: bind-users@lists.isc.org
Subject: Re: Reverse zones best practices
* Brad Bendily [2012-06-25 16:35:28 -0500]:
wouldn't it be more confusing, in a big IP space with servers, deskto
On 26/06/12 16:42, nex6 wrote:
* Brad Bendily [2012-06-25 16:35:28 -0500]:
wouldn't it be more confusing, in a big IP space with servers,
desktops etc all mashed together into one zone?
If you have enough hosts for this to be confusing, you have enough hosts
to store the data in some master
* Brad Bendily [2012-06-25 16:35:28 -0500]:
wouldn't it be more confusing, in a big IP space with servers, desktops etc all
mashed together into one zone?
> I don't know about best practice in this case, but I decided to put our
> reverse entries into one "super netting" file as you call i
* David Dowdle [2012-06-25 14:20:43 -0700]:
so, create zones based on how networking creates vlans eg: /24s we dont have any
/8 or /16 vlan networks yet
> I strongly recommend splitting on /8 /16 and /24 boundries. With
> the number of zones you are talking about, doing anything else wi
I don't know about best practice in this case, but I decided to put our reverse
entries into one "super netting" file as you call it.
We had the same problem that a lot of reverse entries were missing, so I wrote
a script to parse the forward file and create the reverse. Then I incorporated
that
I strongly recommend splitting on /8 /16 and /24 boundries. With the
number of zones you are talking about, doing anything else will get very
confusing very quickly.
If a netblock is larger than a /24, put at the top and bottom of each /24
a comment lile explaining what size it is
For examp
13 matches
Mail list logo
