Օգտագործել 'DNS հյուսիս' կամ պարզապես 'DNS hosting'¶

Այս հոդվածում

• Նախքան սկսելը
• Կարգավորել DNS-ը դոմեյն գրանցողի կողմից
• Կարգավորել DNS-ը օգտագործելով HOSTKEY name servers-ները վահանակում
• Ավելացնել DNS զոնա
• Ջնջել DNS զոնա
• Փոփոխել DNS գրառումները
• DNS գրառման տեսակների ավելացում
• DNS-ի կառավարում API-ի միջոցով
• DNS գրառման տեսակները
• Դոմեյն անվան ավելացման օրինակ
• Standard NGINX-Certbot՝ SSL սերտիֆիկատների ավտոմատ ձեռքբերման համար

Նախքան սկսելը¶

2-րդ կետը կարող է իրականացվել երկու եղանակով: Բավական է նրանցից մեկը:

• Տարբերակ A — DNS registrar-ի մոտ (ավելի պարզ, NS փոփոխություն պետք չէ). Ձեր registrar-ի DNS կարգավորումներում պարզապես ավելացրեք @ → ձեր սերվերի IP գրառ kayıtը (և www, եթե ցանկանում եք): Registrar-ի NS սերվերները մնում են նույնն, և HOSTKEY վահանակում DNS զոնա պետք չէ: Հարմար է պարզ դոմեյնի և սերվերի կապակցման համար:

• Տարբերակ B — DNS HOSTKEY name servers-ով (պետք է, եթե ցանկանում եք կառավարել զոնան HOSTKEY վահանակում). Ձեր registrar-ի վահանակում փոխեք դոմեյնի NS սերվերները ns1.hostkey.com և ns2.hostkey.com (սա կոչվում է դելեգացում), իսկ այնուհետև ստեղծեք DNS զոնան և գրառ kayıtները HOSTKEY վահանակում: NS-ի փոփոխությունը պահանջվում է միայն այս տարբերակի համար — առանց դրա վահանակում գտնվող զոնան չի աշխատի:

Registrar-ում ցանկացած փոփոխությունից հետո սպասեք տարածման ժամանակին (propagation time)՝ 15 րոպեից մինչև 24 ժամ:

Կարգավորել DNS-ը դոմեյն գրանցողի կողմից¶

DNS ¹ կարգավորումը կարող է իրականացվել ձեր դոմեյն գրանցողի միջոցով: Այս առաջադրանքը կատարելու համար անցեք ձեր դոմեյնի settings բաժակ, ընտրեք ձեր registrar-ի NS սերվերները և մուտքագրեք հետևյալ A-records ձեր դոմեյնի համար IPv4-ի պես կամ AAAA-records IPv6-ի համար:

կամ

Կարգավորել DNS-ը օգտագործելով HOSTKEY name servers-ները վահանակում¶

Համոզվեք, որ գրանցողի կողմից դոմեյն անվան կարգավորումները ներառում են հղում HOSTKEY DNS սերվերներին: Եթե այդպիսի հղում չկա, ավելացրեք այն:

Ձեր դոմեյնի համար DNS-սերվերների ցանկը նշելու համար անցեք ձեր registrar-ի personal cabinet-ում գտնվող DNS-servers settings բաժակ և սահմանեք հետևյալ արժեքները՝ ns1.hostkey.com և ns2.hostkey.com:

Հաջորդիվ կարող եք անցնել DNS կառավարմանը Invapi-ում: Դա անելու համար անցեք DNS Management մենյու:

Դրանից հետո դուք կտեղափոխվեք Manage DNS Zones բաժակ:

Ավելացնել DNS զոնա¶

DNS-ը բաժանված է մի քանի DNS զոնաների ², որոնք հստակ սահմանում են կառավարվող տարածքները DNS namespace-ում:

DNS զոնան ավելացվում է Add DNS zone դիալոգային պատուհանի միջոցով «DNS zones management» բաժակում:

• Name — DNS զոնայի անվանումը: Սա պետք է լինի ամբողջական դոմեյն անվանում (FQDN):
• SOA record (TTL, Mname և այլն SOA record բաժնից) — մանրամասների համար տես SOA record;
• Երկու NS records — մանրamasների համար տես NS Entry:

Ջնջել DNS զոնա¶

DNS զոնան ջնջելու համար ընտրեք այն DNS Zone-ի կողքին գտնվող դրոփ-լիստից, ապա սեղմեք Delete DNS Zone:

Փոփոխել DNS գրառումները¶

DNS գրառման տեսակը կազմակերպելու համար՝

1. Բացեք DNS Zone Management բաժակը՝ ընտրելով DNS Hosting ենթաբաժակը օգտատիրոջ անվան վրա սեղմելով,
2. Գրառման տեսակը կամ փոփոխելու համար ընտրեք ցանկալի զոնան DNS zone-ի կողքին գտնվող դրոփ-լիստից,
3. Եթե ցանկանում եք ավելացնել նոր գրառման տեսակ, սեղմեք Add a new DNS record կոճակը և ընտրեք գրառման տեսակը դրոփ-լիստից,
4. Եթե ցանկանում եք փոփոխել կամ ջնջել գոյություն ունեցող գրառում, սեղմեք այն DNS գրառման վրա, որը ցանկանում եք թարմացնել կամ ջնջել,
5. Լրացրեք դաշտերը կամ կատարեք փոփոխություններ բացվող դիալոգային պատուհանում:
6. Սեղմեք Add record նոր գրառման տեսակ ավելացնելու համար կամ Save record գոյություն ունեցողը փոփոխելու համար:

Դուք կարող եք կազմակերպել հետևյալ գրառման տեսակները դոմեյնների և ենթադոմեյներների համար՝

• SOA record
• NS record
• A record
• AAAA record
• CNAME record
• MX record
• TXT record
• DKIM record
• SPF record
• SRV record

SOA record¶

Դիալոգային պատուհանում նշեք SOA գրառման տեսակի դաշտերը.

• TTL — կյանքի տևողությունը: Սա DNS գրառումների դաշտ է, որը որոշում է, թե որքան ժամանակ է վավեր՝ յուրաքանչյուր գրառման համար, և հետևաբար, թե որքան ժամանակ է պահանջվում գրառումների թարմացումներին հասնելու վերջնական օգտվողներին: Ավելի երկար TTL-ները արագացնում են DNS հարցումները՝ մեծացնելով քեշավորված արդյունքների հավանականությունը, սակայն ավելի երկար TTL նշանակում է նաև, որ գրառման թարմացումներն ավելի երկար են տևում:
• Mname — այս DNS զոնայի முதնական (primary master) name server-ը:
  • UPDATE հարցումները պետք է ուղղորդվեն մայր սերվերին:
  • NOTIFY հարցումները տարածվում են հիմնական մայր սերվերից դուրս:
• Rname — այս DNS զոնայի համար պատասխանատու ադմինիստրատորի էլեկտրոնային փոստի հասցեն: Սովորաբար էլեկտրոնային հասցեն կոդավորվում է որպես անուն: @-ից առաջ կանգնած էլեկտրոնային հասցեի մասը դառնում է անվան առաջին պիտակը, իսկ @-ից հետո գտնվող դոմեյն անվանումը՝ անվան մնացած մասը:
• Serial — այս DNS զոնայի հաջորդական համարը: Եթե երկրորդային (slave) name server-ը նկատում է, որ այս թիվը մեծացել է, սլեյվ սերվերը ենթադրում է, որ զոնան թարմացվել է և սկսում է զոնայի փոխանցում (zone transfer):
• Refresh — վայրկյանների քանակը, որից հետո երկրորդային name server-ները պետք է գրառման տեսակ հարցնեն մայր SOA սերվերից՝ DNS զոնայի փոփոխությունները հայտնաբերելու համար: Խորհուրդ է տրվում փոքր և կայուն DNS զոնաների համար՝ 86400 վայրկյան (24 ժամ):
• Retry — վայրկյանների քանակը, որից հետո երկրորդային name server-ները պետք է նորից փորձեն հարցում ուղարկել մայր սերվերին, եթե այն չի պատասխանում: Սա պետք է լինի Refresh-ից փոքր: Խորհուրդ է տրվում փոքր և կայուն DNS զոնաների համար՝ 7200 վայրկյան (2 ժամ):
• Expire — վայրկյանների քանակը, որից հետո երկրորդային name server-ները պետք է դադարեն պատասխանել այս DNS զոնայի հարցումներին, եթե முதնական սերվերը չի պատասխանում: Այս արժեքը պետք է լինի թարմացումների և փոձերի (retries) գումարից մեծ: Խորհուրդ է տրվում փոքր և կայուն DNS զոնաների համար՝ 3600000 վայրկյան (1000 ժամ):
• Minimum — օգտագործվում է எதிர்மական քեշավորման (negative caching) կյանքի տևողությունը հաշվարկելիս: Authoritative name server-ները ընդունում են SOA TTL-ի և SOA minimum-ի ավելի փոքր արժեքը՝ որպես SOA TTL՝ բացասական պատասխանների համար: Resolver-ները օգտագործում են ստացված SOA TTL-ը, որպեսզես հասկանեն, թե որքան ժամանակ է իրենց թույլատրվում քեշավորել բացասական պատասխանը: Խորհուրդ է տրվում փոքր և կայուն DNS զոնաների համար՝ 172800 վայրկյան (2 օր):

NS record¶

Դիալոգային պատուհանում նշեք NS գրառման տեսակի դաշտերը.

• Name — գրառման անունը, դատարկ՝ հենց DNS զոնայի համար;
• TTL — գրառման կյանքի տևողությունը վայրկյաններով (քեշավորում): Սա այն ժամանակն է, թե որքան ժամանակ կարող են այլ DNS սերվերները քեշավորել այս գրառումը: Սովորաբար սահմանվում է 3600;
• Data — մեկ կամ մի քանի FQDN, որոնք տարանջատված են բացատով: Օրինակ՝ ns1.example.com ns2.example.com:

A record¶

Դիալոգային պատուհանում նշեք A գրառման տեսակի դաշտերը.

Հետևյուրն են A գրառման դաշտերը.

• Name — ենթադոմեյնի գրառման անունը, դատարկ՝ հենց DNS զոնայի համար (@);
• TTL — կյանքի տևողությունը: Սովորաբար հավասար է 3600-ին;
• Data — մեկ կամ մի քանի IPv4 հասցեներ, որոնք տարանջատված են բացատով. Օրինակ՝ 104.17.210.9 104.17.210.20: Սա սովորաբար ձեր սերվերի հասցեն է:

AAAA record¶

Դիալոգային պատուհանում նշեք AAAA գրառման տեսակի դաշտերը.

• Name — գրառման անունը, դատարկ՝ հենց DNS զոնայի համար;
• TTL — կյանքի տևողությունը, սովորաբար 3600;
• Data — մեկ կամ մի քանի IPv6 հասցեներ, որոնք տարանջատված են բացատով. Օրինակ՝ 2606:4700:4700::1111 2606:4700:4700::1001:

CNAME record¶

Դիալոգային պատուհանում նշեք CNAME գրառման տեսակի դաշտերը.

• Name — գրառման անունը, դատարկ՝ հենց DNS զոնայի համար;
• TTL — կյանքի տևողությունը, սովորաբար 3600;
• Data — մեկ FQDN: Օրինակ՝ example.com:

MX record¶

Դիալոգային պատուհանում նշեք MX գրառման տեսակի դաշտերը.

• Name — գրառման անունը, դատարկ՝ հենց DNS զոնայի համար;
• TTL — կյանքի տևողությունը, սովորաբար 3600;
• Priority — նշում է, թե որ փոստային սերվերը պետք է լինի առաջնահերթություն: Ավելի ցածր "priority" արժեքը, օրինակ՝ 10 կամ 20, նախընտրելի է.
• Data — մեկ կամ մի քանի փոստային սերվերի FQDN, IPv4 և IPv6: Օրինակ՝ mail.example.com 2606:4700:4700::1001 104.17.210.20:

TXT record¶

Դիալոգային պատուհանում նշեք TXT գրառման տեսակի դաշտերը.

• Name — գրառման անունը, դատարկ՝ հենց DNS զոնայի համար;
• TTL — կյանքի տևողությունը, սովորաբար 3600;
• Data — Տեքստ (առանց չափանիշային չակերտների):

DKIM record¶

Դիալոգային պատուհանում նշեք DKIM գրառման տեսակի դաշտերը.

• Name — գրառման անունը, դատարկ՝ հենց DNS զոնայի համար;
• TTL — կյանքի տևողությունը, սովորաբար 3600;
• Data — v=DKIM1; p=[Public key]

SPF record¶

Դիալոգային պատուհանում նշեք SPF գրառման տեսակի դաշտերը.

• TTL - կյանքի տևողությունը, սովորաբար 3600;
• Data — v=spf1 ip4=192.0.2.0 ip4=192.0.2.1 include:examplesender.email [-//+]all

SRV record¶

Դիալոգային պատուհանում նշեք SRV գրառման տեսակի դաշտերը.

• Service — ցանկալի ծառայության խորհրդանիշ անունը;
• Protocol — ձեր օգտագործվող ծառայության տրանսպորտային պրոտոկոլը, սովորաբար TCP կամ UDP;
• TTL — կյանքի տևողությունը, սովորաբար 3600;
• Priority — թիրախային հոստի առաջնահերթությունը. ցածր արժեքը նշանակում է ավելի նախընտրելի;
• Weight — նույն առաջնահերտություն ունեցող գրառման տեսակների հարաբերական կշիռը, բարձր արժեքը նշանակում է ընտրվելու ավելի մեծ հավանականություն.
• Port — TCP կամ UDP պորտ, որտեղ պետք է գտնվի ծառայությունը;
• Target — ծառայությունը մատուցող մեքենայի կանոնիկ hostname-ը:

DNS գրառման տեսակների ավելացում¶

Դոմեյնի համար DNS զոնաների և գրառումների ավելացումն ու նշանակումը հաստատելու համար օգտագործեք dig գործիքը կոնսոլից կամ ստուգեք առցանց գործիքների միջոցով, ինչպիսիք են Google's DNS Lookup ծառայությունը կամ DNS Checker:

dig myowndomain.com
dig www.myowndomain.com

nslookup myowndomain.com
nslookup www.myowndomain.com

DNS-ի կառավարում API-ի միջոցով¶

API calls կարող են օգտագործվել DNS զոնաներն ու գրառման տեսակներ ավելացնելու, փոփոխելու կամ ջնջելու, ինչպես նաև դրանց ընթացիկ արժեքները ստանալու համար:

DNS գրառման տեսակները¶

DNS գրառումները հրահանգներ են, որոնք պահպանվում են authoritative DNS սերվերներում: Դրանք տեղեկատվություն են տրամադրում զոնայի մասին, ներառյալ կապակցված IP հասցեն և հարցումների մշակման եղանակը: Գրառումները օգտագործում են DNS սինտաքս, որը տեքստային շարք է, որը հրահանգներ է տալիս DNS սերվերին: Դրանք ունեն TTL (time to live), ինչը ցույց է տալիս, թե որքան ժամանակ է վավեր՝ յուրաքանչյուր գրառման համար, և հետևաբար, թե որքան ժամանակ է պահանջվում գրառումների թարմացումներին հասնելու վերջնական օգտվողներին: Ավելի երկար TTL-ները արագացնում են DNS հարցումները՝ մեծացնելով քեշավորված արդյունքների հավանականությունը, սակայն ավելի երկար TTL նշանակում է նաև, որ գրառման թարմացումներն ավելի երկար են տևում:

Յուրաքանչյուր DNS զոնա պետք է ունենա DNS գրառման տեսակների նվազագույն հավաքածու՝ օգտվողներին դոմեյն անվան միջոցով իրենց կայքին հասանելիություն տալու համար: Լրացուցիչ գրառումները կարող են ծառայել այլ նպատակների:

DNS գրառման տեսակների հիմնական տեսակները.

• SOA record

  "start of authority" (SOA) DNS գրառումը պարունակում է էական տեղեկատվություն DNS զոնայի մասին, ներառյալ ադմինիստրատորի էլեկտրոնային հասցեն, թե երբ էր վերջին անգամ թարմացվել զոնան և սերվերի կողմից թարմացումների միջև սպասման միջակայքը:

  Համապատասխանելու համար IETF ստանդարտներին, բոլոր DNS զոնաներն ունեն պետք է Start of Authority (SOA) գրառում: Այս գրառումը նաև կարևոր է զոնայի փոխանցման համար և ավտոմատ կերպով ավելացվում է DNS զոնայի ստեղծման պահին:

• NS record

  NS-ը nameserver-ի հապավումն է: NS գրառումը նշում է այն DNS սերվերը, որը authoritative է DNS զոնայի համար, այսինքն՝ այն սերվերը, որը պարունակում է իրական DNS գրառումները: NS գրառումները համացանցին հուտորում են, թե որտեղ գտնել DNS զոնայի IP հասցեն: DNS զոնան սովորաբար ունի մի քանի NS գրառներ, որոնք նշում են այդ զոնայի முதնական և երկրորդային name server-ները: Նվազագույնս կազմակերպված NS գրառները անհրաժեշտ են օգտվողների համար կայքին կամ հավելվածին հասանելիություն ունենալու համար:

• A record

  "A"-ն ներկայացնում է հասցեի գրառումը, որը DNS գրառման տեսակների ամենապարզ տեսակն է: Այն նշում է պարտավորված DNS զոնայի IP հասցեն:

  A գրառները սահմանափակվում են IPv4 հասցեներով, մինչդեռ AAAA գրառները օգտագործվում են IPv6 հասցեներ ունեցող կայքերի համար:

• AAAA record

  AAAA գրառումները դոմեյն անվանը համապատասխանում են IPv6 հասցեի: Դրանք նման են A գրառ kayıtներին, բայց պահպանում են IPv6 հասցեն՝ IPv4-ի փոխարեն:

• CNAME record

  "Canonical Name" (CNAME) գրառումը դոմեյնի այլընտրանքային անվանցումից (alias) ուղղորդում է "կանոնական" դոմեյնին: CNAME գրառումն օգտագործվում է A գրառման փոխարեն, երբ դոմեյնը կամ ենթադոմեյնը մեկ այլ դոյմեյնի այլընտրանքային անվանումն է: Բոլոր CNAME գրառումները պետք է ուղղորդվեն դոմեյնի, այլոչ թե IP հասցեի:

  Ենթադրենք blog.example.com-ը ունի CNAME գրառման տեսակ՝ example.com արժեքով (առանց blog-ի): Սա նշանակում է, որ երբ DNS սերվերը դիմում է blog.example.com-ի համար, այն իրականում կատարում է ևս մեկ DNS հարցում example.com-ի համար և վերադարձնում է example.com-ի IP հասցեն՝ իր A գրառման միջոցով: Այս դեպքում մենք կարող ենք ասել, որ example.com-ը blog.example.com-ի կանոնական (կամ իրական) անունն է:

• MX record

  "Mail Exchange" (MX) DNS գրառումը նշանակում է էլեկտրոնային փոստը դեպի փոստային սերվեր: MX գրառումը որոշում է, թե ինչպես պետք է ուղարկվեն էլեկտրոնային հաղորդագրությունները՝ համաձայն SMTP-ի (էլեկտրոնային փոստի ստանդարտ պրոտոկոլ): Ինչպես CNAME գրառման տեսակները, MX գրառումը միշտ պետք է ուղղորդվի այլ դոմեյնի:

• TXT record

  Տեքստային (TXT) գրառումը թույլ է տալիս դոմեյնի ադմինիստրատորին տեքստ մուտքագրել DNS համակարգում: TXT գրառումները սկզբնաբար նախատեսված էին մարդուն ընթեռնելի նշումներ պահպանելու համար, սակայն այժմ դրանք կարող են պարունակել նաև մեքենայով ընթեռնվող տվյալներ: Մեկ դոմեյնը կարող է ունենալ մի քանի TXT գրառում:

• DKIM record

  DomainKeys Identified Mail (DKIM)-ը էլեկտրոնային փոստի նույնականացման մեթոդ է, որը օգնում է կանխել սպամերների և այլ հարձակվողների կողմից իրենց իրական դոմեյնի տեսք ունենալը:

  Բոլոր էլեկտրոնային փոստի հասցեները ունեն դոմեյն՝ @ նշանից հետո գտնվող մասը: Հարձակվողները կարող են փորձել կեղծել դոմեյնը phishing հարձակումներ իրականացնելու համար:

• SPF record

  "A Sender Policy Framework" (SPF) գրառումը TXT գրառման տեսակ է, որը ցուցակագրում է բոլոր այն սերվերները, որոնք իրավունք ունեն নির্দিষ্ট դոմեյնից էլեկտրոնային փոստ ուղարկել:

  SPF գրառման տեսակները ստեղծվել են, քանի որ SMTP պրոտոկոլը բնորոշ չէ հաստատել from հասցեն: Առանց SPF-ի կամ այլ հաստատման գրառումների, հարձակվողը կարող է հեշտությամբ կեղծել ուղարկողին:

• SRV record

  "Service" (SRV) գրառումը նշում է սպասարկվող ծառայության հոստը և պորտը, օրինակ՝ VoIP, ակնկրկիկ հաղորդագրություններ և այլն: Մյուս DNS գրառման տեսակների մեծ մասը նշում է միայն սերվերը կամ IP հասցեն, բայց SRV գրառները ներառում են նաև պորտ:

Դոմեյն անվան ավելացման օրինակ¶

DNS զոնայի և գրառման տեսակների ավելացում¶

Ինչպես կարելի է կարգավորել դոմեյնը Invapi-ում.

1. Մուտք գործեք ձեր Invapi հաշիվ:

   • Անցեք ձեր հաշիվի մենյուի DNS Hosting բաժակ:
   • Սեղմեք Add DNS zone կոճակը:
   • Add DNS zone ձևաթղթում մուտքագրեք ձեր դոմեյն անվանումը (myowndomain.com) Name դաշտում:
   • Սեղմեք Add a new DNS zone կոճակը՝ նոր զոնա ստեղծելու համար:

2. Ավելացրեք A գրառման տեսակ դոմեյնի համար:

   • Invapi-ի DNS կարգավորումներում սեղմեք Add new DNS record կոճակը և ընտրեք A:
   • Հայտնվող ձևաթղթում մուտքագրեք @ Name դաշտում, և ձեր սերվերի IP հասցեն Data դաշտում:
   • Սեղմեք Add Record կոճակը:

3. Ավելացրեք CNAME գրառման տեսակ www. ենթադոմեյնի համար:

   • Invapi-ի DNS կարգավորումներում սեղմեք Add new DNS record կոճակը և ընտրեք CNAME:
   • Հայտնվող ձևաթղթում մուտքագրեք www Name դաշտում, և ձեր դոմեյն անվանումը (myowndomain.com) Data դաշտում:
   • Սեղմեք **Add Record կոճակը:

Եթե ամեն ինչ ճիշտ է, դուք պետք է տեսնեք ձեր DNS զոնայի նմանատիպ կարգավորումները.

DNS գրառման տեսակների տարածման ստուգում¶

Սպասեք, մինչև DNS գրառումները տարածվեն ամբողջ համացանցում (սա կարող է տևել 2-ից 24 ժամ): Օգտագործեք dig կամ nslookup հրամանները՝ ստուգելու համար, որ ձեր DNS գրառումները ծառայում են HOSTKEY-ի NS սերվերների կողմից.

dig myowndomain.com
dig www.myowndomain.com

nslookup myowndomain.com
nslookup www.myowndomain.com

Standard NGINX-Certbot՝ SSL սերտիֆիկատների ավտոմատ ձեռքբերման համար¶

HOSTKEY ինֆրաստրուկտուրան օգտագործում է NGINX-ի և Certbot-ի վրա հիմնված ստանդարտ լուծումը SSL սերտիֆիկատների կառավարման համար: Այս լուծումը օգտագործում է պաշտոնական docker-nginx-certbot պատկերը և ավտոմատ կերպով կառավարում է SSL սերտիֆիկատները բոլոր հաճախորդների վահանակների համար:

nginx-certbot կոնտեյները տեղակայելուց հետո, docker-compose ֆայլը գտնվում է /root/data/nginx թղթապանակում, իսկ լռնական (default) կոնֆիգուրացիան գտնվում է այդ նույն թղթապանակի user_conf.d ենթաթղթապանակում: Այս կառուցվածքը հնարավորություն է տալիս կարգավորել լրացուցիչ պարամետրեր, ինչպիսին են՝

• Let's Encrypt-ի համար էլեկտրոնային հասցեն փոփոխելը;
• Nginx կոնֆիգուրացիան հարմարեցնելը;
• Հատուկ (custom) դոմեյներ ավելացնելը:

Ծառայության աշխատանքային ունակությունը ապահովելու համար անհրաժեշտ են հետևյալ նախապայմանները.

1. Ճիշտ կազմակերպված DNS գրառման տեսակներ դոմեյնների համար;
2. 80-րդ պորտը բաց լինել Let's Encrypt վավերացման համար;
3. 443-րդ պորտը բաց լինել HTTPS միացումների համար: