Unbound 1.7.2rc1 pre-release

Wouter · June 4, 2018, 12:07pm

Hi,

Unbound 1.7.2rc1 pre-release is available:
https://www.nlnetlabs.nl/downloads/unbound/unbound-1.7.2rc1.tar.gz
sha256 561c33f80b757820e3bd632cd339673da84a71dbb6328d124324db2c63a7f833
pgp https://www.nlnetlabs.nl/downloads/unbound/unbound-1.7.2rc1.tar.gz.asc

This release fixes bugs in DNS-over-TLS for windows, and adds the option
for windows users to use the CA certificates from the Windows cert
stores, tls-win-cert: yes in unbound.conf.

The code has been updated with a speed up that improves performance for
large numbers of incoming TCP and TLS connections.

There is an option to allow to ignore an unset RD bit for access control
subnets and always allow recursion to the request.

Windows unbound 1.7.2rc1 download links, 64 and then 32bit:
https://www.nlnetlabs.nl/downloads/unbound/unbound-1.7.2rc1.zip
https://www.nlnetlabs.nl/downloads/unbound/unbound_setup_1.7.2rc1.exe
https://www.nlnetlabs.nl/downloads/unbound/unbound-1.7.2rc1-w32.zip
https://www.nlnetlabs.nl/downloads/unbound/unbound_setup_1.7.2rc1-w32.exe
And .asc pgp signatures.

Features:
- Fix low-rtt-pct to low-rtt-permil, as it is parts in one thousand.
- Qname minimisation default changed to yes.
- Use accept4 to speed up incoming TCP (and TLS) connections,
  available on Linux and FreeBSD.
- tls-win-cert option that adds the system certificate store for
  authenticating DNS-over-TLS connections. It can be used instead
  of the tls-cert-bundle option, or with it to add certificates.
- Patch from Syzdek: Add ability to ignore RD bit and treat all
  requests as if the RD bit is set.
- Rename additional-tls-port to tls-additional-ports.
  The older name is accepted for backwards compatibility.

Bug fixes:
- Fix for crash in daemon_cleanup with dnstap during reload,
  from Saksham Manchanda.
- Also that for dnscrypt.
- Fix spelling error in man page and note defaults as no instead of
  off.
- Fix that unbound-control reload frees the rrset keys and returns
  the memory pages to the system.
- Fix fail to reject dead peers in forward-zone, with ssl-upstream.
- Fix that configure --with-libhiredis also turns on cachedb.
- Fix gcc 8 buffer warning in testcode.
- Fix function type cast warning in libunbound context callback type.
- Fix windows to not have sticky TLS events for TCP.
- Fix read of DNS over TLS length and data in one read call.
- Fix mesh state assertion failure due to callback removal.
- Fix contrib/libunbound.pc for libssl libcrypto references,
  from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226914
- Fix that libunbound can do DNS-over-TLS, when configured.
- Fix that windows unbound service can use DNS-over-TLS.
- unbound-host initializes ssl (for potential DNS-over-TLS usage
  inside libunbound), when ssl upstream or a cert-bundle is configured.
- For TCP and TLS connections that don't establish, perform address
  update in infra cache, so future selections can exclude them.
- Fix that tcp sticky events are removed for closed fd on windows.
- Fix close events for tcp only.
- Fix windows tcp and tls spin on events.
- Add routine from getdns to add windows cert store to the SSL_CTX.
- in compat/arc4random call getentropy_urandom when getentropy fails
  with ENOSYS.
- Fix that fallback for windows port.
- Fix deadlock caused by incoming notify for auth-zone.

Best regards, Wouter

Harry_Schmalzbauer · June 5, 2018, 7:23am

Hello,

me again, again regarding auth-zones:
I'm running 1.7.2rc1 on FreeBSD11.2/adm64 and can confirm that the NOTIFY-dedlock vanished.

But CNAME records aren't resolved as soon as the record comes from auth-zone:.

Other problems keep me from thinking/researching, but as far as I know, the authoritative server has to return the CANME results alsong with the record, correct?
This isn't the case with 1.7.2rc1!

Thanks,

-harry

Wouter · June 5, 2018, 7:29am

Hi Harry,

Hi,

Unbound 1.7.2rc1 pre-release is available:
https://www.nlnetlabs.nl/downloads/unbound/unbound-1.7.2rc1.tar.gz
sha256 561c33f80b757820e3bd632cd339673da84a71dbb6328d124324db2c63a7f833
pgp
https://www.nlnetlabs.nl/downloads/unbound/unbound-1.7.2rc1.tar.gz.asc

Hello,

me again, again regarding auth-zones:
I'm running 1.7.2rc1 on FreeBSD11.2/adm64 and can confirm that the
NOTIFY-dedlock vanished.

But CNAME records aren't resolved as soon as the record comes from
auth-zone:.

Other problems keep me from thinking/researching, but as far as I know,
the authoritative server has to return the CANME results alsong with the
record, correct?

Yes, but only if you set for-downstream: no and for-upstream: yes.
With for-downstream, if that was enabled, then unbound responds with the
authority response to the downstream client, and that response does not
contain the CNAME result (in fact Unbound includes CNAME results, but
only if it is from the same auth-zone). The for-upstream: yes makes
unbound resolve CNAMEs, and pick information from the auth-zone where
necessary.

If the config that is used has these settings, then I would be
interested in some more information. What CNAME and so? How to
reproduce or perhaps a simple verbosity 4 log of what is happening.

Best regards, Wouter

Harry_Schmalzbauer · June 5, 2018, 7:38am

Hi Harry,

Hi,

Unbound 1.7.2rc1 pre-release is available:
https://www.nlnetlabs.nl/downloads/unbound/unbound-1.7.2rc1.tar.gz
sha256 561c33f80b757820e3bd632cd339673da84a71dbb6328d124324db2c63a7f833
pgp
https://www.nlnetlabs.nl/downloads/unbound/unbound-1.7.2rc1.tar.gz.asc

Hello,

me again, again regarding auth-zones:
I'm running 1.7.2rc1 on FreeBSD11.2/adm64 and can confirm that the
NOTIFY-dedlock vanished.

But CNAME records aren't resolved as soon as the record comes from
auth-zone:.

Other problems keep me from thinking/researching, but as far as I know,
the authoritative server has to return the CANME results alsong with the
record, correct?

Yes, but only if you set for-downstream: no and for-upstream: yes.
With for-downstream, if that was enabled, then unbound responds with the
authority response to the downstream client, and that response does not
contain the CNAME result (in fact Unbound includes CNAME results, but

Hello Wouter,

thanks a lot for your quick help.
Pilot error here: I had for-downstream: yes (and for-upstream: yes).

Sorry for the noise, will need some time to have a closer look at those two options and their meaning.
Your hints are very helpful, but I'm unsure what I want right now

only if it is from the same auth-zone). The for-upstream: yes makes
unbound resolve CNAMEs, and pick information from the auth-zone where
necessary.

If the config that is used has these settings, then I would be
interested in some more information. What CNAME and so? How to
reproduce or perhaps a simple verbosity 4 log of what is happening.

Will drop a note as soon as I had time to play with that, but I guess everything is working like designed, it's just a configuration error on my side.

Thanks,

-Harry

Harry_Schmalzbauer · June 5, 2018, 1:51pm

Hi Harry,

Hi,

Unbound 1.7.2rc1 pre-release is available:
https://www.nlnetlabs.nl/downloads/unbound/unbound-1.7.2rc1.tar.gz
sha256 561c33f80b757820e3bd632cd339673da84a71dbb6328d124324db2c63a7f833
pgp
https://www.nlnetlabs.nl/downloads/unbound/unbound-1.7.2rc1.tar.gz.asc

Hello,

me again, again regarding auth-zones:
I'm running 1.7.2rc1 on FreeBSD11.2/adm64 and can confirm that the
NOTIFY-dedlock vanished.

But CNAME records aren't resolved as soon as the record comes from
auth-zone:.

Other problems keep me from thinking/researching, but as far as I know,
the authoritative server has to return the CANME results alsong with the
record, correct?

Yes, but only if you set for-downstream: no and for-upstream: yes.
With for-downstream, if that was enabled, then unbound responds with the
authority response to the downstream client, and that response does not
contain the CNAME result (in fact Unbound includes CNAME results, but

Hello Wouter,

thanks a lot for your quick help.
Pilot error here: I had for-downstream: yes (and for-upstream: yes).

Sorry for the noise, will need some time to have a closer look at those two options and their meaning.
Your hints are very helpful, but I'm unsure what I want right now

only if it is from the same auth-zone). The for-upstream: yes makes
unbound resolve CNAMEs, and pick information from the auth-zone where
necessary.

If the config that is used has these settings, then I would be
interested in some more information. What CNAME and so? How to
reproduce or perhaps a simple verbosity 4 log of what is happening.

Will drop a note as soon as I had time to play with that, but I guess everything is working like designed, it's just a configuration error on my side.

Hello Wouter, all,

I can confirm that setting "for-downstream: no" leads to A answers for A-queries when RR type is CNAME.

But unfortunately I don't get the idea. Maybe somebody (besides the developers) else has already thought about the two for-(down|up])stream: options and can tell me what I'm missing.

Please correct me if my assumptions are wrong, which I'd like to try to describe here for those two options.

for-upstream:
As far as I understand, setting "for-upstream: no" can have only one usecase: To copy remote zone data to a local file. Without defining the zonefile:, this setting was completely useless as far as I understand, since the resolver doesn't use that data at all.

 For convenience, quoting the man page here \(for\-upstream:\):
     Default yes\.  If enabled, unbound fetches data from this data
     collection for answering recursion queries\.  Instead of sending
     queries over the internet to the authority servers for this
     zone, it&#39;ll fetch the data directly from the zone data\. Turn it
     on when you want unbound to provide recursion for downstream
     clients, and use the zone data as a local copy to speed up
     lookups\.

for-downstream: (assuming "for-upstream: yes" is kept as default setting):
Setting "for-downstream: no" is an option to validate unauthoritative answers to clients. The records are taken from the local copy of the zone data, but additionally validated before returned _without_ aa flag.

Keeping "for-downstream: yes" as the default setting, flags answers as authoritative (aa) to the clients, and the records came from the local copy of the zone data. No validation is done before answering.

 For convenience, quoting the man page here:
     Default yes\.  If enabled, unbound serves authority responses to
     downstream clients for this zone\.  This option makes unbound
     behave, for the queries with names in this zone, like one of the
     authority servers for that zone\.  Turn it off if you want
     unbound to provide recursion for the zone but have a local copy
     of zone data\.  If for\-downstream is no and for\-upstream is yes,
     then unbound will DNSSEC validate the contents of the zone
     before serving the zone contents to clients and store validation
     results in the cache\.

(Sorry if formating doesn't make it onto the list, I'm not used to my new MUA)

My problem: CNAME records are not resolved, at least not, if the CNAME record points to a different zone, although unbound also has authoritative zone data for it!

My scanario:

                      Upstream internet resolver
                             &gt;

LAN-client ------ UNBOUND
>
LAN master

forward-zone:
name "."
address: Upstream internet resolver

forward-zone:
name "example.com"
address: LAN master

auth-zone:
name "lanONE.example.com"
master: LAN maser

auth-zone:
name "lanTWO.example.com"
master: LAN maser

auth-zone:
name "2.0.192.in-addr.arpa"
master: LAN master
…

With the default settings (for-upstream: yes and for-downstream: yes), 'drill @UNBOUND host123.lanONE.example.com A IN' I get an authoritative answer with the corresponding A record as long as host123.lanONE.example.com has either an A record or the CNAME points to the same zone.
Now I have the following data in the zone:
host123.lanONE.example.com. CNAME host123.lanTWO.example.com.

The query above returns the CNAME record as authoritative answer, but doesn't show the A records, for the zone, which it is also authoritative for.

I'm missing the reason why one would want that behaviour!?!

I can get my desired behaviour by overriding the default with "for-downstream: no", but in my case unbound unsucessfully/unnecesarrily validates answers, which are unauthoritative – while I'd like them to be authoritative but unvalidated.

Sorry if there's something obvious I'm not seeing and wasting peoples' time...

Thanks for any hints,

-harry

Wouter · June 11, 2018, 9:55am

Hi,

Unbound 1.7.2 is available:
https://www.nlnetlabs.nl/downloads/unbound/unbound-1.7.2.tar.gz
sha256 a85fc7bb34711992cf128b2012638ebb8dc1fe15818baa381f6489240845eaa0
pgp https://www.nlnetlabs.nl/downloads/unbound/unbound-1.7.2.tar.gz.asc

This release fixes bugs in DNS-over-TLS for windows, and adds the option
for windows users to use the CA certificates from the Windows cert
stores, tls-win-cert: yes in unbound.conf.

The code has been updated with a speed up that improves performance for
large numbers of incoming TCP and TLS connections.

There is an option to allow to ignore an unset RD bit for access control
subnets and always allow recursion to the request.

Windows unbound 1.7.2 download links, 64 and then 32bit:
https://www.nlnetlabs.nl/downloads/unbound/unbound-1.7.2.zip
https://www.nlnetlabs.nl/downloads/unbound/unbound_setup_1.7.2.exe
https://www.nlnetlabs.nl/downloads/unbound/unbound-1.7.2-w32.zip
https://www.nlnetlabs.nl/downloads/unbound/unbound_setup_1.7.2-w32.exe
And .asc pgp signatures.

Features:
- Fix low-rtt-pct to low-rtt-permil, as it is parts in one thousand.
- Qname minimisation default changed to yes.
- Use accept4 to speed up incoming TCP (and TLS) connections,
  available on Linux, FreeBSD and OpenBSD.
- tls-win-cert option that adds the system certificate store for
  authenticating DNS-over-TLS connections. It can be used instead
  of the tls-cert-bundle option, or with it to add certificates.
- Patch from Syzdek: Add ability to ignore RD bit and treat all
  requests as if the RD bit is set.
- Rename additional-tls-port to tls-additional-ports.
  The older name is accepted for backwards compatibility.

Bug fixes:
- Fix for crash in daemon_cleanup with dnstap during reload,
  from Saksham Manchanda.
- Also that for dnscrypt.
- Fix spelling error in man page and note defaults as no instead of
  off.
- Fix that unbound-control reload frees the rrset keys and returns
  the memory pages to the system.
- Fix fail to reject dead peers in forward-zone, with ssl-upstream.
- Fix that configure --with-libhiredis also turns on cachedb.
- Fix gcc 8 buffer warning in testcode.
- Fix function type cast warning in libunbound context callback type.
- Fix windows to not have sticky TLS events for TCP.
- Fix read of DNS over TLS length and data in one read call.
- Fix mesh state assertion failure due to callback removal.
- Fix contrib/libunbound.pc for libssl libcrypto references,
  from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226914
- Fix that libunbound can do DNS-over-TLS, when configured.
- Fix that windows unbound service can use DNS-over-TLS.
- unbound-host initializes ssl (for potential DNS-over-TLS usage
  inside libunbound), when ssl upstream or a cert-bundle is configured.
- For TCP and TLS connections that don't establish, perform address
  update in infra cache, so future selections can exclude them.
- Fix that tcp sticky events are removed for closed fd on windows.
- Fix close events for tcp only.
- Fix windows tcp and tls spin on events.
- Add routine from getdns to add windows cert store to the SSL_CTX.
- in compat/arc4random call getentropy_urandom when getentropy fails
  with ENOSYS.
- Fix that fallback for windows port.
- Fix deadlock caused by incoming notify for auth-zone.

Best regards, Wouter