DNSSEC

**Դոմենային անունների համակարգի անվտանգության ընդարձակումներ** (, DNSSEC), Ինտերնետ ինժեներական խորհրդի (IETF) ընդլայնման առանձնահատկությունների փաթեթ է՝ Ինտերնետ պրոտոկոլի (IPv6 համացանցային հաղորդակարգ) ցանցերում Դոմենային անունների համակարգում (DNS) փոխանակված տվյալների ապահովման համար: Պրոտոկոլն ապահովում է տվյալների իմիտացիոն պաշտպանություն, պրոքսի սերվերի միջոցով տվյալների փոխանցման գոյության մերժում և տվյալների ամբողջականություն, բայց ոչ հասանելիություն կամ գաղտնիություն։

## Ընդհանուր ակնարկ
Դոմենային անունների համակարգի սկզբնական դիզայնը չի ներառում անվտանգության որևէ առանձնահատկություն: Այն ընկալվել է միայն որպես ընդլայնելի բաշխված համակարգ: DNSSEC փորձում է ավելացնել անվտանգությունը՝ միաժամանակ պահպանելով հետընթաց համատեղելիությունը: 2004 թվականի RFC 3833-ը փաստագրում է DNS-ին սպառնացող որոշ հայտնի սպառնալիքներ և դրանց լուծումները DNSSEC-ում:

DNSSEC-ը ստեղծվել է DNS օգտագործող հավելվածները պաշտպանելու կեղծված կամ մանիպուլյացիայի ենթարկված DNS տվյալների ընդունումից, ինչպիսին է 	
DNS spoofing-ը: DNSSEC պաշտպանված գոտիների բոլոր պատասխանները թվային են ստորագրված։ Ստուգելով թվային ստորագրությունը՝ DNS լուծիչը կարող է ստուգել՝ արդյոք տեղեկատվությունը նույնական է (այսինքն՝ չփոփոխված և ամբողջական) գոտու սեփականատիրոջ կողմից հրապարակված և հեղինակավոր DNS սերվերի վրա մատուցվող տեղեկատվությանը: Թեև IP հասցեների պաշտպանությունը շատ օգտատերերի անմիջական մտահոգությունն է, DNSSEC-ը կարող է պաշտպանել DNS-ում հրապարակված ցանկացած տվյալ, ներառյալ տեքստային գրառումները (TXT) և փոստի փոխանակման գրառումները (MX), և կարող է օգտագործվել անվտանգության այլ համակարգերի բեռնաթափման համար, որոնք հրապարակում են DNS-ում պահվող վկայագրերի գաղտնագրման հղումներ, ինչպիսիք են (CERT records, RFC 4398), SSH մատնահետքերը (SSHFP, IETF RFC 4255), IPSec հանրային բանալիներ (IPSECKEY, IETF RFC 4025), TLS Trust Anchors (TLSA, IETF RFC 6698) կամ գաղտնագրված հաճախորդի բարև (SVCBH))։

DNSSEC-ը չի ապահովում տվյալների գաղտնիությունը. մասնավորապես, DNSSEC-ի բոլոր պատասխանները վավերացված են, բայց ոչ ծածկագրված:

Այլ ստանդարտներ (ոչ DNSSEC) օգտագործվում են DNS սերվերների միջև ուղարկված զանգվածային տվյալների ապահովման համար (օրինակ՝ DNS գոտու փոխանցում): Ինչպես փաստագրված է, որոշ օգտատերեր և մշակողներ կեղծ ենթադրություններ են անում DNS անունների վերաբերյալ, օրինակ՝ ենթադրելով, որ ընկերության ընդհանուր անունը գումարած «.com» միշտ նրա տիրույթի անունն է:

DNSSEC բնութագրերը (կոչվում են DNSSEC-bis) մանրամասն նկարագրում են ընթացիկ DNSSEC արձանագրությունը: Տես IETF RFC 4033, IETF RFC 4034, and  IETF RFC 4035։ Այս նոր RFC-ների հրապարակմամբ (2005 թվականի մարտ) ավելի վաղ RFC-ն՝ RFC 2535-ը, հնացել է: RFC-ների ամբողջական փաթեթը, որը նշում է DNSSEC-ը, հավաքվում է RFC 9364-ում, որը նաև BCP 237 է:

Տարածված կարծիք կա, որ DNS-ի անվտանգությունը չափազանց կարևոր է ամբողջ ինտերնետի ապահովման համար, սակայն DNSSEC-ի տեղակայումը հատկապես խոչընդոտվել է մի քանի դժվարություններով․
* Հետընթացի հետ համատեղելի ստանդարտի նախագծման անհրաժեշտությունը, որը կարող է չափվել ըստ ինտերնետի չափերի,
* Ցանկության դեպքում «գոտիների հաշվառման» կանխարգելում,
* DNSSEC-ի ներդրում DNS սերվերների և լուծիչների (հաճախորդների) լայն տեսականիով,
* Իրականացնողների միջև տարաձայնություն այն հարցում, թե ով պետք է տիրապետի վերին մակարդակի դոմենի արմատային բանալիները,
* DNSSEC-ի և DNSSEC-ի տեղակայման ընկալվող բարդության հաղթահարում։

## Գործառնություն
DNSSEC-ն աշխատում է թվային ստորագրելով գրառումները DNS որոնման համար՝ օգտագործելով հանրային բանալիների գաղտնագրությունը։ DNSKEY-ի ճիշտ գրառումը վավերացվում է վստահության շղթայի միջոցով՝ սկսած DNS արմատական դոմենի համար հաստատված հանրային բանալիների մի շարքից, որը վստահելի երրորդ կողմն է: Դոմենների սեփականատերերը ստեղծում են իրենց սեփական բանալիները և վերբեռնում դրանք՝ օգտագործելով իրենց DNS կառավարման վահանակը իրենց դոմենի անունների գրանցամատյանում, որն իր հերթին բանալիները secDNS-ի միջոցով հրում է դոմենի օպերատորին (օրինակ՝ Verisign .com-ի համար), որը ստորագրում և հրապարակում է դրանք DNS-ում:

### Ռեսուրսների գրառումներ
DNS-ն իրականացվում է մի քանի ռեսուրսների գրառումների օգտագործմամբ: DNSSEC-ն իրականացնելու համար ստեղծվել կամ հարմարեցվել են DNS գրառումների մի քանի նոր տեսակներ՝ DNSSEC-ի հետ օգտագործելու համար․
;RRSIG (ռեսուրսների գրանցման ստորագրություն)
Ներառում է DNSSEC ստորագրությունը գրառումների հավաքածուի համար: DNS լուծիչները ստուգում են ստորագրությունը հանրային բանալիով, որը պահվում է DNSKEY գրառումում,
;DNSKEY
Ներառում է հանրային բանալի, որն օգտագործում է DNS լուծիչը՝ RRSIG գրառումներում DNSSEC ստորագրությունները ստուգելու համար,
;DS (պատվիրակության ստորագրող)
Ներառում է պատվիրակված գոտու անվանումը: Հղում է DNSKEY գրառումը ենթապատվիրակված գոտում: DS գրառումը տեղադրվում է մայր գոտում՝ պատվիրակող NS գրառումների հետ միասին,
;NSEC (հաջորդ անվտանգ գրառում)
Ներառում է հղում դեպի դոմենի հաջորդ գրառումների անվանը և թվարկում է գրառման անվան համար գոյություն ունեցող տեսակները,DNSSEC վավերացման մաս:
;NSEC3 (հաջորդ անվտանգ գրառման տարբերակը 3)
Ներառում է գոտու հաջորդ գրառման անվան հղումներ (հաշված անունների տեսակավորման կարգով) և թվարկում է գրառումների տեսակները, որոնք գոյություն ունեն NSEC3 գրառումի սեփական անվան առաջին պիտակի մեջ պարունակվող հեշ արժեքով ծածկված անվան համար: Այս գրառումները կարող են օգտագործվել լուծիչների կողմից՝ ստուգելու գրառումների անվան և տեսակի բացակայությունը՝ որպես DNSSEC վավերացման մաս: NSEC3 գրառումները նման են NSEC գրառումներին, սակայն NSEC3-ն օգտագործում է գաղտնագրությամբ հաշված գրառումների անուններ՝ խուսափելու դոմենում գրառումների անունների թվարկումից:
;NSEC3PARAM (հաջորդ անվտանգ գրանցման 3-րդ տարբերակի պարամետրերը)
Հեղինակավոր DNS սերվերներն օգտագործում են այս գրառումը՝ հաշվարկելու և որոշելու, թե որ NSEC3 գրառումները պետք է ներառվեն գոյություն չունեցող անունների/տեսակների վերաբերյալ DNSSEC հարցումների պատասխաններում:

DNSSEC կիրառելիս՝ DNS որոնման յուրաքանչյուր պատասխան ներառում է RRSIG DNS գրառում՝ ի լրումն պահանջվող գրառման տեսակի: RRSIG գրառումը թվային ստորագրությունն է DNS ռեսուրսի ռեսուրսի պատասխանների հավաքածուի համար: Թվային ստորագրությունը ստուգվում է՝ գտնելով DNSKEY գրառումում հայտնաբերված ճիշտ հանրային բանալին: NSEC և NSEC3 գրառումներն օգտագործվում են որևէ ռեսուրսային գրառման (RR) գոյություն չունենալու մասին ծածկագրային ապացույցներ տրամադրելու համար: DS գրառումն օգտագործվում է DNSKEY-ների նույնականացման համար որոնման ընթացակարգում՝ օգտագործելով վստահության շղթան: NSEC և NSEC3 գրառումներն օգտագործվում են կեղծիքի դեմ կայուն դիմադրության համար:

#### Ալգորիթմներ
DNSSEC-ը նախագծվել է ընդարձակելի լինելու համար, որպեսզի մինչ առկա ալգորիթմների դեմ հարձակումները հայտնաբերվեն, նորերը կարող են ներդրվել հետին համատեղելի ձևով, ինչպես նկարագրված է IETF RFC 8624-ում։ Աղյուսակը սահմանում է 2019 թվականի հունիսի դրությամբ անվտանգության այն ալգորիթմները, որոնք առավել հաճախ օգտագործվում են կամ օգտագործվել են․

### Որոնման ընթացակարգ
DNS-ի որոնման արդյունքներից անվտանգությանը տեղյակ DNS լուծիչը կարող է որոշել, թե արդյոք հարցվող դոմենի հեղինակավոր անունների սերվերն աջակցում է DNSSEC-ին, արդյոք նրա ստացած պատասխանն ապահով է և արդյոք առկա է որևէ տեսակի սխալ: Փնտրման ընթացակարգը տարբեր է ռեկուրսիվ անունների սերվերների համար, ինչպիսիք են բազմաթիվ ISP-ների, և սթաբ ռեզոլվների համար, ինչպիսիք են հիմնական օպերացիոն համակարգերում լռելյայն ներառվածները: Մայքրոսոֆթ Վինդոուզն օգտագործում է սթաբ ռեզոլվներ, իսկ Windows Server 2008 R2-ը և Windows 7-ը, մասնավորապես, օգտագործում են չվավերացնող, բայց DNSSEC-ից տեղյակ սթաբ ռեզոլվներ։

#### Ռեկուրսիվ անունների սերվերներ
Օգտագործելով վստահության շղթայի մոդելը, մայր տիրույթում (DNS դոմեն) Delegation Signer (DS) գրառումը կարող է օգտագործվել ենթադոմեյնում DNSKEY գրառումը ստուգելու համար, որն այնուհետև կարող է պարունակել այլ DS գրառումներ՝ հետագա ենթադոմեյնները ստուգելու համար: Ռեկուրսիվ ռեզոլվերը, ինչպիսին է ISP անունների սերվերը, ցանկանում է ստանալ «www.example.com» դոմենի IP հասցեները (A գրառում և/կամ AAAA գրառումներ):

# Գործընթացը սկսվում է, երբ անվտանգությանը տեղյակ ռեզոլվերը դնում է «DO» («DNSSEC OK») դրոշակի բիթը DNS հարցումում: Քանի որ DO բիթը գտնվում է ընդլայնված դրոշի բիթերում, որոնք սահմանված են DNS-ի (EDNS) ընդլայնման մեխանիզմներով IETF RFC 6891, բոլոր DNSSEC գործարքները պետք է աջակցեն EDNS-ին: Անհրաժեշտ է նաև EDNS աջակցություն՝ թույլ տալու համար DNSSEC գործարքներ պահանջող ավելի մեծ փաթեթների չափսեր,
# Երբ ռեզոլվերը պատասխան է ստանում սովորական DNS որոնման գործընթացի միջոցով, այնուհետև ստուգում է՝ համոզվելու, որ պատասխանը ճիշտ է: Իդեալում, անվտանգության մասին տեղյակ ռեզոլվերը կսկսի արմատական դոմենի DS և DNSKEY գրառումները ստուգելուց: Այնուհետև այն կօգտագործի DS գրառումները «com» վերին մակարդակի դոմենի համար, որը գտնվել է արմատում՝ ստուգելու DNSKEY գրառումները «com» գոտում: Այնտեղից այն կտեսնի, թե արդյոք կա «example.com» ենթադոմեյնի DS գրառում «com» գոտում, և եթե լինի, ապա կօգտագործի DS գրառումը։ Վերջապես, այն կհաստատի «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 թվականի հուլիսի 15-ի դրությամբ DNSSEC-ի տեղակայումը արմատականացման համար ավարտված է։ .com տիրույթը ստորագրվել է վավեր անվտանգության բանալիներով, և ապահով պատվիրակությունն ավելացվել է արմատային գոտում 2011 թվականի ապրիլի 1-ին։

#### Անավարտ ռեզոլվերներ
«Նվազագույն DNS ռեզոլվերներ են, որոնք օգտագործում են ռեկուրսիվ հարցման ռեժիմ՝ DNS լուծման աշխատանքի մեծ մասը ռեկուրսիվ անունների սերվերի վրա բեռնաթափելու համար»։ Անավարտ ռեզոլվերը պարզապես հարցումը կուղարկի ռեկուրսիվ անունների սերվերին և պատասխանում կօգտագործի վավերացված տվյալների (AD) բիթը՝ որպես «պարզելու, թե արդյոք ռեկուրսիվ անունների սերվերը կարողացել է վավերացնել պատասխանի «Պատասխան» և «Լիազորություն» բաժինների բոլոր տվյալների ստորագրությունները»։ Մայքրոսոֆթ Վինդոուզն օգտագործում է անավարտ ռեզոլվեր, իսկ Windows Server 2008 R2-ը և Windows 7-ը, մասնավորապես, օգտագործում են չվավերացնող, բայց AD-bit-ի տեղեկացված անավարտ ռեզոլվեր։

Վավերացնող անավարտ ռեզոլվերը կարող է նաև պոտենցիալ կերպով կատարել իր ստորագրության վավերացումը՝ հարցման հաղորդագրություններում դնելով Checking Disabled (CD) բիթը։ Վավերացնող անավարտ ռեզոլվերն օգտագործում է CD բիթը՝ իր ռեկուրսիվ նույնականացումն իրականացնելու համար: Նման վավերացնող անավարտ ռեզոլվերի օգտագործումը հաճախորդին ապահովում է DNS-ի վերջնական անվտանգություն DNSSEC կիրառող դոմենների համար, նույնիսկ եթե ինտերնետ ծառայության մատակարարին կամ նրանց կապը վստահելի չէ:

Չվավերացնող անավարտ ռեզոլվերները պետք է հիմնվեն արտաքին DNSSEC վավերացման ծառայությունների վրա, ինչպիսիք են օգտատիրոջ ինտերնետ ծառայության մատակարարի կամ հանրային ռեկուրսիվ անունների սերվերի կողմից վերահսկվողները, ինչպես նաև իր և այդ անունների սերվերների միջև կապի ուղիները՝ օգտագործելով մեթոդներ, ինչպիսիք են DNS TLS-ի միջոցով։

### Վստահության խարիսխներին և նույնականացման շղթաներ
Որպեսզի կարողանանք ապացուցել, որ DNS պատասխանը ճիշտ է, անհրաժեշտ է իմանալ առնվազն մեկ բանալի կամ DS գրառում, որը ճիշտ է այլ աղբյուրներից, բացի DNS-ից: Այս ելակետերը հայտնի են որպես վստահության խարիսխներ և սովորաբար ստացվում են օպերացիոն համակարգով կամ որևէ այլ վստահելի աղբյուրի միջոցով: Երբ DNSSEC-ը նախագծվել էր ի սկզբանե, կարծում էին, որ միակ վստահության խարիսխը, որը պետք կլինի արմատական դոմենն է: Արմատային խարիսխներն առաջին անգամ հրապարակվել են 2010 թվականի հուլիսի 15-ին։

Վավերացման շղթան իրենից ներկայացնում է միացված DS և DNSKEY գրառումներ, որոնք սկսվում են վստահության խարիսխից մինչև տվյալ դոմենի հեղինակավոր անունների սերվերը: Առանց վավերացման ամբողջական շղթայի, DNS որոնման պատասխանը չի կարող ապահով վավերացվել:

### Ստորագրություններ և գոտիների ստորագրում
Կրկնվող հարձակումները սահմանափակելու համար կան ոչ միայն սովորական DNS TTL արժեքներ քեշավորման նպատակով, այլ RRSIG գրառումներում լրացուցիչ ժամանակային դրոշմներ՝ ստորագրության վավերականությունը սահմանափակելու համար: Ի տարբերություն TTL արժեքների, որոնք հարաբերական են գրառումների ուղարկման ժամանակին, ժամանակի դրոշմները բացարձակ են: Սա նշանակում է, որ անվտանգության մասին տեղեկացված բոլոր DNS լուծիչները պետք է ունենան բավականին սերտորեն համաժամեցված ժամացույցներ, ասենք մի քանի րոպեի ընթացքում:

Այս ժամադրոշմները ենթադրում են, որ գոտին պետք է պարբերաբար վերստորագրվի և վերաբաշխվի երկրորդական սերվերներին, հակառակ դեպքում ստորագրությունները կմերժվեն վավերացնող լուծիչների միջոցով:

### Բանալու կառավարում
DNSSEC-ը ներառում է բազմաթիվ տարբեր բանալիներ, որոնք պահվում են ինչպես DNSKEY գրառումներում, այնպես էլ այլ աղբյուրներից՝ վստահության խարիսխներ ձևավորելու համար:

Բանալների փոխարինումը թույլատրելու համար անհրաժեշտ է **բանալիների փոխարկման** սխեմա: Որպես կանոն, դա ենթադրում է առաջին հերթին նոր բանալիների դուրսբերում նոր DNSKEY գրառումներում, ի լրումն առկա հին բանալիների: Այնուհետև, երբ կարելի է վստահորեն ենթադրել, որ գործող արժեքների ժամանակը հանգեցրել է հին բանալիների քեշավորման ավարտին, այս նոր բանալիները կարող են օգտագործվել: Ի վերջո, երբ կարելի է վստահորեն ենթադրել, որ հին ստեղների օգտագործմամբ գրառումների քեշավորման ժամկետը սպառվել է, հին DNSKEY գրառումները կարող են ջնջվել: Այս գործընթացը ավելի բարդ է այնպիսի բաների համար, ինչպիսիք են խարիսխներին վստահելու բանալիները, օրինակ՝ արմատից, ինչը կարող է պահանջել օպերացիոն համակարգի թարմացում:

DNSKEY գրառումներում բանալիները կարող են օգտագործվել երկու տարբեր բաների համար, և սովորաբար յուրաքանչյուրի համար օգտագործվում են տարբեր DNSKEY գրառումներ: Նախ, կան **բանալիների ստորագրման բանալիներ** (KSK), որոնք օգտագործվում են DNSKEY այլ գրառումներ ստորագրելու համար, որոնք պարունակում են **գոտու ստորագրման բանալիներ** (ZSK), որոնք օգտագործվում են այլ գրառումներ ստորագրելու համար: Քանի որ ZSK-ները լիովին հսկողության տակ են և օգտագործվում են մեկ որոշակի DNS գոտու կողմից, դրանք կարող են ավելի հեշտությամբ և ավելի հաճախ փոխվել: Արդյունքում, ZSK-ները կարող են շատ ավելի կարճ լինել, քան KSK-ները և դեռ առաջարկում են պաշտպանության նույն մակարդակը՝ միաժամանակ նվազեցնելով RRSIG/DNSKEY գրառումների չափը:

Երբ ստեղծվում է նոր KSK, DS գրառումը պետք է տեղափոխվի մայր գոտի և հրապարակվի այնտեղ: DS գրառումներն օգտագործում են KSK-ի կրիպտոգրաֆիկ հեշ ֆունկցիա ամբողջական բանալու փոխարեն՝ գրառումների չափը փոքր պահելու համար: Սա օգտակար է այնպիսի գոտիների համար, ինչպիսին է .com դոմենը, որոնք շատ մեծ են: Հիմնական գոտում DS բանալիների թարմացման ընթացակարգը նույնպես ավելի պարզ է, քան DNSSEC-ի նախկին տարբերակները, որոնք պահանջում էին, որ DNSKEY գրառումները լինեն հիմնական գոտում:

Սերտորեն կապված սկզբունքը Ալգորիթմի շրջադարձն է, որը ներառում է գոտի մի ստորագրող Ալգորիթմից մյուսը տեղափոխելը: Դրա լավ օրինակը կլինի Ալգորիթմ 8-ից (RSA/SHA-256) Ալգորիթմ 13 (ECDSA/SHA-256) միգրացիան: Մի քանի ccTLD-ներ արդեն տեղափոխվել են, այդ թվում .at, .br, .cz, .ch, .fr, .ie, .nl և .ph։ Verisign 2023 թվականի վերջին Ալգորիթմ 13 է տեղափոխել .com, .net և .edu։ Արմատային տիրույթի միգրացիան Ալգորիթմ 8-ից Ալգորիթմ 13 ներկայումս պլանավորվում է 2024 թվականին։

### DANE աշխատանքային խումբ
DNS-ի վրա հիմնված Անվանված սուբյեկտների նույնականացումը (DANE) IETF աշխատանքային խումբ է, որի նպատակն է մշակել պրոտոկոլներ և տեխնիկա, որոնք թույլ են տալիս ինտերնետ հավելվածներին գաղտնագրորեն ապահովված հաղորդակցություն հաստատել TLS, DTLS, SMTP և S/MIME-ի հետ՝ հիմնված DNSSEC-ի վրա

Նոր պրոտոկոլները հնարավորություն կտան լրացուցիչ երաշխիքներ և սահմանափակումներ ունենալ հանրային բանալիների ենթակառուցվածքի վրա հիմնված ավանդական մոդելի համար: Դրանք նաև հնարավորություն կտան տիրույթի սեփականատերերին հաստատել վկայագրեր իրենց համար՝ առանց երրորդ կողմի վկայականների մարմիններին հղում կատարելու:

Google Chrome 14-ում միացված է DNSSEC կեռավորված վկայագրերի աջակցությունը սակայն հետագայում հեռացվել է։ Mozilla Firefox-ի համար աջակցությունը տրամադրվել է հավելման միջոցով, մինչդեռ հայրենական աջակցությունը ներկայումս սպասում է ինչ-որ մեկին, ով կսկսի աշխատել դրա վրա։

## Պատմություն
DNS-ը կարևոր և հիմնարար ինտերնետային ծառայություն է, սակայն 1990 թվականին Սթիվ Բելովինը հայտնաբերեց դրա անվտանգության լուրջ թերությունները: Այն ապահովելու ուղղությամբ հետազոտությունները սկսվեցին և կտրուկ առաջընթաց ունեցան, երբ նրա թերթը հրապարակվեց 1995 թվականին։ Նախնական RFC 2065-ը հրապարակվել է IETF-ի կողմից 1997 թվականին, և այդ հստակեցման իրականացման սկզբնական փորձերը հանգեցրել են վերանայված (և համարվում է լիովին գործունակ) հստակեցման 1999 թվականին որպես IETF RFC 2535: Ծրագրեր են կազմվել RFC 2535-ի վրա հիմնված DNSSEC-ի տեղակայման համար:

Ցավոք, IETF RFC 2535 հստակեցումը շատ էական խնդիրներ ուներ ամբողջ ինտերնետի մասշտաբով. 2001 թվականին պարզ դարձավ, որ այս հատկանիշն անպիտան է մեծ ցանցերի համար: Նորմալ աշխատանքի ընթացքում DNS սերվերները հաճախ չեն համաժամանակացվում իրենց մայր սերվերների հետ: Սա սովորաբար խնդիր չէ, բայց երբ DNSSEC-ը միացված է, այս չհամաժամեցված տվյալները կարող են հանգեցնել լուրջ ինքնաստեղծ ծառայության մերժման: Բնօրինակ DNSSEC-ը պահանջում էր վեց հաղորդագրությունից բաղկացած բարդ պրոտոկոլ և մեծ թվով տվյալների փոխանցումներ՝ հիմնական փոփոխություններ կատարելու համար դուստր գոտում (դուստր DNS գոտիները պետք է ուղարկեին իրենց բոլոր տվյալները մայր գոտի, որպեսզի մայր գոտին ստորագրեր յուրաքանչյուր պրոտոկոլ, այնուհետև ուղարկի այդ ստորագրությունները դուստր գոտի, որպեսզի նա դրանք պահպանի SIG-ի գրառումներում): Բացի այդ, հանրային բանալու փոփոխությունները կարող են անհեթեթ հետևանքներ ունենալ. օրինակ, եթե «.com» գոտին փոխի իր հանրային բանալին, այն պետք է ներկայացնի 22 միլիոն գրառում (քանի որ անհրաժեշտ կլինի թարմացնել իր բոլոր դուստր ստորագրությունները): Այսպիսով, DNSSEC-ը, ինչպես սահմանված է RFC 2535-ում, չի կարող մասշտաբվել ինտերնետին:

IETF-ը հիմնարար փոփոխություններ է կատարել DNSSEC-ում, որն այժմ կոչվում է DNSSEC-bis՝ այն տարբերելու RFC 2535-ի սկզբնական DNSSEC մոտեցումից: Այս նոր տարբերակն օգտագործում է «պատվիրակության բաժանորդների (DS) ռեսուրսների գրառումները»՝ մայր և դուստր գոտիների միջև պատվիրակության կետերում անուղղության լրացուցիչ մակարդակ ապահովելու համար: Նոր մոտեցման դեպքում, երբ դուստր հիմնական հանրային բանալին փոխվում է,  յուրաքանչյուր մուտքի համար վեց հաղորդագրություն օգտագործելու փոխարեն օգտագործվում է մեկ պարզ հաղորդագրություն. դուստրը նոր հանրային բանալի է ուղարկում իր մայր գոտուն (իհարկե, ստորագրված): Մայր գոտին պարզապես պահում է մեկ հիմնական հանրային բանալի յուրաքանչյուր դուստր գոտու համար. դա շատ ավելի գործնական է: Սա նշանակում է, որ քիչ տվյալներ են փոխանցվում մայր գոտիներին: Սա նշանակում է, որ հաճախորդները ստիպված կլինեն մի փոքր ավելի շատ աշխատանք կատարել բանալիների ստուգման ժամանակ: Ավելի կոնկրետ, DNS գոտու KEY RRset-ի ստուգումը պահանջում է ստորագրության ստուգման երկու գործողություն՝ RFC 2535-ով պահանջվողի փոխարեն (ոչ մի ազդեցություն չկա RR-ների այլ տեսակների համար ստուգված ստորագրությունների քանակի վրա): Շատերը սա համարում են վճարման փոքր գին, քանի որ այն ավելի գործնական է դարձնում DNSSEC-ի տեղակայումը: Նոր տարբերակը հրապարակված է RFC4033-4035-ում։

2024 թվականի հունվարին հայտարարվել է «KeyTrap» ծառայության մերժման հարձակումը բոլոր տեխնիկական պայմաններին համապատասխանող DNSSEC ռեզոլվերների համար: DNSSEC հստակեցումը (RFC4033-4035) սահմանում է, որ ռեզոլվերը, երբ ստանում է ստորագրված փաթեթ վերին հոսանքով, պետք է փորձի բոլոր բանալիները բոլոր ստորագրությունների վրա ճիշտ «պիտակով», մինչև համակցություններից մեկը հաջողությամբ հաստատվի: Փաթեթում տեղադրելով նույն «պիտակով» բազմաթիվ բանալիներ և այդ «պիտակին» համապատասխանող բազմաթիվ ստորագրություններ՝ հետազոտողները կարող են դանդաղեցնել ռեզոլվերը 2 միլիոն գործակցով։ Ի պատասխան՝ ռեզոլվերները սկսել են սահմաններ դնել ստուգման սխալների քանակի, բանալիների պիտակների բախումների և հեշի հաշվարկների վրա։

## IETF հրապարակումներ
* RFC 2535 Domain Name System Security Extensions
* RFC 3225 Indicating Resolver Support of DNSSEC
* RFC 3226 DNSSEC and IPv6 A6 Aware Server/Resolver Message Size Requirements
* RFC 3833 A Threat Analysis of the Domain Name System
* RFC 4033 DNS Security Introduction and Requirements (DNSSEC-bis)
* RFC 4034 Resource Records for the DNS Security Extensions (DNSSEC-bis)
* RFC 4035 Protocol Modifications for the DNS Security Extensions (DNSSEC-bis)
* RFC 4398 Storing Certificates in the Domain Name System (DNS)
* RFC 4431 The DNSSEC Lookaside Validation (DLV) DNS Resource Record
* RFC 4470 Minimally Covering NSEC Records and DNSSEC On-line Signing
* RFC 4509 Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
* RFC 4641 DNSSEC Operational Practices
* RFC 4955 DNS Security (DNSSEC) Experiments
* RFC 5011 Automated Updates of DNS Security (DNSSEC) Trust Anchors
* RFC 5155 DNSSEC Hashed Authenticated Denial of Existence
* RFC 5702 Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC
* RFC 6014 Cryptographic Algorithm Identifier Allocation for DNSSEC
* RFC 6605 Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC
* RFC 6725 DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates
* RFC 6781 DNSSEC Operational Practices, Version 2
* RFC 6840 Clarifications and Implementation Notes for DNS Security (DNSSEC)
* RFC 6975 Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC)
* RFC 7129 Authenticated Denial of Existence in the DNS
* RFC 7344 Automating DNSSEC Delegation Trust Maintenance
* RFC 7583 DNSSEC Key Rollover Timing Considerations
* RFC 8078 Managing DS Records from the Parent via CDS/CDNSKEY
* RFC 8080 Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC
* RFC 8198 Aggressive Use of DNSSEC-Validated Cache
* RFC 8624 Algorithm Implementation Requirements and Usage Guidance for DNSSEC
* RFC 8749 Moving DNSSEC Lookaside Validation (DLV) to Historic Status
* RFC 9077 NSEC and NSEC3: TTLs and Aggressive Use
* RFC 9157 Revised IANA Considerations for DNSSEC
* RFC 9276 Guidance for NSEC3 Parameter Settings
* RFC 9364 (BCP 237) DNS Security Extensions

## Գործիքներ
DNSSEC-ի տեղադրումը պահանջում է ծրագրակազմ սերվերի և հաճախորդ։ Որոշ գործիքներ, որոնք աջակցում են DNSSEC-ին, ներառում են.
* Վինդոուզ 7-ը և Windows Server 2008 R2-ը ներառում է «անվտանգության մասին տեղյակ» լուծիչ, որն ի վիճակի է տարբերակել անվտանգ և ոչ անվտանգ պատասխանները ռեկուրսիվ անունների սերվերի միջոցով: Windows Server 2012 DNSSEC-ը համատեղելի է անվտանգ դինամիկ թարմացումների հետ Active Directory-ում ինտեգրված գոտիներով, ինչպես նաև Active Directory-ի խարիսխի ստեղների կրկնօրինակմամբ այլ նման սերվերների վրա։
* BIND-ը՝ DNS անունների ամենահայտնի սերվերը (որը ներառում է dig - Domain Information Groper), ներառում է ավելի նոր *DNSSEC-bis* (DS գրառումներ) պրոտոկոլ, ինչպես նաև աջակցություն NSEC3 գրառումների համար։
* Unbound DNS անվան սերվեր է, որը գրվել է ի սկզբանե, որպեսզի նախագծվի DNSSEC կոնցեպտների շուրջ:
* mysqlBind, GPL DNS կառավարման ծրագրակազմը DNS ASP-ների համար, այժմ աջակցում է DNSSEC-ին:
* OpenDNSSEC նշանակված DNSSEC ստորագրող գործիք է, որն օգտագործում է PKCS#11՝ ապարատային անվտանգության մոդուլների հետ ինտերֆեյսի համար:
* Knot DNS ավելացրել է DNSSEC ավտոմատ մուտքագրման աջակցություն 1.4.0 տարբերակում:
* PowerDNS ամբողջությամբ աջակցում է DNSSEC-ին 3.0 տարբերակին՝ նախապես ստորագրված և ուղիղ ստորագրված ռեժիմներով։
* DNSSEC: Ինչ է սա և ինչու է անհրաժեշտ այն երկարաժամկետ իրականացնել — Ստուգեք այն Համացանցային համայնքի և Նիդեռլանդների կառավարության նախաձեռնությունը

## Տես նաև
*DNSCrypt
*DNSCurve
*DNS ընդլայնման մեխանիզմներ
*TSIG
*RPKI

## Ծանոթագրություններ

## Հավելյալ գրականություն
* 

## Արտաքին հղումներ
* DNSSEC – DNSSEC information site: DNSSEC.net
* DNSEXT DNS Extensions IETF Working Group
* DNSSEC-Tools Project

Կատեգորիա:Դոմենի անվան համակարգ
Կատեգորիա:Դոմենի անվան համակարգի ընդարձակումներ
Կատեգորիա:Ինտերնետի ստանդարտներ
Կատեգորիա:Ցանցային հաղորդակարգեր