4 ms·
Y'see, I do get all that. And I could have phrased the "never heard of ordering" thing better: of course I have. What I've never heard of is people relying on
by ealexhudson 9y ago
Y'see, I do get all that. And I could have phrased the "never heard of ordering" thing better: of course I have.
What I've never heard of is people relying on that to get DNS results correct. If your first server doesn't work, you _get the wrong results_. I don't understand on what planet that is acceptable sysadmin setup.
Split DNS zones have been a thing for years. This isn't a good substitute.
- ChuckMcM 9y agoI see it as implementation being perceived as architecture. The instance of the library that is quoted does this, it is not part of the architecture. That library has been used in a lot of places, so people start relying on the side effect (a common one is to stand up a local DNS server, have it 'shadow' or give alternative results to some queries, like ad network host names, and if the host name isn't in it then to fail so that the next DNS server is queried which is more likely a 'legit' server.) One of the reasons the IETF likes multiple running implementations of an RFC is they often have different side effects and so they call out things which might hang people up. The "correct" way to shadow, and to achieve user required semantics, is to create a DNS proxy that answers queries that it is supposed to and recursively getting results for ones that it doesn't. Correct here is in scare quotes because it doesn't mean it is right but instead just insures side effects of the libraries will not be a problem.