Slow IXFR...
Robert Messinger
lists at mail.tiggee.com
Wed Jul 3 20:54:34 UTC 2002
You are correct. It is grabbing it off the root name servers.
Now that does not make any sense to me. This forces you
to leave your network if you want to update a namserver
which is internal to your network but (with NAT) is actually
using a different ISP.
*sigh* it was a valiant effort.
Please someone tell me if I'm wrong here.
On Wed, 3 Jul 2002 dbotham at edeltacom.com wrote:
>
>
> Believe it or not, I think your name server will get the A RR for the name
> servers from the appropriate tld name server. Do a dump on your name
> server and find the corrosponding records in the dump file. I think you
> will see that the answer there is the answer you would get from a tld name
> server (gtld-server for a com domain). I had a problem with notifies not
> going to the slave once. I could not figure out why. Then I did a:
>
> dig ns domain.com @a.gtld-servers.com
>
> and got an A record with the wrong IP (a netsol blunder). Then, I dumped
> my named process and greped the file for the hostname of my slave. There
> it was, with the same info found at the tld name server (not the A record
> in the local zone file!).
>
> Dave...
>
>
> |---------+---------------------------->
> | | Robert Messinger |
> | | <lists at mail.tigge|
> | | e.com> |
> | | Sent by: |
> | | bind-users-bounce|
> | | @isc.org |
> | | |
> | | |
> | | 07/03/2002 02:25 |
> | | PM |
> | | |
> |---------+---------------------------->
> >------------------------------------------------------------------------------------------------------------------------------|
> | |
> | To: bind-users at isc.org |
> | cc: |
> | Subject: Re: Slow IXFR... |
> >------------------------------------------------------------------------------------------------------------------------------|
>
>
>
>
>
>
> Ahhhh... Now you have me thinking. And now I think I'm close.
>
> What does the nameserver use to resolve it's queries internally?
> Does it resolve the NS record itself (by leaving the network) or does
> it get the same result as if I did a dig?
>
> Here is my scenario.
>
> Domain (test.com)
> test.com. NS ns1.test.com
> test.com. NS ns2.test.com
>
> Using views for test.com (which has it's DNS on a seperate machine) I have
> differnent IPs for the A records ns1 and ns2 depending if it's internal
> or external.
>
> (internal network)
> ns1.test.com. A 10800 192.168.1.5
> ns2.test.com. A 10800 192.168.1.6
>
> (external network)
> ns1.test.com. A 10800 12.12.12.12
> ns2.test.com. A 10800 12.12.12.13
>
>
> Now when I do a dig on my nameserver it returns the correct result since it
> is on the internal network - 192.168.1.6
>
> But when it tries to do a IXFR will it send it to 12.12.12.13 or
> 192.168.1.6?
>
> If it queries the external network then I would have to change the master
> IP for
> the external network, now it is set to the internal network.
>
>
> Thanks for all help!
>
> On Thu, 4 Jul 2002 Mark_Andrews at isc.org wrote:
>
> >
> > >
> > >
> > > How could I endure that NOTIFY is working?
> >
> > That there are no firewalls blocking the packets.
> > That source address of the notify matches the address in the
> > masters clause.
> > That the master can resolve the addresses of the slaves and
> > those addresses match the address the slave is listening on.
> >
> > Mark
> >
> > > I thought I only needed the "also-notify" if the
> > > slave servers were stealth and by default the notify
> > > was set to yes.
> > >
> > > Plus I have a NS record for the second nameserver.
> > >
> > >
> > > On the master I have this.
> > > options {
> > > version "The best version... What do you expect.";
> > > directory "/var/named";
> > > pid-file "/var/named/named.pid";
> > > // Server will attempt to do all work required to answer query.
> > > recursion yes;
> > > allow-recursion { "internal"; };
> > > // Maximum number of simultaneous recursive lookups the server
> will p
> > > erform [100]
> > > recursive-clients 100;
> > > allow-query { any; };
> > > allow-transfer { "secdns"; };
> > > // These people are banned from everything
> > > blackhole { none; };
> > > provide-ixfr yes;
> > > // The default is 100. Maximum number of simultaneous client
> TCP conn
> > > ections
> > > tcp-clients 100;
> > > // How fast server removes expired RR. default is 60
> > > cleaning-interval 60;
> > > };
> > >
> > On the slave I have this.
> > > options {
> > > version "The best version... What do you expect.";
> > > directory "/var/named";
> > > pid-file "/var/named/named.pid";
> > > // Server will attempt to do all work required to answer query.
> > > recursion yes;
> > > allow-recursion { "internal"; };
> > > // Maximum number of simultaneous recursive lookups the server
> will p
> > > erform [100]
> > > recursive-clients 100;
> > > allow-query { any; };
> > > request-ixfr yes;
> > > // These people are banned from everything
> > > blackhole { none; };
> > > // The default is 100. Maximum number of simultaneous client
> TCP conn
> > > ections
> > > tcp-clients 100;
> > > // How fast server removes expired RR. default is 60
> > > cleaning-interval 60;
> > > // listen-on port 53 { 192.168.1.12; };
> > > };
> > >
> > >
> > > On Wed, 3 Jul 2002 Mark_Andrews at isc.org wrote:
> > >
> > > >
> > > > >
> > > > >
> > > > > It seems to take a long time for the IXF to happen
> > > > > to the domain.
> > > > > On the slave server I have the line request-ixfr yes;
> > > > > And on the master I have the line provide-ixfr yes;
> > > > >
> > > > > These are both in the "options" section in the named.conf
> > > > >
> > > > > What is the best way to speed this up?
> > > > >
> > > > > Thanks in advance!
> > > > >
> > > > >
> > > > Ensure that NOTIFY is working.
> > > > --
> > > > Mark Andrews, Internet Software Consortium
> > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > > > PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews at isc.org
> > > >
> > >
> > >
> > --
> > Mark Andrews, Internet Software Consortium
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews at isc.org
> >
>
>
>
>
>
>
>
>
More information about the bind-users
mailing list