notifies & bind 8 (extended)
Kevin Darcy
kcd at daimlerchrysler.com
Tue Apr 10 21:35:37 UTC 2001
Unfortunately, you'll have to talk to the maintainers of "artemis" to see why it's taking so long between the
completion of the zone transfer and when the new data is available from their server. Maybe they are running a
modified replication process in order to conserve server resources, e.g. run named-xfer manually and reload
once a day (midnight sounds suspicious to me), with all of the zones defined as "master" in the named.conf
file...
-
Kevin
José M. Fandiño wrote:
> Hi friends,
>
> I'm using a stealth master server with my ISP which have two name
> servers, minerva and artemis, when I do a record update and the
> slaves complete the notify (them give me an ACK) a server (minerva)
> do an AXFR seconds later and the other one have a delay of several
> minutes (probably as a consequence of the OS load as Kevin said).
>
> The trouble arise when after of the AXFRs I query to both name
> servers, minerva have a correct SOA but artemis not. If I don't
> understand wrong after ot the AXFRs succeed the only possible delay is
> the proper OS delay for write the transfers to the zone files, but
> I get up to 16 hours!!! of delay.
> Close to midnight artemis seems answer correctly the SOA for my zone.
>
> I guess that they have artemis in any type of read-only mode
> and a cron job do a ftp/ssh/rsync/... transfer. This is any
> shadow security trick? :-? ¿human stupidity? :)
> Don't break this the DNS consistency?
>
> the worst is that is people manage the 45% of the zones under
> the .es TLD.
>
> regards,
>
> Kevin Darcy wrote:
> >
> > NOTIFY just triggers slaves to check the SOA of a zone. At that point,
> > it's not following the NOTIFY protocol any more, it's following the
> > regular zone-transfer protocol.
> >
> > In any case, if a slave server is being bombarded with NOTIFYs, this
> > could delay *either* the AXFRs themselves *or* the writing of the
> > AXFR data to the file, or *both*. When a machine is overloaded, any
> > number of things could get delayed.
>
> --
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.1
> GCS d- s+: a- C+++ UL++++$ P+ L+++ E--- W++ N+ o K- w---
> O+ M+ V- PS PE+ Y PGP+>+++ t+ 5 X+++ R- tv@ b+++ DI-- D+++
> G e- h++ !r !z
> ------END GEEK CODE BLOCK------
>
> -- Attached file included as plaintext by Listar --
> -- File: log.txt
>
> My stealth master server (8.2.3)
> 05-Apr-2001 17:30:54.520 hint zone "" (IN) loaded (serial 0)
> 05-Apr-2001 17:30:54.523 master zone "fadesa.es" (IN) loaded (serial 2001040501)
> 05-Apr-2001 17:30:54.525 master zone "55.55.195.in-addr.arpa" (IN) loaded (serial 2001040501)
> 05-Apr-2001 17:30:54.527 master zone "67.140.194.in-addr.arpa" (IN) loaded (serial 2001040501)
> 05-Apr-2001 17:30:54.528 master zone "0.0.127.in-addr.arpa" (IN) loaded (serial 2001040501)
> 05-Apr-2001 17:30:54.533 listening on [127.0.0.1].53 (lo)
> 05-Apr-2001 17:30:54.533 listening on [194.140.67.226].53 (eth0)
> 05-Apr-2001 17:30:54.534 listening on [195.55.55.9].53 (eth0:0)
> 05-Apr-2001 17:30:54.535 Forwarding source address is [0.0.0.0].1803
> 05-Apr-2001 17:30:54.546 chrooted to /var/chroot/named8
> 05-Apr-2001 17:30:54.547 group = named
> 05-Apr-2001 17:30:54.547 user = named
> 05-Apr-2001 17:30:54.548 Ready to answer queries.
> 05-Apr-2001 17:31:03.550 Sent NOTIFY for "55.55.195.in-addr.arpa IN SOA" (55.55.195.in-addr.arpa); 2 NS, 2 A
> 05-Apr-2001 17:31:19.550 Sent NOTIFY for "fadesa.es IN SOA" (fadesa.es); 2 NS, 2 A
> 05-Apr-2001 17:31:19.577 Received NOTIFY answer from 194.179.1.101 for "fadesa.es IN SOA"
> 05-Apr-2001 17:31:19.581 Received NOTIFY answer from 194.179.1.100 for "fadesa.es IN SOA"
> 05-Apr-2001 17:31:19.843 approved AXFR from [194.179.1.100].54720 for "fadesa.es"
> 05-Apr-2001 17:31:19.844 zone transfer (AXFR) of "fadesa.es" (IN) to [194.179.1.100].54720
> 05-Apr-2001 17:38:33.743 approved AXFR from [194.179.1.101].38023 for "fadesa.es"
> 05-Apr-2001 17:38:33.744 zone transfer (AXFR) of "fadesa.es" (IN) to [194.179.1.101].38023
>
> ; <<>> DiG 2.2 <<>> @artemis.ttd.net fadesa.es. IN SOA
> ; (1 server found)
> ;; res options: init recurs defnam dnsrch
> ;; got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
> ;; flags: qr aa rd ra; Ques: 1, Ans: 1, Auth: 2, Addit: 2
> ;; QUESTIONS:
> ;; fadesa.es, type = SOA, class = IN
>
> ;; ANSWERS:
> fadesa.es. 86400 SOA fuego.fadesa.es. postmaster.fadesa.es. (
> 2001040412 ; serial
> 10800 ; refresh (3 hours)
> 3600 ; retry (1 hour)
> 604800 ; expire (7 days)
> 86400 ) ; minimum (1 day)
>
> ;; AUTHORITY RECORDS:
> fadesa.es. 86400 NS artemis.ttd.net.
> fadesa.es. 86400 NS minerva.ttd.net.
>
> ;; ADDITIONAL RECORDS:
> artemis.ttd.net. 308389 A 194.179.1.101
> minerva.ttd.net. 308389 A 194.179.1.100
>
> ;; Total query time: 47 msec
> ;; FROM: fuego to SERVER: artemis.ttd.net 194.179.1.101
> ;; WHEN: Tue Apr 5 19:41:42 2001
> ;; MSG SIZE sent: 27 rcvd: 163
>
> ; <<>> DiG 2.2 <<>>
> ; (1 server found)
> ;; res options: init recurs defnam dnsrch
> ;; got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
> ;; flags: qr aa rd ra; Ques: 1, Ans: 1, Auth: 2, Addit: 2
> ;; QUESTIONS:
> ;; fadesa.es, type = SOA, class = IN
>
> ;; ANSWERS:
> fadesa.es. 86400 SOA fuego.fadesa.es. postmaster.fadesa.es. (
> 2001040501 ; serial
> 10800 ; refresh (3 hours)
> 3600 ; retry (1 hour)
> 604800 ; expire (7 days)
> 86400 ) ; minimum (1 day)
>
> ;; AUTHORITY RECORDS:
> fadesa.es. 86400 NS artemis.ttd.net.
> fadesa.es. 86400 NS minerva.ttd.net.
>
> ;; ADDITIONAL RECORDS:
> artemis.ttd.net. 345600 A 194.179.1.101
> minerva.ttd.net. 345600 A 194.179.1.100
>
> ;; Total query time: 37 msec
> ;; FROM: fuego to SERVER: minerva.ttd.net 194.179.1.100
> ;; WHEN: Tue Apr 5 19:44:10 2001
> ;; MSG SIZE sent: 27 rcvd: 163
More information about the bind-users
mailing list