Live data from Hacker News

DNSGlobe – Rust TUI to watch DNS propagate around the world

github.com

21–30 of 74 posts

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

#21
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…

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.

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

#22

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 tha…

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 combination just seems to be vibe coders' favorite, for some reason.

It's the secret key to HN front page!

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

#24
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…

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)

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

#25

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 tha…

Addressed the feedback

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

#26
post #14

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 tha…

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 is…

Having created and debugged human-written code with silent bugs, vulnerabilities, or unnecessary performance issues since my first day on the job, and pointing you to myriad companies with bugs and vulnerabilities that existed pre-AI, all I can say is "plus ça change, plus c'est la même chose."

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

#28
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…

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 t…

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.

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

#29
post #10
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…

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 res…

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

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

#30
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…

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 t…

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.
Post reply on HN