Slow IXFR...

dbotham at edeltacom.com dbotham at edeltacom.com
Wed Jul 3 20:23:39 UTC 2002



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