two bind9 masters - Debian

This is a discussion on two bind9 masters - Debian ; Hi all, What are the pros and cons of having two master DNS servers for one zone holding identical data for this zone ? I mean the RFC and practical point of view. What are Your opinions . Regards. -- ...

+ Reply to Thread
Results 1 to 16 of 16

Thread: two bind9 masters

  1. two bind9 masters

    Hi all,
    What are the pros and cons of having two master DNS servers for one
    zone holding identical data for this zone ?
    I mean the RFC and practical point of view.
    What are Your opinions .

    Regards.

    --
    Wojciech Ziniewicz
    Unix SEX :{look;gawk;find;sed;talk;grep;touch;finger;find;f l
    ex;unzip;head;tail; mount;workbone;fsck;yes;gasp;fsck;more;yes;yes;eje
    ct;umount;makeclean; zip;split;done;exit:xargs!!}


    --
    To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  2. Re: two bind9 masters


    On 10/10/2007, at 4:19 PM, Roberto C. Sánchez wrote:

    > On Wed, Oct 10, 2007 at 04:16:45PM +0200, Wojciech Ziniewicz wrote:
    >> Hi all,
    >> What are the pros and cons of having two master DNS servers for one
    >> zone holding identical data for this zone ?
    >> I mean the RFC and practical point of view.
    >> What are Your opinions .
    >>

    > I think that this may only work in the case of using something like
    > ldap2dns.


    I see no reason why this will not work... although probably not
    practical.

    The setup that I am used to is a hidden primary, and two secondaries.

    The two secondaries are the servers which are entered into the
    registries databases and queried by the Internet users.

    The primary is only used for admin purposes like changing dns
    records, etc
    and the two secondaries grab their info from there - no need to copy
    the zones
    back and forth all the time. - Although you still need to copy of the
    list
    of zone files across...

    Andrew

  3. Re: two bind9 masters

    Hi,

    On Wed, Oct 10, 2007 at 04:16:45PM +0200, Wojciech Ziniewicz wrote:
    > What are the pros and cons of having two master DNS servers for one
    > zone holding identical data for this zone ?
    > I mean the RFC and practical point of view.
    > What are Your opinions .


    As long as you have a way to keep them up to date and in sync then
    that is your business, and it's fine. AXFR is not mandated as the
    method.

    The pros depend on your reasons for doing this. The most obvious
    con is that it's going to be a lot easier to end up with
    inconsistent data unless you are careful.

    Depending on your reasons for doing this it may be better to use
    a different nameserver, like powerdns with a mysql backend and mysql
    replication for keeping in sync, for example. Without you saying
    why you want to do this it is hard to speculate.

    Cheers,
    Andy

    --
    http://bitfolk.com/ -- No-nonsense VPS hosting
    Encrypted mail welcome - keyid 0x604DE5DB

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFHDOK1IJm2TL8VSQsRAivLAJ48tFpw71TAFi4fG8Yok9 InUOtIYgCg8mlW
    wD046Gm1/mZTPbXcN50StpM=
    =GiZF
    -----END PGP SIGNATURE-----


  4. Re: two bind9 masters

    Le Wednesday 10 October 2007 16:16:45 Wojciech Ziniewicz, vous avez écrit*:
    > Hi all,
    > What are the pros and cons of having two master DNS servers for one
    > zone holding identical data for this zone ?
    > I mean the RFC and practical point of view.
    > What are Your opinions .


    If you have dynamic DNS updates (Microsoft AD controllers, DHCP...) It will
    certainly not work as it should.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQBHDTfBDltnDmLJYdARApQoAKCbukX7l6lKSSuLUcSzio 36nEuQSgCfdglR
    LHKoT7QtETL/UhqfSVp0Frg=
    =pQjI
    -----END PGP SIGNATURE-----


  5. Re: two bind9 masters

    2007/10/10, Gilles Mocellin :
    > Le Wednesday 10 October 2007 16:16:45 Wojciech Ziniewicz, vous avez écrit:
    > > Hi all,
    > > What are the pros and cons of having two master DNS servers for one
    > > zone holding identical data for this zone ?
    > > I mean the RFC and practical point of view.
    > > What are Your opinions .

    >
    > If you have dynamic DNS updates (Microsoft AD controllers, DHCP...) It will
    > certainly not work as it should.


    No, I only want to have about 50 static zones held in two masters -
    two of them holding identical data. If there are any cons more ,
    please tell me.

    regards


    --
    Wojciech Ziniewicz
    Unix SEX :{look;gawk;find;sed;talk;grep;touch;finger;find;f l
    ex;unzip;head;tail; mount;workbone;fsck;yes;gasp;fsck;more;yes;yes;eje
    ct;umount;makeclean; zip;split;done;exit:xargs!!}

  6. Re: two bind9 masters

    On Wed, 10 Oct 2007, Wojciech Ziniewicz wrote:
    > No, I only want to have about 50 static zones held in two masters -
    > two of them holding identical data. If there are any cons more ,
    > please tell me.


    There are none, *as long as* you are completely sure the two name servers
    will always be in sync, i.e. whatever you use to send zone files to them
    must work well.

    --
    "One disk to rule them all, One disk to find them. One disk to bring
    them all and in the darkness grind them. In the Land of Redmond
    where the shadows lie." -- The Silicon Valley Tarot
    Henrique Holschuh


    --
    To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  7. Re: two bind9 masters

    2007/10/10, Henrique de Moraes Holschuh :
    > There are none, *as long as* you are completely sure the two name servers
    > will always be in sync, i.e. whatever you use to send zone files to them
    > must work well.


    One server is managed through ISPconfig software. It has about 80
    domains in it now , and works well but for the production use (we're
    now preparing for moving from QA to prod.) there must be 2 or more DNS
    servers for those domains. As the old servers will be shut down, new
    servers must take their role.

    I've managed to modify ISPconfig to manage it's own DNS master server
    as well as any slave server (simple ssh-based commandline scripting )
    but for an existing 80 domains i should remove them and add them again
    that is not what i want. Moreover i dont want to mofidy the code of
    ISPconfig so i can easily apply updates .

    The remaining option is to create two masters - One managed by
    ISPconfig and the second master that will be
    rsyncing/syncing/sshing/whatever to the ISPconfig master everytime the
    CP is doing rndc reload.

    That's all..

    There's another question how to sync those servers but as I said i'll
    probably make a simple crontab under the ISPconfig entry with "rndc
    reload" like :

    rsync /etc/bind/mymaster_zones
    bind@my_second_master_server.com::/masterzones && ssh
    my_second_master_server.com 'rndc reload'

    I think it will be a good way to manage all the things together .

    The probable time of having my servers "unsynced" will be about 0,5
    sec or something like that that is acceptable for me.


    Regards.

    --
    Wojciech Ziniewicz
    Unix SEX :{look;gawk;find;sed;talk;grep;touch;finger;find;f l
    ex;unzip;head;tail; mount;workbone;fsck;yes;gasp;fsck;more;yes;yes;eje
    ct;umount;makeclean; zip;split;done;exit:xargs!!}


    --
    To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  8. Re: two bind9 masters

    Hi,

    On Thu, Oct 11, 2007 at 12:01:52AM +0200, Wojciech Ziniewicz wrote:
    > One server is managed through ISPconfig software. It has about 80
    > domains in it now , and works well but for the production use (we're
    > now preparing for moving from QA to prod.) there must be 2 or more DNS
    > servers for those domains. As the old servers will be shut down, new
    > servers must take their role.


    Nothing in the rest of your email makes clear why you can't just
    have another DNS server slaving off the DNS server that has
    ISPconfig on it.

    I've never used ISPconfig though, but it's hard to believe that it
    configures a DNS server in such a way as to make zone transfers
    impossible. That would be really broken.

    So I'm at a loss as to why a normal setup involving one master and
    one or more slaves will not suffice.

    Cheers,
    Andy

    --
    http://bitfolk.com/ -- No-nonsense VPS hosting
    Encrypted mail welcome - keyid 0x604DE5DB

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFHDVucIJm2TL8VSQsRAueGAJ9mBHbsBueQ50yQVAZt5X D9qoSe9wCeIQlC
    DuIXIteBAuSbeFuQtSxBT9k=
    =vBrK
    -----END PGP SIGNATURE-----


  9. Re: two bind9 masters

    > On Thu, Oct 11, 2007 at 12:01:52AM +0200, Wojciech Ziniewicz wrote:
    >> One server is managed through ISPconfig software. It has about 80
    >> domains in it now , and works well but for the production use (we're
    >> now preparing for moving from QA to prod.) there must be 2 or more DNS
    >> servers for those domains. As the old servers will be shut down, new
    >> servers must take their role.

    >

    Andy Smith wrote:
    > Nothing in the rest of your email makes clear why you can't just
    > have another DNS server slaving off the DNS server that has
    > ISPconfig on it.
    >
    > I've never used ISPconfig though, but it's hard to believe that it
    > configures a DNS server in such a way as to make zone transfers
    > impossible. That would be really broken.


    We decided not to use bind's replication mechanism because it required
    us to add zones to each server by hand.

    For example in our named.inc

    zone "lbgc.org" {
    type master;
    file "db.lbgc";
    };

    Other people have opted not use bind's replication mechanism because
    there have been security issues.

    If it is helpful, our rysnc script is attached.

    #!/usr/bin/perl -w

    # $Revision: 1.9 $
    # $Source: /usr/local/cvsroot/boxes/scripts/some/dnssync,v $
    # %Location: /usr/local/sbin/
    # %Servers: brave csl-dns-01

    use warnings;
    use strict;

    ##
    # Configuration
    ##

    # rndc command-line options
    my $RNDC = '/usr/sbin/rndc';
    my $RNDC_OPTIONS = '-s';
    my $RNDC_COMMAND = 'reload';

    # rsync command-line options
    my $RSYNC = '/usr/bin/rsync';
    my $RSYNC_OPTIONS = "-azql --delete -e 'ssh -i /var/cache/bind/.ssh/id_dsa' ";
    my $EXCLUDE =
    '--exclude=old/ --exclude=named.conf* --exclude=named.options --exclude=rndc.*';
    my $SOURCE = '/etc/bind/';
    my $REMOTE_USER = 'bind';

    my $DIG = '/usr/bin/dig';

    # Hash of each hostname and its BIND config directory
    my %HOST_CONFIGDIR = (
    'csl-dns-01.thecsl.org' => '/etc/bind',
    'csl-dns-02.thecsl.org' => '/usr/local/etc/bind',
    'csl-dns-03.thecsl.org' => '/etc/bind',
    );

    ##
    # Main
    ##
    {
    print "\nReloading localhost\n";
    print `$RNDC $RNDC_OPTIONS localhost $RNDC_COMMAND`;

    foreach my $host ( sort keys %HOST_CONFIGDIR ) {
    print "\n$host";
    print "\tcopy files...";

    my $cmd = "$RSYNC $RSYNC_OPTIONS ";
    $cmd .= "$EXCLUDE $SOURCE ";
    $cmd .= "${REMOTE_USER}\@$host:$HOST_CONFIGDIR{$host}";
    print `$cmd`;
    print "\treload server...";
    system("$RNDC $RNDC_OPTIONS $host $RNDC_COMMAND > /dev/null") == 0
    or warn "FAILED";

    print "\ttest dns is up...";
    system("$DIG \@${host} thecsl.org > /dev/null") == 0
    or warn "FAILED";
    }

    print "\n";

    }


  10. Re: two bind9 masters

    On Thu, Oct 11, 2007 at 12:46:06PM -0400, Dan MacNeil wrote:
    > We decided not to use bind's replication mechanism because it required us
    > to add zones to each server by hand.


    so?

    more to the point, it didn't "require" you to add zones by hand, you
    chose to do that because you weren't sufficiently lazy :-)

    laziness is a virtue because it motivates you to do things the smart
    easy way rather than the hard dumb way.



    > For example in our named.inc
    >
    > zone "lbgc.org" {
    > type master;
    > file "db.lbgc";
    > };


    do you realise how trivially easy it is to generate config fragments like
    that?

    this is part of what perl (and sh and other scripting languages) are FOR
    - to automate generation of repetitive and tedious config fragments like
    bind config, apache virtualhost config, mailing list config, etc etc
    etc.

    for a primary zone, the only thing that differs is the zone name and
    maybe the file name (although the filename can be the same as the zone
    name or derived from it).

    for a secondary, the only things that change are the zone name and the master
    server's IP to secondary it from.

    so, a text file like this:

    master master1.example.com
    master master2.example.com
    secondary sec1.example.com 192.168.1.1
    secondary sec2.example.com 192.168.1.1
    secondary sec3.example.com 172.31.1.1

    (or you can skip the first word if you have one text file for masters
    and another text file for secondaries - in fact, if you secondary for
    several other ISPs you could have one secondary file per ISP. or it
    could be pulled out of a database)

    with a trivial line perl script could generate a named config file
    which could be included into named.conf.


    the script would look something like the one below. it's trivial - i
    wrote it from scratch for this email, with just the memory of doing
    something similar years ago to guide me.

    it's written as a filter. input on stdin, output on stdout. redirect as
    needed. most of my systems automation scripts are written that way - i
    find it far more useful and flexible than hard-coding input and output
    filenames...and allows easy testing of changes by piping output into
    less or to a /tmp/ file.


    #! /usr/bin/perl

    $Default_Primary_IP = '192.168.1.1';

    while (<>) {
    chomp;
    s/#.*//;
    next if (/^$/);

    my ($Type, $Zone, $ZSource) = split ;

    if ($Type =~ /^(master|primary)$/io) {

    # Zone filename defaults to same as Zone if blank
    $ZSource = $Zone if ($ZSource eq '') ;
    print <<__EOF__;

    zone "$Zone" {
    type master;
    file "$ZSource";
    };
    __EOF__
    } elsif ($Type =~ /^(secondary|slave)/io) {
    # Use default primary IP if ZSource is blank
    $ZSource = $Default_Primary_IP if ($ZSource eq '');

    print <<__EOF__;

    zone "$Zone" {
    type slave;
    file "$Zone";
    masters {
    $ZSource;
    } ;
    };
    __EOF__

    };
    };

    NOTE: untested but It Should Work. there may be minor syntactic
    errors because i wrote it without referring to any documentation - in
    particular, i can never remember whether it's 'eq' or '==' for comparing
    strings until i look it up in the perlop man page.


    a script like this, combined with a Makefile to automate the generation
    (and scp-ing or rsync-ing of files) when the source text files have
    changed can completely automate management of DNS zones - and even
    automatically check in changes to a revision control system like RCS or
    Subversion.

    in fact, subversion can serve a double use as the delivery mechanism
    to get updates to other machines. check-in the files on one machine,
    check them out on others. then you can edit the files on any of the
    machines and know that the changes will be replicated to all the others.
    i have used this technique to replicate my (generated) apache virtual
    host config from one load-balanced web server to others in the same
    load-balanced web farm.

    once the automation scripts are written and tested, updating things
    is as simple as editing one small text file and running "make" - the
    Makefile automates everything, and does everything else in precisely the
    correct order.

    craig

    --
    craig sanders

    Other than that, Mrs. Lincoln, how did you like the play?


    --
    To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  11. Re: two bind9 masters

    Hi,
    I haven't found any cons, at least none I can think of right away. What I did
    in my setup is.

    1. setup a ssh key pair using the root user
    (http://www.ibm.com/developerworks/library/l-keyc.html) and place the public
    keys on the other servers.

    2. create your records as you would on your master dns server.

    3. create a simple shell script like so
    /etc/init.d/bind9 reload
    /usr/bin/scp /etc/bind/named.conf* root@server1.domain.com:/etc/bind/
    /usr/bin/scp /etc/bind/reverse.* root@server1.domain.com:/etc/bind/
    /usr/bin/scp /etc/bind/db.* root@server1.domain.com:/etc/bind/
    /usr/bin/scp /etc/bind/named.conf* root@server2.domain.com:/etc/bind/
    /usr/bin/scp /etc/bind/reverse.* root@server2.domain.com:/etc/bind/
    /usr/bin/scp /etc/bind/db.* root@server2.domain.com:/etc/bind/
    /usr/bin/ssh server1.domain.com /etc/init.d/bind9 reload
    /usr/bin/ssh server2.domain.com /etc/init.d/bind9 reload

    the ssh key pair is used to scp the named.conf and all the records to the
    other dns servers and reload bind. some may prefer a different configuration
    but this setup works for me. hope this helps you out with what your tring to
    acomplish.

    Eric Hudspeth

    On Wed, 10 Oct 2007 16:16:45 +0200, Wojciech Ziniewicz wrote
    > Hi all,
    > What are the pros and cons of having two master DNS servers for one
    > zone holding identical data for this zone ?
    > I mean the RFC and practical point of view.
    > What are Your opinions .
    >
    > Regards.
    >
    > --
    > Wojciech Ziniewicz
    > Unix SEX :{look;gawk;find;sed;talk;grep;touch;finger;find;f l
    > ex;unzip;head;tail;
    > mount;workbone;fsck;yes;gasp;fsck;more;yes;yes;eje
    > ct;umount;makeclean; zip;split;done;exit:xargs!!}
    >
    > --
    > To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
    > with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


    --
    linux inside? geek outside! (http://www.geekoutside.com)


    --
    To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  12. Re: two bind9 masters

    Dan MacNeil schrieb:
    > We decided not to use bind's replication mechanism because it required
    > us to add zones to each server by hand.
    >
    > For example in our named.inc
    >
    > zone "lbgc.org" {
    > type master;
    > file "db.lbgc";
    > };
    >


    In my setup I use a small shell-script that parses named.conf for the
    master-entrys and generates the named.conf (with the slave entrys) for
    the slave servers. It distributes that generated file via ssh with
    keyauth and reloads the slaves. This script is called before every
    master-reload. so that the slaves always know there zones and retrieve
    the zones when they catch the masters notify.

    The masters named.conf and zones are generated with several admin-panels
    in the past. SysCP is in use here at the moment.

    Best regards
    Dominique Görsch


    --
    To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  13. Re: two bind9 masters

    > Dan MacNeil schrieb:
    >> We decided not to use bind's replication mechanism because it required
    >> us to add zones to each server by hand.
    >> [snip]


    Dominique Görsch wrote:
    > In my setup I use a small shell-script that parses named.conf for the
    > master-entrys and generates the named.conf (with the slave entrys) for
    > the slave servers. It distributes that generated file via ssh with
    > keyauth and reloads the slaves.
    > [snip]


    I think the difference between the two approaches is that we:

    0) generate named.inc & zone files
    1) scp named.conf & zone files
    2) rndc reload the satellite servers

    and many other people have a script:

    0) generate named.inc & zone files
    1) scp/rsync named.conf
    2) rndc reload the satellite servers
    3) use the bind replication mechanism

    I claim our approach is slightly simpler as we don't have to increment
    the serial# (perhaps done by SysCP) in the zone files and we have one
    less step. :->


    --
    To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  14. Re: two bind9 masters

    On 12.10.07 14:50, Dan MacNeil wrote:
    > I think the difference between the two approaches is that we:
    >
    > 0) generate named.inc & zone files
    > 1) scp named.conf & zone files
    > 2) rndc reload the satellite servers
    >
    > and many other people have a script:
    >
    > 0) generate named.inc & zone files
    > 1) scp/rsync named.conf
    > 2) rndc reload the satellite servers
    > 3) use the bind replication mechanism


    You're wrong, the 3) is here done automatically, those scripts do not care
    about this. You are trying to make assumption those scripts care about more
    than yours, which is not true.

    > I claim our approach is slightly simpler as we don't have to increment
    > the serial# (perhaps done by SysCP) in the zone files and we have one
    > less step. :->


    it's a bit different: Your approach requires distributing all the zones (not
    just the bind config) across all servers, while others just distribute the
    config.

    Also, the fact you don't increment serisl number makes your design much
    harder to detect and fix errors, while DNS zone transfer mechanism takes
    care about that automatically.

    --
    Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
    Warning: I wish NOT to receive e-mail advertising to this address.
    Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
    If Barbie is so popular, why do you have to buy her friends?


    --
    To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  15. Re: two bind9 masters

    I think we're talking micro-optimization here but...

    > it's a bit different: Your approach requires distributing
    > all the zones (not just the bind config) across all servers,
    > while others just distribute the config.


    And how is this is a problem?

    rsync only squirts the parts of the files that have changed, which for
    us is almost always a few lines in:

    named.inc
    db.example.com

    ....but if it didn't, we're not talking a few hundred K even for hundreds
    of zones.

    > Also, the fact you don't increment serial number makes
    > your design much harder to detect and fix errors, while
    > DNS zone transfer mechanism takes care about that automatically.


    We're not using the bind replication mechanism, so what does
    incrementing the serial number give us that the timestamp on the file?

    I'd be curious as to specific examples of problems detected by the bind
    replication mechanism.

    > You're wrong, the 3) is here done automatically, those scripts
    > do not care about this. You are trying to make assumption those
    > scripts care about more than yours, which is not true.


    Perhaps I've miss-read the docs, It seems to me that the bind zone
    replication mechanism ***REQUIRES*** you (or your control panel) to
    update the serial number in the "master" zone file. If you don't
    increment the serial number, you don't get replication. The replication
    is triggered by a change in serial number.

    Something or somebody in your environment is incrementing these serial
    numbers or your setup wouldn't work.

    We're (sigh) not using a control panel. Avoiding the step of parsing
    out and incrementing the serial# in the SOA record in our zone files is
    a mild plus for us.

    As a new data point I will concede that **IF** there is not a new zone
    requiring a transfer of named.inc, bind replicating the zone changes
    allows the slave server to take the time to only reload the changed zone.

    With a few thousand zones or a lot of traffic, I guess avoiding
    reloading the entire server could be a plus.


    #########

    Matus UHLAR - fantomas wrote:
    > On 12.10.07 14:50, Dan MacNeil wrote:
    >> I think the difference between the two approaches is that we:
    >>
    >> 0) generate named.inc & zone files
    >> 1) scp named.conf & zone files
    >> 2) rndc reload the satellite servers
    >>
    >> and many other people have a script:
    >>
    >> 0) generate named.inc & zone files
    >> 1) scp/rsync named.conf
    >> 2) rndc reload the satellite servers
    >> 3) use the bind replication mechanism

    >
    > You're wrong, the 3) is here done automatically, those scripts do not care
    > about this. You are trying to make assumption those scripts care about more
    > than yours, which is not true.
    >
    >> I claim our approach is slightly simpler as we don't have to increment
    >> the serial# (perhaps done by SysCP) in the zone files and we have one
    >> less step. :->

    >
    > it's a bit different: Your approach requires distributing all the zones (not
    > just the bind config) across all servers, while others just distribute the
    > config.
    >
    > Also, the fact you don't increment serisl number makes your design much
    > harder to detect and fix errors, while DNS zone transfer mechanism takes
    > care about that automatically.
    >



    --
    To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  16. Re: two bind9 masters

    > I think we're talking micro-optimization here but...
    >
    > > it's a bit different: Your approach requires distributing
    > > all the zones (not just the bind config) across all servers,
    > > while others just distribute the config.


    On 16.10.07 10:50, Dan MacNeil wrote:
    > And how is this is a problem?


    Basically it's different.

    > > Also, the fact you don't increment serial number makes
    > > your design much harder to detect and fix errors, while
    > > DNS zone transfer mechanism takes care about that automatically.

    >
    > We're not using the bind replication mechanism, so what does
    > incrementing the serial number give us that the timestamp on the file?


    It will give you (or admins on other side of the net) a possibility to
    detect that one of your hosts has older zone (comparing SOAs). Now, all
    they will return the same SOA and if one of them returns different RRs,
    nobody except you will be able to find out where the problem lies.

    > > You're wrong, the 3) is here done automatically, those scripts
    > > do not care about this. You are trying to make assumption those
    > > scripts care about more than yours, which is not true.

    >
    > Perhaps I've miss-read the docs, It seems to me that the bind zone
    > replication mechanism ***REQUIRES*** you (or your control panel) to
    > update the serial number in the "master" zone file. If you don't
    > increment the serial number, you don't get replication. The replication
    > is triggered by a change in serial number.


    Read your original mail again. You mentioned one step more to do (reload
    zones using *XFR) when using DNS transfers comparing to your way of doins
    things. I am only telling you that it's not true, because it's something
    that will be done automatically, so your scripts have nothing to do with
    that.

    You made an assumption that scripts will be more complicated because of DNS
    transfers. That is not true.

    > As a new data point I will concede that **IF** there is not a new zone
    > requiring a transfer of named.inc, bind replicating the zone changes
    > allows the slave server to take the time to only reload the changed zone.
    >
    > With a few thousand zones or a lot of traffic, I guess avoiding
    > reloading the entire server could be a plus.


    With bind replication, no rsync has to be done when config is not needed,
    servers will only transfer changed zones and only reload those. This is much
    more efficient than calling rsync every time something has changed.

    And when you rsync zones, how do you tell which zones to reload? Either you
    call 'rndc reload' or HUP the server, which will cause named to reload all
    zones (yes, it will detect those unchanged), or you call "rndc reload" for
    each changed zone. Both are not needed when using DNS zone transfers.

    --
    Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
    Warning: I wish NOT to receive e-mail advertising to this address.
    Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
    Linux - It's now safe to turn on your computer.
    Linux - Teraz mozete pocitac bez obav zapnut.


    --
    To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

+ Reply to Thread