Vraag Forceer graven om op te lossen zonder cache te gebruiken


Ik vraag me af of er een manier is om een ​​DNS-server te ondervragen en caching te omzeilen (met dig). Vaak verander ik een zone op de DNS-server en ik wil controleren of deze correct van mijn werkstation wordt opgelost. Maar aangezien de server aanvragen heeft opgelost, krijg ik vaak de oude. Het herstarten of downloaden van de server is niet echt iets leuks.


70
2018-03-21 17:15


oorsprong




antwoorden:


U kunt de @ syntaxis om het domein op te zoeken vanaf een bepaalde server. Als de DNS-server gezaghebbend is voor dat domein, is het antwoord geen resultaat in de cache.

dig @ns1.example.com example.com

Je kunt de gezaghebbende servers vinden door te vragen naar de NS records voor een domein:

dig example.com NS

100
2018-03-21 17:21



Oh oke. Ja, ik was bekend met de @ -syntaxis, maar ik heb niet het idee gehad om de gezaghebbende server te ondervragen. Bedankt! - Daniel
Kanttekening: in gevallen waarin u probeert te zien welke antwoorden een caching-server zou krijgen, +norecurse is aanbevolen. +recurse is standaard ingeschakeld, verandert zo af en toe de manier waarop een DNS-server uw vraag volledig interpreteert. - Andrew B
Wat als u wacht op het veranderen van de gezaghebbende servers? - guaka
@KasperSouren Heb je het over de NS-records op de gezaghebbende servers of de lijmrecords bij de ouder? Je kunt de ouder vinden met +trace maar pas op voor caching. Andrew B schreef een goede uitleg over hoe caching je kan misleiden als je wacht tot nameservers veranderen. - Ladadadada
u kunt ook op google dns controleren dig @8.8.8.8 example.com. de records lijken daar veel sneller. - machineaddict


Er is geen standaard, betrouwbare manier om een ​​nameserver te dwingen te reageren zonder de cache te gebruiken. Dig zelf is geen nameserver, het is gewoon een tool die uw zoekopdracht doorgeeft aan welke nameservers u ook hebt geconfigureerd, met behulp van standaard DNS-verzoeken. Er is een manier om te zeggen "gebruik geen recursie", maar dit is niet wat u wilt - het zou gewoon lookups van domeinnamen op het ruimere internet verhinderen.

Als u wilt voorkomen dat een nameserver reageert vanuit de cache, moet u dat bereiken door de configuratie te wijzigen op de nameserver, maar als je de nameserver niet bestuurt, kun je dat niet doen.

Je kunt er echter wel graven bypass de geconfigureerde naamservers en voer een eigen recursief verzoek uit dat teruggaat naar de basisservers. Gebruik hiervoor de +trace keuze.

dig example.com +trace

In de praktijk omdat dit alleen de gezaghebbende servers zal bevragen in plaats van uw lokale caching-resolver, zal het resultaat niet verouderd zijn, zelfs als die servers interne caching gebruiken. Het extra voordeel van het gebruik +trace is dat je alle afzonderlijke verzoeken langs het pad te zien krijgt.


19
2018-05-31 15:00



Gebruik makend van +norecurse vertel de nameserver gewoon om de informatie terug te geven die hij heeft (inclusief eventuele cache-info), dus dat is niet correct. +trace zal werken omdat het de recursieketen helemaal tot aan een gezaghebbende server zal volgen. - Raman
Merk op dat ik dit antwoord heb aangepast om het te verwijderen +norecurse aanbeveling omdat het de kwestie in de war bracht. - thomasrutter


Iets belangrijks om op te merken, wat ik merk dat veel mensen er nooit bij betrekken als ze het erover hebben +trace is dat gebruiken +trace betekent dat de dig-client de trace uitvoert, niet de DNS-server die is opgegeven in uw config (/etc/resolv.conf). Dus, met andere woorden, je dig-client werkt zoals een recursieve DNS-server, zou je het moeten vragen. Maar - belangrijker, je hebt geen cache.

Meer informatie - dus als je al om een ​​hebt gevraagd mx opnemen met dig -t mx example.com en je /etc/resolv.conf is 8.8.8.8 dan zal het doen van alles in de TTL van de zone het resultaat in de cache retourneren. In zekere zin, als u op zoek bent naar iets over uw eigen zone en hoe Google dit ziet, heeft u uw DNS-resultaten met Google enigszins vergiftigd voor de TTL van uw Zone. Niet slecht als je een korte TTL hebt, wat onzin als je een 1 uur hebt.

Dus, terwijl +trace zal je helpen te zien wat er te zien zou zijn als je Google voor de EERSTE keer zou vragen en het had geen vermelding in het cachegeheugen, het kan je een verkeerd idee geven dat Google iedereen hetzelfde zal vertellen als wat jouw +trace Het resultaat was, wat het niet zal doen als je eerder hebt gevraagd en een lange TTL hebt, omdat het dat van cache zal dienen tot de TTL verloopt - DAN zal het hetzelfde dienen als wat je +tracegeopenbaard.

Kan niet teveel details IMO hebben.


10
2018-05-24 23:10



Heeft graaf een eigen cache of gebruikt het de OS cache? - CMCDragonkai
Dig heeft geen cache. Als de upstream nameserver die het gebruikt, echter profiteert. - thomasrutter
dig mydomain.com +trace geeft me gewoon de resolvd stomp resultaten van 127.0.0.53. Zien github.com/systemd/systemd/issues/5897 - James Bowery
Tijdens gebruik +trace graven begint het traceren met de opgegeven nameserver (bijvoorbeeld 8.8.8.8 als dat is wat u hebt geconfigureerd) voor de eerste lookup (de rootzone), maar daarna gebruikt het de geretourneerde naamservers voor verdere query's. Dus als uw geconfigureerde nameserver niet werkt of niet goed reageert op een query voor de root-nameservers, kunt u problemen ondervinden (zoals in de bovenstaande opmerking). - thomasrutter


Deze bash zal de DNS-vermeldingen van example.com opsommen uit de eerste weergegeven naamserver:

dig @$(dig @8.8.8.8 example.com ns +short | head -n1) example.com ANY +noall +answer
  • De binnenste dig bevraagd google's DNS (8.8.8.8) om example.com's te krijgen nameservers.
  • De outer digqueries voorbeeld.com's voornaamsserver.

Hier is hetzelfde als een alias voor een .zshrc (en waarschijnlijk. 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; }

Hier is de uitvoer voor / .:

  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

Deze oplossing is gecompliceerd genoeg om onpraktisch te onthouden, maar eenvoudig genoeg om het probleem niet te verhelpen. dig is niet mijn specialiteit -  verbeteringen welkom :-)


1
2018-01-11 17:49