Jak ustala się kolejność wyszukiwania DNS?

Na przykład: zarejestrowaliśmy nazwę domeny domain.com i dodaliśmy rekordy serwera nazw na serwerze rejestratorów:
ns1.domain.com.
ns2.domain.com.
ns3.domain.com.

Następnie szukamy domeny.com . Otrzymujemy wszystkie 3 adresy serwerów nazw.
1. Który z tych serwerów zostanie poproszony i dlaczego?
2. Czy kolejność rekordów NS w pliku strefy ma znaczenie?
3. Czy jest to określone w RFC ?

Niestety odpowiedź brzmi „to zależy”. Czynniki, od których zależy, będą się różnić w zależności od domeny i sposobu konfigurowania serwerów będących właścicielami, a także sposobu konfigurowania lokalnego DNS.

Po pierwsze, jeśli chodzi o zwracane rekordy NS: idealnie można losowo uporządkować kolejność zwracania tych rekordów, więc kolejność może się różnić przy każdym żądaniu. Z drugiej strony nie jest to zrobione przez wszystkie implementacje DNS, więc możesz uzyskać listę uporządkowaną statycznie. Chodzi o to, że nie możesz być pewien.

Następnie niektóre implementacje DNS będą wysyłać zapytania do każdego NS równolegle i używać jednej z tych odpowiedzi, które będą pierwsze. Inne trafią w każde z nich, ustalą najszybszą liczbę żądań i skorzystają z tego. Lub może po prostu kradnąć.

Istnieje wiele specyfikacji RFC dla DNS, dwie z nich są bardziej przydatne:

http://www.faqs.org/rfcs/rfc1912.html

http://www.faqs.org/rfcs/rfc1033.html

Zdaję sobie sprawę, że jest to coś bez odpowiedzi, bez niczego ostatecznego do odebrania, ale biorąc pod uwagę powyższe, jedynym prawdziwym sposobem na określenie zachowania dla danej domeny jest przetestowanie.

Najczęstsze wdrożenie, jakie widziałem na poziomie klienta, takie jak dostawcy usług internetowych na całym świecie, jest następujące:

1. Ktoś (np. Abonent sieci szerokopasmowej) prosi serwery DNS usługodawcy internetowego o rozpoznanie rekordu A dla witryny foo.example.com.
2. ISP sprawdza własną pamięć podręczną, a jeśli ten rekord jest buforowany i nadal uważany za „świeży”, jest natychmiast zwracany przez pamięć podręczną. ( Tak działają wszystkie pamięci podręczne DNS, aby nie niepotrzebnie obciążały serwerów DNS danej witryny ).
3. Jeśli nie mieli tego rekordu w pamięci podręcznej lub jeśli pamięć podręczna jest uważana za „nieaktualną / nieaktualną”, dostawca usług internetowych wie, że musi ponownie rozwiązać ostatni rekord.
4. Teraz dostawca usług internetowych musi wiedzieć, które serwery nazw mają zapytać o najnowszy rekord.
5. ISP zaczyna od sprawdzenia swojej buforowanej listy autorytatywnych serwerów nazw dla domeny (są to ns1.przyklad.com, ns2.przyklad.com itd. Wraz z ich adresami IP). Jeśli te rekordy są nadal uważane za świeże, przejdzie do kroku 8.
6. Jeśli buforowane rekordy serwera nazw zostały uznane za wygasłe lub jeśli nie miały żadnych zapisanych w pamięci podręcznej rekordów dla tej domeny, dostawca usług internetowych wysyła zapytanie do głównych serwerów nazw TLD (takich jak rejestr .com, jeśli jest to domena .com), aby uzyskać najbardziej aktualne pary nazwa-serwer / nazwa na przykład.com. ( Możesz to zrobić samemu przez „dig @ b.gtld-servers.net example.com”, aby zobaczyć, co główne serwery nazw dla twojej TLD wiedzą o twojej domenie - jeśli twoja domena należy do zwykłych TLD com / net / etc. Inne TLD musiałyby wysyłać zapytania do swoich serwerów głównych ).
7. Główne serwery nazw dla TLD zawsze zwracają serwery nazw w dokładnie takiej kolejności, w jakiej zostały określone przez ciebie; żadna randomizacja nie jest kontynuowana. Zwracają również adresy IP dla każdego serwera nazw; jest to znane jako „KLEJ” i pozwala internetowi rozwiązać problem „kurczaka i jajka”, jak rozwiązać nazwę hosta serwera nazw na adres IP, zanim w ogóle cokolwiek dowie się o domenie. Co więcej, większość z nich (np. Rejestry com / net / etc, które są największe) wykorzystują czas pamięci podręcznej wynoszący 2 dni, aby nie były ciągle wbijane w „jaka jest lista serwerów nazw dla domeny X?” upraszanie. To jest źródło powszechnej wiedzy, że MUSISZ poczekać 2 dni, aż będziesz mógł bezpiecznie powiedzieć, że twoje nowe serwery nazw są znane na całym świecie, po tym jak „
8. Kiedy ISP zna serwery nazw example.com i ich adresy IP, takie jak ns1.przyklad.com, ns2.przyklad.com, ns3.przyklad.com, ISP wybiera teraz losowy serwer z tej listy i wysyła zapytanie. ( To miło z ich strony, nie niepotrzebnie młotkują wszystkie serwery DNS danej witryny i pomagają dalej w równoważeniu obciążenia, nie zawsze odpytując pierwszy wymieniony serwer nazw ).
9. Jeśli dostawca usług internetowych nie otrzyma odpowiedzi z tego serwera nazw w określonym terminie, wysyła zapytanie do innego na liście.
10. Gdy otrzyma odpowiedź, dostawca usług internetowych przechowuje ją teraz we własnej lokalnej pamięci podręcznej. Jak długo pozostanie w pamięci podręcznej; każdy rekord zwrócony przez dowolny serwer DNS ma również powiązany z nim czas „miękkiego wygaśnięcia” (w sekundach), czyli czas, przez jaki klient wysyłający zapytanie (taki jak serwer DNS dostawcy usług internetowych) może buforować ten rekord, zanim zostanie uznany za „ nadal użyteczne, ale być może nieaktualne, nowe zapytanie powinno odbywać się JEŻELI MOŻLIWE, aby mieć pewność, że się nie zmieniło. Istnieje również czas „twardego wygaśnięcia”, który jest określony w rekordzie „SOA” (Początek uprawnień) każdego serwera nazw (możesz go zobaczyć za pomocą „dig @ ns1.example.com example.com -t soa”), który określa globalny „twardy limit” dla wszystkich rekordów zwracanych przez ten serwer, po czym jakakolwiek pamięć podręczna MUSI USUNĄĆ swój buforowany rekord NAWET JEŚLI serwery nazw są wyłączone i nie można ponownie wyszukać rekordów. Zwykle miękki termin ważności wynosi od 30 minut do 5 godzin, a twardy termin zwykle wynosi od 1-3 tygodni.
11. Po tym wyczerpującym zadaniu dostawca usług internetowych w końcu ma najnowszy rekord DNS i może zwrócić go kwerendującemu subskrybentowi Internetu szerokopasmowego, który nie jest wcale mądrzejszy, jak wielkie zadanie wykonano za sceną!

Ten proces powtarza się dla KAŻDEGO wyszukiwania rekordów. Jednak tylko pierwsze zapytanie wykonuje całą pracę; adresy IP serwera nazw zostaną następnie zbuforowane, a kolejne zapytania do serwera DNS buforującego ISP będą mogły szybko przejść do kroku 8.

Teraz, jeśli chodzi o randomizację kroku 8, działa ona na poziomie rekordu. Powiedzmy, że abonent Internetu szerokopasmowego tego dostawcy zapytał o następujące rekordy:

• Foo.example.com
• Example.com
• Www.example.com
• MX example.com (klient ISP nie powinien pytać o ten rekord, ale to tylko przykład)

Każdy rekord będzie traktowany jako osobny „byt”, niezależnie buforowany i przeglądany. Powiedzmy, że subskrybent i dostawca usług internetowych nigdy wcześniej nie napotkali domeny i oba mają całkowicie zerowe rekordy buforowane. Wyszukiwanie może wyglądać następująco:

• Foo.example.com przez ns1.example.com, a następnie przechowywane w pamięci podręcznej dostawcy usług internetowych
• A example.com przez ns3.example.com, a następnie przechowywane w pamięci podręcznej dostawcy usług internetowych
• Www.example.com przez ns2.example.com, a następnie przechowywane w pamięci podręcznej dostawcy usług internetowych
• MX example.com przez ns3.example.com, a następnie przechowywane w pamięci podręcznej dostawcy usług internetowych

Ilekroć buforowane rekordy wygasają miękko, proces jest powtarzany, więc nawet nie wiesz, że kolejne żądania dla tego rekordu będą ponownie korzystać z tego samego serwera.

Dlatego Twoim absolutnym największym celem jest upewnienie się, że wszystkie Twoje serwery DNS są całkowicie zsynchronizowane ze sobą, doskonale odzwierciedlając każdy rekord DNS na każdym serwerze. Nigdy nie wiadomo, na który serwer trafi klient DNS i nie można polegać na żadnym zamówieniu. Nie ma takiej rzeczy.

Ponadto, jak wspomniał Adam C., same serwery DNS na poziomie serwera (example.com) mogą zwrócić rekordy NS i losowo uporządkować ich kolejność. Zwykle zwykłe serwery DNS losowo przydzielają swoje rekordy NS z niewielkim prawdopodobieństwem, że słaba implementacja DNS zawsze wybiera pierwszy zwracany serwer nazw. Jednak serwery nazw ROOT TLD (wspomniane wcześniej) nigdy nie randomizują listy, a ich lista jest naprawdę ważna, jeśli chodzi o rozwiązanie domeny. Dlatego większość implementacji wybiera losowy serwer z list serwerów nazw, aby uniknąć uderzenia w ten sam serwer i przeciążenia go.

W porządku, to jest twój element w działaniu DNS i o czym powinieneś pamiętać.

• W skrócie: traktuj wszystkie swoje serwery DNS tak, jakby były tylko jednym serwerem, co sprawia, że ​​Twoim najwyższym celem w życiu jest upewnienie się, że wszystkie są w stanie odpowiedzieć na każde zapytanie, które może zostać do nich skierowane.

Uwaga: Wyższe cele w życiu niż zarządzanie DNS mogą być dostępne, ale są sprzedawane osobno, użyj swojej wyobraźni. ;-)