> Whatever M&M does has nothing to do with my post about > "propagation".
Your world-renowned, subject-matter-expert employer uses the term you decry as the choice of "unknowing, misleading people." If you can't stop them from using it, you obviously can't expect less expert people to stop using it. > Master/slave zone replication, whether intra or internet, is > typically accomplished within seconds via NOTIFY. It's very > definitely not the multi-day "propagation delay" that non-DNS people > seem to imagine is the cause of their internet DNS questions or > problems. Your presentation of how "propagation" is used in common parlance is incomplete. It is widely used to describe replication delays for both zone transfers and cached records. We hear it used equally in reference to A, MX, and NS records. You can verify this simply via Google. > With TTLs in general tending to be regrettably smaller and smaller > (to the point of being so short that some NSs ignore the record's > TTL field and add their own, longer TTL), the expiry of stale > records from cache is less of a problem. "Less of a problem" as time goes by does not mean that cached stale RRs are not (a) still common causes of confusion, and (b) what providers explicitly refer to when they speak of propagation delays. > Probably the longest TTLs are 2 days as seen in the .com and other > TLD parent servers. And it's that 2-day period that's validly pointed out by providers cautioning their customers, in addition to another 1-day or half-day pad for reboots in many cases, when they speak of "propagation." Should there instead be no warning, or maybe a fraudulent claim to provide instantaneous global changes? Remember, not everyone gets paid by the hour to answer people's stupid support questions. > Expiry of stale records from cache is unavoidable. The way "DNS > propagation" is often used is that the changes in delegation records > will require several days to become effective... That's one way. It is one of two ways. Google for a couple of minutes and you will see the reality of the term's usage "in the wild." There is no way that one can claim that replication delays are not vastly common causes of DNS non-problems (i.e. behavior expected by experts--but that still causes confusion to those _not_ expecting it). Since they are hands-off in nature, it can be convenient for experts (or those posed as such) to scapegoat replication delays to avoid dealing with what are real configuration issues. This does not change the validity of having user-friendly names for expected behavior. Pretending that replication delays/propagation will never be "felt" by non-DNS admins or end users is ridiculous. --Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] SpamAssassin plugs into Declude! http://www.mailmage.com/products/software/freeutils/SPAMC32/download/release/ Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail Aliases! http://www.mailmage.com/products/software/freeutils/exchange2aliases/download/release/ http://www.mailmage.com/products/software/freeutils/ldap2aliases/download/release/ To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
