Qeyda Domain an Pêşkêşkarê DNS-ê qutbûn: Serdema Kêfa Redemption Domain, DNSSEC SERVFAIL Xefik, û Koçberiya Nameserver a Awarte¶

Hişyar dibin ku hûn bibînin ku malpera bingehîn a pargîdaniya we, xalên dawiya API-yê (api.example.com), û e-nameya pargîdanî (MX tomarên ji bo Google Workspace an Microsoft 365) li seranserê cîhanê bi tevahî nayên bidestxistin (DNS_PROBE_FINISHED_NXDOMAIN an SERVFAIL) qeyrana binesaziyê ya tev-reş e. Berevajî serverek malperê ya yekane têkçû ku bandorê li ser yek karûbar dike, Pergalek Navê Domainê (DNS(SSO), portalên piştevaniya xerîdar, û e-nameyên bûyer-bersivê yên hatine. Di pratîkê de, reşkirinên domainê yên gerdûnî ji sê sedemên cûda derdikevin: (1) dawiya domanê ya qezayî ku qerta krediyê ya li ser pelê qediya û qeydkerê we revand. NS tomarên ku ji bo rûpela parkkirinê ya pay-per-click nîşan bide 24 to 48 hours berî dîroka qedandina rastîn; (2) ** Êrîşek DDoS an qutbûna balafirê-kontrolê ** li pêşkêşkarê weya DNS-ya desthilatdar (Route 53, Cloudflare, GoDaddy, Namecheap, DNSimple, NS1); an (3) a şikestî DNSSEC (DS tomar) zincîra pêbaweriyê di dema veguheztina servera navên bilez de ku dibe sedema erêkirina çareserkeran (8.8.8.8, 1.1.1.1, çareserkerên ISP) da ku ji sedî 100 seyrûsefera xwe bi wan re dakêşin SERVFAIL. Ger êrîşkerek pêbaweriyên têketina qeydkerê we tawîz da û domaina we bi xirabî veguhezand an guhezand, veguherîne revandina navê domainê, DNS-ya qediya, û girtina malperê; Ger sertîfîkaya TLS-ya we qediya an piştî ku DNS hate vegerandin şikest, bibînin Sertîfîkaya SSL / TLS di hilberînê de, girtina pêşiya barkirina HSTS, û nûvekirina acîl qediya û Google Workspace an Microsoft 365 kilîtkirina rêveberiya domaina xwerû û verastkirina DNS. Ger ev qutbûn ragihandina klînîkî ya nexweşxaneyê, rêça şandina acîl ya 911/112, an karûbarên gelemperî yên krîtîk asteng dike, bi hejmara xweya acîl ya herêmî re telefon bikin (911 li Dewletên Yekbûyî û Kanada, 112 li seranserê Yekîtiya Ewropayê, 999 li Keyaniya Yekbûyî) an bi pelrêça me re şêwir bikin hejmarên acîl.

Vê niha bikin¶

1. ** Di 10 çirkeyan de teşhîs bikin ka têkçûn Domainek Qedbûyî/Rawestandî ye (EPP Status), Qutbûna Pêşkêşkarê DNS-ya Desthilatdar, an a DNSSEC Têkçûna Verastkirinê**:
2. Run whois yourdomain.com | grep -iE "Status|Expiry|Name Server" û dig +trace yourdomain.com.
3. Biceribînin ka gelo derbas dibe DNSSEC pejirandin (+cd = Kontrolkirina Neçalak) dihêle ku domaina we dîsa çareser bibe:

   dig @8.8.8.8 yourdomain.com A
   dig @8.8.8.8 yourdomain.com A +cd
   

   Ger emrê yekem vegere status: SERVFAIL dema ku emrê duyemîn (+cd) yekser vedigere status: NOERROR digel navnîşana IP-ya servera we, ** pêşkêşkerên DNS yên we NE xwar in: we DNSSEC (DS qeyda li qeydê) şikestî ye **. Tavilê bizivirin Qonaxa 3-ê da ku stûyê jêbirin DS li qeydê xwe tomar bikin.
4. ** Ger domaina we qediya (Auto-Renew Grace Period an Redemption Grace Period), tavilê têkeve nav tomara xweya heyî û xercê nûvekirin / berdêl bidin; Li bendê nebin ku domain "dakeve" da ku hûn wê ji nû ve bi erzan tomar bikin**:
5. Di nav **1 heta 45 rojên pêşîn ** piştî bidawîbûnê de (Auto-Renew Grace Period), nûvekirina di tabloya qeyda we de serverên navên weyên orîjînal bi lêçûna nûvekirina standard vegerîne ($10 to $30).
6. Di nav 30-roj de Redemption Grace Period (RGP / redemptionPeriod), divê hûn xercê vegerandina qeydê ya mecbûrî bidin ($80 to $250) bi navgîniya qeydkarê weya heyî. Ger hûn li bendê bin ku domain 5-roj biqedîne Pending Delete** qonaxa xilaskirinê $100, botên sniper-ê yên otomatîkî yên davêjin (DropCatch, SnapNames, NameJet) dê domaina we di hundurê de bişkîne 5 milliseconds serbestberdanê û bi hezaran dolaran di mezadê de.
7. **QET Nameserverên xwe neguherînin (NS) dûrî pêşkêşkerek DNS-ya çalakkirî ya DNSSEC (wek Cloudflare, Route 53, an Google Cloud DNS) bêyî rakirina DS pêşî li qeydê xwe tomar bikin **: Ger DNSSEC çalak e û hûn xwe biguherînin NS di dema qutbûnê de bêyî jêbirina dêûbav ji pêşkêşkerek DNS-ê ya rizgarkirinê re tomar dike DS (Delegation Signer) di nav de tomar bike .com / .org Pêşî devera TLD, her çareserkerê erêkirî yê li ser Erdê dê bersivên ne-îmzekirî yên pêşkêşkerê DNS-ê yên nû wekî êrîşek xapandina krîptografî red bike (SERVFAIL).
8. ** Ger hûn ji pargîdaniya xwe girtî ne @yourdomain.com e-name ji ber ku domaina we ye MX tomar qediyane, NE bikirtînin "Koda vegerandina şîfreyê bişînin admin@yourdomain.com" li qeydê we **: Dema ku domaina we ye NS an MX tomar negirêdayî ne, her e-nameyek verastkirinê jê re hatî şandin @yourdomain.com vedigere an di dorê de winda dibe. MFA-ya MFA-ya MFA-ya qeydkerê xwe, e-nameya hilanînê ya derveyî-bandê bikar bînin (@gmail.com / @proton.me), an herikîna verastkirina nasnameya têlefonê.
9. Piştî nûkirina domanek qediya, bi destan verast bikin ku Tomarkarê we serverên navên xwerû yên orîjînal sererast kiriye (NS) li şûna ku hûn domainê li ser bihêlin sedoparking.com / renewyourname.net: Dema ku domainek qediya, qeydker adeta we dinivîsin NS tomarên bi pêşkêşkerên navên parkkirinê (ns1.parklogic.com, dns1.name-services.com). Carinan dayîna nûvekirinê dema ku hûn serverên navên parkkirinê çalak dihêlin heya ku hûn bi destan wan vegerînin dîroka qedandina sala pêş nûve dike.
10. ** Veşarkên DNS-ê yên vegerî yên giştî yên gerdûnî paqij bikin (Google 8.8.8.8, Cloudflare 1.1.1.1, OpenDNS) ya duyem ya te NS an DS tomar têne vegerandin **: Li şûna ku 24 ber 48 demjimêran li bendê bin ji bo cached NXDOMAIN an rûpela parkkirinê NS tomarên ku bi xwezayî biqedin, paqijkirina cache-ya gerdûnî ya tavilê li Google Public DNS (developers.google.com/speed/public-dns/cache) û Cloudflare 1.1.1.1 (one.one.one.one/purge-cache/).

Dara biryarê: Domaina gerdûnî an DNS-ê kêşeya acîl reş dike¶

Vê herikandinê bikar bînin da ku qata tam a hiyerarşiya DNS destnîşan bikin (TLD Registry, Registrar EPP Status, DNSSEC DS Chain, an Authoritative Nameserver) cihê ku çareserî têk diçe:

flowchart TD
    Start["Veqetîna Gerdûnî: Malpera Domain û E-name Nabe Çareserkirin (NXDOMAIN / SERVFAIL)"] --> RunDiag["Bixebitîne: whois domain.com Û dig @8.8.8.8 domain.com +cd"]

    RunDiag --> CheckCD{"Ma dig @8.8.8.8 domain.com têk diçe, Dema ku +cd lê zêde dike Serkeftin?"}

    CheckCD -->|"Erê: Bi +cd re dixebite, Bê +cd têk diçe"| DnssecBreak["Zencîreya pêbaweriyê ya DNSSEC şikestî: Qeyda Stale DS-ê li Registrar OR Navçeya Re-Sign jêbirin -> Flush 8.8.8.8 & 1.1.1.1"]

    CheckCD -->|"Na: IP-ya parkkirinê her du jî têk diçin an vedigerin"| CheckWhois{"Rewşa WHOIS EPP Domain & Dîroka Qedandinê kontrol bikin"}

    CheckWhois -->|"Rewş: clientHold an serverHold"| HoldState["Qeydker / Rawestandina Qeydê: Rastkirina E-nameyê ya ICANN RAA an Tevilî Bilêta Birêvebirinê Biqede"]

    CheckWhois -->|"Dîroka Qedandinê Derbas Bû (Rewş: Demjimêra Xwe Nûkirin)"| GraceRenew["Roja 1 heta 45-Piştî-Qedexekirinê: Di Portala Tomarê de Nûvekirina Standard bidin -> NS-ya Xwerû ya Vegerandin Verast bikin"]

    CheckWhois -->|"Rewş: RedemptionPeriod (RGP)"| RgpRestore["Roja 45 heta 75-a piştî qedandinê: Bilêta Piştgiriya Qeydkerê Lezgîn vekin / Heqê Vegerandina RGP bidin (80-250 $) Tavilê"]

    CheckWhois -->|"Rewş: li benda Delete"| PendingDel["Girtina 5-rojî ya paşîn: Li Registrar nayê nûve kirin -> Li Hemî Drop-Catchersên Mezin Naha Bicihînin"]

    CheckWhois -->|"Rewş: başe / Veguhastina xerîdar Qedexeye Û Di Pêşerojê de Biqede"| AuthDown["Qeydkirina Domainê Tendurist -> Qirkirina Pêşkêşkarê DNS-ya Desthilatdar an devera winda"]

    AuthDown --> MigrateNS["Pelê Zonê (`BIND` / Terraform) ji Pêşkêşkarê DNS-ya Duyemîn re têxe -> Heke DNSSEC Li ser e, Tomara DS jê bibe -> NS-ê li Registrar nûve bike"]

Qonaxa 1: Jiyana Bidawîbûna Domaina ICANN (Auto-Renew vs. Redemption vs. Pending Delete)¶

Dema ku Domainek Asta Top-Generîkî (gTLD wekî .com, .net, .org, .io, .ai, .co, .app, .dev) diqede ji ber ku qerta krediyê ya oto-nûvekirî têk çû an jî qerta darayî hate betal kirin piştî ku karmendek çû, domain di çerxa jiyanê ya pir-qonaxa hişk re derbas dibe ku ji hêla ** Polîtîkaya Vegerandina Qeydkirina Qeydkirî ya ICANN (ERRP)** û peymanên operatorê qeydkirinê (Verisign ji bo .com/.net, PIR ji bo .org, Identity Digital).

Domainek çawa dimire û çima ew BERÎ an ROJA 1-ê ya bidawîbûnê de negirêdayî dibe¶

+-------------------------------------------------------------------------+
| ICANN gTLD EXPIRATION TIMELINE (.com / .net / .org example)             |
|                                                                         |
| [Active Domain]                                                         |
|       |                                                                 |
|       v  (Expiration Date Reached: Day 0)                               |
| +---------------------------------------------------------------------+ |
| | STAGE 1: Auto-Renew Grace Period (Day 1 to Day 30-45)               | |
| | - EPP Status: ok or clientHold (Registrar swaps your NS to parking) | |
| | - Production Impact: 100% OFFLINE within 0 to 48 hours of expiry    | |
| | - Recovery: Log into registrar & pay normal renewal ($10-$30).      | |
| +---------------------------------------------------------------------+ |
|       |  (Registrar sends Delete command to Registry at Day 30-45)      |
|       v                                                                 |
| +---------------------------------------------------------------------+ |
| | STAGE 2: Redemption Grace Period [RGP] (Exactly 30 Calendar Days)   | |
| | - EPP Status: redemptionPeriod (Domain removed from TLD Root Zone)  | |
| | - Recovery: Still 100% guaranteed to original owner, MUST pay       | |
| |   Registry RGP Redemption Fee ($80-$250) + renewal via registrar.   | |
| +---------------------------------------------------------------------+ |
|       |  (30-Day RGP expires without redemption payment)                |
|       v                                                                 |
| +---------------------------------------------------------------------+ |
| | STAGE 3: Pending Delete (Exactly 5 Calendar Days)                   | |
| | - EPP Status: pendingDelete                                         | |
| | - Recovery: IMPOSSIBLE to renew or redeem at any price. Registry    | |
| |   rejects all registrar commands until public drop at Day 5 (~18:00 | |
| |   UTC for Verisign .com/.net).                                      | |
| +---------------------------------------------------------------------+ |
+-------------------------------------------------------------------------+

Maf, lêçûn, û kiryarên xweyên tam li ser her qonaxên qedandinê, tevî Domênên Level Top-koda welat (ccTLDs çawa .uk, .de, .eu, .ca, .au), yên ku ** ICANN-ê naşopînin gTLD qaîdeyên:

Qonaxa 2: Vegerandina gav-bi-gav a an qediya RedemptionPeriod domain¶

Vê rêzika tam bişopînin da ku di demek herî kin de domainek qediyayî vegerînin serhêl:

Gav 1: Dema ku ji nû ve gihîştina Hesabê xweya Registrar bistînin @yourdomain.com email mirî ye¶

Li vir Catch-22-a klasîk a domainek qediya ye: - Domaina we (company.com) qediya, wisa MX tomar ji bo company.com çareserkirinê rawestand. - Hûn hewl didin ku têkevin nav tomara domaina xwe (GoDaddy, Namecheap, Cloudflare, Porkbun, Hover, Network Solutions, Gandi), û qeydker dibêje: "Me koda verastkirinê ya 6-hejmar şand admin@company.com" - Ji ber ku company.com qediya ye, ew e-name qet nikare were.

Meriv çawa tavilê ji çerxa e-nameya domaina qediyabûyî derkeve: 1. ** Hîn tiştek neguhezînin an biguhezînin: kontrol bikin ka hûn dikarin TENÊ girtina nameya acîl ya demkî bizivirînin ger domain neqedîbe (heke domain bixwe di asta TLD de qediya be, MX heta ku neyê nûkirin nikare li her deverê çareser bike)**. 2. **Kanala Vegerandina Hesabê ya Tomarê "Gihîştina E-nameya Wenda / Domain Qediya" bikar bînin : - Hema hema hemî qeydkerên pejirandî yên ICANN bi taybetî ji bo xerîdarên ku e-nameya têketinê rûniştî ye têlefonek an nasnameya hukûmetê / kargêriya verastkirina belgeya pargîdanî-tevlemendî peyda dikin. @ domaina qediyayî di hundurê hesabê de. - Berî ku hûn bangî piştgirîya qeydê bikin, sê hêman amade bin: (a) 4 reqemên paşîn ên qerta krediyê an Nasnameya danûstendinê ya PayPal-ê ku li ser fatûreya nûvekirinê ya berê hatî bikar anîn, (b) Nasnameya Hesaba Qeydker / PIN-ya Xerîdar , û © Nasnameya wêneya hukûmetê + Gotarên Tevnegirtinê / Rêxistinê ji nû ve bihaya kargêriyêTech / Admin / Registrant). 3. ** Piştî ku têkevî, tavilê navnîşana e-nameya Hesabê Tomarê biguherîne navokek derveyî (@gmail.com, @proton.me, an domainek acîl ya cihê ya ku we xwediyê we ye) û ** Mifteya Ewlekariya Hardware (FIDO2) an ** TOTP Authenticator App MFA ji ber vê yekê têketinê çu carî ne girêdayî ye @company.com dîsa email.

Gav 2: Nûvekirin an jî bicih bikin RedemptionPeriod (RGP) Vegerînin¶

1. ** Ger domain di Qonaxa 1 de ye (Auto-Renew Grace Period, Rojên 1 heta 30/45)**:
2. Biçe ** Billing -> Nûvekirin ** an ** Lîsteya Doman -> Parzûna Qediya** û fatûreya nûkirinê bidin.
3. ** Kontrola krîtîk 60 çirke piştî dayîna dravdanê : Pêşkêşkerên navên domainê vekin (NS) mîhengên di dashboarda qeydkirinê de. Kontrol bikin ka qeydker bixweber serverên weya navên rastîn paşde vedigerîne (mînak, ns-123.awsdns-15.com an ada.ns.cloudflare.com(ns1.sedoparking.com / dns1.registrar-servers.com). Ger serverên parkkirinê hîn jî têne navnîş kirin, bi destan ji nû ve têkevin serverên navên hilberîna xwe û hilînin.
4. ** Ger domain di Qonaxa 2 de ye (Redemption Grace Period / redemptionPeriod, Rojên 30/45 heta 75)**:
5. Li tabloyek cihê li hundurê tabloya qeyda xweya xweya ku bi gelemperî Domayên Qedbûyî -> Redemption, Trash / Restore, an Billing Grace/Redemption bi navkirî binihêrin.
6. Xerca RGP Restore + 1-salî nûvekirina bidin.
7. Restorasyona RGP çawa li Registry dixebite (Verisign / PIR)? Dema ku hûn xercê RGP didin, qeydkarê we ji EPP <update><restore op="request"> fermana Tomara TLD. Registry tavilê statûya domainê ji diguherîne redemptionPeriod to pendingRestore **û domaina xwe datîne NS di nav 15 û 60 hûrdemî de dîsa vedigere nav Zona Root TLD ** dema ku qeydkerê we radest dike restore op="report" pejirandina lihevhatinê.

Gav 3: Bi paqijkirinê derengiya cache ya ISP ya herêmî derbas bikin 8.8.8.8 û 1.1.1.1¶

Dema ku domaina we qediya, li çaraliyê cîhanê çareserkerên DNS-ya paşverû serverên navên parkkirinê an negatîf veşart. NXDOMAIN bersiv (ji hêla TLD's ve tê rêvebirin SOA Minimum TTL, bi gelemperî 900 to 3,600 çirkeyan, an 86,400 seconds for NS tomar). The moment dig @a.gtld-servers.net yourdomain.com NS (lêpirsîn .com servera root rasterast) dîsa serverên navên hilberîna rastîn nîşan dide: 1. Googl Public DNS Flush Cache (https://developers.google.com/speed/public-dns/cache): - Cureyê flush NS yekem ji bo yourdomain.com, paşê bişon SOA, A, AAAA, MX, û TXT. 2. Vekin **Cloudflare 1.1.1.1 Purge Cache ** (https://one.one.one.one/purge-cache/): - Paqijkirin NS, A, AAAA, û MX ji bo yourdomain.com.

Qonaxa 3: Pêşkêşvanê Navê Awarte (NS) Koçberî Di dema Qutbûna Pêşkêşkara DNS de (Û ya DNSSEC xefik)¶

Ger qeydkirina domaina we ji sedî 100 derbasdar û neqewimin be, lê ** Pêşkêşkarê DNS-ya Destûrdar ** (Route 53, Cloudflare, GoDaddy DNS, DigitalOcean DNS, Azure DNS, DNSimple, Dyn(NS) naha ji pêşkêşkerek DNS-ya piştgir re?

The #1 Koçber Kujer: Guhestina NS Dema ku DNSSEC (DS Qeyd) Çalak e¶

Berî guhertina yek NS li qeydê xwe tomar bikin, vê fermanê bişopînin da ku kontrol bikin ka DNSSEC li ser domaina we di qeyda dêûbav TLD de çalak e:

dig +short yourdomain.com DS @8.8.8.8

+-------------------------------------------------------------------------+
| WHY CHANGING NS RECORDS WITH AN ACTIVE DS RECORD BREAKS THE INTERNET    |
|                                                                         |
| 1. Parent TLD (.com) holds your old DNS provider's DS Record (Key #2371)|
| 2. Old DNS Provider goes down. You import zone to New DNS Provider      |
|    (unsigned, or signed with a brand-new Key #9910) and swap NS.        |
| 3. Validating Resolver (8.8.8.8 / 1.1.1.1 / Comcast / ISP) queries      |
|    New DNS Provider, sees signature does NOT match DS Key #2371.        |
| 4. Resolver assumes an active MITM Spoofing Attack -> Returns SERVFAIL  |
| 5. RESULT: Your domain stays 100% dead worldwide even though the new    |
|    DNS servers are up and answering cleanly.                            |
+-------------------------------------------------------------------------+

Lîsteya Kontrolê ya Koçberiya Nameservera Awarte ya Ewle (Sifir SERVFAIL Doz)¶

1. ** Pêşî li pêşkêşkarê nû yê DNS-ê Pelê DNS Zone-ya xweya bêkêmasî ji nû ve ava bikin an import bikin **:
2. Qet tomarên DNS-ya xwe ji bîrê texmîn nekin (@, www, û api kêm caran tenê tomar in; jibîrkirin MX, SPF/TXT, DKIM, _dmarc, autodiscover, an CAA radestkirina e-nameyê û nûvekirina TLS dişkîne).
3. Dema ku dashboardê pêşkêşkarê DNS-ya weya bingehîn dakêşe hûn li ku derê qada DNS-ya xweya tevahî bibînin:
   • ** Binesaziya-wek-Kodê kontrol bikin (Terraform, Pulumi, OctoDNS, DNSControl)** di depoya xweya Git de.
   • ** Hinardekirina devera dawîn kontrol bikin (BIND .zone pelan)** an li databasên DNS yên dîrokî bigerin (SecurityTrails, ViewDNS.info, DNSDumpster, an Censys / crt.sh ji bo subdomainan).
   • ** Qeydên cache yên bipirsin hîn jî di hundurê çareserkerên vegerê yên giştî de rûniştine ** (dig @8.8.8.8 yourdomain.com MX, dig @1.1.1.1 yourdomain.com TXT, dig @9.9.9.9 api.yourdomain.com A) berî ku TTLyên wan biqedin.
4. ** Piştrast bikin ku pêşkêşkarê nû yê DNS-ê ji bo her tomarek krîtîk bi rehetî bersiv dide BERÎ ku dest bi qeydê xwe bike **: Bifikirin ku pêşkêşvanê weya nû we tayîn kiriye ns1.rescuedns.com û ns2.rescuedns.com. Bi wan re rasterast ceribandin dig:

   dig @ns1.rescuedns.com yourdomain.com SOA +norecurse
   dig @ns1.rescuedns.com yourdomain.com A +norecurse
   dig @ns1.rescuedns.com yourdomain.com MX +norecurse
   

   Li bendê bin ku flags: rêzê di dig sernivîs bi eşkere tê de aa (Authoritative Answer) û vedigere status: NOERROR.
5. **Ger dig +short yourdomain.com DS vegeriyan a DS tomarkirin, tomarkirin DNSSEC li registrar **:
6. ** Di dema qutbûnek çalak de ku peydakarê DNS-ya kevn bi tevahî negihîştî ye**: Têkeve ** Tomara Domainê ** (li cihê ku we domain kirî), biçin beşa DNSSEC / DS Records, û hemû jêbirin. DS tomar dike ji ber vê yekê domain vedigere bê îmze (Insecure) moda li devera dêûbavê TLD. Bisekine heta dig +short yourdomain.com DS @a.gtld-servers.net vala vedigere (û dişewite DS in 8.8.8.8 / 1.1.1.1), an dabînkerê **nû ** DNS lê zêde bike DS Heke koçek pir-îmzaker a plankirî bikin, li kêleka ya kevin tomar bikin.
7. ** Pêşkêşkerên Nameyê nûve bikin (NS) li Tomara Domaina xwe**: Li şûna serverên navên mirî ns1.rescuedns.com û ns2.rescuedns.com di panela **Pêşkêşkerên Navên Xweser ** yên qeydkerê we de (têbînî: diguhere NS tomarên di hundurê edîtorê zonê de tiştekî nake dema ku serverên kevn mirin; divê hûn **Gue / Parent Delegation Nameservers ** di asta Registrar de biguherînin).
8. ** Paqijkirin NS û DS cache li ser Google (8.8.8.8) û Cloudflare (1.1.1.1)**: Amûrên paqijkirina cache ya giştî ji Qonaxa 2 Gav 3 bikar bînin da ku zorê bidin pejirandina tavilê ya pêşkêşkerên navên nû.

Qonaxa 4: Di rewşek awarte de Ji Girtina Veguheztina Tomarê ya ICANN-ê ya 60-rojî sax bimînin¶

Heke hûn hewce ne ku domaina xwe veguhezînin qeydek nû (ICANN Inter-Registrar Transfer), tenê ji hêla ** ve têne asteng kirinDomain Status: clientTransferProhibited** û peyamek ku dibêje: "Ev domain di bin kilîtkirina Veguheztina ICANN-ê ya 60-rojî de ye ji ber ku agahdariya têkiliyê vê dawiyê hate nûve kirin"?

1. Çima kilîtkirina 60-rojî dest pê kir: Li gorî Siyaseta Veguheztinê ya ICANN (Beş II.C.1), dema ku domanek nû hatî tomarkirin, di navbera qeydkeran de tê veguheztin an jî di bin "Guherîna Tomarker" de derbas dibe (Beş II.C.1), qeydker kilîtkirina veguheztina 60-rojî danîne. Têkiliya qeydker).
2. ** Meriv çawa kilîtkirina 60-rojî ya Guhertina Qeydkirî derbas dike an jê vediqetîne **:
3. Berî guherandina hûrguliyên pêwendiya WHOIS: Hema hema hemî qeydkerên sereke qutiyek kontrolê rast li ser ekrana guhastina têkiliyê bi nîşankirî peyda dikin: "Piştî vê nûvekirina pêwendiyê ji kilîtkirina veguheztina 60-rojî veqete." Kontrolkirina wê qutikê dihêle hûn navnîşana e-nameya rêvebir/qeydkar nûve bikin û hîn jî an EPP Auth-Code (Transfer Secret) di heman rojê de domainê veguhezînin.
4. ** Bînin bîra xwe ku hûn NE hewce ne ku hûn qeydkirina domainê veguhezînin da ku pêşkêşkerên DNS-ê biguhezînin : Her çend domainek 60 rojan li dijî * Veguheztinên Tomar * girtî be jî (clientTransferProhibited), hûn hîn jî dikarin Navserverên wê biguherînin (NS tomar) li qeydkerê heyî di her kêliyê de ku heyama benda sifirê ye; guheztina DNS-ê hûrdeman digire, lê veguheztinek qeydkirî ya tevahî 5 heta 7 rojan digire heya ku qeydkarê winda tavilê bikirtîne ** Veguheztina Derketî Pejirandin (FOa) bişkoka.

Qonax 5: Zehfkirina qeydên domainê û DNS li dijî qutbûna pêşerojê¶

Dema ku domain û çareseriya DNS-ya we ji sedî 100 were sererast kirin, vê navnîşa kontrolê ya berxwedanê temam bikin:

• **Bikêrkirin Registry Lock (serverDeleteProhibited, serverUpdateProhibited, serverTransferProhibited) li ser qadên hilberîna krîtîk ên mîsyonê **: Standard Registrar Lock (clientTransferProhibited) dikare bi yek klîk were qut kirin heke êrîşkar têketina qeydkarê we direvîne. ** Registry Lock ** (ji hêla Verisign, PIR, Cloudflare, CSC, MarkMonitor, Gandi, û Porkbun/Namecheap ji bo domên pargîdaniyê ve hatî pêşkêş kirin) domainê rasterast di asta TLD Registry-ê de kilît dike, berî her tiştî pêdiviya dengek pir-kesî/verastkirina krîptografî ya derveyî-bandê hewce dike. NS tomar dikare were guhertin an domain jêbirin.
• ** Pêşî 5 heta 10 salan domainên hilberînê nû bikin (ICANN maximum horizon is 10 years)**: Tu carî domanek karsaz-krîtîk li ser nûvekirina sal-sal nehêlin, ku qerta krediya pargîdanî ya yekane ya qediyabûyî dikare bibe sedema qutbûna qedandinê. 5 heta 10 salan bi carekê bidin pêş.
• ** Tu carî an bikar neynin @yourdomain.com Navnîşana e-nameyê wekî têketinê an pêwendiya ragihandina fatûreyê li rêveberiya qeydkirinê yourdomain.com**: Lîsteya belavkirina ewlehiyê ya taybetî li ser domanek îdarî ya serbixwe an hesabê derveyî hişk bikar bînin, û çavdêriyê bikin RDAP / WHOIS tarîxên qedandinê bi riya çavdêrên xweser ên derveyî Prometheus / Uptime (domain_expiry_days < 60).
• ** Jêrîn NS û DS TTL (300 to 3600 çirkeyan) 48 saetan beriya her koça DNS-ê ya plansazkirî**: Kêmkirina TTL-yên pêşîn piştrast dike ku çareserker di nav 5 hûrdeman de ji qutkirina plansazkirî veguherînin.

Hejmarên awarte yên herêmî û protokolên ajansê¶

Gava ku qutbûnek domain an DNS bandorê li saziyên lênihêrîna tenduristî, karûbarên acîl, karûbarên şaredariyê, an binesaziya hukûmetê dike, van kanalên mezinbûna herêmî bişopînin:

• ** Dewletên Yekbûyî û Kanada : Dial 911 heke qutbûnek domain / DNS telemetrîya nexweşxaneyê ya klînîkî, şandina ambûlansê, an pergalên ewlehiya jiyanê asteng dike. Êrîşên DDoS yên li ser binesaziya DNS an revandina BGP/DNS ji CISA re rapor bikin (1-844-Say-CISA / cisa.gov/report), FBI IC3 (ic3.gov), an ** Navenda Kanadayî ya Ewlekariya Sîber (1-833-CYBER-88). Ji bo .gov domên, têkilî ** CISA .gov Registrar Helpdesk **.
• ** Keyaniya Yekbûyî **: Dial 999 ji bo metirsiyên li ser jiyanê an astengiyên NHS yên tûj. Ji NCSC (ncsc.gov.uk), û bi Nominet re têkilî daynin (01865 332244) rasterast ji bo lezgîn .uk / .gov.uk / .nhs.uk pirsgirêkên qeydê.
• Yekîtiya Ewropî: Dial 112 li hemî welatên endamên Yekîtiya Ewropî. Pêşkêşkerên karûbarê DNS û qeydên navên TLD di binê Rêveberiya NIS2 ya EU de têne rêve kirin (Directive 2022/2555) û divê di nav 24 demjimêran de bûyerên hebûna girîng ji CSIRT-ya xweya neteweyî re ragihînin.
• Australya û Zelanda Nû: Dial 000 li Avusturalya an 111 li Zelanda Nû; Bûyerên DNS an domainê yên krîtîk ji ACSC re rapor bikin (1300 CYBER1), auDA (ji bo .au), an ** Komîsyona Navê Domainê NZ ** (ji bo .nz).
• ** Hindistan û Asya-Pasîfîk **: Dial 112 li Hindistanê ji bo bersiva acîl; êrîşên binesaziya DNS / domainê ji **CERT-In (incident@cert-in.org.in) ** di nav 6 saetan de an **NIXI ** ji bo .in zêdekirina qeydê.

Pirsên pir caran têne pirsîn¶

Çima domaina min 24 saetan BERÎ dema demboriya xwe ya fermî ya WHOIS rawestand?¶

Pêşîn, deverên demjimêr kontrol bikin: WHOIS `Registry Expiry Date` her dem bi **UTC (`Z`)**, ku 4 heta 8 saetan li pêş deverên dema Amerîkaya Bakur e (tê wateya ku domainek li `2026-11-01T04:00:00Z` di rastiyê de diqede `8:00 PM PDT` di 31ê cotmehê de). Ya duyemîn, heke we `NS` tomar hebûn a `24-hour` an `48-hour` TTL û qeydker wan li hev guhert `00:00 UTC` di roja qedandinê de, bikarhênerên ku çareserkerên wan zû nûve kirin tavilê li rûpela parkkirinê dikevin dema ku yên din bi saetan veşart dimînin.

Qeydkerê min bi tevahî ji karsaziyê ne an bersiv nade (Dead / De-accredited Registrar), û domaina min diqede. Ez çawa wê xilas bikim?¶

Dema ku ICANN di binê **Pêvajoya Veguhastina Qeydkirî ya Nepejirkirî de qeydkerek têkçûyî bi dawî aniye an pejirandî bike (`DARTP`)**, ICANN bixweber hemî domanan bi giranî ji qeydkeran re bi lêçûnek sifir veguhezîne qeydkerek serketî. Check `whois yourdomain.com` (an `lookup.icann.org`) da ku hûn bibînin ka kîjan **Tomar** û **IANA ID** niha domaina we digire, an gilîyek bilez **Nûvekirina Domê / Veguhastinê** rasterast bi **Peymana Peymana ICANN (`icann.org/compliance/complaint`)**.

Çima malpera min ji bo hin xerîdar li ser daneyên hucreyî dixebite, lê dîsa jî 6 demjimêran piştî ku min domainê nû kir rûpela parkkirinê ya qediya li Wi-Fi ya nivîsgeha me nîşan dide?¶

Tora nivîsgeha we an çareserkerê DNS-ya vegerî ya ISP-ya herêmî rûpela parkkirinê ya qeydker veşart. `NS` û `A` dema ku domain qediyabû tomar dike, û serverên navên parkkirinê bi eşkere TTL-yên bilind destnîşan dikin (`3,600` to `86,400` çirkeyan / 24 demjimêran) ji ber vê yekê rûpelên reklamê dirêjtir cache dimînin. Google paqij bike (`8.8.8.8`) û Cloudflare (`1.1.1.1`) amûrên wan ên paqijkirina webê bikar bînin, dûv re li ser komputera xweya herêmî bixebitin `ipconfig /flushdns` (Windows), `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder` (macOS), an `sudo resolvectl flush-caches` (Linux).

Çi Diqewime ji E-nameyên şandin @yourdomain.com Dema ku Domain an DNS-ya me 18 demjimêran qediya? Ma Ew Herheyî Wenda Ne?¶

Di pir rewşan de, E-nameyên rewa yên ku di nav 12 û 48 demjimêrên pêşîn ên qutbûna DNS-ê de hatine şandin NAYÊ winda ne: ew li ser servera posta şanderê têne rêz kirin û dê di çend demjimêrên pêş de bixweber bigihîjin.. Di bin **`RFC 5321` (Protokola Veguheztina Maîlê ya Hêsan, Beş 4.5.4.1)**, dema ku serverek e-nameyê dişîne (`Gmail`, `Microsoft Exchange Online`, `Postfix`) têkçûnek demkî ya lêgerîna DNS digire (`SERVFAIL`) an nikare bi an ve girêbide `MX` mazûvan, ew peyamê ji bo **4 heta 5 rojan (`96 to 120 hours`)**, ji nû ve bi paşvekêşana berbiçav ve diceribîne. Lêbelê, heke di rûpela parkkirinê ya qeydkerê de qediyaye ** qertafek null hebe `MX` tomar (`0 .`)** an serverek posta parkkirinê ya ku nameyê bi hişk red kir `550 5.1.1 User Unknown` rijandina daîmî, wan şanderan agahdariyek bilez a bilez wergirtin û divê e-nameyên xwe ji nû ve bişînin.

Ma ez dikarim di heman demê de du pêşkêşkerên DNS saz bikim (Cloudflare + Route 53) tenê bi navnîşkirina du Cloudflare NS tomar û du Rêya 53 NS qeydên li registrar min?¶

Erê, heta ku `DNSSEC` neçalak e (an jî bi rêkûpêk ve hatî mîheng kirin `RFC 8901` Multi-Signer DNSSEC) û her du pêşkêşker tomarên DNS-ê yên yeksan pêşkêş dikin. Çareserkerên vegerî li hemî dêûbavên navnîşkirî dipirsin `NS` tomar bi karanîna hilbijartina derengiya dor-robin/RTT (`SRTT`). Ger hûn navnîş bikin `ns1.providerA.com`, `ns2.providerA.com`, `ns1.providerB.com`, û `ns2.providerB.com` di nav pêşkêşkerên navên xwerû yên qeydkerê xwe de û her du deveran bi karanîna **OctoDNS**, **DNSControl**, **Terraform**, an jî hevdem bikin. `AXFR / IXFR` veguheztinên zonê, domaina we bixweber ji sedî 100 qutbûnek an pêşkêşkerek DNS-ê xilas dibe.

Ferqa di navbera çi ye clientHold û serverHold li WHOIS?¶

Kodên rewşa EPP bi ** dest pê dikin`client...`** (`clientHold`, `clientTransferProhibited`) ji hêla **Domain Registrar ** (firotana ku hûn lê hesabê xwe birêve dibin, wek Namecheap an GoDaddy) têne danîn û ji hêla piştgirî an pergala fatûreya qeydkerê we ve tavilê dikare were rakirin. Kodên statûyê bi ** dest pê dikin`server...`** (`serverHold`, `serverTransferProhibited`) rasterast ji hêla ** Operator Registry TLD ** ve têne saz kirin (`Verisign`, `PIR`, `Nominet`) ji ber fermanên dadgehê, nakokîyên UDRP, rawestandina îstismarkirina di asta qeydê de, an hardware ** Qeyda Qeydê **, û pêdivî ye ku bi navgîniya qeydkarê xwe re têkilî daynin da ku rakin.

rêberên Related¶

• Rakirina navê domainê, DNS-ya qediya, û girtina malperê
• Sertîfîkaya SSL/TLS di hilberînê de qediya, qefilandina pêşbarkirina HSTS, bloka tomara CA CAA, û nûkirina acîl
• Google Workspace an Microsoft 365 kilîtkirina rêveberê domaina xwerû, verastkirina DNS TXT, û rizgarkirina kirêdar
• Rizgarkirina DNS, ji nû veavakirina WAN routerê ISP, û xapandina portalê girtî
• Krîza mêvandariya malperê, koçberî, û sererastkirina hilanînê
• Hejmarên awarte li gorî welat

Çavkanî û rêbernameya fermî¶

• Pargîdaniya Înternetê ya Ji bo Nav û Hejmarên Tayînkirî (ICANN): * Polîtîkaya Vegerandina Qeydkirinê qediya (ERRP), Polîtîkaya Jêbirina Domainê Qediya (EDDP), Siyaseta Veguheztina Nav-Registrar (60-Roj Guherîna Qeydkirî), û Referansa Kodên Rewşa EPP (clientHold, redemptionPeriod, pendingDelete)*.
• Task Force Endezyariya Înternetê (IETF): RFC 6781 (DNSSEC Practices Operations: Rollovers Key û Rewşa Awarte DS Rakirin) & RFC 8901 (Modelên DNSSEC yên Pir-Îmzekar ji bo DNS-ya Desthilatdar a Pir-Pêşkêşker).
• Enstîtuya Neteweyî ya Standard û Teknolojiyê (NIST) (Dewletên Yekbûyî): Weşana Taybet 800-81-2: Pergala Navê Domainê Ewle (DNS) Rêbernameya Bicihkirinê.
• Ajansa Ewlehiya Sîber û Binesaziyê (CISA) (Amerîka): *Rêveberiya Rewşa Awarte 19-01: Kêmkirina Binesaziya DNS-ê *.
• Ajansa Yekîtiya Ewropî ji bo Ewlekariya Sîber (ENISA): * Rêbernameya Teknîkî ya NIS2 ji bo Pêşkêşkerên Karûbarê DNS û Tomarên Navê TLD *.