I'm imagining you want a way to make dig act like the caching
nameserver and do what it would do and show you the answer.
dig +trace does something similar to this. There is no nameserver
operation
that dig could do to tell a caching nameserver to act differently
for one query. You could
I've been doing some testing lately on query times. What I did was
create a new zone and create a * record within it. Then, from a shell,
I do dig @server $RANDOM.test.testdomain.com. For more randomness,
you can combine: dig @server $RANDOM.$RANDOM.test.testdomain.com
That's how I've worked
On Mon, 5 Jan 2009, Stephen Ward wrote:
On Mon, 05 Jan 2009 16:24:04 +, Chris Thompson wrote:
On Jan 5 2009, John Wobus wrote:
[...] There is no nameserver
operation
that dig could do to tell a caching
For all my attempts to read the manual on DIG I can't find a way to do
something really simple.
Is there a way to dig a domain name so even if the results are in cache,
it will ignore these and re-read them? It's really from a testing
perspective I'm looking at this. I can mash the keyboard
If you're referring to your local system's cache, you can bypass this by
specifying a DNS server for dig to query. use @dns.server.domain or
@4.2.2.2(for example) for this.
If you're referring to the cache on the server you're trying to query,
sorry, that's beyond your control, unless you have
5 matches
Mail list logo