https://issues.apache.org/SpamAssassin/show_bug.cgi?id=4385
--- Comment #19 from D. Stussy <[email protected]> 2012-03-31 22:47:34 UTC --- Registrar boundries - am I drunk? Hardly. However, you're not thinking. The whole reason for pulling the zone is to learn new gTLDs. ALL GTLDs have as their registerable unit the 2LD element, so there's NO NEED to consider registrar boundaries. Only ccTLDs have those. Although this will also detect changes in ccTLDs, that's not its purpose, nor do those change with any frequency. Regardless, ccCTLD registrar boundaries cannot be determined automatically. As far as AXFR or other transfer goes, one DOES need to fetch the information somehow whenever it changes. Blindly transferring it once per day is a waste of bandwidth - as the root zone may not have changed at all. Although current root-zone policy does update the SOA serial every day, such a policy cannot be relied upon. All that matters is that when the zone data is updated, the SOA serial MUST be updated too, and that's when we need to refresh the data. So why AXFR vs. FTP or some other transfer? Because a properly set up name server will perform the transfer for us automatically and ONLY when the SOA serial changes, thus preventing blind updates to the local copy of the data (e.g. based on a cron transfer), especially those that happen when the data has NOT changed. All we then need check is the file update time of the local file the zone vs. the file update time of the file containing the processed data (as an alternative to SOA serial comparison). -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
