DNSCrypt / dnscrypt-server-docker

A Docker image for a non-censoring, non-logging, DNSSEC-capable, DNSCrypt-enabled DNS resolver
https://dnscrypt.info
ISC License
659 stars 132 forks source link

icann _ KSK rollover #48

Closed zzzkeil closed 6 years ago

zzzkeil commented 6 years ago

Hi, i need help to understand exactly what i have to configure on my dnscrypt servers.

I get this message forward form my provider :

This message is a follow up to an initial message sent by ICANN on 21 August 2018 that contained an important announcement about the upcoming change, or "rollover", of the root zone DNSSEC key signing key (KSK) on 11 October 2018, as well as an invitation to participate in a survey to assess network operators' readiness for the root KSK rollover. (The original message is copied below.)

Our original email made reference to recursive resolvers in ASXXXXXXX that might not be prepared for the root KSK rollover but did not provide a list of the specific IP addresses we determined were associated with those resolvers. We apologize for this omission.

At the end of this message, please find a list of IP addresses from ASXXXXXXX that since 1 September 2017 have sent at least one RFC 8145 trust anchor configuration report indicating they were not configured with the new KSK.

Please note that these IP addresses appear in our records because they sent a trust anchor configuration report to one of the root name servers in the form of a DNS query following the protocol defined in RFC 8145 (https://www.rfc-editor.org/rfc/rfc8145.txt). Not just recursive resolvers but any device, including those belonging to end users (such as mobile phones), could potentially send such a query: we are aware of at least one multi-platform VPN software implementation that reported its lack of the new KSK using this mechanism. (This software has since been updated with the new KSK.) In addition, because these reports are made with a simple DNS query, they can be forwarded through multiple resolvers and can also be easily spoofed. Therefore, the presence of an IP address in the list below does not definitively indicate that address originated a trust anchor report.

Please also note that IP addresses on your network that are not on the list below could still be unprepared for the root KSK rollover: only very recent versions of certain resolver software actually report their trust anchor configuration to the root servers. Your network could still have recursive resolvers with DNSSEC validation enabled that are unprepared for the root KSK rollover on 11 October 2018. If you have not already done so, we would therefore encourage you to check any DNSSEC-validating recursive resolvers to confirm that these resolvers are configured with the new root zone KSK and are prepared for the root KSK rollover on 11 October 2018.

For more information on how to check whether a resolver you operate has the new KSK, see: https://www.icann.org/dns-resolvers-checking-current-trust-anchors

For more information on how to update your resolver to use the new KSK, see: https://www.icann.org/dns-resolvers-updating-latest-trust-anchor

Finally, our records do not yet show a response from ASXXXXXXX to the KSK preparedness survey. Could we please kindly request that you complete this very short survey to assist ICANN in its assessment of networks' readiness for the root KSK rollover? The nine-question survey can be completed in under a minute:

https://www.research.net/r/KSKRolloverPreparedness?ASnumber=XXXXXXXX

We have extended the survey deadline and will be accepting responses until 13 September 2018.

Thank you for your participation!

For more information about the root KSK rollover project, see: https://www.icann.org/kskroll

If you have questions about the rollover or this survey, please send email to globalsupport@icann.org with "KSK Rollover" in the subject line.

Kind regards,

The ICANN Root KSK Rollover Project Team


Original message sent on 21 August 2018:

On 11 October 2018, ICANN will change or "roll over" the DNSSEC key signing key (KSK) of the DNS root zone. Based on information from your network received at the DNS root name servers [1], we believe that there may be at least one recursive resolver (also referred to as a recursive name server or caching name server) with DNSSEC validation enabled in ASXXXXXXX that is unprepared for the KSK rollover. If that resolver is not updated before 11 October 2018, users of that resolver will not be able to resolve any DNS queries, resulting in an outage for them.

To repeat this important point: any DNS resolvers on your network with DNSSEC validation enabled that are not properly updated to use the new KSK will fail on 11 October 2018 or shortly thereafter.

For more information on how to check whether a resolver you operate has the new KSK, see: https://www.icann.org/dns-resolvers-checking-current-trust-anchors

For more information on how to update your resolver to use the new KSK, see: https://www.icann.org/dns-resolvers-updating-latest-trust-anchor

In advance of the rollover, we are running a short survey of network operators who we believe are running one or more validating DNS resolvers that we believe may be unprepared for the rollover. Your participation in the survey will be valuable to the entire operations community.

Please take the survey about your preparedness for the root KSK rollover:

https://www.research.net/r/KSKRolloverPreparedness?ASnumber=xxxxxxx

We will be accepting responses for 14 days, ending on 4 September 2018.

For more information about the root KSK rollover project, see: https://www.icann.org/kskroll

If you have questions about the rollover or this survey, please send email to globalsupport@icann.org with "KSK Rollover" in the subject line.

[1] One or more resolvers on your network appear to be configured to send queries to the root name servers to report their DNSSEC trust anchor configuration. Please see RFC 8145 (https://www.rfc-editor.org/rfc/rfc8145.txt) for more information about this reporting mechanism.


IP addresses from ASXXXXXXX that since 1 September 2017 have sent at least one trust anchor configuration report indicating they were not configured with the new KSK:

[...] 46.xxx.xxx.xxx [...]

jedisct1 commented 6 years ago

You don't have to do anything. Unbound will seamlessly use the new root KSK.