DNSSEC: Домендік атау жүйесінің қауіпсіздігін қамтамасыз ету стандарты

DNSSEC: қауіпсіз домендік атау жүйесі. IETF стандарттары деректерді қорғауды, сақтауды қамтамасыз етеді. Киберқорғаныс, DNS қауіпсіздігі туралы біліңіз!

22 мин оқу

100%

Дереккөз: Domain Name System Security Extensions — Wikipedia

Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.

Мазмұны

Кіріспе

Домендік атаулар жүйесінің қауіпсіздік кеңейтулері (DNSSEC) – Интернет-инженерлік жұмыс тобының (IETF) Домендік атаулар жүйесінде (DNS) алмасылатын белгілі бір ақпаратты қорғауға арналған спецификациялар жиынтығы. Бұл протокол Интернет-протокол (IP) желілерінде деректердің криптографиялық растауын, бар екенін нақтылауды және деректердің сақталуын қамтамасыз етеді, бірақ қолжетімділік пен құпиялылықты қамтамасыз етпейді.

Операция

DNSSEC ашық кілт криптографиясын қолдана отырып, DNS іздеуі үшін жазбаларға цифрлық қол қою арқылы жұмыс істейді. Дұрыс DNSKEY жазбасы сенім тізбегі арқылы расталады, бұл сенімді үшінші тарап болып табылатын DNS түбір аймағының тексерілген ашық кілттері жиынтығынан басталады. Домен иелері өз кілттерін жасайды және оларды домендік атау тіркеушісіндегі DNS басқару панелі арқылы жүктейді, ол өз кезегінде кілттерді secDNS арқылы аймақ операторына (мысалы, com үшін Verisign) жібереді, ол оларды қол қойып, DNS-те жариялайды.

Ресурс деректері

DNS бірнеше ресурстық жазбаларды пайдалану арқылы іске асырылады. DNSSEC-ті іске асыру үшін бірнеше жаңа DNS жазба түрлері құрылды немесе DNSSEC-пен пайдалану үшін бейімделді: RRSIG (ресурс жазба қолтаңбасы) Жазбалар жиынтығының DNSSEC қолтаңбасын қамтиды. DNS-резолюторлар қолтаңбаны DNSKEY жазбасында сақталған ашық кілтпен тексереді. DNSKEY DNS-резолюторлардың RRSIG жазбаларындағы DNSSEC қолтаңбаларын тексеру үшін пайдаланатын ашық кілтті қамтиды. DS (делегация қол қоюшы) Делегацияланған аймақтың атауын қамтиды. Кіші делегацияланған аймақтағы DNSKEY жазбасына сілтеме жасайды. DS жазбасы бас аймаққа NS жазбаларымен бірге орналастырылады. NSEC (келесі қауіпсіз жазба) Аймақтағы келесі жазба атауына сілтеме жасайды және жазба атауы үшін бар жазба түрлерін тізімдейді. DNS-резолюторлар NSEC жазбаларын пайдалану арқылы DNSSEC-ті растаудың бір бөлігі ретінде жазба атауы мен түрінің жоқтығын тексереді. NSEC3 (келесі қауіпсіз жазба нұсқасы 3) Аймақтағы келесі жазба атауына (хэштелген атаулар ретімен) сілтеме жасайды және NSEC3 жазбасының өзінің атауының бірінші белгісінде хэш-мәні қамтылған атау үшін бар жазба түрлерін тізімдейді. Бұл жазбаларды DNSSEC-ті растаудың бір бөлігі ретінде жазба атауы мен түрінің жоқтығын тексеру үшін пайдалануға болады. NSEC3 жазбалары NSEC жазбаларына ұқсас, бірақ NSEC3 аймақтағы жазба атауларын санаудан аулақ болу үшін криптографиялық түрде хэштелген жазба атауларын қолданады. NSEC3PARAM (келесі қауіпсіз жазба нұсқасы 3 параметрлері) Авторитетті DNS серверлері осы жазбаны есептеу және DNSSEC сұраныстарына жауап ретінде қандай NSEC3 жазбаларын қосу керектігін анықтау үшін қолданады. DNSSEC қолданылған кезде DNS іздеудің әрбір жауабы сұралған жазба түрінен басқа RRSIG DNS жазбасын қамтиды. RRSIG жазбасы – бұл жауап DNS ресурстық жазбалар жиынтығының цифрлық қолтаңбасы. Цифрлық қолтаңба DNSKEY жазбасында табылған дұрыс ашық кілтті табу арқылы тексеріледі. NSEC және NSEC3 жазбалары кез келген ресурстық жазбаның (RR) жоқ екендігіне криптографиялық дәлелдеме беру үшін қолданылады. DS жазбасы сенім тізбегін пайдалана отырып, іздеу процедурасында DNSKEY-лерді аутентификациялауда қолданылады. NSEC және NSEC3 жазбалары жалғандауға қарсы берік кедергі үшін қолданылады.

DNS is implemented by the use of several resource records. To implement DNSSEC, several new DNS record types were created or adapted to use with DNSSEC:
RRSIG (resource record signature) Contains the DNSSEC signature for a record set. DNS resolvers verify the signature with a public key, stored in a DNSKEY record. DNSKEY Contains the public key that a DNS resolver uses to verify DNSSEC signatures in RRSIG records. DS (delegation signer) Holds the name of a delegated zone. References a DNSKEY record in the sub delegated zone. The DS record is placed in the parent zone along with the delegating NS records. NSEC (next secure record) Contains a link to the next record name in the zone and lists the record types that exist for the record's name. DNS resolvers use NSEC records to verify the non existence of a record name and type as part of DNSSEC validation. NSEC3 (next secure record version 3) Contains links to the next record name in the zone (in hashed name sorting order) and lists the record types that exist for the name covered by the hash value in the first label of the NSEC3 record's own name. These records can be used by resolvers to verify the non existence of a record name and type as part of DNSSEC validation. NSEC3 records are similar to NSEC records, but NSEC3 uses cryptographically hashed record names to avoid the enumeration of the record names in a zone. NSEC3PARAM (next secure record version 3 parameters) Authoritative DNS servers use this record to calculate and determine which NSEC3 records to include in responses to DNSSEC requests for non existing names/types. When DNSSEC is used, each answer to a DNS lookup contains an RRSIG DNS record, in addition to the record type that was requested. The RRSIG record is a digital signature of the answer DNS resource record set. The digital signature is verified by locating the correct public key found in a DNSKEY record. The NSEC and NSEC3 records are used to provide cryptographic evidence of the non existence of any Resource Record (RR). The DS record is used in the authentication of DNSKEYs in the lookup procedure using the chain of trust. NSEC and NSEC3 records are used for robust resistance against spoofing.

Алгоритмдер

DNSSEC кеңейтілмелі болу үшін жобаланған, сондықтан қолданылып жүрген алгоритмдерге қарсы шабуылдар анықталғанда, жаңалары кері үйлесімділікпен енгізілуі мүмкін. Төмендегі кесте 2019 жылдың маусым айындағы жағдай бойынша ең көп қолданылған немесе қолданылған қауіпсіздік алгоритмдерін көрсетеді:

Алгоритм өрісі | Алгоритм көзі | DNSSEC қолтаңбалау | DNSSEC растау
------- | -------- | -------- | --------
1 | RSA/MD5 | |
3 | DSA/SHA 1 | |
5 | RSA/SHA 1 | |
6 | DSA NSEC3 SHA1 | |
7 | RSASHA1 NSEC3 SHA1 | |
8 | RSA/SHA 256 | |
10 | RSA/SHA 512 | |
12 | GOST R 34.10 2001 | |
13 | ECDSA P 256/SHA 256 | |
14 | ECDSA P 384/SHA 384 | |
Ұсынылады | 15 | Ed25519 | Ұсынылады
Ұсынылады | 16 | Ed448 | Ұсынылады

Дайджест өрісі | Дайджест көзі | DNSSEC делегациялау | DNSSEC растау
------- | -------- | -------- | --------
1 | SHA 1 | |
2 | SHA 256 | |
3 | GOST R 34.10 2001 | |
4 | SHA 384 | Ұсынылады |

Іздеу тәртібі

DNS іздеу нәтижелері бойынша, қауіпсіздікке назар аударатын DNS шешушісі, сұралған доменнің авторитетті атау сервері DNSSEC-ті қолдайтынын, алынған жауаптың қауіпсіз екенін және қандай да бір қате бар-жоғын анықтай алады. Рекурсивті атау серверлері (көптеген интернет-провайдерлердегідей) және негізгі операциялық жүйелерге енгізілген түйіндерді шешушілер үшін іздеу процедурасы әртүрлі. Microsoft Windows түйіндерді шешушіні пайдаланады, ал Windows Server 2008 R2 және Windows 7 әсіресе растамайтын, бірақ DNSSEC-ті білетін түйіндерді шешушіні пайдаланады.

Рекурсивті атау серверлері

Сенім тізбегі моделін пайдалану арқылы, бас домендегі (DNS аймағы) Делегация қолтаңбалаушы (DS) жазбасын кіші домендегі DNSKEY жазбасын тексеру үшін пайдалануға болады, ал ол өз кезегінде тағы да кіші домендерді тексеру үшін басқа DS жазбаларын қамти алады. Мысалы, ISP сервері сияқты рекурсивті ажыратушы "www.example.com" доменінің IP мекенжайларын (A жазбасы және/немесе AAAA жазбалары) алуды қалайды. Процесс қауіпсіздікке назар аударатын ажыратушы DNS сұранысында "DO" ("DNSSEC OK") битін орнатқанда басталады. DO биті DNS үшін кеңейту механизмдерімен (EDNS) анықталған кеңейтілген ту биттерінде болғандықтан, барлық DNSSEC транзакциялары EDNS-ті қолдауы керек. DNSSEC транзакцияларына қажетті пакеттердің үлкен көлемін қамтамасыз ету үшін де EDNS қолдауы қажет. Ажыратушыға қалыпты DNS іздеу процесі арқылы жауап келгенде, ол жауаптың дұрыс екеніне көз жеткізу үшін тексереді. Идеалды жағдайда, қауіпсіздікке назар аударатын ажыратушы DNS түбіріндегі DS және DNSKEY жазбаларын тексеруден бастайды. Содан кейін ол "com" жоғарғы деңгейлі доменінің DS жазбаларын, түбірде табылған "com" аймағындағы DNSKEY жазбаларын тексеру үшін пайдаланады. Одан кейін ол "example.com" кіші домені үшін "com" аймағында DS жазбасы бар-жоқ екенін көреді, егер бар болса, ол DS жазбасын "example.com" аймағында табылған DNSKEY жазбасын тексеру үшін пайдаланады. Соңында, ол "www.example.com" домені үшін A жазбаларына жауапта табылған RRSIG жазбасын тексереді. Жоғарыдағы мысалға бірнеше ерекшеліктер бар. Біріншіден, егер "example.com" DNSSEC-ті қолдамаса, жауапта RRSIG жазбасы болмайды және "com" аймағында "example.com" үшін DS жазбасы болмайды. Егер "example.com" үшін DS жазбасы болса, бірақ жауапта RRSIG жазбасы болмаса, бірдеңе дұрыс емес, мүмкін ортадағы адам шабуыл жасап, DNSSEC ақпаратын алып тастап, A жазбаларын өзгертіп жатыр. Немесе, бұл DO битін сұраныстан немесе RRSIG жазбасын жауаптан алып тастаған, қауіпсіздікке көз жеткізбейтін атау сервері болуы мүмкін. Немесе бұл конфигурациялық қате болуы мүмкін. Келесісі, "www.example.com" деп аталатын доменнің жоқ болуы мүмкін, бұл жағдайда жауапта RRSIG жазбасын қайтарған орнына NSEC жазбасы немесе NSEC3 жазбасы болады. Бұл - "келесі қауіпсіз" жазбалар, олар ажыратушыға доменнің атауы жоқ екенін дәлелдеуге мүмкіндік береді. NSEC/NSEC3 жазбаларында RRSIG жазбалары бар, оларды жоғарыда көрсетілгендей тексеруге болады. Соңында, "example.com" аймағы DNSSEC-ті іске асырса, бірақ "com" аймағы немесе түбір аймағы жоқ болса, "қауіпсіздік аралы" құрылады, оны басқа жолмен растау қажет. 2010 жылдың мәліметі бойынша, DNSSEC-ті түбірге енгізу аяқталды. Com домені жарамды қауіпсіздік кілттерімен қолтаңбаланды және қауіпсіз делегация 2011 жылдың 1 сәуірінде түбір аймағына қосылды.

Using the chain of trust model, a Delegation Signer (DS) record in a parent domain (DNS zone) can be used to verify a DNSKEY record in a subdomain, which can then contain other DS records to verify further subdomains. Say that a recursive resolver such as an ISP name server wants to get the IP addresses (A record and/or AAAA records) of the domain "www. example. com". The process starts when a security aware resolver sets the "DO" ("DNSSEC OK") flag bit in a DNS query. Since the DO bit is in the extended flag bits defined by Extension Mechanisms for DNS (EDNS), , all DNSSEC transactions must support EDNS. EDNS support is also needed to allow for the much larger packet sizes that DNSSEC transactions require. When the resolver receives an answer via the normal DNS lookup process, it then checks to make sure that the answer is correct. Ideally, the security aware resolver would start with verifying the DS and DNSKEY records at the DNS root. Then it would use the DS records for the "com" top level domain found at the root to verify the DNSKEY records in the "com" zone. From there, it would see if there is a DS record for the "example. com" subdomain in the "com" zone, and if there were, it would then use the DS record to verify a DNSKEY record found in the "example. com" zone. Finally, it would verify the RRSIG record found in the answer for the A records for "www. example. com". There are several exceptions to the above example. First, if "example. com" does not support DNSSEC, there will be no RRSIG record in the answer and there will not be a DS record for "example. com" in the "com" zone. If there is a DS record for "example. com", but no RRSIG record in the reply, something is wrong and maybe a man in the middle attack is going on, stripping the DNSSEC information and modifying the A records. Or, it could be a broken security oblivious name server along the way that stripped the DO flag bit from the query or the RRSIG record from the answer. Or, it could be a configuration error. Next, it may be that there is not a domain name named "www. example. com", in which case instead of returning a RRSIG record in the answer, there will be either an NSEC record or an NSEC3 record. These are "next secure" records that allow the resolver to prove that a domain name does not exist. The NSEC/NSEC3 records have RRSIG records, which can be verified as above. Finally, it may be that the "example. com" zone implements DNSSEC, but either the "com" zone or the root zone do not, creating an "island of security" which needs to be validated in some other way. as of 2010, deployment of DNSSEC to root is completed. The com domain was signed with valid security keys and the secure delegation was added to the root zone on 1 April 2011.

Шөптің түйінін шешуші құрылғылар

Stub resolvers – "DNS ажыратымдылығының көп бөлігін рекурсивті атау серверіне жүктеу үшін рекурсивті сұраныс режимін пайдаланатын минималды DNS-резолюторлар". Stub resolver қарапайым түрде сұрауды рекурсивті атау серверіне жібереді және жауаптағы расталған деректер (AD) битін "рекурсивті атау сервері жауаптың Жауап және Авторитет бөлімдеріндегі барлық деректердің қолтаңбаларын тексерді ме, жоқ па, соны білу үшін" деген меңзеу ретінде пайдаланады.

Сенім зәкірлері мен аутентификация тізбектері

DNS жауабының дұрыстығын дәлелдеу үшін DNS-тен басқа көздерден алынған кемінде бір дұрыс кілт немесе DS жазбасын білу қажет. Осы бастапқы нүктелер сенімді тіреулер деп аталады және әдетте операциялық жүйе арқылы немесе басқа сенімді көзден алынады. DNSSEC әрқашан жобаланған кезде, тек DNS түбірі үшін ғана бір сенімді тіреудің қажеттігі туралы ойлар болған. Түбірлік тіреулер алғаш рет 2010 жылдың 15 шілдесінде жарияланды. Растау тізбегі – бұл сенімді тіреуден басталып, сұраныс доменінің авторитетті атау серверіне дейін жалғасатын DS және DNSKEY жазбаларының тізбегі. Толық растау тізбегі болмаса, DNS сұрауына алынған жауапты қауіпсіз растау мүмкін емес.

Қолтаңбалар және аймақтарға қол қою

Қайталау шабуылдарын шектеу үшін, кэш мақсатындағы қалыпты DNS TTL мәндерінен өзге, RRSIG жазбаларында қолтаңбаның жарамдылық мерзімін шектеу үшін қосымша уақыт белгілері де бар. TTL мәндері жазбалар жіберілген сәттен бастап есептелетін болса, уақыт белгілері абсолютті уақытты көрсетеді. Осыған байланысты, барлық қауіпсіздікке назар аударатын DNS шешуіштерінің сағаттары бірнеше минутқа жуық дәлдікпен синхронды болуы керек. Бұл уақыт белгілері аймақтың жүйелі түрде қайта қол қойылғанын және екінші серверлерге қайта таратылғанын талап етеді, әйтпесе растаушы шешуіштер қолтаңбаларды қабылдамайды.

Кілтті басқару

DNSSEC көптеген түрлі кілттерді қамтиды, олар DNSKEY жазбаларында және басқа көздерден сенімділік зәкірлерін қалыптастыру үшін сақталады. Кілттерді алмастыру үшін кілтті жаңару схемасы қажет. Әдетте, бұл жаңа DNSKEY жазбаларында жаңа кілттерді орнатуды қамтиды, қазіргі ескі кілттермен қатар. Содан кейін, өмір сүру мерзімі (TTL) мәндері ескі кілттердің кэштелу мерзімінің өтіп кеткенін болжауға мүмкіндік берген кезде, осы жаңа кілттерді пайдалануға болады. Ақырында, ескі кілттерді пайдаланатын жазбалардың кэштелу мерзімі өткенін болжау қауіпсіз болған кезде, ескі DNSKEY жазбаларын жоюға болады. Бұл процесс, мысалы, операциялық жүйені жаңартуды қажет ететін түбірлік деңгейдегі сенімділік зәкірлерінің кілттері үшін күрделірек. DNSKEY жазбаларындағы кілттер екі түрлі мақсатта қолданылуы мүмкін және әдетте әрқайсысы үшін әртүрлі DNSKEY жазбалары пайдаланылады. Біріншіден, аймақтық қол қою кілттерін (ZSK) қамтитын басқа DNSKEY жазбаларына қол қою үшін қолданылатын негізгі қол қою кілттері (KSK) бар, ал ZSK кілттері басқа жазбаларға қол қою үшін қолданылады. ZSK кілттері бір DNS аймағының толық бақылауында болғандықтан, оларды оңай және жиі алмастыруға болады. Осының салдарынан ZSK кілттері KSK кілттеріне қарағанда әлдеқайда қысқа болуы мүмкін, сонымен қатар RRSIG/DNSKEY жазбаларының көлемін азайта отырып, бірдей қорғау деңгейін ұсынады. Жаңа KSK кілті жасалған кезде DS жазбасы жоғары деңгейдегі аймаққа көшіріліп, онда жариялануы керек. DS жазбалары кілттің толық нұсқасының орнына KSK кілтінің хабарламалық дайджестін пайдаланады, бұл жазбалардың көлемін кішірейтуге мүмкіндік береді. Бұл com домені сияқты өте үлкен аймақтар үшін пайдалы. Жоғары деңгейдегі аймақтағы DS кілттерін жаңарту процедурасы DNSKEY жазбаларын жоғары деңгейдегі аймақта болуын талап еткен DNSSEC-тің бұрынғы нұсқаларына қарағанда қарапайым. Алгоритмді жаңару принципімен тығыз байланысты, бұл аймақты бір қол қою алгоритмінен екіншісіне көшіруді қамтиды. Мысалы, 8-ші алгоритмнен (RSA/SHA 256) 13-ші алгоритмге (ECDSA/SHA 256) көшуді қарастыруға болады. Бірнеше ccTLD аймақтары көшірілді, соның ішінде at, br, cz, ch, fr, ie, nl және ph. Verisign 2023 жылдың соңында com, net және edu аймақтарын 13-ші алгоритмге көшірді. Түбірлік доменді 8-ші алгоритмнен 13-ші алгоритмге көшіру 2024 жылдың басында жоспарлануда.

DNSSEC involves many different keys, stored both in DNSKEY records, and from other sources to form trust anchors. In order to allow for replacement keys, a key rollover scheme is required. Typically, this involves first rolling out new keys in new DNSKEY records, in addition to the existing old keys. Then, when it is safe to assume that the time to live values have caused the caching of old keys to have passed, these new keys can be used. Finally, when it is safe to assume that the caching of records using the old keys have expired, the old DNSKEY records can be deleted. This process is more complicated for things such as the keys to trust anchors, such as at the root, which may require an update of the operating system. Keys in DNSKEY records can be used for two different things and typically different DNSKEY records are used for each. First, there are key signing keys (KSK) which are used to sign other DNSKEY records containing zone signing keys (ZSK), which are used to sign other records. Since the ZSKs are under complete control and use by one particular DNS zone, they can be switched more easily and more often. As a result, ZSKs can be much shorter than KSKs and still offer the same level of protection while reducing the size of the RRSIG/DNSKEY records. When a new KSK is created, the DS record must be transferred to the parent zone and published there. The DS records use a message digest of the KSK instead of the complete key in order to keep the size of the records small. This is helpful for zones such as the com domain, which are very large. The procedure to update DS keys in the parent zone is also simpler than earlier DNSSEC versions that required DNSKEY records to be in the parent zone. A closely related principle is that of Algorithm rollover, this involves migrating a zone from one signing Algorithm to another. A good example of this would be migrating from Algorithm 8 (RSA/SHA 256) to Algorithm 13 (ECDSA/SHA 256). Several ccTLD's have already migrated including at, br, cz, ch, fr, ie, nl and ph. Verisign migrated com, net and edu to Algorithm 13 in late 2023. The migration of the root domain from Algorithm 8 to Algorithm 13 is currently in planning as of early 2024.

DANE жұмыс тобы

DNS-ге негізделген атаулы тілімдердің куәландырылуы (DANE) – DNSSEC негізінде TLS, DTLS, SMTP және S/MIME арқылы шифрланған қауіпсіз байланыстарды орнатуға мүмкіндік беретін протоколдар мен техникаларды әзірлеу мақсатымен құрылған IETF жұмыс тобы. Жаңа протоколдар қауымдық кілт инфрақұрылымына негізделген дәстүрлі модельге қосымша сенімділік пен шектеулерді қамтамасыз етеді. Олар сондай-ақ домен иелеріне үшінші тарап сертификаттау органдарына жүгінбей, өздері үшін сертификаттарды жариялауға мүмкіндік береді. DNSSEC-ке тіркелген сертификаттарға қолдау Google Chrome 14 нұсқасында енгізілген, бірақ кейіннен алынып тасталды. Mozilla Firefox үшін қолдау қосымша арқылы ұсынылды, ал ендігі қолдау онымен жұмыс істейтін біреуді күтіп тұр.

Тарих

DNS – Интернет қызметінің маңызды және негізгі бөлігі, бірақ 1990 жылы Стив Белловин оның қауіпсіздігіндегі елеулі кемшіліктерді анықтады. Оны қорғау бойынша зерттеулер басталды және оның еңбегі 1995 жылы жарияланғанда қарқынды дамыды. Алғашқы RFC 2065 1997 жылы IETF жариялады, ал осы спецификацияны іске асырудың алғашқы тыңайлаулары 1999 жылы IETF RFC 2535 ретінде қайта қаралып (және толыққанды жұмыс істейтін деп есептелді) жаңа спецификацияға әкелді. RFC 2535 негізінде DNSSEC-ті енгізу жоспарланды. Алайда, IETF RFC 2535 спецификациясы толық Интернетке дейін кеңейтуде өте маңызды мәселелерге тап болды; 2001 жылға қарай бұл спецификацияның ірі желілер үшін қолдануға жарамсыз екені анық болды. Құрылымдық түрде DNS серверлері көбінесе ата-аналық серверлермен синхронды болмайды. Бұл әдетте мәселе тудырмайды, бірақ DNSSEC қосылғанда, бұл синхронды емес деректер өзінен туындайтын қызмет көрсетуден бас тартудың салдарына әкелуі мүмкін. Бастапқы DNSSEC бала үшін кілттерді өзгерту үшін күрделі алты хабарлама протоколы мен көптеген деректерді беруді қажет етті (DNS балалық аймақтары барлық деректерін ата-анаға жіберуі керек, ата-ана әрбір жазбаға қол қоюы керек, содан кейін бұл қолтаңбаларды балаға SIG жазбасында сақтау үшін қайта жіберуі керек). Сонымен қатар, ашық кілттерді өзгерту абсурдты әсерлерге ие болуы мүмкін; мысалы, егер ".com" аймағы өзінің ашық кілтін өзгертсе, оған 22 миллион жазба жіберу қажет болар еді (өйткені ол барлық балаларының қолтаңбаларын жаңартуы керек). Осылайша, RFC 2535-те анықталған DNSSEC Интернетке кеңейтілмейтін еді. IETF DNSSEC-ті түбірімен өзгертті, RFC 2535-тің бастапқы DNSSEC-тен ерекшеленуі үшін қажет болған жағдайда оны DNSSEC bis деп атады. Бұл жаңа нұсқа ата-аналық және балалық аймақтар арасындағы делегациялау нүктелерінде қосымша жанамалық деңгейін қамтамасыз ету үшін «делегациялау қол қоюшысының (DS) ресурстық жазбаларын» пайдаланады. Жаңа тәсіл бойынша, баланың бас ашық кілті өзгерген кезде, баланың әрбір жазбасы үшін алты хабарламаның орнына бір ғана хабарлама болады: бала жаңа ашық кілтті өзінің ата-анасына жібереді (әрине, қол қойылған). Ата-аналар әр балаға бір бас ашық кілтті сақтайды; бұл әлдеқайда тиімді. Бұл ата-ана мен бала арасында ауыстырылатын деректердің үлкен көлеміне қарағанда, ата-анаға аз көлемдегі деректер беріледі дегенді білдіреді. Бұл клиенттер кілттерді тексеру кезінде көбірек жұмыс істеуі керек дегенді білдіреді. Нақтырақ айтқанда, DNS аймағының KEY RRset-ін тексеру үшін RFC 2535-те қажет болған бір тексеру операциясының орнына екі қолтаңба тексеру операциясы қажет (басқа типтегі RRset-тер үшін тексерілген қолтаңбалар санына әсер етпейді). Көптеген адамдар бұл аз құнға тұрарлық деп санайды, өйткені ол DNSSEC-ті енгізуді практикалық етеді. Жаңа нұсқа RFC4033 және RFC4035-те жарияланды. 2024 жылдың қаңтарында DNSSEC спецификациясын сақтайтын барлық шешушілерге қатысты «KeyTrap» қызмет көрсетуден бас тарту шабуылы жарияланды. DNSSEC спецификациясы (RFC4033 және RFC4035) шешушінің жоғарыдан қол қойылған пакет алғанда, барлық комбинациялардың бірі сәтті тексерілгенге дейін барлық қолтаңбаларда дұрыс «белгісі» бар барлық кілттерді сынап көруі керектігін көрсетеді. Зерттеушілер бір «белгі» бар көптеген кілттерді және сол «белгіге» сәйкес келетін көптеген қолтаңбаларды пакетке салып, шешушінің жұмысын 2 миллион есе баяулатуы мүмкін. Бұл жағдайға жауап ретінде, шешушілер тексеру қателерінің, кілт тегтерінің қақтығыстары мен хэш есептеулерінің мөлшеріне шектеу қоюға кірісті.

DNS is a critical and fundamental Internet service, yet in 1990 Steve Bellovin discovered serious security flaws in it. Research into securing it began, and progressed dramatically when his paper was made public in 1995. The initial RFC 2065 was published by the IETF in 1997, and initial attempts to implement that specification led to a revised (and believed fully workable) specification in 1999 as IETF RFC 2535. Plans were made to deploy DNSSEC based on RFC 2535. Unfortunately, the IETF RFC 2535 specification had very significant problems scaling up to the full Internet; by 2001 it became clear that this specification was unusable for large networks. In normal operation DNS servers often get out of sync with their parents. This isn't usually a problem, but when DNSSEC is enabled, this out of sync data could have the effect of a serious self created denial of service. The original DNSSEC required a complex six message protocol and a lot of data transfers to perform key changes for a child (DNS child zones had to send all of their data up to the parent, have the parent sign each record, and then send those signatures back to the child for the child to store in a SIG record). Also, public key changes could have absurd effects; for example, if the ". com" zone changed its public key, it would have to send 22 million records (because it would need to update all of the signatures in all of its children). Thus, DNSSEC as defined in RFC 2535 could not scale up to the Internet. The IETF fundamentally modified DNSSEC, which is called DNSSEC bis when necessary to distinguish it from the original DNSSEC approach of RFC 2535. This new version uses "delegation signer (DS) resource records" to provide an additional level of indirection at delegation points between a parent and child zone. In the new approach, when a child's master public key changes, instead of having six messages for every record in the child, there is one simple message: the child sends the new public key to its parent (signed, of course). Parents simply store one master public key for each child; this is much more practical. This means that a little data is pushed to the parent, instead of massive amounts of data being exchanged between the parent and children. This does mean that clients have to do a little more work when verifying keys. More specifically, verifying a DNS zone's KEY RRset requires two signature verification operations instead of the one required by RFC 2535 (there is no impact on the number of signatures verified for other types of RRsets). Most view this as a small price to pay, since it makes DNSSEC deployment more practical. The new version is published in RFC4033 4035. In January 2024, a "KeyTrap" denial of service attack was announced for all specification respecting DNSSEC resolvers. The DNSSEC specification (RFC4033 4035) specifies that a resolver, when receiving a signed packet from the upstream, should try all keys with the correct "tag" on all signatures until one of the combinations successfully verifies. By putting many keys with the same "tag" and many signatures corresponding to that "tag" in a packet, the researchers can slow down a resolver by a factor of 2 million. In response, resolvers began to place limits on the amount of verification errors, key tag collisions, and hash calculations.

NXDOMAIN жауаптары мен NSEC-ті аутентификациялау

Доменнің жоқтығын криптографиялық тұрғыдан дәлелдеу үшін, жоқ доменге жасалған әрбір сұранысқа жауапқа қол қою қажет. Бұл онлайн қол қою серверлері үшін мәселе тудырмайды, себебі олардың кілттері онлайн режимінде қолжетімді болады. Дегенмен, DNSSEC офлайн компьютерлерді пайдаланып жазбаларға қол қою үшін жасалған, осылайша аймақ қол қою кілттерін қауіпсіз сақтауға болады. Бұл, жоқ домендерге жасалған сұраныстарға жауап беруді растау кезінде қиындық тудырады, өйткені әрбір мүмкін хост атауына жасалған сұранысқа алдын ала жауап беру мүмкін емес. Алғашқы шешім – аймақтағы әрбір домен жұбы үшін NSEC жазбаларын жасау болды. Егер клиент k.example.com доменіне жазба сұраса, сервер a.example.com және z.example.com арасында ештеңе жоқ екенін көрсететін NSEC жазбасымен жауап береді. Алайда, бұл дәстүрлі NXDOMAIN қателеріне қарағанда аймақ туралы көбірек ақпаратты ашады, себебі ол нақты домендердің бар екенін көрсетеді.

Доменді басып өтудің алдын алу

NSEC3 жазбалары (RFC 5155) атауларды тікелей тізімдеудің орнына оларды хэштеу арқылы жасалды. Уақыт өте келе, GPU және арнайы аппараттық құралдарды қолдана отырып хэштеудегі жетістіктер NSEC3 жауаптарын офлайн сөздік шабуылдары арқылы қолжетімді етуге мүмкіндік берді. NSEC5 ұсынылған, ол аймақты өзгертуге пайдаланылатын жеке кілтті сақтамай, авторитивті серверлерге NSEC жауаптарына қол қоюға рұқсат береді. Осылайша, NSEC5 кілтінің ұрлануы аймақты оңай санау мүмкіндігіне ғана әкеледі. Протоколдың дамуындағы қиындықтар мен кері үйлесімділікті сақтау қажеттілігіне байланысты, онлайн DNSSEC серверлері бар екенін тікелей растаудың орнына "ақ өтірік" қайтарады. RFC 4470-те сипатталған әдіс сұралған доменді лексикалық тұрғыдан қоршап тұрған домендер жұбын қамтитын NSEC жазбасын қайтарады. Мысалы, k.example.com сұранысы j.example.com және l.example.com (құбылмалы) домендері арасында ештеңе жоқ екенін көрсететін NSEC жазбасын береді. Бұл NSEC3 жазбаларымен де мүмкін. Cloudflare жауап мөлшерінің үштен бір бөлігіне дейін азайтатын екі баламалы тәсілді ұсынды. Біріншісі, "қара өтірік" деп аталатын, "ақ өтірік" тәсілінің өзгеруі болып табылады және ол жалпы DNS клиенттерінің мінез-құлқынан пайдаланып, болмауды ықшам түрде көрсетеді. Екінші тәсіл "жазба бар, бірақ сұралған жазба түрі жоқ" деп дәлелдеуді таңдайды, оны "DNS мылтығы" деп атайды. DNSSEC-тің кең ауқымды қолданылуы электрондық пошта мекенжайлары үшін кілттерді қауіпсіз тарату сияқты көптеген басқа қауіпсіздік мәселелерін де шеше алады. DNSSEC-тің ірі желілердегі қолданылуы да қиындықтар тудырады. Ozment және Schechter DNSSEC (және басқа технологиялардың) "бастапқы проблемасы" бар екенін атап өтеді: пайдаланушылар әдетте технологияны бірден пайда көруге мүмкіндік берген жағдайда ғана қолданады, бірақ егер пайдаланушыларға шығындарынан артық пайда алу үшін минималды деңгейде қолдану қажет болса (DNSSEC үшін де солай), оны енгізу қиын. DNSSEC DNS иерархиясының кез келген деңгейінде орналастырылуы мүмкін, бірақ оны көптеген басқалар қабылдамас бұрын аймақта кеңінен қолжетімді болуы керек. DNS серверлері DNSSEC-ті қолдайтын бағдарламалық қамтамасыз етумен жаңартылуы керек, ал DNSSEC деректері құрылып, DNS аймақ деректеріне қосылуы керек. TCP/IP қолданатын клиенттердің DNS шешушісі (клиенті) DNSSEC мүмкіндіктерін пайдаланудан бұрын жаңартылуы керек. Сонымен қатар, кез келген шешуші DNSSEC-ті пайдалануды бастамас бұрын кем дегенде бір сенімді ашық кілтті иеленуі немесе алуы керек. DNSSEC-тің іске асырылуы кейбір DNS серверлеріне қосымша жүктеме тудыруы мүмкін. Көптеген DNSSEC қолтаңбаланған жауаптар әдепкі UDP мөлшерінен, 512 байттан әлдеқайда үлкен. Теориялық тұрғыдан алғанда, бұл бірнеше IP фрагменттері арқылы шешілуі мүмкін, бірақ көптеген "аралық құрылғылар" оларды дұрыс өңдемейді. Бұл TCP-ні пайдалануға әкеледі. Дегенмен, қазіргі көптеген TCP іске асырулары әрбір TCP қосылымы үшін көп мөлшерде дерек сақтайды; ауыр жүктемелі серверлер көптеген (әлдебір) DNSSEC сұрауларына жауап беруге тырысып, ресурстардан таусылуы мүмкін. Осы жүктемені азайту үшін TCP Cookie Transactions сияқты кейбір протокол кеңейтімдері әзірленді. Осы қиындықтарды шешу үшін DNSSEC-ті енгізуге көп күш жұмсалуда, өйткені Интернет көптеген ұйымдар үшін өте маңызды.

The NSEC3 records (RFC 5155) were created as an alternative which hashes the name instead of listing them directly. Over time, advancements in hashing using GPUs and dedicated hardware meant that NSEC3 responses could be cheaply brute forced using offline dictionary attacks. NSEC5 has been proposed to allow authoritative servers to sign NSEC responses without having to keep a private key that can be used to modify the zone. Thus stealing an NSEC5KEY would only result in the ability to more easily enumerate a zone. Due to the messy evolution of the protocol and a desire to preserve backwards compatibility, online DNSSEC signing servers return a "white lie" instead of authenticating a denial of existence directly. The technique outlined in RFC 4470 returns a NSEC record in which the pairs of domains lexically surrounding the requested domain. For example, request for k. example. com would thus result in an NSEC record proving that nothing exists between the (fictitious) domains j. example. com and l. example. com. This is also possible with NSEC3 records. CloudFlare pioneered a pair of alternative approaches, which manage to achieve the same result in one third of the response size. The first is a variation on the "white lies" approach, called "black lies", which exploits common DNS client behavior to state the nonexistence more compactly. The second approach instead chooses to prove that "the record exists but the requested record type does not", which they call "DNS shotgun". Wide scale deployment of DNSSEC could resolve many other security problems as well, such as secure key distribution for e mail addresses. DNSSEC deployment in large scale networks is also challenging. Ozment and Schechter observe that DNSSEC (and other technologies) has a "bootstrap problem": users typically only deploy a technology if they receive an immediate benefit, but if a minimal level of deployment is required before any users receive a benefit greater than their costs (as is true for DNSSEC), it is difficult to deploy. DNSSEC can be deployed at any level of a DNS hierarchy, but it must be widely available in a zone before many others will want to adopt it. DNS servers must be updated with software that supports DNSSEC, and DNSSEC data must be created and added to the DNS zone data. A TCP/IP using client must have their DNS resolver (client) updated before it can use DNSSEC's capabilities. What is more, any resolver must have, or have a way to acquire, at least one public key that it can trust before it can start using DNSSEC. DNSSEC implementation can add significant load to some DNS servers. Common DNSSEC signed responses are far larger than the default UDP size of 512 bytes. In theory, this can be handled through multiple IP fragments, but many "middleboxes" in the field do not handle these correctly. This leads to the use of TCP instead. Yet many current TCP implementations store a great deal of data for each TCP connection; heavily loaded servers can run out of resources simply trying to respond to a larger number of (possibly bogus) DNSSEC requests. Some protocol extensions, such as TCP Cookie Transactions, have been developed to reduce this loading. To address these challenges, significant effort is ongoing to deploy DNSSEC, because the Internet is so vital to so many organizations.

Ертеде іске қосылу

Бастапқы қолданушылардың ішінде Бразилия (.br), Болгария (.bg), Чехия Республикасы (.cz), Намибия (.na), Пуэрто-Рико (.pr) және Швеция (.se) кіреді, олар өз елдік кодтарының жоғарғы деңгейлі домендері үшін DNSSEC қолданады; Интернетке нөмірлерді тағайындау агенттігінен (IANA) оған берілген барлық кері іздеу жазбаларына (addr.arpa) қол қойған RIPE NCC. ARIN да өз кері аймақтарына қол қойып жатыр. 2007 жылдың ақпанында TDC шведтік провайдерлердің арасында бұл мүмкіндікті клиенттеріне ұсынған алғашқысы болды. IANA 2007 жылдың маусымынан бастап қол қойылған түбірдің үлгісін сынақтан өткізді. Түбірге өндірістік қол қою кезеңіне дейін бірнеше балама сенім анкерлері болды. IKS Jena 2006 жылдың 19 қаңтарында біреуін, Интернет жүйелері консорциумы сол жылдың 27 наурызында тағы біреуін енгізді, ал ICANN өзі 2009 жылдың 17 ақпанында үшіншісін жариялады. 2009 жылдың 2 маусымында Afilias, Public Interest Registry-нің org аймағы үшін тіркелім қызметін ұсынатын компания, org TLD-ге қол қойды. Afilias және PIR 2008 жылдың 26 қыркүйегінде "2009 жылдың басында" басталатын, жақын байланыстағы ірі тіркеушілерді ("достар мен туыстар") қамтитын бірінші кезең домендерін қол қоюға алғашқылардың бірі болатынын мәлімдеді. 2010 жылдың 23 маусымында 13 тіркеуші ORG домендері үшін DNSSEC жазбаларын ұсынатыны белгілі болды. VeriSign com және net домендері үшін NSEC3 эксперименттерін жүргізу мақсатында пилоттық жобаны іске қосты. 2009 жылдың 24 ақпанында олар DNSSEC-ті барлық жоғарғы деңгейлі домендеріне (.com, .net және т.б.) 24 ай ішінде енгізетінін хабарлады, ал сол жылдың 16 қарашасында com және net домендеріне 2011 жылдың бірінші тоқсанына дейін қол қойылатынын, іске асырудың техникалық аспектілеріне байланысты туындаған кешігулерден кейін мәлімдеді. Бұл мақсатқа жоспарланғандай қол жеткізілді және Verisign компаниясының DNSSEC вице-президенті Мэтт Ларсон DNSSEC-ті дамытуға қосқан үлесі үшін InfoWorld компаниясының 2011 жылғы Технологиялық көшбасшылық сыйлығын жеңіп алды.

Жоспарлау

2008 жылдың қыркүйегінде ICANN және VeriSign іске асыру ұсыныстарын жариялады, ал қазан айында Ұлттық телекоммуникациялар және ақпарат басқармасы (NTIA) халықтан пікірлер сұрады. Алған пікірлер түпкілікті орындау жоспарының жасалуына әсер етіп-етпегені белгісіз. 2009 жылдың 3 маусымында Ұлттық стандарттар және технологиялар институты (NIST) ICANN, VeriSign және NTIA-мен бірлесіп, 2009 жылдың соңына дейін түбірлік аймаққа қол қою жоспарларын жариялады. 2009 жылдың 6 қазанында 59-шы RIPE конференциясының мәжілісінде ICANN және VeriSign түбірлік аймақта DNSSEC-ті енгізудің жоспарланған кестесін жариялады. Мәжілісте 2009 жылдың 1 желтоқсанынан бастап айына бір түбірлік атау серверіне кезең-кезеңімен енгізілетіні, ал түбірлік атау сервері 2010 жылдың 1 шілдесінде DNSSEC қол қойылған аймаққа қызмет көрсететіні және түбірлік аймақ RSA/SHA256 DNSKEY арқылы қол қойылатыны хабарланды. Бұл аймақты қол қою үшін пайдаланылған кілттердің тексерілмейтінін білдіреді; мұндай енгізудің себебі DNSSEC ресурстарына сұраныс жасалған кездегі үлкен жауаптардың нәтижесінде трафик үлгілеріндегі өзгерістерді бақылау болды. org жоғарғы деңгейлі домені 2010 жылдың маусымында DNSSEC-пен қол қойылды, одан кейін com, net және edu 2010 және 2011 жылдары қол қойылды. Елдік кодты жоғарғы деңгейлі домендер 2010 жылдың мамыр айынан бастап кілттерді сақтауға мүмкіндік алды. 2011 жылдың өзінде жоғарғы деңгейлі домендердің 25% -дан астамы DNSSEC-пен қол қойылды.

Іске асыру

2010 жылдың 25 қаңтарында L (ell) түбірлік сервері қасақана жарамсыз түбірлік аймақты (DURZ) қызмет көрсетуді бастады. Аймақ 2010 жылдың мамыр айынан бастап барлық он үш түбірлік сервер DURZ-ді қызмет көрсетуге көшті. DLV, түбірлік сенімділік анкері болмаған жағдайда DNSSEC-ті енгізуді жеңілдету мақсатында жасалды. Ол кезде валидаторлар DNS-тің қол қойылған тармақтарына сәйкес келетін көптеген сенімділік анкерлерін сақтауға мәжбүр болады деп есептелді. DLV-нің мақсаты – валидаторларға сенімділік анкерлерін басқару жұмысын сенімді үшінші тарапқа жүктеуге мүмкіндік беру болды. DLV тіркелгісі әр валидатордың өз тізімін жүргізуінің орнына сенімділік анкерлерінің орталық тізімін ұстады. DLV-ді пайдалану үшін, BIND немесе Unbound сияқты, оны қолдайтын және DLV аймағы үшін сенімділік анкерімен конфигурацияланған валидатор қажет болды. Бұл аймақта DLV жазбалары болды; олардың форматы DS жазбаларымен бірдей болды, бірақ олар берілген қосалқы аймаққа сілтеме жасаудың орнына DNS ағашының басқа бөлігіндегі аймаққа сілтеме жасады. Валидатор түбірден тексеріліп жатқан RRset-ке дейін сенімділік тізбегін таба алмаған жағдайда, ол сенімділіктің балама тізбегін ұсына алатын DLV жазбасын іздеді. Сенімділік тізбегіндегі үзілістер, мысалы, қол қойылмаған жоғары деңгейлі домендер немесе DNSSEC делегацияларын қолдамайтын тіркеушілер, төменгі деңгейлі домендердің әкімшілеріне DLV-ді пайдалану арқылы олардың DNS деректерін DLV-ді пайдалануға конфигурацияланған ажыратушылармен тексеруге мүмкіндік берді. Бұл, тіркеушілер мен TLD тізілімдеріне DNSSEC-ті дұрыс қолдау үшін қысым жасау арқылы DNSSEC-ті енгізуге кедергі келтірген болуы мүмкін. DLV сонымен қатар DNSSEC-ті тексеру үшін қосымша актерлер мен код жолдарын қосу арқылы күрделілікті арттырды. ISC 2017 жылы DLV тіркелгісін тоқтатты. DLV қолдауы BIND 9.12 нұсқасында ескірді және BIND 9.16 нұсқасынан толығымен алынып тасталды. Unbound 1.5.4 нұсқасы (2015 жылдың шілдесі) DLV-ді үлгілік конфигурацияда және нұсқаулық бетінде ескірген деп белгіледі. Knot Resolver және PowerDNS Recursor DLV-ді ешқашан іске асырмады. 2020 жылдың наурызында IETF , DLV-ді стандарт ретінде зейнеткерлікке шығарып, RFC 4432 және RFC 5074-ті "Тарихи" статусына көшті.

On January 25, 2010, the L (ell) root server began serving a Deliberately Unvalidatable Root Zone (DURZ). The zone uses signatures of a SHA 2 (SHA 256) hash created using the RSA algorithm, as defined in As of May 2010, all thirteen root servers began serving the DURZ. DLV was intended to make DNSSEC easier to deploy in the absence of a root trust anchor. At the time it was imagined that a validator might have to maintain large numbers of trust anchors corresponding to signed subtrees of the DNS. The purpose of DLV was to allow validators to offload the effort of managing a trust anchor repository to a trusted third party. The DLV registry maintained a central list of trust anchors, instead of each validator repeating the work of maintaining its own list. To use DLV, a validator that supports it was needed, such as BIND or Unbound, configured with a trust anchor for a DLV zone. This zone contained DLV records; these had exactly the same format as DS records, but instead of referring to a delegated sub zone, they referred to a zone elsewhere in the DNS tree. When the validator could not find a chain of trust from the root to the RRset it is trying to check, it searched for a DLV record that could provide an alternative chain of trust. Gaps in the chain of trust, such as unsigned top level domains or registrars that did not support DNSSEC delegations, meant administrators of lower level domains could use DLV to allow their DNS data to be validated by resolvers which had been configured to use DLV. This may have hindered DNSSEC deployment by taking pressure off registrars and TLD registries to properly support DNSSEC. DLV also added complexity by adding more actors and code paths for DNSSEC validation. ISC decommissioned its DLV registry in 2017. DLV support was deprecated in BIND 9.12 and completely removed from BIND 9.16. Unbound version 1.5.4 (July 2015) marked DLV as decommissioned in the example configuration and manual page. Knot Resolver and PowerDNS Recursor never implemented DLV. In March 2020, the IETF published , retiring DLV as a standard and moving RFC 4432 and RFC 5074 to "Historic" status.

DNSSEC-ті АҚШ федералды үкіметінің қолдану бастамасы

АҚШ-тың Ішкі қауіпсіздік департаментінің ғылым және технология басқармасы "DNSSEC Deployment Initiative" бағдарламасын демеушілік етеді. Бұл бастама "Интернет атау инфрақұрылымының қауіпсіздігін жақсартатын қауіпсіздік шараларын ерікті түрде қабылдауға барлық секторларды шақырады, бұл көптеген елдер мен мемлекеттік және жеке сектордағы ұйымдарды қамтитын жаһандық, ынтымақтастық күш-жігерінің бір бөлігі болып табылады." DHS сонымен қатар DNSSEC-ті жетілдіруге және оны АҚШ-тың федералды үкіметі ішінде енгізуге бағытталған жұмыстарды қаржыландырады. 2007 жылдың 30 наурызында АҚШ-тың Ішкі қауіпсіздік департаменті "ДНС түбірлік аймағына қол қою кілті АҚШ үкіметінің сенімді қолында болуын" ұсынды деген хабарлама тарады. Алайда, кездесу залында АҚШ үкіметінің бірде-бір өкілі болған жоқ, ал мақаланы тудырған пікірді басқа тарап айтқан. Кейіннен DHS, АҚШ үкіметі мұндай ұсыныс жасады деген жалған қорытындыға басқалар қалай келгені туралы түсіндірме берді: "АҚШ Ішкі қауіпсіздік департаменті DNSSec-ті іске асырудың техникалық жоспасын әзірлеуді қаржыландырады және өткен қазанда оның бастапқы жобасын көптеген халықаралық сарапшыларға пікір білдіру үшін жіберді. Жобада түбірлік аймақ кілтінің иесі немесе "операторы" кім болуы мүмкін екенінің бірнеше нұсқасы қарастырылған, ол негізінен мемлекеттік органға немесе мердігерге дейін тоғысып келеді. "Біз құжаттың ешбір жерінде түбірлік кілт операторының кім екені туралы ешқандай ұсыныс жасамадық", - деді Homeland Security-тің киберқауіпсіздік зерттеу және дамыту басқарушысы Моуган.

DNSSEC-ті АҚШ-тың федералды үкіметінде қолдану

Ұлттық стандарттар және технологиялар институты (NIST) 2006 жылдың 16 мамырында NIST арнайы басылымы 800-81 «Secure Domain Name System (DNS) Deployment Guide» құжатын жариялады, онда DNSSEC-ті қалай енгізуге болатындығы туралы нұсқаулар келтірілген. NIST осы енгізу нұсқаулығына сілтеме жасай отырып, NIST SP800-53 R1 құжатында жаңа DNSSEC Federal Information Security Management Act (FISMA) талаптарын жариялауды жоспарлаған. АҚШ агенттіктері NIST SP800-53 R1 соңғы рет жарияланғаннан кейін бір жыл ішінде осы жаңа FISMA талаптарын орындауға тиіс болған. Алайда, сол кезде NSEC3 әлі аяқталмаған еді. NIST екіге бөлінген домендерді пайдалануды ұсынды, бұл техника мүмкін екені белгілі, бірақ дұрыс орнату қиын және жоғарыда айтылған қауіпсіздік кемшіліктеріне ие. 2008 жылдың 22 тамызында Басқару және Бюджет кеңсесі (OMB) АҚШ Федералдық агенттіктеріне gov домендерінде DNSSEC-ті енгізуді талап ететін меморандум шығарды; gov түбірлік домені 2009 жылдың қаңтарына дейін, ал gov доменінің барлық кіші домендері 2009 жылдың желтоқсанына дейін қол қойылған болуы керек еді. Меморандумда gov домендеріне назар аударылғанмен, АҚШ Қорғаныс ақпараттық жүйелер агенттігі (DIA) OMB DNSSEC талаптарын mil (АҚШ әскери) доменінде де орындауға ниетті екенін мәлімдеді. NetworkWorld-тің Кэролин Даффи Марсан DNSSEC-тің «OMB талаптарымен байланысты классикалық «тауық пен жұмыртқа» дилеммасынан зардап шегуіне байланысты кеңінен қолданылмағанын, бірақ енді «жұмыртқа жарылып жатқандай» сезім тудыратынын» айтты.

Резолюторларға орналастыру

Бірнеше интернет-провайдерлер DNSSEC-ті тексерілген DNS рекурсивті шешушілерді енгізуді бастады. Comcast АҚШ-та мұны іске асырған алғашқы ірі интернет-провайдер болды, 2010 жылдың 18 қазанында өз ниеттерін жариялап, 2012 жылдың 11 қаңтарында енгізуді аяқтады. APNIC жүргізген зерттеуге сәйкес, DNSSEC-ті тексеруді жүзеге асыратын DNS шешушілерді ғана пайдаланатын клиенттердің үлесі 2013 жылдың мамыр айында 8,3%-ға жетті. Осы клиенттердің шамамен жартысы Google-дың қоғамдық DNS шешушісін пайдаланды. 2015 жылдың қыркүйегінде Verisign тегін қоғамдық DNS шешуші қызметін жариялады, және баспасөз хабарламаларында көрсетілмесе де, ол DNSSEC тексеруін де жүргізеді. 2016 жылдың басына қарай APNIC мониторингі DNSSEC-ті тексеруді жүзеге асыратын DNS шешушілерді ғана пайдаланатын клиенттердің үлесі шамамен 15%-ға дейін өскенін көрсетті.

DNSSEC қолдау

Google-дің жалпыға қолжетімді рекурсивті DNS сервері 2013 жылдың 6 мамырында DNSSEC растауын қосты. BIND, ең көп қолданылатын DNS басқару бағдарламалық құралы, 9.5 нұсқасынан бастап DNSSEC қолдауын әдепкі бойынша қосады. Quad9 жалпыға қолжетімді рекурсивті DNS 2016 жылдың 11 мамырында құрылғаннан бері өзінің негізгі 9.9.9.9 мекенжайында DNSSEC растауын жүзеге асырып келеді. Quad9 сондай-ақ, негізінен қателерді жою мақсатында DNSSEC растауын жүзеге асырмайтын баламалы қызметті ұсынады.