Jak sprawdzić, czy informacje DNS zostały rozpowszechnione?

16

Skonfigurowałem nowy wpis DNS dla jednej z moich subdomen (nie skonfigurowałem jeszcze wirtualnych hostów Apache ani nic podobnego). Jak mogę sprawdzić, czy informacje DNS zostały rozpowszechnione?

Zakładałem, że mogę po prostu ping my.subdomain.comzałożyć, że jeśli to rozwiąże, pokaże adres IP, który podałem w rekordzie A. Nie wiem jednak, czy zakładam poprawnie. Jaki jest najlepszy sposób na sprawdzenie tych informacji?

domain-name-system 
— Andrzej
źródło
3
Nie głupie pytanie. Odkrywanie tego rodzaju rzeczy nie jest takie proste.
— aseq
1
Zgadzam się z @aseq, że to nie jest głupie pytanie, ale „spróbuj i zobacz” dałoby ci również odpowiedź. Jest to również coś, na co Google mógłby odpowiedzieć równie łatwo przy najmniejszym wysiłku (poszukaj How to test if DNS information has propagated- krwawy tytuł pytania generuje dobre wyniki Google).
— voretaq7
4
Nie sądzę, żebyś marnował czas ludzi. Twoje pytanie wywołało cenne odpowiedzi. Nigdy nie wiadomo, jak może się wydawać proste z pozoru pytanie, na które można „po prostu googlować”. Jedną z wartości tego forum jest to, że odpowiedzi i pytania można bardzo łatwo rozszerzyć.
— aseq
1
@ i nic złego w pytaniu, co wielu z nas uważa za proste pytania - prawdopodobnie będzie to najlepszy wynik Google dla tego ciągu za kilka dni ze względu na sposób indeksowania / rankingu witryny. Ogólnie jednak Google jest lepszym (szybszym) miejscem do patrzenia: jeśli Google nie wie, zapytaj tutaj (a Google się nauczy) :-)
— voretaq7
1
Zrozumiałem, dlaczego nic, czego próbowałem, nie działa. Najwyraźniej nasza sieć jest skonfigurowana w taki sposób, że należy także dodać nową subdomenę do naszego lokalnego DNS. Tak więc subdomena była dostępna ze świata zewnętrznego, tylko nie w naszej sieci, w której testowałem. = [Ale użycie nslookupi digpodczas określania zewnętrznego serwera sprawiło, że mogłem zweryfikować zewnętrzne informacje DNS.
— Andrew

Odpowiedzi:

15

Możesz użyć dig lub nslookup, powiedz, że twój (lub dostawca, jeśli nie prowadzisz własnego) serwer nazw to ns1.przyklad.com.

Za pomocą nslookup:

nslookup - ns1.example.com

Po wyświetleniu monitu:

my.example.com

Jeśli rozwiąże się ono zgodnie z oczekiwaniami, to zadziała. Powinien dać ci coś takiego:

Name:   example.com
Address: 192.0.43.10

Rozprzestrzenienie się w pozostałej części Internetu może chwilę potrwać, co jest poza twoją kontrolą.

Za pomocą dig:

dig@ns1.example.com my.example.com

Powinieneś zobaczyć coś takiego:

;; ANSWER SECTION:
example.com.        172800  IN  A   192.0.43.10

Samo użycie polecenia ping może dać ci pomysł, ale tylko wtedy, gdy się propaguje (buforowane przez zdalne serwery nazw mogą być lepszym sposobem na jego opisanie), a lokalna pamięć podręczna dns może wymagać opróżnienia. Chociaż w twoim przypadku nie dotyczy to, ponieważ jest to nowy rekord. W takim przypadku powinien być dostępny natychmiast. Powyższy sposób jest bardziej precyzyjny, dając ci pomysł, a nie tylko pingowanie go.

Jeśli używasz systemu Windows, polecenia i składnia mogą się nieco różnić, ale są dość podobne.

— aseq
źródło
3
+1 Jeśli cokolwiek robisz z DNS, zdobądź kopię dig(* systemy nix już to mają, dostępne są różne wersje dla systemu Windows).
— Chris S
3
-1. Przykro mi. Naprawdę jestem, ale ta odpowiedź „propaguje” mit, który propagują rekordy DNS, czego z pewnością NIE. Termin, którego szukasz, to „buforowanie”, które dzieje się z rekordami DNS na podstawie TTL rekordu. Ponieważ OP odnosi się do nowego rekordu DNS, nie mogło dojść do buforowania, dlatego każdy klient DNS, który chce rozwiązać dany rekord, otrzyma odpowiedź ... natychmiast ... ponieważ nie może być buforowany przez tego klienta ... lub ten klient DNS server ... lub jakikolwiek inny serwer DNS. Rekordy DNS nie są propagowane do „reszty Internetu”.
— joeqwerty
1
joeqwerty ma absolutną rację. Serwery dns będą buforować pozytywne lub negatywne trafienie przez określony czas. Jednak oprócz oryginalnego postu istnieje kilka publicznych serwerów nazw, w tym stare GTE (4.2.2.1, 4.2.2.2, 4.2.2.3 i 4.2.2.4) i Google (8.8.8.8, 8.8). 4.4). Prosta zasada, nowe zmiany mogą potrwać do czasu ttl dla pozytywnego lub negatywnego trafienia. Są jednak przypadki, w których aplikacje implementują złą logikę i buforują odpowiedzi przez dłuższy czas.
— bangdang
2
Nie sądzę, że naprawdę musisz trzymać się dokładnej definicji, aby uzyskać punkt. Poza tym uważam, że propagowanie nie jest złym słowem do użycia. Obejmuje ten temat w tym sensie, że buforowanie rekordu DNS rozprzestrzenia się na większą liczbę serwerów. To rozprzestrzenianie się odnosi się do propagowania. Zaktualizowałem swoją odpowiedź, aby odzwierciedlić fakt, że nowy rekord jest natychmiast dostępny.
— aseq
1
@aseq, to ​​jest mylący termin. I najczęściej okazuje się, że ppl, którzy myślą / mówią o DNS jako swego rodzaju „propagacji”, nie wiedzą, jak działa DNS. Zwykle stwierdzają takie bzdury, jak: „rozpowszechnianie informacji DNS przez Internet / Ziemię zajmuje 2-3 dni” i tak dalej.
— poige
7

Nie można przetestować propagacji rekordów DNS, ponieważ propagacja DNS nie występuje. Możesz sprawdzić, czy klient lub serwer DNS ma buforowany konkretny rekord DNS.

Ponieważ jest to nowy rekord DNS, nie mogło wystąpić buforowanie. Zakładając, że twoje serwery nazw są poprawnie zarejestrowane na serwerach nadrzędnych i że serwery nazw działają poprawnie, ten rekord DNS powinien być natychmiast dostępny dla każdego klienta lub serwera DNS.

— joeqwerty
źródło
Cieszę się, że pomogę ...
— joeqwerty
Czy jest jakiś sposób, aby sprawdzić, czy wpisałem prawidłowy adres IP? Chciałem tylko mieć pewność, że użyłem prawidłowego adresu IP. Ktoś, z kim rozmawiałem, wydawał się sądzić, że ping nie powiedzie się, jeśli nie skonfiguruję jeszcze Apache VHost.
— Andrew
Ping nie jest narzędziem do testowania DNS. Dig i Nslookup to narzędzia do testowania DNS. Użyj Dig lub Nslookup, aby przetestować nowy rekord DNS. Zapytanie dotyczące rekordu na serwerze nazw, a następnie zapytanie o rekord na innych serwerach nazw, aby upewnić się, że znajdują serwer nazw i że serwer nazw odpowiada prawidłową odpowiedzią.
— joeqwerty
1
„propagacja” to pojęcie wymyślone na wypadek, gdyby ludzie nie mogli zrozumieć faktycznej sytuacji, jaką jest starzenie się i wygasanie pamięci podręcznej. Dostawcy DNS musieli powiedzieć, że „Twoje dane mogą być widoczne dopiero po XX godzinach”. Wyjaśnienie, dlaczego było potrzebne, aby nie wyglądało na to, że dostawca DNS był opóźnieniem. Zbyt wielu ludzi „nie umie znieść prawdy”. Wymyślona „propagacja” to skuteczna przykrywka. Prawdziwi maniacy DNS wiedzą, co się naprawdę dzieje, ponieważ czytają szczegóły techniczne.
— Skaperen
Prawda ... Nienawidzę używać terminu, który „propaguje” błędne wyobrażenie o tym, jak działa DNS.
— joeqwerty
5

Podczas gdy inne odpowiedzi są całkiem dobre, pamiętajcie, że to, co wam przekazano, może nie zostać mi przekazane. zamiast korzystać z DIG lub NSlookup i spędzając godzinę na sprawdzaniu serwerów DNS na całym świecie, zwykle używam http://www.whatsmydns.net/, aby zobaczyć, jak przebiega propagacja.

— Jim B.
źródło
W DNS nie ma propagacji, termin ten jest raczej mylący dla wszelkiego rodzaju lamerów, którzy nie znajdą się w czytaniu RFC, więc nie używaj <strike> propaguj </strike>. ;-D
— poige
1
Oczywiście w DNS występuje propagacja, RFC zakładają, że czytelnik rozumie, że informacje mogą się propagować, gdy serwery wykonują wyszukiwania i pamięć podręczną. jest to szczególnie oczywiste, gdy lamerzy czytają RFC, a potem zastanawiają się, dlaczego rekord na ich serwerze nie pasuje do wyników wyszukiwania z innego serwera. Odkrywają, że propagacja ma definicję „rozprzestrzeniać się szeroko” (dokładnie to należy sprawdzić - dystrybucja zaktualizowanych rekordów)
— Jim B
Ani dystrybucja, ani propagacja (oprócz master do slave).
— poige
Prawdopodobnie jest to relikt z czasów, gdy czasami prawie w ciągu dnia pobieranie zmian dokonanych w domenach .com było ładowane na główne serwery nazw (
— dawno
@ poige- dziękuję za sprawdzenie braku zrozumienia, jak działa buforowanie DNS. Sugerowałbym zapoznanie się z dokumentami RFC na temat działania DNS i być może sprawdzenie witryny, z którą się łączyłem, w celu uzyskania przykładów z prawdziwego świata.
— Jim B
3

Najprostszym sposobem, aby upewnić się, że twoje autorytatywne serwery DNS w ścieżce delegacji odpowiadają poprawnie, jest użycie dig +trace:

; <<>> DiG 9.7.3 <<>> +trace www.google.com a
;; global options: +cmd
.           80050   IN  NS  m.root-servers.net.
.           80050   IN  NS  f.root-servers.net.
.           80050   IN  NS  i.root-servers.net.
.           80050   IN  NS  h.root-servers.net.
.           80050   IN  NS  c.root-servers.net.
.           80050   IN  NS  k.root-servers.net.
.           80050   IN  NS  d.root-servers.net.
.           80050   IN  NS  g.root-servers.net.
.           80050   IN  NS  a.root-servers.net.
.           80050   IN  NS  b.root-servers.net.
.           80050   IN  NS  e.root-servers.net.
.           80050   IN  NS  l.root-servers.net.
.           80050   IN  NS  j.root-servers.net.
;; Received 509 bytes from 192.168.1.1#53(192.168.1.1) in 0 ms

com.            172800  IN  NS  c.gtld-servers.net.
com.            172800  IN  NS  k.gtld-servers.net.
com.            172800  IN  NS  g.gtld-servers.net.
com.            172800  IN  NS  d.gtld-servers.net.
com.            172800  IN  NS  j.gtld-servers.net.
com.            172800  IN  NS  f.gtld-servers.net.
com.            172800  IN  NS  i.gtld-servers.net.
com.            172800  IN  NS  m.gtld-servers.net.
com.            172800  IN  NS  e.gtld-servers.net.
com.            172800  IN  NS  a.gtld-servers.net.
com.            172800  IN  NS  l.gtld-servers.net.
com.            172800  IN  NS  h.gtld-servers.net.
com.            172800  IN  NS  b.gtld-servers.net.
;; Received 504 bytes from 198.41.0.4#53(a.root-servers.net) in 127 ms

google.com.     172800  IN  NS  ns2.google.com.
google.com.     172800  IN  NS  ns1.google.com.
google.com.     172800  IN  NS  ns3.google.com.
google.com.     172800  IN  NS  ns4.google.com.
;; Received 168 bytes from 192.43.172.30#53(i.gtld-servers.net) in 20 ms

www.google.com.     604800  IN  CNAME   www.l.google.com.
www.l.google.com.   300 IN  A   173.194.35.180
www.l.google.com.   300 IN  A   173.194.35.178
www.l.google.com.   300 IN  A   173.194.35.176
www.l.google.com.   300 IN  A   173.194.35.177
www.l.google.com.   300 IN  A   173.194.35.179
;; Received 132 bytes from 216.239.34.10#53(ns2.google.com) in 27 ms

Nastąpi to po przekazaniu uprawnień do serwerów nazw autorytatywnych dla Twojego zapytania. Ostatnią odpowiedzią jest zwykle ta, o którą najbardziej się martwisz, ale ślad jest pomocny, ponieważ pokazuje, kto odpowiada za każdą delegację. Jeśli jednak zmieniasz serwery nazw, może to być bardzo przydatne.

Należy pamiętać, że śledzenie będzie bezpośrednio sprawdzać autorytatywne serwery, więc nie ma buforowania. Jest to najlepszy wskaźnik, że odpowiedzi są zwracane zgodnie z oczekiwaniami, ale nie jest to dobry wskaźnik tego, co mogą spotkać użytkowników końcowych. Ponieważ jednak często nie masz kontroli nad buforowaniem serwerów nazw innych ludzi (poza tym, że masz dalekowzroczność, aby obniżyć TTL, poczekaj na pierwotne TTL, wprowadzając zmiany, a następnie przywracając TTL), zwykle nie warto tego sprawdzać po fakcie.

— Cakemox
źródło
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.