Wymuś wykopanie bez rozpoznawania pamięci podręcznej


90

Zastanawiam się, czy istnieje sposób na zapytanie serwera DNS i ominięcie buforowania (z dig). Często zmieniam strefę na serwerze DNS i chcę sprawdzić, czy poprawnie rozpoznaje ona strefę na mojej stacji roboczej. Ale ponieważ pamięć podręczna serwera rozwiązała żądania, często otrzymuję stare. Ponowne uruchomienie lub załadowanie serwera nie jest naprawdę przyjemne.

Odpowiedzi:


119

Możesz użyć @składni, aby wyszukać domenę z określonego serwera. Jeśli serwer DNS jest autorytatywny dla tej domeny, odpowiedzią nie będzie wynik w pamięci podręcznej.

dig @ns1.example.com example.com

Możesz znaleźć autorytatywne serwery, prosząc o NSrekordy dla domeny:

dig example.com NS

2
W porządku Tak, znałem składnię @, ale nie miałem pomysłu, by zapytać o to autorytatywny serwer. Dzięki!
Daniel

3
Uwaga dodatkowa: w przypadkach, gdy próbujesz zobaczyć, jakie odpowiedzi uzyska serwer buforujący, +norecursezaleca się. +recursejest domyślnie włączony, od czasu do czasu zmienia sposób, w jaki serwer DNS całkowicie interpretuje twoje pytanie.
Andrew B,

4
Co zrobić, jeśli czekasz na zmianę autorytatywnych serwerów?
guaka

@KasperSouren Czy mówisz o rekordach NS na autorytatywnych serwerach lub zapisach kleju u rodzica? Możesz znaleźć rodzica, +traceale uważaj na buforowanie. Andrew B napisał dobre wyjaśnienie, w jaki sposób buforowanie może Cię oszukać, czekając na zmianę serwerów nazw.
Ladadadada,

3
możesz również sprawdzić w Google dns dig @8.8.8.8 example.com. zapisy pojawiają się tam znacznie szybciej.
machineaddict

25

Nie ma standardowego, niezawodnego sposobu zmuszenia serwera nazw do odpowiedzi bez użycia pamięci podręcznej. Dig nie jest serwerem nazw, to po prostu narzędzie, które przekazuje zapytanie do dowolnego skonfigurowanego serwera nazw, przy użyciu standardowych żądań DNS. Jest to sposób, aby powiedzieć „nie używaj rekursji”, ale to nie jest to, co chcesz - to po prostu uniknąć wyszukiwań nazw domen na szerszym dostępem do Internetu.

Jeśli chcesz zatrzymać serwer nazw przed odpowiedzią z pamięci podręcznej, musisz to osiągnąć, zmieniając konfigurację serwera nazw , ale jeśli nie kontrolujesz serwera nazw, nie możesz tego zrobić.

Możesz jednak uzyskać wykop, aby ominąć skonfigurowane serwery nazw i wykonać własne żądanie rekurencyjne, które wraca do serwerów głównych. Aby to zrobić, użyj +traceopcji.

dig example.com +trace

W praktyce, ponieważ spowoduje to wysłanie zapytania tylko do autorytatywnych serwerów, a nie lokalnego programu rozpoznawania pamięci podręcznej, wynik nie będzie przestarzały, nawet jeśli te serwery wykorzystują buforowanie wewnętrzne. Dodatkową zaletą używania +tracejest to, że możesz zobaczyć wszystkie oddzielne żądania złożone wzdłuż ścieżki.


10
Użycie +norecursepo prostu mówi serwerowi nazw, aby zwrócił wszelkie informacje, które posiada (w tym informacje z pamięci podręcznej, jeśli istnieją), więc nie jest to poprawne. +tracebędzie działać, ponieważ będzie podążać za łańcuchem rekurencji aż do autorytatywnego serwera.
Raman

1
Pamiętaj, że zmodyfikowałem tę odpowiedź, aby usunąć +norecursezalecenie, ponieważ pomieszało to problem.
thomasrutter

13

Należy tu zauważyć ważną kwestię, o której zauważam, że wiele osób nigdy nie bierze pod uwagę, gdy mówi o +tracetym, że użycie +traceoznacza, że ​​klient kopiowania wykona śledzenie, a nie serwer DNS określony w konfiguracji (/etc/resolv.conf). Innymi słowy, twój klient kopiowania będzie działał tak jak rekurencyjny serwer DNS, gdybyś go poprosił. Ale - co ważne, nie masz pamięci podręcznej.

Więcej szczegółów - więc jeśli już poprosiłeś o mxrekord przy użyciu dig -t mx example.comi /etc/resolv.conf to 8.8.8.8, to zrobienie czegokolwiek wewnątrz TTL strefy zwróci buforowany wynik. W pewnym sensie, jeśli szukasz czegoś na temat własnej strefy i tego, jak Google ją widzi, to w pewnym sensie zatrułeś wyniki DNS za pomocą Google dla TTL swojej strefy. Nieźle, jeśli masz krótki czas TTL, nieco śmieci, jeśli masz 1 godzinę.

Tak więc, chociaż +tracepomoże ci zobaczyć, co POWINIENEŚ zobaczyć, gdybyś poprosił Google po raz pierwszy i nie miał wpisu z pamięci podręcznej, może dać ci fałszywy pomysł, że Google powie każdemu to samo, co +tracewynik, który nie zrobi tego, jeśli poprosiłeś wcześniej i będziesz miał długi czas TTL, ponieważ będzie on podawany z pamięci podręcznej aż do wygaśnięcia TTL - NASTĘPNIE będzie służyć tak samo, jak to, co +traceujawniłeś.

Nie mogę mieć zbyt wielu szczegółów IMO.


Czy dig ma własną pamięć podręczną lub korzysta z pamięci podręcznej systemu operacyjnego?
CMCDragonkai

Dig nie ma pamięci podręcznej. Jeśli jednak korzysta z serwera nazw nadrzędnego, korzysta z tego.
thomasrutter

dig mydomain.com +tracepo prostu zwraca mi resolvdwyniki z 127.0.0.53. Zobacz github.com/systemd/systemd/issues/5897
James Bowery

Podczas korzystania z +tracedig rozpoczyna się śledzenie przy użyciu określonego serwera nazw (np. 8.8.8.8, jeśli tak właśnie skonfigurowałeś) dla pierwszego wyszukiwania (strefa główna), ale potem używa on zwróconych serwerów nazw dla dalszych zapytań. Jeśli więc skonfigurowany serwer nazw nie działa lub nie odpowiada poprawnie na zapytanie dotyczące głównych serwerów nazw, możesz mieć problemy (jak w powyższym komentarzu).
thomasrutter,

2

Ta bash wykopie wpisy DNS example.com z jego pierwszego serwera nazw:

dig @$(dig @8.8.8.8 example.com ns +short | head -n1) example.com ANY +noall +answer
  • Kopa wewnętrzna pyta google DNS (8.8.8.8), aby uzyskać serwery nazw example.com.
  • Kopnia zewnętrzna pyta o serwer nazw w example.com.

Oto to samo co alias dla .zshrc (i prawdopodobnie .bashrc):

# e.g. `checkdns google.com`
checkdns () { dig @$(dig @8.8.8.8 $1 ns +short | head -n1) $1 ANY +noall +answer; ping -c1 $1; }

Oto wynik dla / .:

☀  checkdns slashdot.org                                                                                                dev
-->Server DNS Query

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @ns1.dnsmadeeasy.com. slashdot.org ANY +noall +answer
; (2 servers found)
;; global options: +cmd
slashdot.org.       21600   IN  SOA ns0.dnsmadeeasy.com. hostmaster.slashdotmedia.com. 2016045603 14400 600 604800 300
slashdot.org.       86400   IN  NS  ns3.dnsmadeeasy.com.
slashdot.org.       86400   IN  NS  ns4.dnsmadeeasy.com.
slashdot.org.       86400   IN  NS  ns0.dnsmadeeasy.com.
slashdot.org.       86400   IN  NS  ns2.dnsmadeeasy.com.
slashdot.org.       86400   IN  NS  ns1.dnsmadeeasy.com.
slashdot.org.       3600    IN  MX  10 mx.sourceforge.net.
slashdot.org.       3600    IN  TXT "google-site-verification=mwj5KfwLNG8eetH4m5w1VEUAzUlHotrNwnprxNQN5Io"
slashdot.org.       3600    IN  TXT "v=spf1 include:servers.mcsv.net ip4:216.34.181.51 ?all"
slashdot.org.       300 IN  A   216.34.181.45
-->Local DNS Query
PING slashdot.org (216.34.181.45) 56(84) bytes of data.
64 bytes from slashdot.org (216.34.181.45): icmp_seq=1 ttl=242 time=33.0 ms

--- slashdot.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 33.026/33.026/33.026/0.000 ms

To rozwiązanie jest wystarczająco skomplikowane, aby było niepraktyczne do zapamiętania, ale wystarczająco proste, aby problem nie został rozwiązany. digto nie moja specjalność - mile widziane ulepszenia :-)

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.