https://xdi-attack.net/test.html

[RayG]

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 <benno at NLnetLabs.nl> 
Sent: 25 August 2021 11:02
To: unbound-users at lists.nlnetlabs.nl
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 at 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/