https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6281
--- Comment #9 from Mark Martinec <[email protected]> 2010-01-10 15:12:23 UTC --- I followed what happened to my (test) change r897247 on 60_whitelist_dkim.cf (Bug 6279 #c7), letting a script poll the four DNS servers every minute: Rule change committed on 2010-01-08 16:15 UTC, zone serial number at that time was 2010010800, TXT record showed "897136" (last change). 41 hours (!) later (2010-01-10 09:00 UTC) the three a,b,c.auth-ns.sonic.net DNS servers started to pick up the change, which took about 6 minutes to propagate to all three, including sequence number update on a zone SOA, and a rules TXT record update. The ns.hyperreal.org was left behind for another 10 minutes on a zone SOA seq.no. change (still ok), but it took another 50 minutes for it to pick up the TXT record change too. This coincides to the TTL on a TXT record at a time of a SOA update by ns.hyperreal.org, which may indicate that update notifications are not passed between master and a slave. Which is weird in itself, as the SOA for spamassassin.org shows that ns.hyperreal.org is the master and the other tree are slaves, not the other way around, as follows from propagation times. Strange. As the TTL on a TXT record is 3600 seconds, clients could experience up to a further hour to notice a change. A client that polls hourly but has bad luck, could just miss the event, which may suggest that we should not pick a round number for a TTL, but perhaps 50 minutes (in view of Justin's link http://www.stdlib.net/~colmmacc/2009/09/14/period-pain/ ). But the principal question here is, why it took 41 hours from SVN check-in to the first zone change. What steps are involved here? Cron job? Is a manual intervention required or is this supposed to propagate automatically? -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
