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:
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
+norecursezaleca się. +recursejest domyślnie włączony, od czasu do czasu zmienia sposób, w jaki serwer DNS całkowicie interpretuje twoje pytanie.
+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.
dig @8.8.8.8 example.com. zapisy pojawiają się tam znacznie szybciej.
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.
+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.
+norecursezalecenie, ponieważ pomieszało to problem.
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.
dig mydomain.com +tracepo prostu zwraca mi resolvdwyniki z 127.0.0.53. Zobacz github.com/systemd/systemd/issues/5897
+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).
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
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 :-)