Forventet tid til axfr for hidden primary

[madssj]

Jeg synes at det er meget forskelligt hvor længe der går fra man sender en notifier mod jer, til der rent faktisk sker en axfr. For få uger siden skete axfr inden for få sekunder, pt. sker det med 15 minutters forsinkelse, og til tider sker det med op mod 2 timers forsinkelse.

Jeg, og andre, har spurgt jer før hvad dette skyldtes, og om det er muligt at gøre noget - dog uden svar. Jeg håber at kunne få lokket et svar ud af jer denne gang, da det ville være meget rart at have en indikation af forsinkelsen. Det er lidt svært at planlægge flytninger eller opdateringer af dns når man ikke kender tiden til axfr rent faktisk sker

For god ordens skyld, er her en snippet fra bind:

Kode: [Vælg]

$ sudo tail -f /var/log/daemon.log
Feb  5 11:32:01 peewee named[3169]: zone coniuro.com/IN: loaded serial 2009020501
Feb  5 11:32:01 peewee named[3169]: zone coniuro.com/IN: sending notifies (serial 2009020501)
Feb  5 11:32:01 peewee named[3169]: zone coniuro.dk/IN: loaded serial 2009020501
Feb  5 11:32:01 peewee named[3169]: zone coniuro.dk/IN: sending notifies (serial 2009020501)
Feb  5 11:32:01 peewee named[3169]: zone coniuro.net/IN: loaded serial 2009020501
Feb  5 11:32:01 peewee named[3169]: zone coniuro.net/IN: sending notifies (serial 2009020501)
Feb  5 11:32:01 peewee named[3169]: zone coniuro.org/IN: loaded serial 2009020501
Feb  5 11:32:01 peewee named[3169]: zone coniuro.org/IN: sending notifies (serial 2009020501)
Feb  5 11:45:41 peewee named[3169]: client 213.173.243.11#57578: transfer of 'coniuro.com/IN': AXFR-style IXFR started
Feb  5 11:45:41 peewee named[3169]: client 213.173.243.11#57578: transfer of 'coniuro.com/IN': AXFR-style IXFR ended
Feb  5 11:51:09 peewee named[3169]: client 213.173.243.11#50834: transfer of 'coniuro.dk/IN': AXFR-style IXFR started
Feb  5 11:51:09 peewee named[3169]: client 213.173.243.11#50834: transfer of 'coniuro.dk/IN': AXFR-style IXFR ended


[madssj]

Og det er først omkring nu (inden for 5-10 minutter), at denne axfr er kommet ud til ns1-5.

[Calzone]

Normalt er det inden for 3min, hvis der går mere vil jeg tro det er firewall problemer eller ligenden (som også tidligere svaret).

[czar]

Og det er først omkring nu (inden for 5-10 minutter), at denne axfr er kommet ud til ns1-5.

"så hurtigt som muligt"

kommer an på kø'en af opdateringer størrelzen af den, og svartiderne

[madssj]

Normalt er det inden for 3min, hvis der går mere vil jeg tro det er firewall problemer eller ligenden (som også tidligere svaret).

Det er ikke, som også tidligere skrevet, et firewall problem.

[madssj]

kommer an på kø'en af opdateringer størrelzen af den, og svartiderne

Den største opdatering jeg har lavet inden for det sidste år, har været at tilføje 2 records på en gang. Som regel er der tale om en ændring af et CNAME eller oprettelsen af samme.

Kunne I på en eller anden måde lave en indikation af denne kø-størrelse?

[Calzone]

Det er ikke, som også tidligere skrevet, et firewall problem.

Fakta er at AXFR -> NS1-NS5 er ude inden for 3-4min på alle serverne, så hvis det går langsomere for dig kan det hverken være AXFR eller NS1 til NS5.

[madssj]

Fakta er at AXFR -> NS1-NS5 er ude inden for 3-4min på alle serverne, så hvis det går langsomere for dig kan det hverken være AXFR eller NS1 til NS5.

Irelevant af hvad du mener fakta er, så tager det rent faktisk længere tid end 4 minutter for axfr at pushe data videre til ns1-5 i visse tilfælde. Jeg har været ude for at det tager op til 15 minutter før det sker (før dig viser det offentligt), og det passer meget godt med det czar siger. Derfor må det altså hænge sammen med belastningen af systemet, og er derfor ikke ligefrem et fastdefinerbart tidsrum.

[Calzone]

Som skrevet, så skriver jeg det igen, normalt er zoner ude inden for 3-4 min, tager det længere tid for dig hver gang, så kan det IKKE være systemet!

[madssj]

Som skrevet, så skriver jeg det igen, normalt er zoner ude inden for 3-4 min, tager det længere tid for dig hver gang, så kan det IKKE være systemet!

Det tager netop ikke længere tid for mig hver gang, men tiden det tager er variabel fra mellem 5 sekunder, til op mod 2 timer.

Det var jo derfor jeg skrev følgende:

Jeg synes at det er meget forskelligt hvor længe der går fra man sender en notifier mod jer, til der rent faktisk sker en axfr. For få uger siden skete axfr inden for få sekunder, pt. sker det med 15 minutters forsinkelse, og til tider sker det med op mod 2 timers forsinkelse.

Hvis jeg mente at det tog over en time hver eneste gang, så ville jeg have skrevet det.

[madssj]

Lidt yderligere problemer og observationer:

Feb 10 08:55:37 peewee named[3169]: zone coniuro.com/IN: loaded serial 2009021001
Feb 10 08:55:37 peewee named[3169]: zone coniuro.com/IN: sending notifies (serial 2009021001)
Feb 10 08:55:37 peewee named[3169]: zone coniuro.dk/IN: loaded serial 2009021001
Feb 10 08:55:37 peewee named[3169]: zone coniuro.dk/IN: sending notifies (serial 2009021001)
Feb 10 08:55:37 peewee named[3169]: zone coniuro.net/IN: loaded serial 2009021001
Feb 10 08:55:37 peewee named[3169]: zone coniuro.net/IN: sending notifies (serial 2009021001)
Feb 10 08:55:37 peewee named[3169]: zone coniuro.org/IN: loaded serial 2009021001
Feb 10 08:55:37 peewee named[3169]: zone coniuro.org/IN: sending notifies (serial 2009021001)
Feb 10 09:02:56 peewee named[3169]: client 213.173.243.11#56677: transfer of 'coniuro.org/IN': AXFR-style IXFR started
Feb 10 09:02:56 peewee named[3169]: client 213.173.243.11#56677: transfer of 'coniuro.org/IN': AXFR-style IXFR ended
Feb 10 09:47:43 peewee named[3169]: client 213.173.243.11#54403: transfer of 'coniuro.net/IN': AXFR-style IXFR started
Feb 10 09:47:43 peewee named[3169]: client 213.173.243.11#54403: transfer of 'coniuro.net/IN': AXFR-style IXFR ended
Feb 10 09:47:43 peewee named[3169]: client 213.173.243.11#63768: transfer of 'coniuro.dk/IN': AXFR-style IXFR started
Feb 10 09:47:43 peewee named[3169]: client 213.173.243.11#63768: transfer of 'coniuro.dk/IN': AXFR-style IXFR ended

Det ser ud til at domænerne denne gang bliver axfr'et bagfra, som en LIFO. coniuro.com er stadig ikke blevet axfr'et.

czar, kan du evt. lave et udtræk for 93.163.25.26 i bind's log og se om den brokker sig over et eller andet?

[madssj]

Alternativet til at NOTIFY kommer til at virke ordentligt er vel, at jeg sætter refresh i mine zoner til 60, men det tror jeg ikke I ville synes så godt om, derfor ville jeg, stadigvæk, sætte stor pris på hvis I kunne hjælpe lidt til med at komme til bunds i dette

[madssj]

Ud over dette er jeg egentlig løbet lidt tør for ideer til, hvordan jeg kan hjælpe jer med at finde ud af hvad der er galt. Jeg ville være frygtelig ked af at skulle finde mig et alternativ til GratisDNS, men det ender det med, at jeg bliver nødt til at gøre hvis vi ikke kan finde ud af hvad det er der går galt. Det kan da ikke være normalt at tidsrummet for en axfr er så sporadisk som jeg oplever det.

Hvis I skal bruge andet information fra mig, så må I endelig sige til.

Jeg har derudover set mig nødsaget til, at sætte refresh på mine zoner ned.

tcpdump fra afsendelse af NOTIFY:

# tcpdump -neeet net 213.173.243.0/28
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
00:1b:21:22:cb:87 > 00:00:24:c5:3c:64, ethertype IPv4 (0x0800), length 147: 93.163.25.26.44902 > 213.173.243.11.53:  37152 notify [b2&3=0x2400] [1a] SOA? coniuro.com. (105)
00:1b:21:22:cb:87 > 00:00:24:c5:3c:64, ethertype IPv4 (0x0800), length 136: 93.163.25.26.44902 > 213.173.243.11.53:  38139 notify [b2&3=0x2400] [1a] SOA? coniuro.dk. (94)
00:1b:21:22:cb:87 > 00:00:24:c5:3c:64, ethertype IPv4 (0x0800), length 147: 93.163.25.26.44902 > 213.173.243.11.53:  32226 notify [b2&3=0x2400] [1a] SOA? coniuro.net. (105)
00:1b:21:22:cb:87 > 00:00:24:c5:3c:64, ethertype IPv4 (0x0800), length 147: 93.163.25.26.44902 > 213.173.243.11.53:  58392 notify [b2&3=0x2400] [1a] SOA? coniuro.org. (105)


tcpdump fra test af axfr fra administrationen.

# tcpdump -neeet net 213.173.243.0/28
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
00:1b:21:22:cb:87 > 00:00:24:c5:3c:64, ethertype IPv4 (0x0800), length 74: 93.163.25.26.53 > 213.173.243.10.54633: S 3811825211:3811825211(0) ack 2472078639 win 5792 <mss 1460,sackOK,timestamp 193777259 8455689,nop,wscale 6>
00:1b:21:22:cb:87 > 00:00:24:c5:3c:64, ethertype IPv4 (0x0800), length 66: 93.163.25.26.53 > 213.173.243.10.54633: . ack 32 win 91 <nop,nop,timestamp 193777264 8455691>
00:1b:21:22:cb:87 > 00:00:24:c5:3c:64, ethertype IPv4 (0x0800), length 1514: 93.163.25.26.53 > 213.173.243.10.54633: . 1:1449(1448) ack 32 win 91 <nop,nop,timestamp 193777264 8455691> 41565* 100/0/0[|domain]
00:1b:21:22:cb:87 > 00:00:24:c5:3c:64, ethertype IPv4 (0x0800), length 1212: 93.163.25.26.53 > 213.173.243.10.54633: P 1449:2595(1146) ack 32 win 91 <nop,nop,timestamp 193777264 8455691> 24946 zoneInit [b2&3=0x74c0] [1280a] [3072q] [256n] [3au][|domain]
00:1b:21:22:cb:87 > 00:00:24:c5:3c:64, ethertype IPv4 (0x0800), length 66: 93.163.25.26.53 > 213.173.243.10.54633: F 2595:2595(0) ack 33 win 91 <nop,nop,timestamp 193777275 8455695>


AXFR testen giver det forventede resultat.