5 ms·

DNSGlobe – Rust TUI to watch DNS propagate around the world

83 points by Callicles 3mo ago

teddyh 3mo ago
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.
- Callicles 3mo ago
  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.
  - teddyh 3mo ago
    > 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.
    - Terretta 3mo ago
      dnspatter (dns spatter + dns patter)
  - marysol5 3mo ago
    Anycast goes BRRRRRRRRR Just because YOU query a server, doesn't mean that a user somewhere else is querying the same server.
- toast0 3mo ago
  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?
  - c22 3mo ago
    Percolate?
  - timwis 3mo ago
    My interpretation of the concern is that propagate implies that the new value is being pushed out to other resolvers, when in fact those other resolvers pull the new value (once their cached value expires).
  - jon-wood 3mo ago
    > Delays are hopefully minimal on modern systems The delays are almost always self inflicted by people who've blindly put 36400 in the TTL field like some sort of magic charm rather than considering how long they want the cache expiry to be. Long ago I was one of them and then I had the company greybeard point out that DNS record updates are a thing we had control over - just drop the TTL to 30 seconds or whatever a day before a planned change of servers and (barring the odd stubborn resolver which thinks it knows better than you do) the time it takes for those caches to refresh goes from 24 hours to 30 seconds.
- deleted 3mo ago
  [deleted]
- perching_aix 3mo ago
  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.
- MaulingMonkey 3mo ago
  > 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.
  - AndyMcConachie 3mo ago
    >> 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? The actual issue is that some people misunderstand how DNS works, and the notion that records propagate doesn't help people understand it better. It propagates a misunderstanding of DNS.
    - phikappa 3mo ago
      DNSGlobe – Rust TUI to watch misunderstandings about DNS propagate around the world (github.com/514-labs) There I fixed it for you.
      - josteink 3mo ago
- browningstreet 3mo ago
  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 it’s fine. Oh that reminds me. I made a bunch of DNS changes a while ago and left all the TTLs set to 5 minutes. I should up them.
  - teddyh 3mo ago
    > 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.
    - inigyou 3mo ago
      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?
      - JdeBP 3mo ago
        Forwarding proxy DNS servers leading to a (yes) single resolving proxy DNS server at the end. * https://jdebp.uk/FGA/dns-server-roles.html https://jdebp.uk/FGA/dns-server-roles.html
      - teddyh 3mo ago
        See this old thread: <https://news.ycombinator.com/item?id=19654515 https://news.ycombinator.com/item?id=19654515>
    - toast0 3mo ago
      > 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 https://www.merriam-webster.com/dictionary/propagate
- muppetman 3mo ago
  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)
  - tgv 3mo ago
    But is there a functional difference between push and pull in this case? Is there something that cannot be explained in terms of propagation? Perhaps timing: there's no reason for propagation to wait an hour or a day. BTW, only last week I explained a potential problem of a DNS change with caching, and it was understood. There doesn't seem to be a need to simplify it.
    - jon-wood 3mo ago
      There is absolutely a reason for propagation to wait an hour or a day, and you've set that value in the TTL field for the record in question. It stands for Time To Live and specifies how long downstream resolvers should cache the last value they saw before querying the authoritative server again, if you set that value to a few seconds then almost every DNS resolver in the world will get updated values within a few seconds as they expire the cached value.
      - tgv 3mo ago
        The discussion was about caching vs propagation. You're already mixing them.
  - timwis 3mo ago
    Just FYI, those discussions might be ending because your analogy comes across as a threat to punch them in the mouth, rather than because it convinces them.
- walrus01 3mo ago
  > 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.
  - teddyh 3mo ago
    It’s still arbitrary, with no geographical (or other) form of propagation.
- marysol5 3mo ago
  Not to mention 8.8.8.8 queried from the UK and from the US aren't the same place....
robohoe 3mo ago
Aren’t there websites already that check global DNS servers to check TTL expiry of DNS records?
- teddyh 3mo ago
  There are many; I often use <https://dnschecker.org/ https://dnschecker.org/>
  - Callicles 3mo ago
    Yeah, I used to use https://www.whatsmydns.net/ https://www.whatsmydns.net/. I wanted it in the terminal without ads.
OptionOfT 3mo ago
Vibe-coded. Sorry. https://github.com/514-labs/dnsglobe/blob/c29802162636832e88b56bbb205e6c773c254e5b/src/dns.rs#L69 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.
- Callicles 3mo ago
  This was 100% vibe-coded with Claude Code and Fable. https://x.com/thatsFrScience/status/2073741209592295866 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.
- orangeboats 3mo ago
  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.
  - zx8080 3mo ago
    > The combination just seems to be vibe coders' favorite, for some reason. It's the secret key to HN front page!
  - blacklite 3mo ago
    That's not whose favorite it is; it's the favorite of who's doing the work. :)
  - inigyou 3mo ago
    It must be because if you program in Rust, you don't have bugs ;)
krypd0h 3mo ago
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'.
- Callicles 3mo ago
  Thanks for the feedback!
  - krypdoh 3mo ago
    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 :)
    - Callicles 3mo ago
      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 :)
    - Callicles 3mo ago
      I added runtime by adding a resolver and removing it. I also made the map responsive.
- Callicles 3mo ago
  Released a new version with the suggestion ;)
LouisvilleGeek 3mo ago
Not sure of why everyone is negative against this tool? I quite like it. Thanks for sharing!
- drcongo 3mo ago
  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.
throwitaway222 3mo ago
Rust terminal apps are the bees knees right now
panki27 3mo ago
It's called DNSGlobe but it does not feature a globe, only a map :(
- Callicles 3mo ago
  ha that could be less handy but cooler
- Callicles 3mo ago
  Done
Flaapjan 3mo ago
[dead]
bcjdjsndon 3mo ago
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?
- khurs 3mo ago
  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 https://crates.io p.s. stop being so grumpy!
  - oksurerly 3mo ago
    > most hardcore programmers > Vibe-coded LOL. LMAO.
    - khurs 3mo ago
      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 https://en.wikipedia.org/wiki/Straw_man
      - bcjdjsndon 3mo ago
        > Stop being a pain They're always so emotional, rustaceans.
  - bcjdjsndon 3mo ago
    > so most users will be network/sysadmin types, their natural habitat is the terminal. But we've moved beyond learning commands like a programmer just to operate a program.... Have some respect or at least sympathy for your users
matteogauthier 3mo ago
It reminds me of https://globalping.io/ https://globalping.io/
deleted 3mo ago
[deleted]

83 points by Callicles 3mo ago

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.

Callicles 3mo ago
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.
- teddyh 3mo ago
  > 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.
  - Terretta 3mo ago
    dnspatter (dns spatter + dns patter)
- marysol5 3mo ago
  Anycast goes BRRRRRRRRR Just because YOU query a server, doesn't mean that a user somewhere else is querying the same server.
toast0 3mo ago
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?
- c22 3mo ago
  Percolate?
- timwis 3mo ago
  My interpretation of the concern is that propagate implies that the new value is being pushed out to other resolvers, when in fact those other resolvers pull the new value (once their cached value expires).
- jon-wood 3mo ago
  > Delays are hopefully minimal on modern systems The delays are almost always self inflicted by people who've blindly put 36400 in the TTL field like some sort of magic charm rather than considering how long they want the cache expiry to be. Long ago I was one of them and then I had the company greybeard point out that DNS record updates are a thing we had control over - just drop the TTL to 30 seconds or whatever a day before a planned change of servers and (barring the odd stubborn resolver which thinks it knows better than you do) the time it takes for those caches to refresh goes from 24 hours to 30 seconds.
deleted 3mo ago
[deleted]
perching_aix 3mo ago
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.
MaulingMonkey 3mo ago
> 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.
- AndyMcConachie 3mo ago
  >> 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? The actual issue is that some people misunderstand how DNS works, and the notion that records propagate doesn't help people understand it better. It propagates a misunderstanding of DNS.
  - phikappa 3mo ago
    DNSGlobe – Rust TUI to watch misunderstandings about DNS propagate around the world (github.com/514-labs) There I fixed it for you.
    - josteink 3mo ago
browningstreet 3mo ago
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 it’s fine. Oh that reminds me. I made a bunch of DNS changes a while ago and left all the TTLs set to 5 minutes. I should up them.
- teddyh 3mo ago
  > 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.
  - inigyou 3mo ago
    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?
    - JdeBP 3mo ago
      Forwarding proxy DNS servers leading to a (yes) single resolving proxy DNS server at the end. * https://jdebp.uk/FGA/dns-server-roles.html https://jdebp.uk/FGA/dns-server-roles.html
    - teddyh 3mo ago
      See this old thread: <https://news.ycombinator.com/item?id=19654515 https://news.ycombinator.com/item?id=19654515>
  - toast0 3mo ago
    > 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 https://www.merriam-webster.com/dictionary/propagate
muppetman 3mo ago
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)
- tgv 3mo ago
  But is there a functional difference between push and pull in this case? Is there something that cannot be explained in terms of propagation? Perhaps timing: there's no reason for propagation to wait an hour or a day. BTW, only last week I explained a potential problem of a DNS change with caching, and it was understood. There doesn't seem to be a need to simplify it.
  - jon-wood 3mo ago
    There is absolutely a reason for propagation to wait an hour or a day, and you've set that value in the TTL field for the record in question. It stands for Time To Live and specifies how long downstream resolvers should cache the last value they saw before querying the authoritative server again, if you set that value to a few seconds then almost every DNS resolver in the world will get updated values within a few seconds as they expire the cached value.
    - tgv 3mo ago
      The discussion was about caching vs propagation. You're already mixing them.
- timwis 3mo ago
  Just FYI, those discussions might be ending because your analogy comes across as a threat to punch them in the mouth, rather than because it convinces them.
walrus01 3mo ago
> 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.
- teddyh 3mo ago
  It’s still arbitrary, with no geographical (or other) form of propagation.
marysol5 3mo ago
Not to mention 8.8.8.8 queried from the UK and from the US aren't the same place....

robohoe 3mo ago

Aren’t there websites already that check global DNS servers to check TTL expiry of DNS records?

teddyh 3mo ago
There are many; I often use <https://dnschecker.org/ https://dnschecker.org/>
- Callicles 3mo ago
  Yeah, I used to use https://www.whatsmydns.net/ https://www.whatsmydns.net/. I wanted it in the terminal without ads.

OptionOfT 3mo ago

Vibe-coded. Sorry. https://github.com/514-labs/dnsglobe/blob/c29802162636832e88b56bbb205e6c773c254e5b/src/dns.rs#L69 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.

Callicles 3mo ago
This was 100% vibe-coded with Claude Code and Fable. https://x.com/thatsFrScience/status/2073741209592295866 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.
orangeboats 3mo ago
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.
- zx8080 3mo ago
  > The combination just seems to be vibe coders' favorite, for some reason. It's the secret key to HN front page!
- blacklite 3mo ago
  That's not whose favorite it is; it's the favorite of who's doing the work. :)
- inigyou 3mo ago
  It must be because if you program in Rust, you don't have bugs ;)

krypd0h 3mo ago

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

Callicles 3mo ago
Thanks for the feedback!
- krypdoh 3mo ago
  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 :)
  - Callicles 3mo ago
    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 :)
  - Callicles 3mo ago
    I added runtime by adding a resolver and removing it. I also made the map responsive.
Callicles 3mo ago
Released a new version with the suggestion ;)

LouisvilleGeek 3mo ago

Not sure of why everyone is negative against this tool? I quite like it. Thanks for sharing!

drcongo 3mo ago
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.

throwitaway222 3mo ago

Rust terminal apps are the bees knees right now

panki27 3mo ago

It's called DNSGlobe but it does not feature a globe, only a map :(

Callicles 3mo ago
ha that could be less handy but cooler
Callicles 3mo ago
Done

Flaapjan 3mo ago

[dead]

bcjdjsndon 3mo ago

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?

khurs 3mo ago
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 https://crates.io p.s. stop being so grumpy!
- oksurerly 3mo ago
  > most hardcore programmers > Vibe-coded LOL. LMAO.
  - khurs 3mo ago
    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 https://en.wikipedia.org/wiki/Straw_man
    - bcjdjsndon 3mo ago
      > Stop being a pain They're always so emotional, rustaceans.
- bcjdjsndon 3mo ago
  > so most users will be network/sysadmin types, their natural habitat is the terminal. But we've moved beyond learning commands like a programmer just to operate a program.... Have some respect or at least sympathy for your users

matteogauthier 3mo ago

It reminds me of https://globalping.io/ https://globalping.io/

deleted 3mo ago

[deleted]