Re:Why is DNS still hard to learn?
by txutxu on Saturday July 29, 2023 @07:22AM
(#36919110)
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".
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 (client side issues, intermediate server(s) issues, final server issues), cache!, enterprise interests (from client to server side) and wild global (or local) enterprise positioning, government and agencies interests, ageing, all issues related to the main 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, clients that implement from the last century /etc/hosts to mdns and avahi, 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.
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.
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".
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 (client side issues, intermediate server(s) issues, final server issues), cache!, enterprise interests (from client to server side) and wild global (or local) enterprise positioning, government and agencies interests, ageing, all issues related to the main 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, clients that implement from the last century /etc/hosts to mdns and avahi, 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.
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.