I see several different directions this could go that might be useful. 1. "DNS at the 99th percentile"
Rather than normatively declare limits on things like NS count or CNAME chain length, it would be interesting to measure behaviors out in the real world. How long can your CNAME chain be before resolution failure rates exceed 1%? How many NS records or RRSIGs can you add before 99% of resolvers won't try them all? 2. "DNS Lower Limits" Similar to the current draft, but a change of emphasis: instead of setting upper bounds on the complexity of zones, focus on setting lower bounds on the capability of resolvers. 3. "DNS Intrinsic Limits" Given the existing limits in the protocol (e.g. 64 KB responses, 255 octet names), document the extreme cases that might be challenging to resolve. This could be used to create a live test suite, allowing implementors to confirm that their resolvers scale to the worst-case scenarios. 4. "DNS Proof of Work" In most of these cases, the concern is that a hostile stub can easily request resolution of a pathological domain, resulting in heavy load on the recursive resolver. This is a problem of asymmetry: the stub does much less work than the resolver in each transaction. We could compensate for this by requiring the stub to increase the amount of work that it does. For example, we could * Recommend that resolvers limit the amount of work they will do for UDP queries, returning TC=1 when the limit is reached. * Create a system where stubs pad their UDP query packets to prevent reflection-amplification attacks. * Develop a novel proof-of-work extension, e.g. a continuation system that requires the stub to reissue heavy queries several times before getting the answer. --Ben ________________________________ From: Kazunori Fujiwara <fujiw...@jprs.co.jp> Sent: Tuesday, July 9, 2024 6:06 AM To: dnsop@ietf.org <dnsop@ietf.org> Subject: [DNSOP] draft-fujiwara-dnsop-dns-upper-limit-values Dear DNSOP, I submitted new draft that proposes to consider "Upper limit value for DNS". If you are interested, please read and comment it. I will attend IETF Hackathon. I would like to hear comments about the draft. Abstract: There are parameters in the DNS protocol that do not have clear upper limit values. If a protocol is implemented without considering the upper limit, it may become vulnerable to DoS attacks, and several attack methods have been proposed. This draft proposes reasonable upper limit values for DNS protocols. Name: draft-fujiwara-dnsop-dns-upper-limit-values Revision: 00 Title: Upper limit value for DNS Date: 2024-07-08 Group: Individual Submission Pages: 6 URL: https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-fujiwara-dnsop-dns-upper-limit-values-00.txt__;!!Bt8RZUm9aw!_lsMWK02HedzneFr7X0_6TfwEg09CBgtmX_uc21HIPHwU7goaPidjlUsBGu9yIAf3tP9XpIKP38wnGo$ Status: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-dns-upper-limit-values/__;!!Bt8RZUm9aw!_lsMWK02HedzneFr7X0_6TfwEg09CBgtmX_uc21HIPHwU7goaPidjlUsBGu9yIAf3tP9XpIKUGuh744$ HTMLized: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-fujiwara-dnsop-dns-upper-limit-values__;!!Bt8RZUm9aw!_lsMWK02HedzneFr7X0_6TfwEg09CBgtmX_uc21HIPHwU7goaPidjlUsBGu9yIAf3tP9XpIKD2pUkrE$ -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
