Řešení 1:
Můžete použít @ syntaxe pro vyhledání domény z konkrétního serveru. Pokud je server DNS autoritativní pro danou doménu, odpověď nebude výsledkem uloženým v mezipaměti.
dig @ns1.example.com example.com
Autoritativní servery můžete najít dotazem na NS záznamy pro doménu:
dig example.com NS
Řešení 2:
V protokolu DNS neexistuje žádný mechanismus, který by přinutil jmenný server reagovat bez použití jeho mezipaměti. Dig sám o sobě není jmenný server, je to jednoduše nástroj, který předá váš dotaz jakémukoli jmennému serveru, který jste nakonfigurovali, pomocí standardních požadavků DNS. DNS dělá zahrnout způsob, jak říct serveru, aby nepoužíval rekurzi, ale to není to, co chcete. To je užitečné pouze tehdy, když se chcete přímo dotazovat na autoritativní jmenný server.
Pokud byste chtěli jmennému serveru zabránit v odpovědi z jeho mezipaměti, bylo by to možné provést pouze změnou konfigurace na jmenném serveru , ale pokud neovládáte jmenný server, je to nemožné.
Můžete se však dostat k obejití nakonfigurované jmenné servery a provést svůj vlastní rekurzivní požadavek, který se vrátí ke kořenovým serverům. Chcete-li to provést, použijte +trace možnost.
dig example.com +trace
V praxi, protože to bude dotazovat pouze autoritativní servery, nikoli váš místní překladač mezipaměti, výsledek nebude zastaralý, i když tyto servery používají interní mezipaměť. Další výhodou použití +trace je, že uvidíte všechny jednotlivé požadavky provedené na cestě.
Řešení 3:
Zde je třeba poznamenat něco důležitého, co si všimnu, že mnoho lidí nikdy nezahrnuje, když mluví o +trace je to pomocí +trace znamená, že trasování provede dig klient, nikoli DNS server zadaný ve vaší konfiguraci (/etc/resolv.conf). Jinými slovy, váš dig klient bude fungovat jako rekurzivní server DNS, pokud se ho zeptáte. Ale - co je důležité, nemáte mezipaměť.
Více podrobností – pokud jste již požádali o mx zaznamenejte pomocí dig -t mx example.com a váš /etc/resolv.conf je 8.8.8.8, pak když uděláte cokoli uvnitř TTL zóny, vrátí výsledek uložený v mezipaměti. Svým způsobem, pokud hledáte něco o své vlastní zóně a o tom, jak ji vidí Google, trochu jste otrávili výsledky DNS pomocí Googlu pro TTL vaší zóny. Není to špatné, pokud máte krátké TTL, poněkud nesmyslné, pokud máte 1h.
Takže zatímco +trace vám pomůže zjistit, co BY BYLO vidět, kdybyste se poprvé zeptali Googlu a neměl žádný záznam v mezipaměti, může vám to poskytnout mylnou představu, že Google bude všem říkat totéž, co váš +trace výsledek byl, což nebude, pokud jste se zeptali dříve a máte dlouhé TTL, protože to bude sloužit z mezipaměti, dokud nevyprší TTL - PAK bude sloužit stejně jako vaše +trace odhaleno.
IMO nemůže mít příliš mnoho podrobností.
Řešení 4:
Tento bash získá záznamy DNS example.com z jeho prvního jmenného serveru:
dig @$(dig @8.8.8.8 example.com ns +short | head -n1) example.com ANY +noall +answer
- Internal dig se dotazuje na DNS společnosti Google (8.8.8.8), aby získal jmenné servery example.com.
- Vnější dig se dotazuje na křestní jmenný server example.com.
Zde je totéž jako alias pro .zshrc (a pravděpodobně .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; }
Zde je výstup pro /.:
☀ 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
Toto řešení je dostatečně složité na to, aby bylo nepraktické na zapamatování, ale dostatečně jednoduché na to, aby se problém nevyřešil. dig není moje specialita - vylepšení vítána :-)