local_unbound and trust-anchor-signaling option (RFC8145)

[cvb]

Hello,

Very important change was in the package 'unbound' of the world DNSSEC.

The changing or "rolling" of the KSK Key was originally scheduled to occur on 11 October, but it is being delayed because some recently obtained data shows that a significant number of resolvers used by Internet Service Providers (ISPs) and Network Operators are not yet ready for the Key Rollover. The availability of this new data is due to a very recent DNS protocol feature that adds the ability for a resolver to report back to the root servers which keys it has configured.

https://www.icann.org/news/announcement-2017-09-27-en

Presentation: A Look at RFC 8145 Trust Anchor Signaling for the 2017 KSK Rollover
https://www.icann.org/en/system/fil...-anchor-signaling-ksk-rollover-11oct17-en.pdf

Option 'trust-anchor-signaling' of unbound was enabled by default from version 1.6.7 at 10 October 2017. FreeBSD port 'unbound' have this version now. But FreeBSD 11.1-p1 have version 1.5.10 that have not this option:

=========================================
/usr/sbin/unbound-control get_option trust-anchor-signaling
error unknown option
=========================================

Please, update unbound dns resolver (local_unbound) in the system FreeBSD.

 

[getopt]

From version 1.6.7 on dns/unbound the default of option ‘trust-anchor-signaling’ has been changed to 'yes'. No hint is given when updating.

When running the Unbound port version as a validating querier (not responder) please note RFC 8145 section5.2 which says

5.2 Use by Queriers

A validating DNS resolver (stub or recursive) SHOULD originate a
Key Tag query whenever it also originates a DNSKEY query for a
trust anchor zone. In other words, the need to issue a DNSKEY query
is also the trigger to issue a Key Tag query.

The value(s) included in the Key Tag query represents the Key Tag(s)
of the trust anchor that will be used to validate the expected DNSKEY
response.

A validating DNS resolver SHOULD NOT originate Key Tag queries when
also originating DNSKEY queries for non-trust anchor zones.

A non-validating DNS resolver MUST NOT originate Key Tag queries.

DNS resolvers with caches SHOULD cache and reuse the response to a
Key Tag query just as it would any other response.

In this case in unbound.conf add the line

trust-anchor-signaling: no

Also note

8. Privacy Considerations

This proposal provides additional, optional "signaling" to DNS
queries in the form of Key Tag values. While Key Tag values
themselves are not considered private information, it may be possible
for an eavesdropper to use Key Tag values as a fingerprinting
technique to identify particular validating DNS clients. This may be
especially true if the validator is configured with trust anchors for
zones in addition to the root zone.

A validating resolver need not transmit the Key Tags in every
applicable query. Due to privacy concerns, such a resolver MAY
choose to transmit the Key Tags for a subset of queries (e.g., every
25th time) or by random chance with a certain probability (e.g., 5%).

For further information read RFC 8145 section 8.

 

[SirDice]

Regarding the base version, it won't be updated. The update may find its way into 11.2 but 11.1 won't be changed. Use the port if you need the latest versions with the latest options.