An interesting issue, I am no expert on this but my feelings are that wherever 
something can be done to conform to standards it should be done. Sometimes it 
does not matter if this is in the absolutely correct location (server, resolver 
etc). As they say it is better to implement security fully locked down, it is 
easier to open things up when they "don't work" as expected than it is to close 
it down after the failure has occurred.

In other words we currently have no idea what the next attack may be or how it 
will be implemented. There are many servers and resolver flavours out there and 
what would be good to know is that unbound applies the "rules, limits etc" 
absolutely. Then if we find there is a need to change the approach then it will 
be easier to resolve the issue that may rear it's head at some point in the 
future.

Taking this approach, will also allow those that spot issues in the future 
where domain names are rejected by unbound but are processed without error by a 
server somewhere in the internet ether, to contact the server administrator and 
point out that they are resolving invalid entries. Doing this is perhaps the 
only way to help tidy up whatever mess we feel we may be in right now.

In the end the internet will be all the better for it.

Just my 2p's worth.

RayG

-----Original Message-----
From: Benno Overeinder <[email protected]> 
Sent: 25 August 2021 11:02
To: [email protected]
Subject: Re: https://xdi-attack.net/test.html

Hi Andreas,

On 17/08/2021 22:09, A. Schulze via Unbound-users wrote:
> there is rumor about some weakness in dns. Details in this thread: 
> https://lists.dns-oarc.net/pipermail/dns-operations/2021-August/021260
> .html
> 
> A test site is available at https://xdi-attack.net/test.html The test 
> show unbound-1.13.2 as green (not vulnerable) but there are some hints 
> regarding special character filtering.
> Maybe the unbound developer@nlnetlabs could rate these hints?

We did read the USENIX paper and the email thread on dns-operations. 
Currently, Unbound is binary clean in hostnames/domainnames, but we could 
implement options for additional filtering on hostnames.  (We do already have 
options for scrubbing replies in Unbound.)

However, the discussion on the mailing list also makes it clear that there are 
different ideas about *where* the bad content filtering should take place, in 
the infrastructure (ie. the name servers) or at the endpoint (stub resolvers 
and libraries).  We'd love to hear more community consensus to make this 
architectural decision.

Best,

-- Benno


--
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/


Reply via email to