In message , hugo hugoo writes:
> Dear all=2C
> =20
> I have tried to configure a zone containing a range of IPV6 PTR records.
> My target was to see how it is possible to configure such a zone to
> always return the same answer for all the IPV6 IP=92s in the range.
> And if possible to return sp
This really isn't that hard. Just use tsig and transfer the zone
between views on the slave machine. Just ensure that you transfer
from the view that is getting the notify messages from the master.
You will want BIND 9.9.x or later.
Mark
key view1 {
};
key view16 {
Dear all,
I have tried to configure a zone containing a range of IPV6 PTR records.
My target was to see how it is possible to configure such a zone to
always return the same answer for all the IPV6 IP’s in the range.
And if possible to return specifi names for specific IP’s.
Example of a IPV6
> However - I guess its a little less efficient than the new default 'raw'
> mode, especially for large zones.
More than a little. Raw zonefiles load in about half the time it
takes to parse the equivalent text. The delay only becomes really
noticeable when you have big zones, or a lot of small
This past weekend I upgraded 22 multiprocessor Enterprise Redhat Linux
servers (ver 5.4, and 5.5) from BIND 9.6-ESV-R5-P1 to 9.6-ESV-R7-P1. Six
of the servers began to BIND exit after having run for 8 to 12 minutes.
All 22 server configured with: ./configure --prefix=/usr --sysconfdir=/etc
--lo
Unless I misunderstand
what you're asking it's simple to do.
Something like this:
view "internal"
{
match-clients { 192.168.1.0/24; };
include "stdzones/stdzones.conf";
include "conf/internal-zones.conf";
include "conf/authoritativezones.conf";
include "conf/slavezones.c
On 12/06/12 15:31, Barry Margolin wrote:
In article,
Phil Mayers wrote:
Have you considered a single view containing all the common zones, then
a view per "different" zone that forwards to 127.0.0.1? Provided you
arrange your "match-clients" correctly this should work.
Forwarding only work
In article ,
Phil Mayers wrote:
> Have you considered a single view containing all the common zones, then
> a view per "different" zone that forwards to 127.0.0.1? Provided you
> arrange your "match-clients" correctly this should work.
Forwarding only works for recursive queries. I think he'
> However - I guess its a little less efficient than the new default 'raw'
> mode, especially for large zones. Consider a change of approach and if its
> just an automated check - try 'dig'? I'm finding with in-line signing that
> zones are often spread about in journal files - which makes optio
Dear!
what's going on?
I'd like to share a good online shopping experience with you.
www.li-xiao4。info is a top online store.
It sells brand new phones, TV ,camera and so on. the quality is very good. I
can't believe my eyes when I receive the apple phone,
it is really orig
On 06/12/2012 01:03 AM, Max Bowsher wrote:
That won't help me for slave zones:
* the zones get needlessly re-transferred once for each view
If you actually want a copy of each zone in each view, you can't avoid this.
* the files on disk will be repeatedly overwritten as bind tries to save
t
On Mon, 2012-06-11 at 15:51 -0700, Walter Smith wrote:
> Folks,
>
>
> What tools/commands I can run to get plain ascii/text data out of
> modern raw/binary on BIND 9.9.x slaves?
> I just want to verify that changes are correct down to the slaves. So
> - I can check-in these changes into svn etc.
12 matches
Mail list logo
