Re: [dns-operations] Survey of How to Solving DNS Errors
Moin! On 14 Aug 2024, at 17:27, Xiang Li wrote: > We are a research team from Tsinghua University and Nankai University. Your > participation is greatly appreciated and will significantly contribute to > our research. > > Recently, we are conducting a study on DNS resolution errors to understand > their occurrence, impact, and how you address these issues. Your > participation will provide valuable data and insights for our research. I’m not sure what data you want to get out of that research, but IMHO it is upfront missing a definition of what a resolution error is. One could infer from the survey that you mean anything that does not have the result code NOERROR, but don’t think that is a good measurement as: - NOERROR/NODATA could also be an resolution error for the the end user. - NXDOMAIN and other result codes are normal part of operating DNS and normally nothing to worry about. I just logged in to a random server that is doing tens of thousands of requests per second and it had 15% NXDomain queries 1% SERVFAIL and REFUSED and 0.1% FORMERR and that is a typical RCODE distribution, and it would be impossible to follow and investigate all of them. So long -Ralf ——- Ralf Weber ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Survey of How to Solving DNS Errors
Hi.
On 8/15/24 11:25, Ralf Weber wrote:
I’m not sure what data you want to get out of that research, but IMHO it is
upfront missing a definition of what a resolution error is.
Question 4 ("What types of DNS resolution errors have you encountered most
frequently?") has NXDOMAIN as one option, which implies that NXDOMAIN counts as a
resolution error.
But of course, it's not a resolution error, but a valid outcome of a successful
resolution.
Before reaching this question, I had selected "rarely" for question 3 ("How often
does your organization encounter DNS resolution errors?").
With the knowledge from question 4, the only valid answer for question 3 however seems
"daily", or even "all the time" (which is not an answer option).
Including NXDOMAIN as a resolution error will lead to biased results. For example, many people may
select seeing this "daily", which may lead to a publication saying that "DNS
resolution errors happen all the time", which is vastly inaccurate.
So, unfortunately, I aborted the survey at this point, as it is not
well-defined, and I did not want to increase sample size in this case.
Best,
Peter
--
https://desec.io/
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Survey of How to Solving DNS Errors
On 2024-08-15 11:25 +02, Ralf Weber wrote: > I just logged in to a random server that is doing tens of thousands of > requests per second and it had 15% NXDomain queries 1% SERVFAIL and REFUSED > and 0.1% FORMERR and that is a typical RCODE distribution, and it would > be impossible to follow and investigate all of them. It's not a competition but... we are answering 50% NXDOMAIN and that's considered normal... It's also sad, but what can you do... https://www.ripe.net/analyse/dns/k-root/statistics/root/daily/#return-codes -- In my defence, I have been left unsupervised. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Survey of How to Solving DNS Errors
> On 15 Aug 2024, at 10:39 PM, Florian Obser wrote: > > On 2024-08-15 11:25 +02, Ralf Weber wrote: >> I just logged in to a random server that is doing tens of thousands of >> requests per second and it had 15% NXDomain queries 1% SERVFAIL and REFUSED >> and 0.1% FORMERR and that is a typical RCODE distribution, and it would >> be impossible to follow and investigate all of them. > > It's not a competition but... we are answering 50% NXDOMAIN and that's > considered normal... It's also sad, but what can you do... > > https://www.ripe.net/analyse/dns/k-root/statistics/root/daily/#return-codes > Yes, has been considered "normal" for many years now - all this scaling of the response capacity of the root server system could be characterised as "say "no" faster and in greater volume! As to "what can you do"? there have been a couple of responses to this: One is RFC8198, "Aggressive Use of DNSSEC-Validated Cache", which allows recursive resolvers to "learn" the contents of the root zone from NXDOMAIN responses and allows the recrusive resolver to answer NXDOMAIN from its local cache. The other response is to have the local recursive resolver maintain a local copy of the current root zone - RFC 8806, "Running a Root Server Local to a Resolver". I particularly like Roy Arends and Nicolas Antoniello's 2021 technical analysis ot this approach (https://www.icann.org/en/system/files/files/octo-027-25aug21-en.pdf) regards, Geoff smime.p7s Description: S/MIME cryptographic signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Survey of How to Solving DNS Errors
Qname minimization in relaxed mode intentionally triggers NXDOMAIN looking for e.g. _.anything.example.com On Thu, 15 Aug 2024, Florian Obser wrote: It's not a competition but... we are answering 50% NXDOMAIN and that's considered normal... It's also sad, but what can you do... ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Survey of How to Solving DNS Errors
On Thu, 15 Aug 2024, Geoff Huston wrote: As to "what can you do"? there have been a couple of responses to this: If you run Response Policy Zones (and BIND) you can partially mitigate the impact of search lists on this at the recursive resolver by defining things like *.com.example and *.com.example.com as "CNAME ." and ensuring qname-wait-recurse is set to "no". (Probably best to look at your own traffic with wireshark and identify the low hanging fruit.) -- Fred Morris ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Survey of How to Solving DNS Errors
Not anymore. The current QTYPE is NS without the _ prefix. -- Mark Andrews > On 16 Aug 2024, at 06:33, Fred Morris wrote: > > Qname minimization in relaxed mode intentionally triggers NXDOMAIN looking > for e.g. _.anything.example.com > >> On Thu, 15 Aug 2024, Florian Obser wrote: >> >> It's not a competition but... we are answering 50% NXDOMAIN and that's >> considered normal... It's also sad, but what can you do... > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Survey of How to Solving DNS Errors
> On 16 Aug 2024, at 06:40, Fred Morris wrote: > > On Thu, 15 Aug 2024, Geoff Huston wrote: >> >> As to "what can you do"? there have been a couple of responses to this: >> > > If you run Response Policy Zones (and BIND) you can partially mitigate the > impact of search lists on this at the recursive resolver by defining things > like *.com.example and *.com.example.com as "CNAME ." and ensuring > qname-wait-recurse is set to "no". (Probably best to look at your own traffic > with wireshark and identify the low hanging fruit.) This is a really BAD idea. If you are seeing . the search list configuration is broken. Partially qualified names are a security hazard. > -- > > Fred Morris > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
