Czym są rekordy glue w DNS i kiedy są potrzebne
Czym jest rekord glue?
Rekord glue to adres IP serwera nazw, publikowany nie w Twojej własnej strefie, lecz poziom wyżej — w strefie nadrzędnej, w rejestrze, za pośrednictwem Twojego rejestratora. Istnieje po to, aby przerwać zależność cykliczną.
Weźmy example.com z serwerami nazw ns1.example.com i ns2.example.com. Resolwer, który chce rozwiązać www.example.com, najpierw pyta serwery .com, kto jest autorytatywny dla example.com. Odpowiedź brzmi: „ns1.example.com i ns2.example.com”. Aby o cokolwiek zapytać te serwery, resolwer potrzebuje ich adresów IP — ale rekordy A dla ns1.example.com znajdują się wewnątrz example.com, na tych samych serwerach, których resolwer właśnie szuka. Bez pomocy z zewnątrz wyszukiwanie nigdy nie może się rozpocząć.
Rekord glue jest tą pomocą: wraz z rekordami NS serwery .com przekazują adresy IP ns1 i ns2 w sekcji dodatkowej odpowiedzi. Resolwer korzysta z nich, dociera do serwerów nazw i strefa działa.
Glue w prawdziwej delegacji możesz zobaczyć, pytając serwer TLD o własną domenę (prawdziwa example.com jest delegowana do zewnętrznych serwerów nazw, więc nie pokazuje żadnego glue):
dig NS yourdomain.com @a.gtld-servers.netSekcja authority wymienia nazwy NS; sekcja dodatkowa wymienia ich adresy glue. Jeśli nazwa serwera nazw leży wewnątrz strefy, a w sekcji dodatkowej nic dla niej nie ma, brakuje glue.
Kiedy rekordy glue są wymagane
Glue jest wymagany dokładnie wtedy, gdy nazwa hosta serwera nazw leży wewnątrz strefy, którą ten serwer obsługuje — w świecie DNS nazywa się to serwerem nazw in-bailiwick.
Wymagany: example.com delegowana do ns1.example.com i ns2.example.com. Obie nazwy są pod example.com, więc obie potrzebują glue.
Niewymagany: example.com delegowana do ns1.hosting-provider.net i ns2.hosting-provider.net. Resolwer znajduje te adresy przez delegację .net dla hosting-provider.net; rejestrator example.com nie ma tu nic do dodania. To codzienny przypadek, gdy korzystasz z domyślnych serwerów nazw swojego dostawcy DNS.
Przypadek mieszany: example.com delegowana do ns1.example.com i ns3.seconddns.com — jedna nazwa in-bailiwick, która potrzebuje glue, i jedna zewnętrzna, która go nie potrzebuje. To typowy układ, gdy Twój własny serwer jest podstawowy, a hostowany serwer wtórny odpowiada pod własną nazwą hosta.
Zasada obowiązuje dla każdej nazwy serwera nazw z osobna, nie dla strefy: sprawdź każdy rekord NS i zapytaj, czy ta nazwa leży wewnątrz delegowanej strefy.
Gdzie znajdują się rekordy glue
Glue nie jest rekordem, który dodajesz do własnego pliku strefy. Należy do strefy nadrzędnej — rejestru TLD — a jedyną drogą, by go tam umieścić, jest Twój rejestrator, ponieważ to rejestrator rozmawia z rejestrem w Twoim imieniu.
Każdy rejestrator udostępnia to gdzieś w ustawieniach domeny, pod bardzo różnymi nazwami:
- „Zarejestruj serwer nazw” / „Zarejestruj host” - „Child nameservers” / „Child hosts” - „Rekordy hostów” / „Rekordy glue” - „Prywatne serwery nazw” / „Własne serwery nazw”
Niezależnie od nazwy formularz pyta o dwie rzeczy: nazwę hosta serwera nazw (ns1.example.com) i jego adres IP (IPv4 oraz IPv6, jeśli go masz). Po zatwierdzeniu rejestr publikuje glue w strefie TLD; od tej chwili serwery .com odpowiadają z tym adresem.
Wynikają z tego dwie konsekwencje. Glue to kopia adresu Twojego serwera nazw, utrzymywana ręcznie u rejestratora — jeśli IP serwera się zmieni, glue nie zmieni się razem z nim. A rekord w Twojej własnej strefie (rekord A dla ns1.example.com) nadal musi istnieć i się zgadzać: resolwery używają glue, aby zacząć, a potem ufają temu, co mówi Twoja strefa.
Co się psuje bez glue
Brak glue. Delegacja wskazuje na ns1.example.com, ale rejestr nie ma dla niego adresu. Resolwery nie mogą dotrzeć do serwerów nazw; domena w ogóle się nie rozwiązuje. Niektóre resolwery starają się bardziej niż inne, więc awaria bywa niespójna — „u mnie działa, u klientów nie” — co utrudnia diagnozę.
Nieaktualny glue. Przeniosłeś serwer, zaktualizowałeś rekord A w strefie i zapomniałeś o rejestratorze. Rejestr nadal rozdaje stare IP. Resolwery, które podążają za glue, trafiają na martwy adres albo, co gorsza, do tego, kto teraz jest właścicielem tego IP. Ponieważ większość resolwerów buforuje działający serwer nazw przez długi czas, ta awaria może ujawnić się wiele dni po migracji.
Glue bez pasującego rekordu A. Rejestr twierdzi, że ns1.example.com to 192.0.2.10, a Twoja strefa nie mówi nic albo mówi coś innego. Glue nie jest autorytatywny: gdy resolwer pozna adres z samej strefy, używa go zamiast glue. Błędny rekord A w strefie nadpisuje więc poprawny glue, a brakujący rekord A pozostawia glue w mocy. Utrzymuj oba w zgodzie.
Lame delegation. Glue jest poprawny, adres odpowiada, ale serwer w rzeczywistości nie obsługuje strefy — typowe, gdy serwer nazw został wycofany albo strefa nigdy nie została wczytana na serwerze wtórnym. Niektóre rejestry ccTLD sprawdzają to przy zmianie delegacji (rejestry gTLD nie), a narzędzia monitorujące to sygnalizują; resolwery traktują taki serwer jako uszkodzony i przechodzą na pozostałe, jeśli takie są.
Wszystkie cztery przypadki zawodzą po cichu z punktu widzenia operatora: nic w Twoich dziennikach nie mówi „glue jest błędny”. Objaw zawsze pojawia się dalej w łańcuchu — sporadyczne błędy rozwiązywania nazw, powolne zapytania, opóźnienia poczty — dlatego warto jawnie sprawdzać delegację.
Sprawdzanie delegacji i glue za pomocą dig
Prześledź delegację od korzenia w dół, aby zobaczyć dokładnie, co przekazuje każdy poziom:
dig +trace www.example.com @1.1.1.1Resolwer jest podany jawnie, ponieważ +trace pyta go tylko o zestaw NS korzenia, a dalej sam przechodzi delegację; zadziała każdy resolwer, który zwraca ten zestaw.
W wyniku znajdź krok, w którym serwery TLD odpowiadają dla example.com: tamtejsze rekordy NS to delegacja. Zwróć uwagę, że +trace wypisuje tylko samą delegację, bez sekcji dodatkowej, więc nie pokazuje glue. Aby zobaczyć glue, wybierz dowolny serwer autorytatywny TLD i zapytaj go bezpośrednio o zestaw NS:
dig NS example.com @a.gtld-servers.net +norecurseSekcja dodatkowa pokazuje glue tak, jak widzi go strefa nadrzędna; serwer nazw in-bailiwick bez wpisu w tej sekcji nie ma glue. Porównaj to z tym, co mówi Twoja własna strefa:
dig A ns1.example.com @ns1.example.com +shortOba adresy muszą się zgadzać. Na koniec potwierdź, że każdy wymieniony serwer nazw rzeczywiście obsługuje strefę i zgadza się co do jej wersji:
dig SOA example.com @ns1.example.com +short
dig SOA example.com @ns2.example.com +shortOba powinny odpowiedzieć autorytatywnie tym samym numerem seryjnym. REFUSED lub SERVFAIL w tym miejscu oznacza lame delegation; numer seryjny, który na jednym serwerze pozostaje w tyle, oznacza, że transfery stref nie nadążają — zobacz Czym jest rekord SOA w DNS.
Rekordy glue a wtórne serwery nazw
Temat glue pojawia się najczęściej, gdy ktoś dodaje drugi serwer nazw pod własną domeną. Dwie konfiguracje, dwie różne odpowiedzi:
Serwer wtórny pod nazwą hosta dostawcy. Twoja strefa jest delegowana do ns1.example.com (Twój serwer) i do własnej nazwy dostawcy usługi wtórnej, na przykład ns3.seconddns.com. Tylko ns1 jest in-bailiwick, więc tylko ns1 potrzebuje glue. Gdy adresy dostawcy się zmienią, u rejestratora nic się nie zmienia.
Serwer wtórny pod własną nazwą hosta — spersonalizowany (vanity) serwer nazw, taki jak ns2.example.com, wskazujący na serwer dostawcy. Teraz ns2 również jest in-bailiwick i potrzebuje glue z adresem IP dostawcy. Dodajesz go u rejestratora dokładnie tak jak ns1 i musisz go aktualizować: jeśli dostawca kiedykolwiek zmieni ten adres, glue musi za nim podążyć. Potrzebujesz też pasującego rekordu A dla ns2.example.com we własnej strefie, który następnie trafia na serwer wtórny z każdym transferem strefy.
To krok najczęściej pomijany przy konfigurowaniu serwerów nazw pod własną marką i powód, dla którego idealnie zsynchronizowany serwer wtórny wciąż nie otrzymuje zapytań. Pełną konfigurację — nazwa hosta, glue, rekordy A i weryfikacja — opisuje Personalizowane serwery nazw: konfiguracja, rekordy glue i pułapki.
Częste błędy
- Edycja rekordu A bez aktualizacji glue po przeniesieniu serwera. Zaktualizuj oba i potem sprawdź strefę nadrzędną za pomocą dig. - Dodawanie glue dla nazw spoza strefy (out-of-bailiwick). Większość rejestratorów to odrzuca; te, które akceptują, publikują dane, których strefa nadrzędna nigdy nie użyje. Rejestruj tylko nazwy pod samą domeną. - Glue z prywatnym lub błędnym IP. Rejestratorzy niewiele weryfikują; literówka trafia do rejestru. Sprawdzaj zapytaniem do serwerów TLD, nie tylko do własnego serwera nazw. - Zapominanie o IPv6. Jeśli Twój serwer nazw ma rekord AAAA, zarejestruj także glue IPv6, inaczej resolwery działające wyłącznie po IPv6 nie będą mogły do niego dotrzeć. - Oczekiwanie natychmiastowego efektu. Duże rejestry gTLD publikują zmiany w ciągu minut, ale niektóre ccTLD regenerują swoją strefę co godzinę lub kilka razy dziennie — a resolwery buforują poprzednią delegację nawet przez TTL strefy nadrzędnej — dla .com zwykle 48 godzin. Planuj zmiany IP serwerów nazw z zakładką: utrzymuj stary adres odpowiadający, dopóki nie wygasną pamięci podręczne. - Glue tylko dla jednego serwera nazw in-bailiwick. Jeśli ns1 ma glue, a ns2 (również in-bailiwick) nie, strefa działa tylko dopóty, dopóki działa ns1 — co przekreśla sens posiadania dwóch.