Kiedy szukam swojej domeny na stronie http://www.intodns.com , pojawia się problem:
KLEJ nie został wysłany, gdy poprosiłem twoje serwery nazw o twoje rekordy NS. Jest to w porządku, ale powinieneś wiedzieć, że w tym przypadku wymagane jest dodatkowe wyszukiwanie rekordów w celu uzyskania adresów IP twoich rekordów NS. Możesz to naprawić, na przykład dodając rekordy A do serwerów nazw dla stref wymienionych powyżej.
Ale mam wpisy A dla wszystkich moich serwerów nazw w każdym wpisie strefy:
ns1.example.com. IN A <IP>
ns2.example.com. IN A <IP>
Jak rozwiązać ten problem z KLEJEM?
example.com.Odpowiedzi:
Rekordy kleju to specjalne rekordy A, które są potrzebne, gdy sam serwer nazw dla domeny DNS znajduje się w tej samej domenie.
Na przykład jeśli twoja domena to example.com, a twój serwer nazw to ns.example.com, musisz utworzyć rekord „kleju” A dla ns.example.com w następnej najwyższej strefie DNS, w tym przypadku w strefa „com”. Należy to zrobić za pośrednictwem rejestratora.
Jest to wymagane, ponieważ na żądania DNS dotyczące serwerów nazw (rekordy NS) zawsze odpowiada się nazwą, a nie adresem IP.
Bez rekordu kleju, gdyby zgłoszono żądanie dotyczące rekordów A www.example.com, serwer nazw obsługujący „com” zwróciłby rekord NS na przykład.com jako ns.example.com (nie IP), a pierwotne żądanie nie ma możliwości rozwiązania, ponieważ każda kolejna próba rozwiązania witryny ns.example.com odsyła tylko do strony ns.example.com.
źródło
Problem z GLUE z głównych serwerów DNS polega na tym, że występuje następująca sytuacja:
example.com ma rekordy DNS ns1.przyklad.net i ns2.przyklad.net jako swoje serwery NS. Uprawnienie .com, w którym DNS będzie szukał nazwy domeny, NIE MOŻE podać adresów IP dla ns1.example.net i ns2.example.net, ponieważ nie mają one uprawnień.
Aby to naprawić, domena .com może korzystać z serwerów NS pochodzących z domeny .com. Przykład example.com użyłby ns1.example-2.com i ns2.example-2.com i wszystko będzie dobrze, ponieważ organ .com może podać adres IP dla serwera nazw. Oszczędza to wiele podróży w obie strony do głównych serwerów DNS, ponieważ w twoim przypadku, aby uzyskać example.com, teraz musisz również zapytać .net o example.net.
W moim przypadku wszystkie moje domeny mają własne wpisy NS, więc na przykład.com mam a.ns.example.com i b.ns.example.com, a dla mojej domeny example.net mam a.ns.example .net i b.ns.example.net.
Wymaga to większej konfiguracji i nie wszystkie hosty mogą na to pozwolić. Możesz utknąć z tym, co obecnie masz!
źródło
Sam wypróbowując narzędzie i widząc, co raportuje z niektórymi domenami, które znam, powiedziałbym, że może to być wiele rzeczy, które prowadzą do tego komunikatu informacyjnego (zauważ, że to „ja” dla informacji, a nie „!”)
Na przykład jedna z moich stref ma serwery nazw poza strefą, a wśród autorytatywnych serwerów nazw dla strefy nie wszystkie zawierają rekordy A w swoich autorytatywnych danych, które należy zwrócić w odpowiedzi.
Ale to w porządku - każdy serwer nazw zapytań i tak nie powinien ufać takim danym. Dawno temu nie miałbyś tego, ale w dzisiejszych czasach każdy serwer nazw może próbować kłamać i wymknąć się z danych strefy do pamięci podręcznej.
Więc nie martw się o to. Zanim zapytanie dotrze do twojego serwera nazw, już znalazło przynajmniej niektóre adresy IP twoich serwerów nazw. Bardziej martw się, że delegacje są takie same jak dane twojej strefy (następny wpis, „Niedopasowane rekordy NS”) i że żaden nie jest „kulawy” („Serwery nazw są kulawe: Wszystkie serwery nazw wymienione na serwerach nadrzędnych odpowiadają autorytatywnie dla twojego domena ”- źle sformułowane, ale chcesz się upewnić, że jest tam zaznaczenie).
źródło