"DNS propagation" is a really bad term that could conceivably cover two distinct things:<p>1. The "propagation" of fresh records from a domain's authoritative name servers to users' caching recursive name servers.<p>2. The "propagation" of updated zone information from a domain's master authoritative server to the domain's slave authoritative servers.<p>This tool attempts to check for #1, but no tool can actually check for this. For one thing, it's not really propagation; it's caching. If you query a caching name server and the name is not yet cached, you'll get fresh information immediately. If it is already cached, you'll get stale information until the cache entry expires. There are an untold number of caching name servers out there (you'll find them at every ISP, every company, and even in some home routers). If you look at the list of name servers this tool queries, you'll find only a small slice of the Internet's caching name servers[1]. If none of these servers have your name cached when you run the tool, they will all return fresh information, and the tool will report that your DNS update has "propagated" when in reality there are many caching name servers out there at other ISPs which still have stale information cached.<p>Fortunately, there's a better way to know when your change has "propagated" - look up the record's TTL, which is the maximum number of seconds it can remain cached. Until that amount of time elapses from your update, there are potentially name servers out there serving up stale information.<p>Now, a tool to check for #2 would actually be quite useful. Transfers from master to slave are supposed to happen immediately, and you shouldn't have to worry about this if your domain uses a good DNS service, but I've seen many misconfigured or over-complicated DNS setups where this doesn't happen reliably. A tool that queried all the authoritative servers for a domain to see which ones haven't updated would be quite useful for debugging these sorts of misconfigurations.<p>[1] Specifically, those which are misconfigured to allow queries from anyone. Wide open name servers like these can be used as part of DOS attacks. In a perfect world, the only caching name servers you'd be able to query would be the ones operated by your ISP, and public ones which have anti-DOS features, like Google Public DNS.
YES!<p>Thankyou, thankyou, thankyou.<p>It's a pain to rely on a bunch of different services to see if the DNS record has updated, so happy that this now exists.
Awesome tool Sam! You may want to consider having the code pull a gzip'd version of resolver-list.yml to speed things up. It's 240K uncompressed, but only ~49K compressed. And even perhaps having setup.py grab the resolver list at install instead of first run.<p>EDIT: You're right regarding Github serving it gzipped. You can disregard my comment on that; I was using wget for testing without specifying --header='Accept-Encoding: gzip'.
This is a similar service, but will check your actual domain resolution as seen by hosts that never heard of the domain before: <a href="http://dns.squish.net/" rel="nofollow">http://dns.squish.net/</a><p>It will not tell you anything about the caching servers of course. As agwa says - you're only guaranteed (+/- client issues) that the new entry will be visible after the full TTL period.
This looks pretty cool, waiting for DNS to propagate is a PITA and should help mitigate those "works for me" scenarios relating to out-of-date nameservers.
it would be nice if this was hosted on a server<p>I tried to do something similar but far more basic with<p><a href="http://domain2ip.net" rel="nofollow">http://domain2ip.net</a><p>But something like yours would be nicer.