DNS A a rekord NS

Próbuję lepiej zrozumieć DNS, ale nadal nie otrzymuję całkowicie rekordów A i NS.

O ile rozumiem, rekord A mówi, który adres IP należy do (pod) domeny, do tej pory było dla mnie jasne. Ale, jak zrozumiałem, rekord NS mówi, który punkt serwera nazw należy do (pod) domeny, a ten serwer nazw powinien powiedzieć, który adres IP należy do (pod) domeny. Ale zostało to już określone w rekordzie A w tym samym pliku DNS. Czy ktoś może mi wyjaśnić, co dokładnie robią rekordy NS i serwery nazw, ponieważ prawdopodobnie zrozumiałem coś złego.

edycja: Jak dobrze rozumiem, rekord NS informuje, że należy znaleźć serwer DNS z rekordem A dla określonej domeny, a rekord A mówi, który adres IP należy do domeny. Ale po co umieszczać rekord A i NS w tym samym pliku DNS? Jeśli istnieje już rekord A dla określonej domeny, to dlaczego musisz wskazać inny serwer DNS, który prawdopodobnie dałby ci te same informacje?

Kilka przykładów z fikcyjnego foo.compliku strefy

 ....... SOA record & lots more stuff .......
 foo.com.      IN        NS        ns1.bar.com.

 foo.com.      IN        A         192.168.100.1
 ....... More A/CNAME/AAAA/etc. records .......

Rekord = „Host o nazwie foo.commieszka pod adresem 192.168.100.1”
NS Record = „Jeśli chcesz wiedzieć o hostach w foo.comstrefie, zapytaj serwer nazw ns1.bar.com”

To stare pytanie, ale myślę, że inne odpowiedzi tak naprawdę nie dotykają źródła zamieszania. NSrekordy na wierzchołku podlegają innym zestawom reguł niż NSrekordy pod wierzchołkiem.

• Te NSzapisy na wierzchołku nie definiują skierowania. Zamiast tego zapewniają wiarygodną definicję tych NSrekordów.
• Wszelkie NSrekordy pod wierzchołkiem zrobić określić skierowania. Ten NSrekord nie jest uważany za autorytatywny, Apodobnie jak rekord o tej samej nazwie.

Na podstawie tych reguł możemy wyprowadzić dwa różne zachowania dotyczące tego, co dzieje się, gdy Ana serwerze DNS istnieje taka sama nazwa:

• Jeśli NSrekord nie definiuje odesłania, inne dane mogą istnieć obok niego w tej samej strefie. Ponieważ serwer uważa się za autorytatywny zarówno dla NSrekordu, jak i dla Arekordu, nie ma konfliktu. Właśnie dlatego inne dane zwykle znajdują się obok NSrekordów na szczycie strefy.
• Jeśli NSpłyta ma definiować skierowania, wówczas Azapis jest skutecznie „zamaskowane” przez cięcie strefy . Ten Arekord nie jest autorytatywny i nie może się pojawiać w sekcji odpowiedzi autorytatywnej odpowiedzi. Można go potencjalnie wykorzystać jako dane kleju, które pojawiają się w dodatkowej sekcji polecenia, ale to wszystko.

Mylące? Tak jest. Upuść notatkę w komentarzach, jeśli masz problemy z przestrzeganiem tego, a ja zobaczę, co mogę zrobić.

Rekordy NS określają serwery, które świadczą usługi DNS dla tej nazwy domeny.

Zapis A wskazuje nazwy hostów punktów (takie jak www, ftp, mail) na jeden lub więcej adresów IP.

rekord A mapuje nazwę na adres IP. na przykład

binary.example.com. IN A 192.168.1.42

stwierdza, że ​​binary.example.com. rozwiązuje do 192.168.1.42

rekord NS odwzorowuje nazwę na inny serwer nazw, tj. inny serwer DNS obsługujący tę domenę. tzn. „Nie mam pojęcia o adresie IP tej nazwy, ale jeśli zapytasz tego serwera nazw, może on wiedzieć”

binary.example.com. W NS otherbox.example.com
otherbox.example.com. IN A 192.168.1.2

Jeśli poprosisz serwer DNS, który ma powyższe 2 rekordy dla binary.example.com. (lub www.binary.example.com. lub foo.bar.binary.example.com). powie ci, że będziesz musiał poprosić 192.168.1.2 o przetłumaczenie tych nazw (no cóż, serwer dns mógłby to zrobić dla ciebie, lub może buforować przetłumaczone nazwy i zwrócić je tobie).

Ważne jest, aby mieć zarówno rekord NS, jak i A w strefie, jeśli konieczne jest delegowanie podstrefy na inny serwer DNS.

Np. Mamy serwer dns ns1.bar.com autorytatywny dla strefy bar.com. I musimy przekazać foo.bar.com do ns1.foo.bar.com. Musimy więc utworzyć strefę foo.bar.com i umieścić tam te rekordy:

foo.bar.com.     IN NS ns1.foo.bar.com.
ns1.foo.bar.com. IN A  10.10.10.10

Jeśli nie będziemy mieć. Przekazywanie rekordów nie będzie działać. Takie pary rekordów nazywane są zapisami kleju.

Rekordy kleju to jedyny sposób, aby system DNS znalazł dokładny adres IP autorytatywnego serwera DNS dla strefy innej niż root. Jeśli sprawdzisz dowolną domenę pod kątem rekordów NS za digpomocą Wireshark lub zobaczysz zrzut ruchu, zobaczysz, że w odpowiedzi jest sekcja „dodatkowa”.

;; ANSWER SECTION:
foo.bar.com.             10800   IN      NS      ns1.foo.bar.com.

;; ADDITIONAL SECTION:
ns1.foo.bar.com.         7972    IN      A       10.10.10.10

wykonując żądanie rekurencyjne, np. www.foo.bar.com, klient dns poprosi o autorytatywny DNS dla strefy foo.bar.com i otrzyma odpowiedź ns1.foo.bar.com.

Aby przejść dalej, musi wysłać zapytanie o ns1.foo.bar.com, które jest obsługiwane przez ... ns1.foo.bar.com. Aby przełamać pętlę, delegujący serwer DNS powinien dodać tę dodatkową sekcję z rekordem A.

Serwer ns1.foo.bar.com powinien mieć te same rekordy w swojej strefie, aby mógł być autorytatywny dla strefy foo.bar.com.

Rekordy NS istnieją WYŁĄCZNIE w celu zdefiniowania, KTÓRE NAZWY są odpowiedzialne za określoną domenę.

Istnieje rekord A służący do „ADRESU” określonej maszyny lub usługi.

Przykłady dla ciebie:

W Panelu sterowania DNS zobaczysz niektóre rekordy NS, to są NAMESERVERS lub podstawowa maszyna odpowiedzialna za informowanie Internetu, gdzie znajdują się rzeczy w Twojej domenie.

NS1.CP.COM NS2.CP.COM

Również w panelu DNS będziesz mieć własną domenę (np. -Mikesfunhouse.com), w której potrzebujesz niektórych usług, takich jak strona internetowa.

Więc będziesz mieć rekord Primary A, wskazujący „mikesfunhouse.com” na „76.19.87.956” (oczywiście fałszywy adres IP).

Następnie utworzysz kolejny rekord, rekord www, który przekieruje subdomenę „www”. część do głównej witryny.

Krótko mówiąc, używasz rekordów A do konwersji przestrzeni nazw na adres IP.

Rekord serwera nazw informuje Internet, który serwer DNS przechowuje rekordy A, więc aby wyszukać rekord A dla subdomeny, jest to mniej więcej następujący proces:

Wyszukaj serwery nazw dla domeny -> Zapytaj serwer nazw dla rekordu A poddomeny