Krótka odpowiedź brzmi: bo twórcy tego standardu trochę przekombinowali. W praktyce włączenie DNSSEC na produkcyjnym serwerze oznacza z jednej strony publikację swojej strefy, a z drugiej - w praktyce - odcięcie od znacznej części domen głównych (TLD).

Konfiguracja DNSSEC w serwerze BIND jest najprostsza jeśli użyjemy repozytorium DLV, które ma pełnić rolę tymczasowego dysponenta kluczy publicznych poszczególnych TLD dopóki nie zostanie podpisany korzeń drzewa DNS ("."). Po dodaniu kilku opcji do konfiguracji i wpisaniu klucz DLV jako kotwicy zaufania ("trust anchor") serwer DNS zacznie weryfikować autentyczność tych TLD, które zostały podpisane. Nie ma ich bardzo dużo, ale to zawsze coś (lista kluczy TLD na stronie IANA, w DLV jest więcej bo rejestrują klucze wyższych poziomów).

Problem pojawia jednak gdy spróbujemy połączyć się z dowolnym serwerem w drzewie ORG. Otóż drzewo ORG zostało - jako jedno z dwóch głównych TLD (poza nim jeszcze GOV) - podpisane z użyciem kluczy NSEC3 (RFC 5155). Otóż serwer BIND w najbardziej rozpowszechnionej obecnie wersji 9.5 nie obsługuje rekordów NSEC3. Rezultat jest taki, że niezależnie od tego czy dodany klucz publiczny PIR ręcznie czy przez DLV, BIND nie będzie potrafił zweryfikować autentyczności domen ORG.

Ciekawe jest pochodzenie kluczy NSEC3, ustandardyzowanych dopiero trzy lata po publikacji najnowszej wersji DNSSEC (RFC 4033). Otóż po publikacji RFC 4033 w 2005 ktoś zorientował się, że podpisanie domeny na potrzeby DNSSEC wymaga jej ujawnienia. Czyli zrobienia czegoś, przed czym przestrzegają wszystkie poradniki konfiguracji serwera DNS w rozdziałach o ograniczeniu dostępu do AXFR. Potem do dyskusji włączono jeszcze europejskie przepisy o ochronie danych osobowych (które otwarta strefa może jakoby naruszać). W 2008 powstał standard NSEC3, który rozwiązuje wszystkie opisane problemy ale można powiedzieć, że trzy lata od publikacji RFC 4033 zostały zmarnowane - bo cały soft trzeba napisać od nowa i poczekać, aż osiągnie stadium produkcyjne.

Dlaczego piszę o tym wszystkim? Dlatego, że kilkanaście lat temu z zainteresowaniem obserwowałem rozwój innego, również przekombinowanego protokołu, który miał się stać ogólnointernetowym standardem - chodzi o IPSec. Opisywały go trzy standardy RFC, niezwykle skomplikowane ze wzgledu na swoją uniwersalność, która skutkowała mnóstwem opcji i wyborów implementacyjnych. Przez pierwsze kilka lat autorzy systemów próbowali te standardy zrozumieć i poprawnie zaimplementować tak, by różne implementacje dogadywały się między sobą. Gdy po niezliczonych "bake-off meetings" zaczęły być interoperacyjne nagle okazało się, że przegapiono jeden ważny detal - IPSec jest całkowicie niekompatybilny z NAT, który w międzyczasie stał się standardem w Internecie.

I wtedy się zaczęło - do skomplikowanego, ale dość eleganckiego pod względem formalnym IPSec zaczęto wciskać NAT Traversal, Dead Peer Detection i inne rozszerzenia w stylu XAUTH, co tylko pogłębiło chaos. Gdyby ktoś chciał zaprotestować, że przecież IPSec powszechnie używa się do budowania szyfrowanych tuneli pomiędzy sieciami, to pozwolę sobie przypomnieć, że nędzny ochłap po planowanej początkowo funkcjonalności, jaką było powszechne, ogólnointernetowego szyfrowanie pakietów. A i IPSec jest powoli wypierany nawet z rozwiązań zdalnego dostępu i VPN ze względu na koszmarnie skomplikowaną konfigurację.

To jest stan jaki osiągnęliśmy 15 lat po publikacji pierwszych RFC opisujących IPSec. Czy myślą Państwo, że w międzyczasie rynek potulnie czekał aż projektanci osiągną w końcu kompromis i skończą projektowanie rozwiązującego wszystkie problemy, uniwersalnego protokołu? Otóż nie - większość organizacji przez te wszystkie lata nie używała IPSec tylko dość koszmarnych z kryptograficznego punktu widzenia chałupniczych protokołów w rodzaju PPTP. Ich podstawową zaletą biznesową było to, że po prostu były i jakoś tam działały.