Yes, in the long term you can only survive by being both large and clever, not
just one or the other.
-Bill
> On Nov 26, 2019, at 13:03, David Conrad <d...@virtualized.org> wrote:
>
> On Nov 26, 2019, at 11:33 AM, Jim Reid <j...@rfc1035.com> wrote:
>>> On 26 Nov 2019, at 09:16, Florian Weimer <f...@deneb.enyo.de> wrote:
>>>
>>> Up until recently, well-behaved recursive resolvers had to forward
>>> queries to the root if they were not already covered by a delegation.
>>> RFC 7816 and in particular RFC 8198 changed that, but before that, it
>>> was just how the protocol was expected to work.
>>
>> So what? These RFCs make very little difference to the volume of queries a
>> resolving server will send to the root. QNAME minimisation has no impact at
>> all: the root just sees a query for .com instead of foobar.com. A recursive
>> resolver should already be supporting negative caching and will have a
>> reasonably complete picture of what's in (or not in) the root. RFC8198 will
>> of course help that but not by much IMO.
>
> It would appear a rather large percentage of queries to the root (like 50% in
> some samples) are random strings, between 7 to 15 characters long, sometimes
> longer. I believe this is Chrome-style probing to determine if there is
> NXDOMAIN redirection. A good example of the tragedy of the commons, like
> water pollution and climate change.
>
> If resolvers would enable DNSSEC validation, there would, in theory, be a
> reduction in these queries due to aggressive NSEC caching. Of course,
> practice may not match theory
> (https://indico.dns-oarc.net/event/32/contributions/717/attachments/713/1206/2019-10-31-oarc-nsec-caching.pdf).
>
>
> Of course, steady state query load is largely irrelevant since root service
> has to be provisioned with massive DDoS in mind. In my personal view, the
> deployment of additional anycast instances by the root server operators is a
> useful stopgap, but ultimately, given the rate of growth of DoS attack
> capacity (and assuming that growth will continue due to the stunning security
> practices of IoT device manufacturers), stuff like what is discussed in that
> paper is the right long term strategy.
>
> Regards,
> -drc
> (Speaking for myself)
>
> _______________________________________________
> 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
