The myth of DNS “propagation” needs to die. Changed DNS entries do not “propagate”. The old cached DNS entries in DNS resolvers simply expire, in an arbitrary order. DNS resolvers are not linked geographically; there is no “propagation”.
If this tool was querying a list of widely-used public (and/or private) DNS resolvers, it might be useful. But pretending that DNS entries propagate geographically does not do anyone any favors.
a) different DNS systems get the change out to all the authoritatives different ways. Some of them with much delay. Delays are hopefully minimal on modern systems, but I've worked with bad systems where you change dns in the api and it takes minutes and sometimes hours for the authoritatives to start returning new results; traditional notify/axfr based systems often have a queue of several seconds at least.
b) as resolver caches expire, new queries will hopefully get new answers (as long as the authoritatives get updated per a), and eventually you get the new results everywhere except for resolvers that do terrible things...
When the change is made and it takes time for the results to show up everywhere, I think propagate is a reasonable verb. You could use disperse or diffuse or something else, but you need a verb to let people know it's going to take time for your changes to be visible everywhere.
I don't know that propagate necessary implies the change becomes visible in an orderly way. 'Around the globe' doesn't really either, it's just observing from around the globe as resolvers get new data.
What verb do you prefer to use to describe how unsychronized caches obtain new values?
That's what the tool is doing - querying a bunch of public resolvers around the world to see the state of what they resolve to. Since end users usually use DNS servers close to their location, this gives an idea, around the world, of who sees what.
Agreed, this is a cache that expires and refreshes from the source DNS server. It just looks like a virus that propagates when the cache expires.
> It just looks like a virus that propagates when the cache expires.
No it does not. The changes do not happen geographically. There is no geographical connection whatsoever. Calling the tool “DNSGlobe”, and displaying a map, only further reinforces the myth.
You take the `other`, do a `to_string()` on it, which creates a String representation. Then you pass a reference to that String, and, in the case it doesn't contain `time out` or `timeout` or `refused`, the reference gets turned AGAIN into a String (i.e. new allocation), truncated to 48, and then returned.
There is no check whether that the character at the 48th byte is a character boundary.
Add to that the fact that this is a Rust project with the oldest commit created yesterday and it is using the 2021 edition.
It's gotten to the point that the moment I see "Rust" and "TUI" together, I immediately assume it's vibe coded. The combination just seems to be vibe coders' favorite, for some reason.
The myth of DNS “propagation” needs to die. Changed DNS entries do not “propagate”. The old cached DNS entries in DNS resolvers simply expire, in an arbitrary order. DNS resolvers are not linked geographically; there is no “propagation”.
If this tool was querying a list of widely-used public (and/or private) DNS resolvers, it might be useful. But pretending that DNS entries propagate geographically does not do anyone any favors.
a) different DNS systems get the change out to all the authoritatives different ways. Some of them with much delay. Delays are hopefully minimal on modern systems, but I've worked with bad systems where you change dns in the api and it takes minutes and sometimes hours for the authoritatives to start returning new results; traditional notify/axfr based systems often have a queue of several seconds at least.
b) as resolver caches expire, new queries will hopefully get new answers (as long as the authoritatives get updated per a), and eventually you get the new results everywhere except for resolvers that do terrible things...
When the change is made and it takes time for the results to show up everywhere, I think propagate is a reasonable verb. You could use disperse or diffuse or something else, but you need a verb to let people know it's going to take time for your changes to be visible everywhere.
I don't know that propagate necessary implies the change becomes visible in an orderly way. 'Around the globe' doesn't really either, it's just observing from around the globe as resolvers get new data.
What verb do you prefer to use to describe how unsychronized caches obtain new values?
That's what the tool is doing - querying a bunch of public resolvers around the world to see the state of what they resolve to. Since end users usually use DNS servers close to their location, this gives an idea, around the world, of who sees what.
Agreed, this is a cache that expires and refreshes from the source DNS server. It just looks like a virus that propagates when the cache expires.
> It just looks like a virus that propagates when the cache expires.
No it does not. The changes do not happen geographically. There is no geographical connection whatsoever. Calling the tool “DNSGlobe”, and displaying a map, only further reinforces the myth.
Vibe-coded. Sorry.
https://github.com/514-labs/dnsglobe/blob/c29802162636832e88...
You take the `other`, do a `to_string()` on it, which creates a String representation. Then you pass a reference to that String, and, in the case it doesn't contain `time out` or `timeout` or `refused`, the reference gets turned AGAIN into a String (i.e. new allocation), truncated to 48, and then returned.
There is no check whether that the character at the 48th byte is a character boundary.
Add to that the fact that this is a Rust project with the oldest commit created yesterday and it is using the 2021 edition.
Be better.
It's gotten to the point that the moment I see "Rust" and "TUI" together, I immediately assume it's vibe coded. The combination just seems to be vibe coders' favorite, for some reason.
This was 100% vibe-coded with Claude Code and Fable.
https://x.com/thatsFrScience/status/2073741209592295866
Thanks for the feedback, though, and for taking the time to look at the code. I can ship a round of cleanup.
Aren’t there websites already that check global DNS servers to check TTL expiry of DNS records?
There are many; I often use <https://dnschecker.org/>
Yeah, I used to use https://www.whatsmydns.net/. I wanted it in the terminal without ads.