Live data from Hacker News

DNSGlobe – Rust TUI to watch DNS propagate around the world

github.com

61–70 of 74 posts

Re: DNSGlobe – Rust TUI to watch DNS propagate around the world

#61
post #42
post #38

Earlier quoted context omitted.

> local vs intermediary vs backbone TTLs This is an example of the myth in action. There are no such things. There is a single resolver, which you use, and a set of authoritative server, which that resolver will query when the TTL in the resolver’s cache times out. There is no chain of resolvers.

What do you call it when an application queries systemd-resolved and systemd-resolved queries PiHole and PiHole queries your home router and your home router queries your ISP? What is that if not a chain?

See this old thread: https://news.ycombinator.com/item?id=19654515>

Re: DNSGlobe – Rust TUI to watch DNS propagate around the world

#62
post #17

I like it. Tell the vibe-coder haters to take a hike. Suggestion: It would be helpful if you could sort by COLUMN or group by LOCATION. Keep on vibin'.

Thanks for the feedback!

Sort is working! Another suggestion is to allow the user to edit the DNS resolver list -- in the running program itself. An ADD/DELETE feature would be useful (to me at least).

A quick note... when I open the app I only see the left pane. I wouldn't have known there was a map had I not previously seen/read about it.

Thanks :)

Re: DNSGlobe – Rust TUI to watch DNS propagate around the world

#63
post #38

Earlier quoted context omitted.

Ehh do you remember the defaults back in the day? And how long local vs intermediary vs backbone TTLs could be cached for, even above and beyond the set TTL? The propagation part refers to how long it would take for all those cached requests to expire and when you could tell some random client they should be able to see the new value. Especially when you forgot to lower the TTL ahead of time. It’s a term of art and i…

> local vs intermediary vs backbone TTLs This is an example of the myth in action. There are no such things. There is a single resolver, which you use, and a set of authoritative server, which that resolver will query when the TTL in the resolver’s cache times out. There is no chain of resolvers.

> There is no chain of resolvers.

There absolutely can be a chain of resolvers.

It's very common to run a caching recursive resolver on client nodes that sends its requests to an external recursive resolver (usually the network owner's suggested server). Nicer local caching resolvers will recurse themselves if/when the configured forwarding destination is unavailable. Some decades ago, it wasn't unusual for ISPs to run distributed recursive caching resolvers that would go through a centralized cache ... some of those systems may still exist?

If all of those servers respect and propagate (or pass on, whatever) the authoritative TTL as I think RFCs suggest, then you should see all the caches behind a centralized resolver expire at the same time and then get refreshed on their next request. Of course, some caches don't respect TTLs and some might return the TTL they received (or modified to) in responses from cache and who knows what other garbage they do.

That's why people want to know approximately how much of the population can see my changed records. Sometimes where in the world can people see my changed records ... not because the change is organized geographically, but because showing where people see one value vs the other is more visually stimulating than a % line... and also because that one dumb ISP server that has no cache expiration is likely to cause problems for users in one geography and not worldwide, so it's handy to know that users in that country will have problems when you turn off old servers that you took out of dns weeks ago.

Maybe propagate isn't the best verb for DNS changes to make their way from your source of truth to everyone else's resolutions, but you're welcome to suggest another.

Merriam webster includes these definitions of propagate that I think fit [1]:

> (transitive verb) 3a to cause to spread out and affect a greater number or greater area

> (intransitive verb) to travel through space or a material

Maybe you don't think the first one fits because of 'cause' in there. When you start returning new results, you don't do anything specific to cause the caches to fetch a new result, but... the new results do affect a greater number of caches over time.

We could agree to use percolate though, it was suggested elsewhere in the thread and it's a fun word and easier to spell. It will take time for this change to percolate through our distributed conciousness though. :p

[1] https://www.merriam-webster.com/dictionary/propagate

Re: DNSGlobe – Rust TUI to watch DNS propagate around the world

#64
post #51

Earlier quoted context omitted.

> most hardcore programmers > Vibe-coded LOL. LMAO.

Microsoft are using Rust for Windows and Azure Google are using Rust despite having developed GO SpaceX and NASA are using Rust for critical life and death systems. Cloudflare use Rust to obtain extreme high performance. And many, many more. Stop being a pain: https://en.wikipedia.org/wiki/Straw_man

> Stop being a pain

They're always so emotional, rustaceans.

Re: DNSGlobe – Rust TUI to watch DNS propagate around the world

#65
post #62

Earlier quoted context omitted.

Thanks for the feedback!

Sort is working! Another suggestion is to allow the user to edit the DNS resolver list -- in the running program itself. An ADD/DELETE feature would be useful (to me at least). A quick note... when I open the app I only see the left pane. I wouldn't have known there was a map had I not previously seen/read about it. Thanks :)

I added the ability to specify a config file for the resolvers definition. This is not runtime, though. I will keep that in mind for another release.

Thanks for the follow-up :)

Re: DNSGlobe – Rust TUI to watch DNS propagate around the world

#66
post #63
post #38

Earlier quoted context omitted.

> local vs intermediary vs backbone TTLs This is an example of the myth in action. There are no such things. There is a single resolver, which you use, and a set of authoritative server, which that resolver will query when the TTL in the resolver’s cache times out. There is no chain of resolvers.

> There is no chain of resolvers. There absolutely can be a chain of resolvers. It's very common to run a caching recursive resolver on client nodes that sends its requests to an external recursive resolver (usually the network owner's suggested server). Nicer local caching resolvers will recurse themselves if/when the configured forwarding destination is unavailable. Some decades ago, it wasn't unusual for ISPs to r…

> There absolutely can be a chain of resolvers.

A chain of proxies does not change how we should view the situation. Proxies, by definition, should not affect anything. See this old thread: https://news.ycombinator.com/item?id=19654515>

Re: DNSGlobe – Rust TUI to watch DNS propagate around the world

#68
post #2

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…

Not to mention 8.8.8.8 queried from the UK and from the US aren't the same place....

Re: DNSGlobe – Rust TUI to watch DNS propagate around the world

#69

Earlier quoted context omitted.

DNSGlobe – Rust TUI to watch misunderstandings about DNS propagate around the world (github.com/514-labs) There I fixed it for you.

But it's written in Rust so it must be good :D

Memory safe, but idea unsafe

Re: DNSGlobe – Rust TUI to watch DNS propagate around the world

#70
post #2

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…

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.

Anycast goes BRRRRRRRRR

Just because YOU query a server, doesn't mean that a user somewhere else is querying the same server.

Post reply on HN