Hi Joe,

I hear you, the other side of the noise is that regular DNS people hear the 
noise and this makes the implementors to fix even marginal bugs because we 
can’t afford to not fix them. This especially applies to the wide range of bugs 
that makes the resolver to do more work.

We now have an internal threshold and if the amplification (how many outgoing 
DNS messages for on incoming) is around 100, we just don’t care.

If it’s 1000 or runaway then sure, but the complexity of interactions between 
delegations and redirections is complex and catching all the corner cases would 
increase internal complexity, so reasonable total limits should catch anything 
beyond.

My personal perception is those are class of attacks that only researchers are 
interested in including the “ah, looks like fun, let’s mess with my ISP’s 
resolver” kind of.

There are cheaper and easier ways to abuse DNS than setup a complex web of 
custom DNS servers with carefully crafted records…

I mean I am happy that we get these kind of reports, but sometimes it’s 
overwhelming. And sometimes it’s just clearly visible that the goal is the 
research/paper/poster/conference and not improving the overall security of DNS 
as the report rarely comes with a proposed fix.

Ondrej
--
Ondřej Surý (He/Him)

> On 29. 5. 2024, at 12:02, jab...@strandkip.nl wrote:
> 
> On May 29, 2024, at 01:51, Geoff Huston <g...@apnic.net> wrote:
> 
>> I tried to point out to the folk on the keytrap bandwagon that the
>> 
>> exploit was documented first some years ago, but was completely drowned out
>> by the hysterical fanfare of "we found a weakness in DNS behaviour! Aren't
>> we clever!"
>> 
>> I appreciate that testing widely used software for vulnerabilities is 
>> valuable work,
>> but turning the effort into some bizzarre circus sideshow does nobody any 
>> favours
>> at all.
> 
> I suspect there's a practical consideration that if you don't make a big 
> noise about it it's less likely that you get published (especially if you're 
> competing with other papers that are making a big noise). So while I have had 
> similar reactions to the marketing of some of these rather marginal 
> vulnerabilities over the past few years, it seems possible that the noise is 
> just the cost of academics being engaged. If we want academic research into 
> the DNS and DNS-related stuff, we might need to pay the piper.
> 
> I think we do want the academic engagement, in general. Even the most 
> overblown of these revelations has had some novel insight that has value, 
> even if the overall impact in the real world is somewhat less than claimed. 
> In the dnsbomb case it's exploiting the time that state is held in a resolver 
> when waiting for an upstream response, which I think is interesting to think 
> about on its own, together with the careful pulsing of responses to increase 
> the cost of receiving them. While this is apparently not an immediate threat 
> to BIND9 (or any other resolver that I have heard of) it's interesting to 
> think about how a pulsing attack could be combined with other attacks.
> 
> 
> Joe


_______________________________________________
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Reply via email to