Երկու տարվա զարգացումից հետո ISC կոնսորցիումը թողարկել է BIND 9.18 DNS սերվերի հիմնական նոր մասնաճյուղի առաջին կայուն թողարկումը: 9.18 մասնաճյուղի համար աջակցություն կտրամադրվի երեք տարով՝ մինչև 2 թվականի 2025-րդ եռամսյակը՝ որպես ընդլայնված աջակցության ցիկլի մաս: 9.11 մասնաճյուղի աջակցությունը կավարտվի մարտին, իսկ 9.16 մասնաճյուղին աջակցությունը՝ 2023 թվականի կեսերին: BIND-ի հաջորդ կայուն տարբերակի ֆունկցիոնալությունը զարգացնելու համար ձևավորվել է BIND 9.19.0 փորձնական մասնաճյուղ:
BIND 9.18.0-ի թողարկումն աչքի է ընկնում HTTPS-ով (DoH, DNS՝ HTTPS-ով) և DNS-ով TLS-ով (DoT, DNS՝ TLS-ով), ինչպես նաև XoT (XFR-over-TLS) մեխանիզմով DNS-ի աջակցությամբ: DNS բովանդակության անվտանգ փոխանցման համար. գոտիներ սերվերների միջև (աջակցվում են և՛ ուղարկող, և՛ ստացող գոտիները XoT-ի միջոցով): Համապատասխան կարգավորումների դեպքում մեկ անունով գործընթացն այժմ կարող է սպասարկել ոչ միայն ավանդական DNS հարցումները, այլև DNS-over-HTTPS-ի և DNS-over-TLS-ի միջոցով ուղարկված հարցումները: DNS-over-TLS-ի հաճախորդների աջակցությունը ներկառուցված է dig utility-ում, որը կարող է օգտագործվել TLS-ով հարցումներ ուղարկելու համար, երբ նշված է «+tls» դրոշը:
DoH-ում օգտագործվող HTTP/2 արձանագրության իրականացումը հիմնված է nghttp2 գրադարանի օգտագործման վրա, որը ներառված է որպես ընտրովի հավաքման կախվածություն: DoH-ի և DoT-ի հավաստագրերը կարող են տրամադրվել օգտագործողի կողմից կամ ստեղծվել ավտոմատ կերպով գործարկման պահին:
Դիմումների մշակումը DoH-ի և DoT-ի միջոցով միացված է՝ ավելացնելով «http» և «tls» տարբերակները լսելու հրահանգին: Չկոդավորված DNS-over-HTTP-ն աջակցելու համար կարգավորումներում պետք է նշեք «tls none»: Բանալիները սահմանվում են «tls» բաժնում: Լռելյայն ցանցի 853 նավահանգիստները DoT-ի համար, 443-ը՝ DoH-ի և 80-ը՝ DNS-over-HTTP-ի համար, կարող են վերացվել tls-port, https-port և http-port պարամետրերի միջոցով: Օրինակ:
tls local-tls { key-file "/path/to/priv_key.pem"; cert-file «/path/to/cert_chain.pem»; }; http local-http-server { endpoints { "/dns-query"; }; }; ընտրանքներ { https-port 443; listen-on port 443 tls local-tls http myserver {any;}; }
BIND-ում DoH-ի իրականացման առանձնահատկություններից մեկը TLS-ի համար գաղտնագրման գործողություններն այլ սերվեր տեղափոխելու հնարավորությունն է, ինչը կարող է անհրաժեշտ լինել այն պայմաններում, երբ TLS վկայագրերը պահվում են մեկ այլ համակարգում (օրինակ՝ վեբ սերվերներով ենթակառուցվածքում) և պահպանվում: այլ անձնակազմի կողմից: Չկոդավորված DNS-ի վրա HTTP-ի աջակցությունն իրականացվում է վրիպազերծումը պարզեցնելու և որպես ներքին ցանցի մեկ այլ սերվերի փոխանցման շերտ (կոդավորումը առանձին սերվեր տեղափոխելու համար): Հեռավոր սերվերի վրա nginx-ը կարող է օգտագործվել TLS տրաֆիկ ստեղծելու համար, ինչպես որ HTTPS կապը կազմակերպվում է կայքերի համար:
Մեկ այլ առանձնահատկություն է DoH-ի ինտեգրումը որպես ընդհանուր փոխադրամիջոց, որը կարող է օգտագործվել ոչ միայն լուծողին ուղղված հաճախորդի հարցումները լուծելու համար, այլև սերվերների միջև շփվելիս, հեղինակավոր DNS սերվերի միջոցով գոտիներ փոխանցելիս և այլ DNS-ով աջակցվող ցանկացած հարցում մշակելիս: փոխադրումներ.
Թերություններից, որոնք կարելի է փոխհատուցել՝ անջատելով կառուցումը DoH/DoT-ով կամ գաղտնագրումը այլ սերվեր տեղափոխելով, առանձնանում է կոդերի բազայի ընդհանուր բարդությունը՝ ավելացվել է ներկառուցված HTTP սերվեր և TLS գրադարան, որը կարող է պարունակել։ խոցելիություններ և հանդես են գալիս որպես հարձակումների լրացուցիչ վեկտորներ: Բացի այդ, DoH-ի օգտագործման ժամանակ երթևեկությունն ավելանում է:
Հիշենք, որ DNS-over-HTTPS-ը կարող է օգտակար լինել պրովայդերների DNS սերվերների միջոցով պահանջվող հոսթների անունների մասին տեղեկատվության արտահոսքը կանխելու, MITM հարձակումների և DNS տրաֆիկի կեղծման դեմ (օրինակ՝ հանրային Wi-Fi-ին միանալիս), հակազդելու համար։ արգելափակում DNS մակարդակում (DNS-over-HTTPS-ը չի կարող փոխարինել VPN-ին DPI մակարդակում իրականացվող արգելափակումը շրջանցելով) կամ աշխատանքի կազմակերպման համար, երբ անհնար է ուղղակիորեն մուտք գործել DNS սերվերներ (օրինակ՝ վստահված անձի միջոցով աշխատելիս): Եթե նորմալ իրավիճակում DNS հարցումներն ուղղակիորեն ուղարկվում են համակարգի կազմաձևում սահմանված DNS սերվերներին, ապա DNS-over-HTTPS-ի դեպքում հյուրընկալող IP հասցեն որոշելու հարցումը կցվում է HTTPS տրաֆիկի մեջ և ուղարկվում է HTTP սերվեր, որտեղ Լուծիչը հարցումները մշակում է Web API-ի միջոցով:
«DNS-ը TLS-ով» տարբերվում է «DNS-ից՝ HTTPS-ից» ստանդարտ DNS արձանագրության կիրառմամբ (սովորաբար օգտագործվում է ցանցային պորտը 853), որը փաթաթված է գաղտնագրված կապի ալիքով, որը կազմակերպվել է TLS արձանագրության միջոցով՝ հոսթի վավերականության ստուգմամբ՝ վավերացված TLS/SSL վկայագրերի միջոցով: սերտիֆիկացման մարմնի կողմից: Գոյություն ունեցող DNSSEC ստանդարտը օգտագործում է կոդավորումը միայն հաճախորդի և սերվերի նույնականացման համար, սակայն չի պաշտպանում երթևեկությունը գաղտնալսումից և չի երաշխավորում հարցումների գաղտնիությունը:
Որոշ այլ նորամուծություններ.
- Ավելացվել են tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer և udp-send-buffer կարգավորումները՝ TCP-ի և UDP-ի միջոցով հարցումներ ուղարկելու և ստանալու ժամանակ օգտագործվող բուֆերների չափերը սահմանելու համար: Զբաղված սերվերների վրա մուտքային բուֆերների ավելացումը կօգնի խուսափել երթևեկության գագաթնակետերի ժամանակ փաթեթների անկումից, իսկ դրանց կրճատումը կօգնի ազատվել հին հարցումների պատճառով հիշողության խցանումից:
- Ավելացվել է «rpz-passthru» նոր կատեգորիա, որը թույլ է տալիս առանձին գրանցել RPZ (Արձագանքման քաղաքականության գոտիներ) վերահասցեավորման գործողությունները:
- Պատասխան-քաղաքականություն բաժնում ավելացվել է «nsdname-wait-recurse» տարբերակը, երբ «ոչ» է դրված, RPZ NSDNAME կանոնները կիրառվում են միայն այն դեպքում, եթե քեշում առկա հեղինակավոր անունների սերվերները գտնվեն հարցման համար, հակառակ դեպքում՝ RPZ NSDNAME կանոնը անտեսվում է, սակայն տեղեկատվությունը վերցվում է հետին պլանում և կիրառվում է հետագա հարցումների համար:
- HTTPS և SVCB տեսակներով գրառումների համար իրականացվել է «ԼՐԱՑՈՒՑԻՉ» բաժնի մշակումը:
- Ավելացվել են սովորական թարմացման քաղաքականության կանոնների տեսակները՝ krb5-subdomain-self-rhs և ms-subdomain-self-rhs, որոնք թույլ են տալիս սահմանափակել SRV և PTR գրառումների թարմացումը: Թարմացման քաղաքականության բլոկները նաև ավելացնում են գրառումների քանակի սահմանափակումներ սահմանելու հնարավորություն՝ անհատական յուրաքանչյուր տեսակի համար:
- Dig utility-ի ելքին ավելացվել է տրանսպորտային արձանագրության (UDP, TCP, TLS, HTTPS) և DNS64 նախածանցների մասին տեղեկատվություն: Վրիպազերծման նպատակների համար dig-ը ավելացրել է հատուկ հարցման նույնացուցիչ նշելու հնարավորություն (dig +qid= )
- Ավելացված է աջակցություն OpenSSL 3.0 գրադարանի համար:
- IP-ի մասնատման հետ կապված խնդիրները լուծելու համար, երբ մշակվում են DNS Flag Day 2020-ի կողմից հայտնաբերված մեծ DNS հաղորդագրությունները, լուծիչից հեռացվել է կոդը, որը կարգավորում է EDNS բուֆերի չափը, երբ հարցումին պատասխան չկա: EDNS բուֆերի չափն այժմ հաստատված է (edns-udp-size) բոլոր ելքային հարցումների համար:
- Կառուցման համակարգը փոխվել է autoconf-ի, automake-ի և libtool-ի համակցության օգտագործմանը:
- «Քարտեզ» ձևաչափով գոտիների ֆայլերի աջակցությունը (հիմնական ֆայլի ձևաչափի քարտեզ) դադարեցվել է: Այս ձևաչափի օգտատերերին խորհուրդ է տրվում գոտիները վերածել հումքի ձևաչափի՝ օգտագործելով named-compilezone կոմունալ ծրագիրը:
- Ավելի հին DLZ (Dynamically Loadable Zones) վարորդների աջակցությունը դադարեցվել է, այն փոխարինվել է DLZ մոդուլներով:
- Windows պլատֆորմի կառուցման և գործարկման աջակցությունը դադարեցվել է: Վերջին մասնաճյուղը, որը կարելի է տեղադրել Windows-ում, BIND 9.16-ն է:
Source: opennet.ru