|
As always, thanks for the article (and the debate). DNS itself, as an internet protocol, is "easy" in principle. I did implement and maintain DNS services at the beginning of my career, for more than 200 customers, without any title and without help, except "the internet". Everybody understands "you ask for a name, you get an address to connect as response", or "you can have more than one MX entry and play with the weight", "what is a TTL", etc. But as every internet protocol... as soon as you add to the recipe: historical changes and more than one RFC, upgrades to the protocol, cryptography, different client and server implementations, vendors, operative systems and libraries (and versions), levels of compliance, software applications, misconfiguration, bugs, layers and more layers (inside client, reaching intermediate server(s), final server issues), cache!, enterprise interests (from client to server side) with a wild global (or local) positioning, government and agencies interests, ageing, innovation, all issues related to the long running opensource projects related to the protocol, all issues related to the "new is better" opensource projects (client and server) related to the protocol, user/developers/customers/managers asking (or assuming) impossible things or that there are no limitations, a long history (and a future one) of known attacks and known defenses or mitigations, response ordering (/etc/gai.conf), clients that implement from the last century /etc/hosts to mdns and avahi to nsswitch and ncsd, clients that act as servers (developed by enterprise bug creators)... you know... not easy anymore... things gonna be wild. If there are complementary protocols, let's multiply the complexity: for DNS issues, there is also domain registration issues, whois, DHCP, VPNs, intermediate firewalls, rate limits, anycast, replication, IP, ARP... With any internet protocol, or anything related to computers: 1) While it works, it's fine (and everybody is happy) 2) While we get an issue previously seen, understood and fixed, it's still calm 3) While we get an issue that we can quickly search by symptoms and fix, maybe ok The "not easy" comes after that. When we get a new and unknown problem, a weird issue, unexpected things, and there are 20 or 30 possibly failing actors around the protocol, or XX involved parts. Recently I did a written breakdown of all things related to DNS in the "strace -y -yy -fq -v nc -vz google.com 80" in a linux laptop, and many people at work was surprised of all the things that happen there, inside the "give me the IP" step locally. We could say exactly the same against any issue related to any internet protocol: HTTP? it's easy or hard Depends. It's easy to explain in a sentence what it does. But you don't want to be the guy fixing issues against a float of load balancers used by all the customers, with a legacy (non compliant) device from a high priority customer at 4 A.M. oncall. |