DNSSEC миграција без SERVFAIL-а: стари DS запис мора прво да истекне

|Аутор: Уредништво QUASA|5 мин читања
DNSSEC миграција без SERVFAIL-а: стари DS запис мора прво да истекне

Када већ потписан домен прелази на Cloudflare без подршке за више потписника, Cloudflare упутство за миграцију налаже да прво уклоните стари DS код регистрара и сачекате да његов TTL истекне, па тек онда промените сервере имена. Ако резолвер и даље чува стари DS, а нови ауторитативни сервер објављује други кључ, DNSSEC провера пада и домен може да враћа SERVFAIL.

После промене делегације сачекајте и истек старог NS TTL-а, проверите да нови сервери враћају потребне записе, па укључите DNSSEC у Cloudflare-у и додајте нови DS код регистрара. Ако је Cloudflare већ ауторитативан и DNSSEC укључујете први пут, прескочите кораке за селидбу: потпишите зону у Cloudflare-у, објавите његов DS код регистрара и проверите да ланац поверења ради.

Пре измене забележите DS, делегацију и TTL

DS запис стоји у родитељској зони и повезује њен ланац поверења са кључем потписаног домена. ICANN-ово објашњење DS записа указује на простор за грешку када DNS провајдер и регистар домена одвојено обављају пренос података о кључу. Зато пре миграције утврдите ко потписује стару зону, ко мења DS и које сервере имена објављује родитељска зона.

У наредним командама example.com. је условни пример; замените га својим доменом. Сачувајте резултате упита dig example.com. NS +noall +answer, dig example.com. DS +noall +answer и dig example.com. DNSKEY +dnssec +noall +answer. Ако DS постоји, забележите његов пуни TTL пре брисања. Рекурзивни резолвер може да прикаже само преостало време у свом кешу, па вредност проверите и путем dig +trace example.com. DS, у одговору ауторитативног сервера родитељске зоне.

Пре промене NS записа упоредите и садржај старе и нове зоне. Записи за веб, пошту и друге услуге морају бити спремни на новим серверима: исправан DNSSEC ланац неће надокнадити изостављен A, AAAA или MX запис. Задржите стару зону доступном док резолвери могу да користе кеширану стару делегацију.

Прво укључивање на домену који већ користи Cloudflare

  1. Проверите упитом dig example.com. DS +noall +answer да у родитељској зони није остао DS неког ранијег провајдера. Ако постоји, утврдите ком кључу припада пре додавања новог записа.
  2. У Cloudflare контролној табли отворите DNS Settings и изаберите Enable DNSSEC. Cloudflare потписује зону, објављује DNSKEY и приказује податке за DS који треба објавити у родитељској зони.
  3. Код регистрара унесите DS вредности које је Cloudflare приказао, ако их регистар не преузима аутоматски. Проверите да објављени DS има исту ознаку кључа, алгоритам, тип сажетка и сажетак.
  4. Поновите упит за DS и затражите DNSKEY директно од додељеног Cloudflare ауторитативног сервера: dig @назив_сервера example.com. DNSKEY +dnssec +noall +answer. У команди замените назив_сервера стварним именом сервера.

DS садржи сажетак кључа, а не дословну копију DNSKEY записа. Зато упоредите DS који је Cloudflare дао са DS записом који се заиста враћа из родитељске зоне, а затим проверите одговор валидирајућег резолвера. Само присуство DNSKEY записа или ознака у контролној табли не доказују да је цео ланац исправан.

Селидба већ потписаног домена без више потписника

Овај поступак подразумева привремени период у ком родитељска зона нема DS за домен. Стари провајдер за то време може да настави да служи потписану зону; пресудно је да нови сервери не преузму делегацију док резолвери још могу да се ослоне на кеширани стари DS. Ако стари провајдер омогућава објављивање спољних DNSKEY записа, постоји засебан поступак са више потписника и координацијом кључева.

  1. Уклоните стари DS код регистрара, али оставите стару зону и њено потписивање активним. Проверите да је уклањање стигло до родитељске зоне; тренутак подношења захтева регистру није нужно тренутак промене у DNS-у.
  2. Од потврђене промене у родитељској зони сачекајте пуни раније забележени DS TTL. Упит dig example.com. DS +noall +answer показује стање једног резолвера, док dig +trace example.com. DS помаже да видите одговор родитељске зоне. Празан одговор једног резолвера сам по себи не доказује да су све старе копије истекле.
  3. Тек потом код регистрара поставите Cloudflare сервере имена. Стару зону задржите доступном док не истекне и претходни NS TTL, јер део резолвера још може да користи стару делегацију.
  4. Када нова делегација ради и Cloudflare ауторитативни сервери враћају очекиване записе, укључите DNSSEC. Додајте нови DS код регистрара и поновите проверу DS, DNSKEY и одговора валидирајућег резолвера.

Не скраћујте чекање зато што контролна табла регистрара више не приказује стари DS. Она показује стање уноса, док су раније добијени одговори и даље у кешевима до истека TTL-а. Исто тако, нови DS не треба објавити док нова потписана зона и одговарајући кључ нису доступни преко делегације.

Како испитати SERVFAIL после промене

Најпре упоредите dig @8.8.8.8 example.com. A +dnssec са dig @8.8.8.8 example.com. A +cdflag. Google упутство за дијагностику домена наводи да статус 2, односно SERVFAIL, уз успешан одговор када је DNSSEC провера искључена указује на могућ проблем валидације. Ознака +dnssec тражи DNSSEC податке у одговору; сама по себи не доказује да је локални програм потврдио потпис. Проширена DNS грешка, EDE, може ближе да покаже где је провера стала.

Затим упоредите DS који види резолвер, DS из родитељске зоне и DNSKEY који враћа нови ауторитативни сервер. Ако је у родитељској зони или кешу остао стари DS, а нови сервер нема кључ који му одговара, ланац поверења је прекинут. Ако се DS и кључ слажу, проверите потписе и доступност свих делегираних сервера; SERVFAIL може да настане и због проблема са ауторитативним одговором, па сам код грешке не открива узрок.

Повратак на исправно стање

Ако желите да искључите DNSSEC на исправно потписаној Cloudflare зони, прво уклоните њен DS код регистрара. Потписивање оставите укључено док тај DS не нестане из родитељске зоне и док му не истекне TTL у кешевима. Резолвери који још памте исправан DS тада и даље могу да провере потписане одговоре.

Погрешно објављен DS захтева другачију процену: брисање или исправка код регистрара мења родитељску зону, али не може одмах да избрише погрешну вредност коју су резолвери већ кеширали. Уклоните застарели DS, проверите да ли нови ауторитативни сервер заиста објављује одговарајући кључ и рачунајте на истек кешираног DS-а. Ако су NS већ промењени прерано, одржавајте потребне записе у обе зоне док истичу кеширане делегације; само враћање старих NS записа код регистрара не мења одмах оно што резолвери већ памте.

Прочитајте и:

Подели:

Претплатите се на наш билтен

Добијајте најновије вести о Web3, AI-у и криптовалутама директно у пријемно сандуче.

0