Unbound 1.22.0rc1 pre-release

[Wouter Wijngaards]

Hi Paul,

The unverified glue is about glue that is outside of the strict or 
narrow glue definition of in zone glue, not about glue that is outside 
of bailiwick or outside of parent zone, of course, that is already 
scrubbed. Something about policies at registrars and ownership of 
domains. So, not the case you cite; that would already be scrubbed by 
code in earlier releases.

There are defaults for those options, that are values suggested by the 
researchers. I guess it is possible to toggle these kinds options if the 
server is placed in a situation where they do not apply.

The naming of the redis options could be changed, if that is nicer for 
the users of it. Aliases make for neat backwards compatibility, that is 
nice.

Best regards, Wouter

On 10/10/2024 15:55, Paul Wouters wrote:
> On Thu, 10 Oct 2024, Wouter Wijngaards via Unbound-users wrote:
> 
>> This release has an option to harden against unverified glue, it
>> is enabled with `harden-unverified-glue: yes`. It was contributed
>> by Karthik Umashankar from Microsoft. This protects Unbound against
>> bad glue, that is out of zone, by performing a lookup for it.
> 
> I am quite surprised that this wasn't dropped before this release?
> Do you mean to say unverified (no DNSSEC signed) glue records that
> were out of zone / bailiwick were just added to the cache before?
> If so, that would be CVE worthy. And shouldn't need an option to
> enable/disable.
> 
>> Because it uses the original information as a last resort if nothing
>> works, it should not give lookup failures, and add protection.
> 
> So this is different from an A lookup for nohats.ca. that contains
> glue for cnn.com ? Those are unused and not placed in the cache?
> 
>> There are options to configure the scrubbing for NS records and
>> the CNAME scrubbing and the max global quota lookup limit from
>> previous security fix releases. They can be configured with the
>> options `iter-scrub-ns`, `iter-scrub-cname` and `max-global-quota`.
> 
> I am not sure I understand enough to give these sane values?
> 
>> For redis use, with cachedb, it is possible to specify the
>> timeout for the initial connection separately from the timeout
>> for commands. With the options `redis-command-timeout: 20` and
>> `redis-connect-timeout: 200` they can be set separately, for
>> a longer connect attempt, but a short command timeout to keep
>> resolution faster.
> 
> Maybe make valkey-* aliases and slowly phase out the redis- options?
> 
> Paul