Define a list of DNSSEC-mandatory websites #5

Seb35 commented 2024年05月06日 21:39:45 +02:00

For now, with the options, you can only request all website have DNSSEC or be warned if DNSSEC is failing, but you cannot be warned if a website, which used to have DNSSEC, have no more DNSSEC.

I propose to add a new option where you can define a list of websites which must have DNSSEC and block them if their DNSSEC status is failing or missing. This list may be a list of regexes (e.g. .+\.mycompany\.example). Also, when you click on the padlock on a DNSSEC website, there may be a button to enroll this website in this list.

For now, with the options, you can only request all website have DNSSEC or be warned if DNSSEC is failing, but you cannot be warned if a website, which used to have DNSSEC, have no more DNSSEC. I propose to add a new option where you can define a list of websites which must have DNSSEC and block them if their DNSSEC status is failing or missing. This list may be a list of regexes (e.g. `.+\.mycompany\.example`). Also, when you click on the padlock on a DNSSEC website, there may be a button to enroll this website in this list.

Seb35 commented 2024年05月06日 22:13:28 +02:00

If this is implemented, imho it should be easy to remove a website from the list (after being warned) to avoid accustoming the user to click on "skip security" if a website has regular issues (e.g. the DNSSEC signatures are not renewed on-time).

If this is implemented, imho it should be easy to remove a website from the list (after being warned) to avoid accustoming the user to click on "skip security" if a website has regular issues (e.g. the DNSSEC signatures are not renewed on-time).

Seb35 commented 2026年05月03日 22:39:15 +02:00

This is implemented and currently in the main branch (together with #6).

As implemented, there are two lists: one for DNSSEC and one for DANE. Each entry in the list is either:

• an hostname (e.g. packages.debian.org)
• an hostname with all subdomains, which is a dot "." followed by the hostname (e.g. .debian.org)
• an negative hostname, which is a dash "-" followed by the hostname (e.g. -planet.debian.org)
• an negative hostname with all subdomains, which is a dash "-" followed by a dot "." followed by the hostname (e.g. -.planet.debian.org)

As implemented, a given hostname is considered in a given list if (and only if) it matches a positive hostname and it does not match a negative hostname.

Additionally, the DNSSEC check takes into account both lists DNSSEC and DANE (because if a hostname is considered DANE-enabled, then it is also DNSSEC-enabled).

When DNSSEC (resp. DANE) is missing on some visited website belonging to the DNSSEC (resp. DANE) list, the blocking page is activated (if the options says so) and there is a specific text.

It is possible to check an option (one for DNSSEC, one for DANE) to automatically add in the DNSSEC (resp. DANE) list a visited hostname where DNSSEC (resp. DANE) is valid. Only the hostname is added, it is considered a task for the user to guess if all subdomains should be added. Currently there is the "side-effect" that a DANE-enabled hostname is added to both lists; I have no precise ideas if I change this behaviour to add the hostname only in the DANE list.

This is implemented and currently in the main branch (together with #6). As implemented, there are two lists: one for DNSSEC and one for DANE. Each entry in the list is either: * an hostname (e.g. `packages.debian.org`) * an hostname with all subdomains, which is a dot "." followed by the hostname (e.g. `.debian.org`) * an negative hostname, which is a dash "-" followed by the hostname (e.g. `-planet.debian.org`) * an negative hostname with all subdomains, which is a dash "-" followed by a dot "." followed by the hostname (e.g. `-.planet.debian.org`) As implemented, a given hostname is considered in a given list if (and only if) it matches a positive hostname and it does not match a negative hostname. Additionally, the DNSSEC check takes into account both lists DNSSEC and DANE (because if a hostname is considered DANE-enabled, then it is also DNSSEC-enabled). When DNSSEC (resp. DANE) is missing on some visited website belonging to the DNSSEC (resp. DANE) list, the blocking page is activated (if the options says so) and there is a specific text. It is possible to check an option (one for DNSSEC, one for DANE) to automatically add in the DNSSEC (resp. DANE) list a visited hostname where DNSSEC (resp. DANE) is valid. Only the hostname is added, it is considered a task for the user to guess if all subdomains should be added. Currently there is the "side-effect" that a DANE-enabled hostname is added to both lists; I have no precise ideas if I change this behaviour to add the hostname only in the DANE list.

Seb35 commented 2026年05月03日 23:08:16 +02:00

I have been testing it since a few hours on some known websites. I observe that some big websites with many sub-sites has complex configurations from the global point of view.

1/ Debian: DANE almost everywhere, except on planet.debian.org where there is no DNSSEC

DNSSEC list:
DANE list:
.debian.org
-planet.debian.org

2/ RIPE NCC: DANE somewhere, DNSSEC often but a few notable exceptions

DNSSEC list:
.ripe.net
-www.ripe.net
-access.ripe.net
-idp.ripe.net
DANE list:
labs.ripe.net
lirportal.ripe.net
apps.db.ripe.net
stat.ripe.net
atlas.ripe.net

For RIPE NCC, it could be considered that DANE is everywhere, except on some subdomains where DANE is not activated and some other where DNSSEC is not activated.

3/ FreeBSD: DANE almost everywhere, except on the main website where there is no DNSSEC

DNSSEC list:
DANE list:
.freebsd.org
-www.freebsd.org

I simplified manually the lists above with the assumptions that all subdomains of debian.org and freebsd.org have DANE except the ones without DANE (and without DNSSEC; if they had DNSSEC an entry in the DNSSEC list should be added), but I’m not sure these assumptions are valid.

→ I hope the designed system will be clear enough to manage growing lists, any comments are welcome.

I chose not to implement these lists with regexes, I think it would be less readable.

I have been testing it since a few hours [on some known websites](https://codeberg.org/Seb35/DNSSEC-DANE_Padlock/wiki/Examples-of-websites). I observe that some big websites with many sub-sites has complex configurations from the global point of view. 1/ Debian: DANE almost everywhere, except on planet.debian.org where there is no DNSSEC ``` DNSSEC list: DANE list: .debian.org -planet.debian.org ``` 2/ RIPE NCC: DANE somewhere, DNSSEC often but a few notable exceptions ``` DNSSEC list: .ripe.net -www.ripe.net -access.ripe.net -idp.ripe.net DANE list: labs.ripe.net lirportal.ripe.net apps.db.ripe.net stat.ripe.net atlas.ripe.net ``` For RIPE NCC, it could be considered that DANE is everywhere, except on some subdomains where DANE is not activated and some other where DNSSEC is not activated. 3/ FreeBSD: DANE almost everywhere, except on the main website where there is no DNSSEC ``` DNSSEC list: DANE list: .freebsd.org -www.freebsd.org ``` I simplified manually the lists above with the assumptions that all subdomains of debian.org and freebsd.org have DANE except the ones without DANE (and without DNSSEC; if they had DNSSEC an entry in the DNSSEC list should be added), but I’m not sure these assumptions are valid. **→ I hope the designed system will be clear enough to manage growing lists, any comments are welcome.** I chose not to implement these lists with regexes, I think it would be less readable.