[HN Gopher] Days since it was DNS
___________________________________________________________________
Days since it was DNS
Author : scaglio
Score : 24 points
Date : 2024-05-18 18:56 UTC (4 hours ago)
(HTM) web link (dayssince.itwasdns.net)
(TXT) w3m dump (dayssince.itwasdns.net)
| byteknight wrote:
| Love the hard coded 0
| EricE wrote:
| Yup - nothing to compute!
| Tijdreiziger wrote:
| Now that's what I call optimization.
| Yasuraka wrote:
| It goes up whenever you can't reach it
| nevir wrote:
| I hope it's also reported as a DNS record
| zoky wrote:
| Ok, since I'm obviously not nerdy and/or cynical enough to get
| the joke, what exactly is wrong with DNS? None of the links seem
| to indicate what exactly the problem with it is.
| linuxdaemon wrote:
| As someone who administers DNS servers, I'm going to guess this
| is due to DNS being the first thing that gets blamed when
| something goes wrong; and it is almost never DNS.
| EricE wrote:
| Ha!
|
| https://9gag.com/gag/avOj8WE
| scaglio wrote:
| That's the point, but _often_ in many network issues, the
| name resolution is the root cause of the problem. Not
| necessarily the DNS itself. Sometimes the /etc/hosts is more
| than enough to cause headaches!
| EricE wrote:
| It's not DNS. There's no way it's DNS. It was DNS.
|
| https://medium.com/adevinta-tech-blog/its-not-always-dns-unl...
| dang wrote:
| Discussed here:
|
| _It 's not always DNS, unless it is_ -
| https://news.ycombinator.com/item?id=38719126 - Dec 2023 (73
| comments)
| erikw wrote:
| A DNS misconfiguration is often the root cause of an issue.
| Hence the saying "it's always DNS".
| cwicklein wrote:
| I think it's implied that it's been zero days since the
| underlying cause of some such problem turned out to be DNS
| related. The number zero being hard coded implies that the root
| of the problem is always DNS. But, let's give MTU its due.
| fffrantz wrote:
| Lately, MTU has gotten up my list of things to check when
| stuff goes down.
|
| It seems carriers can't get their MTUs straight as of late,
| especially on MPLS links...
|
| I really thought we had this figured out 20 years ago...
| dervjd wrote:
| "It's always DNS" is basically tongue-in-cheek expression,
| because DNS issues are so frequently the cause of weird
| outages.
|
| Almost anything you do on the internet (or local network)
| depends on DNS functioning correctly. DNS can get complex
| quickly - multiple servers (caching/authoritative/recursive)
| and protocols = lots of opportunities for something to be
| misconfigured. Cached entries in particular can be a nightmare
| if something gets outdated - it takes time for an update to a
| DNS record to propagate to all the other DNS servers on the
| Internet. All kinds of other random services etc depend on DNS
| records being correct and DNS working. When there's an issue
| it's not always immediately apparent that a DNS problem is the
| root cause, leading to lots of time chasing your tail/tearing
| your hair out trying to figure out what the heck broke.
| justsomehnguy wrote:
| Two days ago one (!) User reported they got
| \\\contso.com\dfsroot\profiles\user inaccessible (with errors
| loading the desktop etc).
|
| For me the path was accessible, logging on _the same server_
| proved the path was accessible, 3 hours of the proper
| troubleshooting confirmed everything should work. But yet.
|
| Skipping short the circumstances, one of (the 6 total) DCs
| decided what... DNS server isn't worth running. And for this
| one user DFS (last changed _at least_ two years ago) decided to
| fall back to the file server from 2018, which, of course,
| pointed the DFS target to a no longer existant share.
|
| Of course it wasn't DNS in this case. It was the DNS in this
| one.
| xyst wrote:
| I was setting up my own mail server the other day and re-realized
| how long global DNS propagation really takes.
|
| I'm in the US so it was almost instantaneous between updating the
| dns records in domain register any being able to verify the
| changes with my own rDNS server.
|
| But using a UK or NL dns server didn't immediately pick up those
| recent changes.
|
| Had to wait an additional 48 hrs for global dns propagation.
| bluejekyll wrote:
| This is surprising. What was the TLD for your name? And can you
| share your SOA config for your zone? (don't need the names, I'm
| curious about the TTLs in all the SOA fields)
| xyst wrote:
| tld is .dev
|
| localhost:~# dig dev soa ... ; <<>> DiG 9.16.39 <<>> dev soa
| ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<-
| opcode: QUERY, status: NOERROR, id: 65000 ;; flags: qr rd ra;
| QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
|
| ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;;
| QUESTION SECTION: ;dev. IN SOA
|
| ;; ANSWER SECTION: dev. 299 IN SOA ns-
| tld1.charlestonroadregistry.com. cloud-dns-
| hostmaster.google.com. 1 21600 3600 259200 300
|
| This is the soa config?
|
| > SOA ns-tld1.charlestonroadregistry.com. cloud-dns-
| hostmaster.google.com. 1 21600 3600 259200 300
| toast0 wrote:
| Most TLDs serve glue records with 1-3 day ttls. It's not
| surprising to me that some servers had the old glue cached
| (well, I'm assuming they've got traffic... I would be
| surprised if my domains' glue were cached anywhere of note)
|
| _If_ you can configure your old nameservers to serve the new
| NS records, sometimes that 's helpful.
| fanf2 wrote:
| A change to a record in your zone should propagate to all your
| authoritative servers within a few seconds, using the DNS
| NOTIFY feature. If it doesn't, that's a bug in your provider's
| setup.
|
| Caches rely on the TTL of records in your zone, or the SOA
| negative TTL field for negative answers. You control these
| TTLs, so don't set them to 48 hours. In most cases there's
| little benefit to having TTLs longer than 1 hour. (I use 24
| hours for TTLs on NS records and nameserver addresses, because
| they tend to be more stable, and it's good for tail latency to
| keep them in caches longer.)
| xyst wrote:
| By "zone", is this regional? It was for a .dev tld. So that
| makes sense as to why I (someone in US) was able to see
| changes immediately.
| silisili wrote:
| No, zone in DNS parlance basically means your domain name
| (and its records).
| gumby wrote:
| > Caches rely on the TTL of records in your zone, or the SOA
| negative TTL field for negative answers.
|
| Sadly the word "should" ought to have appeared in your
| sentence.
|
| A lot of resolvers ignore the TTL, either because of the
| number of misconfigured TTL entries (too short), because they
| resolve a _LOT_ of names and figure they can 't afford to
| keep looking up certain names, or out of sheer orneryness.
|
| I don't update frequently so when I do plan to make updates I
| adjust my TTL to a short period, wait a few days, then make
| the updates, then after a week turn the TTL way up again.
| I've noticed that this is pointless with some big sites.
| geerlingguy wrote:
| This would pair up well with my favorite t-shirt ;)
| gmuslera wrote:
| NTP, BGP, MTU and a lot of other acronyms should be also in the
| list of not trivial to trace root cause for things that goes from
| big outages to mysterious malfunctions, specially if there are
| many parties or servers involved. And the security protocols that
| are above those and more (DNSSEC, SSL, etc).
| xist wrote:
| When will this tired meme be retired?
|
| There's almost 300 RFCs related to DNS. It can do many things,
| and some of them are complex. But human error is almost always
| the root cause.
|
| Your inability to configure DNS properly speaks more about you,
| then the service itself.
___________________________________________________________________
(page generated 2024-05-18 23:02 UTC)