I seem to recall your involvement with these unknowing, misleading people: http://www.menandmice.com/2000/2330_enterprise_bind.html. As apparent via Google search, "DNS propagation" has widely understood meanings in both public (non-authoritative) and private (authoritative) contexts.
I've had many discussions with them about their choice of words in the doc and products. Cricket Liu and I used very precise terms in the M&M DNS courses as defined in the RFCs and common DNS parlance used by DNS , and that usage and language was often not the same terminology used by M&M in their products. Programmers typically write bad docs with incorrect, vague language, and write horrible labels for their GUIs. M&M is no exception. Whatever M&M does has nothing to do with my post about "propagation".
Vis-a-vis authoritative servers, it refers to the "pull replication" of zones, taking up to one refresh interval to take effect in toto (barring use of NOTIFY).
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. And TLD servers, the ones people really mean in "DNS progation" context often don't use master/slave replication anyway.
Vis-a-vis the public Internet, it refers to the "pull replication" of records, taking up to the max TTL to take effect in toto.
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. Probably the longest TTLs are 2 days as seen in the .com and other TLD parent servers.
But the observed effect is the same--gradual replication of the most-recently-entered data.
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, when in fact:
1. the new delegation records are available instantaneously to the very next query after the records change (and can be verified as quickly with dig or nslookup).
2. the max expiration of stale (TLD delegation) records being 2 days, and
3. the average expiration of (TLD delegation records) being 1 day.
In no case does "days" or "week" of bogus "DNS propagation" apply, as seems to be the common misunderstanding.
Even if, yes, the TTL concept states that the most-recently-entered data should not be considered to "exist" in a global sense until the TTL expires
what horribly wrong consideration.
Stale records does not affect the fact that new records are valid, do very definitely "exist", and are instantaneously available at the point they are changed.
with the impression of propagation, as long as the person using the term knows what's happening under the surface.
Which is why I entered this thread, not to debate rabbinically or encyclopedically, umpteen shadings, because the most common usage of "DNS propagation" is buzzword-depth of understanding. "DNS propagation" often leads people into waiting (days or weeks) for propapation to occur, when in fact, if they would get away from that misconception of propagation, they could validate/fix their real DNS situation/problems now rather than passively waiting for/wondering about mythical "propagation".
Len
_____________________________________________________________________ http://IMGate.MEIway.com : free anti-spam gateway, runs on 1000's of sites
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/
