Live data from Hacker News

Days since it was DNS

dayssince.itwasdns.net

31–38 of 38 posts

Re: Days since it was DNS

#31

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

Shit can and must be troubleshooted with domain-specific tools.

DNS: I do have an ongoing problem specific to Unbound where it refuses to serve some entries in a transparent zone of DHCP-registered addresses that have written to config files properly but it insists on refusing to resolve certain hosts nondeterministically. But that's the only problem I have had in a long while because mostly infrastructure works out of necessity and scale.

Re: Days since it was DNS

#32

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

I'd been meaning to/thinking about setting up a page for BGP, so here we go: https://itlookedlike.itwasdns.net/but-it-was-bgp/

Re: Days since it was DNS

#33
post #4

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.

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

DFS-N != DNS

a.) lack of monitoring for running services b.) cruft/old configurations

Re: Days since it was DNS

#34
post #10

Earlier quoted context omitted.

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.

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!

I've certainly added a hostname to an /etc/hosts file for testing and forgotten.

Nothing makes sense, where is this address coming from? Oh. It was me. I put it there.

Re: Days since it was DNS

#35
post #25

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.

[deleted]

Re: Days since it was DNS

#36
post #33

Earlier quoted context omitted.

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

DFS-N != DNS a.) lack of monitoring for running services b.) cruft/old configurations

It was inavailable DNS server which triggered changing to an old DFS-N server. People on the same RDS server were working fine and did for literally years.

Re: Days since it was DNS

#37
post #26
post #21

Earlier quoted context omitted.

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…

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

The reason I set my TTLs to 1 hour is to avoid the faff with preparing for a change by fiddling with TTLs. It’s much easier to have a moderate TTL that’s OK for normal use, and not too long to make changes painful.
Post reply on HN