Discussion summary

DNSGlobe is a Rust-based terminal tool for monitoring DNS propagation worldwide, receiving mixed but generally positive feedback. Users appreciate its functionality and the Rust ecosystem's focus on terminal apps.

What the discussion says

  • Many users like the tool and its utility for DNS monitoring.
  • Some suggest adding features like sorting by columns or grouping by location.

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • 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!
  • Released a new version with the suggestion ;)
  • Not sure of why everyone is negative against this tool?

    I quite like it. Thanks for sharing!

  • I like it too. I'll almost certainly get a lot of use out of this and not once will I ever get upset that it uses the word propagation.
  • Rust terminal apps are the bees knees right now
  • It reminds me of https://globalping.io/
  • What's with the rust community and terminals? I get that gui's are tedious in those languages, but surely you don't have to write everything in rust? Or has rust become the be-all-and-end-all for them?
  • They are more easily sloppable.
  • You can do GUI/web easily enough in Rust, but as this is DNS and so most users will be network/sysadmin types, their natural habitat is the terminal.

    Rust is taking over from C/C++ (as per US Government guidance on using more secure languages) and so is attracting the most hardcore programmers.

    Libraries for everything: https://crates.io

    p.s. stop being so grumpy!

  • 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/>
  • It's called DNSGlobe but it does not feature a globe, only a map :(
  • ha that could be less handy but cooler
  • Done
  • 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.

  • Addressed the feedback
  • Nothing wrong with vibecoding a toy project.
  • The very first thing written about this tool is the programming language it's written in.

    Like, when I'm querying a bunch of DNS servers, it is crucial for me to know which compilable language it was written in. Like, the most important thing.

  • 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.

  • Quite mixed on this one given that the author has experience with Rust before coding agents and this is just his toy project.

    There is going to be a time where these vibe coded projects have silent bugs, vulnerabilities or unnecessary performance issues and the AI coding agent just lies to the user that it has none.

    The AI agent will be the one to introduce new issues in the codebase regardless of "tests". The new issue is now the non-technical human vibe-coding is none the wiser.

    We have already seen this in Codex itself. Imagine this propagated in many other code-bases.

    by rvz
  • 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.

  • Not to mention 8.8.8.8 queried from the UK and from the US aren't the same place....
  • There is no such myth that I'd be aware of, and I seriously doubt the author behind this would be operating under such a misunderstanding either. Maybe you used to at some point, but then that's a separate issue.

    Propagation is just an incremental spread across a topology. Doesn't need to be a physical topology whatsoever.

    It may seem like this program suggests a physical propagation as far as its elevator pitch goes, but one glance at the readme clears it up pretty quickly that that's not actually the case.

    Changes do propagate, and seeing funny blinking lights on a world map is cool. Doesn't mean there'd be an intent to convey the process as a geographical spread.

  • Thank you. I have this discussion all the time. The argument I get back "Right, but it seems like the change takes awhile because of the DNS cache expiring, so it's the same as propagating". My counter to that is to say "If I punch you in the mouth, would you just tell people I'd asked you be to be quiet, or would you use the right explanation as to what'd happened?"

    (It's a stupid counterargument, btw, but it ends the discussion)

  • 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.

  • > The old cached DNS entries in DNS resolvers simply expire, in an arbitrary order.

    I really wish that was so. There's lots of weird resolvers out there used by weird ISPs that don't properly respect the TTL value. Setting TTL to some really low number a full day before making a major change is no guarantee that your zone will expire in a bunch of places. All kinds of weird ISPs try to do things with the dns results they present to their customers.

  • > The myth of DNS “propagation” needs to die.

    What's the actual issue? Are you being frustrated by people laboring under the assumption that DNS records are being sent by carrier pidgeon or something?

    > There is no geographical connection whatsoever.

    DNS censorship will presumably be based on geopolitical boundaries, which in turn are bound by geography. And I wouldn't be entirely suprised if poor network connections - including those potentially geographically bound (poor weather / flooding / tornados severing or degrading links or power) had some (minor, infrequent) impact on the rate stale cache entries are evicted in favor of fresh ones.

    Granted, none of that means a DNS resolver halfway across the globe from the authoritative servers can't typically get updated results <200ms (≈light speed), which is safely ignorable / won't be visible as records propagating from geographic neighbor to geographic neighbor. And granted further, I'm both too boring to censor, and too smart to be on call for anything that would make me aware of global outage reports - so the map is admittedly useless to me beyond farming that hacker vibe aura.

    But I imagine there's at least one or two dudes out there that'll see a red dot in, say, Australia - and that'll save them a few minutes, by giving them a shortcut to determining the root cause of some issue reported in Australia by letting them correctly guess/blame stale DNS records.

  • 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?