161–170 of 261 posts
I don't agree with this article. I think DNS is something few people take the time to learn, but it's not actually hard to learn. One of the great things about DNS is that the system itself will tell you about it's internal state in response to queries. It's very easy to inspect a DNS server for a known zone and understand how it works, and there's very good tooling that's free and widely available to do this (like d…
Earlier quoted context omitted.
Can you help me find the mistake in my zone file? $ORIGIN example.net. $TTL 900 @ IN SOA ns1.example.com. hostmaster@example.com. ( 20230728001 1800 300 3600 172800 ) @ IN NS 8.8.8.8. @ IN NS 8.8.4.4. @ IN CNAME example.com. @ IN MX 10 172.253.124.27 www IN CNAME example.com
Also the CNAME if you have a cname you don't want any other records with the same name. It ends up being a confusing and ambiguous situation to be if. You are supposed to use the cname to jump the the actual record. but now there is also a MX record here are we supposed to do anything with it?
It’s not. It’s one of the few things that hasn’t changed much and it’s operation is fairly straightforward. dig is a little confusing. It’s more capable but less straightforward than good old nslookup (which still works fine BTW). I think partly DNS and the core protocols may seem confusing to younger people in the industry because so much stuff “just works” now. For example, today wifi routers “just work” right out…
Is configuring BIND hard just because it's got an obtuse zone and configuration format? Or because there are a lot of DNS-server-level decisions that need to be made?
Because the only three hard problems in computer science are cache invalidation and naming things. And DNS is a caching system for names of things. https://reddit.com/comments/15c2ul2/comment/jtty9dy
It's globally-curated (IANA), hierarchical, federated, easy to modify.
Earlier quoted context omitted.
Ah another one of those "dese damn kids and millennials I tell ya hwat, back in my grandpappys days we used to mine our own copper before laying them lines!"
The "get off my lawn" vibe was totally intended. Doesn't change the fact that there are a bunch of "AWS architects" out there running Terraform and building future disasters because they don't properly understand the infrastructure that the whole thing sits upon. It's just like the morons who think that dynamic linking should be abolished for everyone, because they don't understand the use cases for distributors from…
Back in my day we had two servers handle more requests than your 1000 nodes.
I don't agree with this article. I think DNS is something few people take the time to learn, but it's not actually hard to learn. One of the great things about DNS is that the system itself will tell you about it's internal state in response to queries. It's very easy to inspect a DNS server for a known zone and understand how it works, and there's very good tooling that's free and widely available to do this (like d…
Hello! I wrote this post and I have a couple of things to say about this "DNS is not actually hard" take. It took me many years to feel totally comfortable debugging DNS problems, and I wrote this post to explain why I think it was hard for me. I also used to think that "no, actually, it's easy!" was an encouraging response to "this is hard to learn". And I kind of get it! I love DNS! I think it is surprisingly simpl…
For example, if someone tells me that something is "actually really simple", and I did not get it yet, I tend to think that I likely (not certainly, but likely) have not found the right approach to that something yet, and once I found that way to look at it, things will resolve itself.
But if people assure me that something is "hard to learn" or "hard to get", I'm rather suspecting that that thing is full of unwieldy complexity and/or unintuitive aspects, and unless I'm either up for the challenge (definitely the case sometimes), or learning it is crucial for achieving a certain goal (in which case it may turn out to be fun after all, even if still hard), I might think twice if I want to put the time and energy into it.
In the case of DNS, which I've learned in the nineties, I found the principle simple and elegant, the tools and software unwieldy and sometimes arcane, and a large multitude of little details that are not strictly necessary for understanding and using DNS in basic ways, but that can get important when either debugging or working at scale.
So, in the case of DNS, I'd say the answer is "depends on how deep you want to go", but don't shy away from the simple and elegant principle, even if the arcane software (it has gotten better, though) stands in the way.
I think that matches the content of your article overall?
It’s not. It’s one of the few things that hasn’t changed much and it’s operation is fairly straightforward. dig is a little confusing. It’s more capable but less straightforward than good old nslookup (which still works fine BTW). I think partly DNS and the core protocols may seem confusing to younger people in the industry because so much stuff “just works” now. For example, today wifi routers “just work” right out…
I think you are stretching how bad wifi was in early 2000s - sure its easier today, but in the actual year 2000 you could walk into a store and take home an Apple branded wifi base station (original AirPort unit) - 802.11b stuff of the era was largely as easy to connect new stuff to as today, generally with a passkey. It all largely worked with DHCP out of the box just like most routers today too, if anything the experience is much the same minus the faster speeds, slightly better range and encryption today. Oh and probably some kind of ipv6 support...
You certainly did not need network engineer level knowledge - lots of smart professional folks installed wifi in the 2000s, and solutions like the AirPort base station and many others were about as "turnkey" as they came.
Explain this : dig +human +norecurse @8.8.8.8 google.com HEADER: opcode: QUERY status: NOERROR id: 11653 flags: qr ra records: QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
QUESTION SECTION: google.com. IN A
ANSWER SECTION: google.com. 21 IN A 172.217.4.206
ADDITIONAL SECTION: EDNS: version: 0, flags:; udp: 512
ChatGPT This is a result from the "dig" command, a DNS (Domain Name System) tool used to query DNS servers and retrieve information about domain names. Let's break down the output:
dig: This is the command being executed.
+human: This flag is not a standard dig option. It is likely an extension that is meant to provide a more human-readable output, making it easier for people to understand the results.
+norecurse: This flag tells the DNS server (in this case, the server at IP address 8.8.8.8, which is a public Google DNS server) not to perform recursive lookups. Recursive lookups involve the DNS server querying other DNS servers if it doesn't have the requested information in its cache. By using +norecurse, the server will only provide information if it has it directly available.
@8.8.8.8: This indicates the DNS server being queried, which is the Google Public DNS server located at IP address 8.8.8.8.
google.com: This is the domain name being queried.
Now, let's look at the different sections of the response:
HEADER: This section provides general information about the response. opcode: QUERY: Indicates that the query type is a standard query. status: NOERROR: Indicates that the query was successful, and there were no errors. id: 11653: This is a unique identifier for the query, used to match queries with their respective responses. flags: qr ra: The flags indicate that this is a response (qr) and that recursion is available and allowed (ra). QUESTION SECTION: This section shows the domain name and the type of record being queried. google.com. IN A: The domain name "google.com" is being queried for its IPv4 address (A record). ANSWER SECTION: This section provides the answer to the query. google.com. 21 IN A 172.217.4.206: This line shows the answer. It says that the IPv4 address of "google.com" is 172.217.4.206. The "21" is the time to live (TTL) value in seconds, which indicates how long the information can be cached by other DNS servers or clients before it should be refreshed. ADDITIONAL SECTION: This section provides additional information related to the query. EDNS: version: 0, flags:; udp: 512: This line indicates the use of EDNS (Extension Mechanisms for DNS), which is a set of extensions to the DNS protocol. The version is 0, and the flags are empty. "udp: 512" refers to the maximum payload size that can be used for UDP communication. In summary, the query asked for the IPv4 address (A record) of "google.com" from the Google Public DNS server at IP address 8.8.8.8. The response confirms that the IPv4 address is 172.217.4.206, and it is valid for 21 seconds.
I predate the DNS, and I continue to befuddle myself about details of the DNS on a daily basis despite a life embedded in DNS.
If you love DNS join DNS OARC.