Internal DNS?

[argel1200]

I'm trying to use DNS Benchmark on an internal network to compare geographically dispersed servers. I have an INI file for the nameservers plus the system nameservers, and I'm using my own list of domains. The IPv4 test is failing, which I'm ignoring. The system nameserver is solid red. Most of the other nameservers are red donuts but some are green donuts though no idea why. DNS is working - DNS Benchmark was able to find the name for all the nameservers. I know for a fact the nameservers I'm hitting all support recursion. The system one is listed as a non-routable internal IP (I don't think there's a PTR for its IP address). The rest have their names.

"Run Benchmark" is ghosted out. How do I get it un-ghosted? Does it depend on the IPv4 Internet test succeeding, and if so, what do I need there?

FWIW, I am getting NXDOMAINs back for random-string.amazon.com.

Any ideas?

 

[DanR]

Any ideas?

Have you tried clicking the Big Ruby G?

 

[argel1200]

Have you tried clicking the Big Ruby G?

Looks like some of the app widgets are quickly re-drawn but noting else happens.

 

[peterblaise]

How does it respond to Build Custom List?

 

[argel1200]

How does it respond to Build Custom List?

I have it rebuilding the custom list, and it's failing with a NoReply on all of them so I aborted it. It looks like it's trying to contact each one directly, which won't work - only the internal DNS servers have a path out to public DNS servers. Guessing this explains the IPv4 test failing too?

 

[Scott]

When you say you’re testing on an “internal network”, do you mean a corporate network? Or is it a home network that you control?

 

[Steve]

@argel1200:
I'm puzzled by the fact that "Run Benchmark" is remaining disabled. Once all of the server characterization has settled down it ought to enable. The fact that you're seeing some green circles means that DNSB's direct UDP queries & replies are successfully making the round trip.

If you delete all of the resolvers in the list by using "Remove All DNS Servers" in the Add/Remove dialog, then if you manually add back one IP for a remote UDP resolver that was green before ... does "Run Benchmark" remain disabled?

 

[PHolder]

and I'm using my own list of domains.

I'm not sure what this means in your context. The DNS Benchmark is "generating" DNS names to lookup, but you cannot provide any for it to use.

 

[peterblaise]

Tell us more, @argel1200 - such as

the results of Windows IPCONFIG /ALL​

and IPCONFIG /RELEASE *Con*​

IPCONFIG /FLUSHDNS​

IPCONFIG /RENEW​

​

the results of DNSBench 1​

​

the results of http://www.testipv6.com/​

​

even the results from https://browseraudit.com/​

... just fetching here.

Thanks.

 

[peterblaise]

@argel1200 "... I'm using my own list of domains ..."

Are you using the command line /domains to feed DNSBench your preferred list of what lookups will be tested?

- - - - -

From https://www.grc.com/dns/command-line.htm

/domains ini-file(filename parameter required)​

The /domains command causes the Benchmark to replace its standard list of fifty (50) domain names with whatever list the user supplies in the specified file.​

​

This can be useful for “localizing” the Benchmark so that the domains it is testing against are more relevant to the location where the Benchmark is being used.​

​

By default, DNS lookups of the following set of fifty (50) domains are used with every nameserver in the Benchmark's testing list:​

​

Google.com​ Yahoo.com​ Youtube.com​ Live.com​ Facebook.com​ Msn.com​ Wikipedia.org​ Blogger.com​ Myspace.com​ Yahoo.co.jp​ Baidu.com​ Google.co.in​ Google.de​ Microsoft.com​ Rapidshare.com​ Google.fr​ Ebay.com​ Google.co.uk​ Wordpress.com​ Craigslist.org​ Aol.com​ Google.it​ Flickr.com​ Amazon.com​ Google.co.jp​ Photobucket.com​ Imdb.com​ Bbc.co.uk​ Go.com​ Skyrock.com​ Ask.com​ Friendster.com​ Cnn.com​ Naver.com​ Youku.com​ Google.ca​ Adobe.com​ Ebay.de​ Dailymotion.com​ Conduit.com​ Sohu.com​ Vmn.net​ Apple.com​ Globo.com​ About.com​ Tagged.com​ Mediafire.com​ Ku6.com​ Soso.com​ Livejournal.com​

​

The default domain name list is contained in this simple text file: domains.txt.​

​

You may freely edit the file, adding or subtracting domains as you choose, or completely replacing it with a list of your own.​

​

The domain names used by the Benchmark were chosen for their worldwide popularity with any potentially offensive or controversial domains removed.​

​

Note: Although using fewer than fifty (50) domain names will shorten the Benchmark's total running time, fewer test samples will reduce the accuracy and reproducibility of the benchmark's results.​

​

Conversely, increasing the length of the list would increase the total running time while producing somewhat more consistent results. After extensive testing and statistical analysis, a list of fifty (50) domains was chosen as the best compromise between speed and reliable results.​

 

[argel1200]

@argel1200:
I'm puzzled by the fact that "Run Benchmark" is remaining disabled. Once all of the server characterization has settled down it ought to enable. The fact that you're seeing some green circles means that DNSB's direct UDP queries & replies are successfully making the round trip.

If you delete all of the resolvers in the list by using "Remove All DNS Servers" in the Add/Remove dialog, then if you manually add back one IP for a remote UDP resolver that was green before ... does "Run Benchmark" remain disabled?

Good idea but no luck. When added back in it it's a red donut for a brief moment then back to green donut. Run Benchmark is ghosted and the G logo causes the progress bar to redraw quickly (don't blink!) but the benchmark doesn't start.

Have you ever thought about a Pro / DNS Engineer version that targets internal DNS server testing? Feels like you're almost there.

 

[argel1200]

Are you using the command line /domains to feed DNSBench your preferred list of what lookups will be tested?

Yes, I was hoping to eliminate the internet entirely from the benchmark so I could compare the internal DNS servers. I know this is not the intended use, but it seemed viable with the command-line options.

But, now I suspect there's too much hardcoded under the hood, such as whatever issue I'm running into preventing the benchmarks. Plus the cache test uses <random>.amazon.com which obviously requires the Internet.

 

[AlanD]

Yes, I was hoping to eliminate the internet entirely from the benchmark so I could compare the internal DNS servers. I know this is not the intended use, but it seemed viable with the command-line options.

But, now I suspect there's too much hardcoded under the hood, such as whatever issue I'm running into preventing the benchmarks. Plus the cache test uses <random>.amazon.com which obviously requires the Internet.

Resolving <random>.amazon.com should not need a direct connection to the internet as long as your system DNS has access and can act as a relay.

What you are trying to do makes sense in a corporate environment. If you define the internal DNS servers as the targets, I would expect DNSB to work. Building a custom resolver list obviously would not work, but using your own .ini file should.

 

[peterblaise]

@AlanD "... using your own .ini file ..."

DNSBench uses 2 different types of INI files in 2 different ways:

- as IP addresses of DNS Servers, which appear as a list in the
[ DNS Server ], [ Names ] tab, sourced from [ Add/Remote ]
- - System,
- - non-System GRC Defaults,
- - manually entered DNS Server addresses,
- - and INI files of DNS Server addresses.

- as human-friendly domain names in the form of name.tld to be
searched via those DNS Servers using the command line:
DNSBENCH /DOMANNS MY.INI
... replacing the DNSBench in-built default visible here:

https://www.grc.com/dns/domains.txt

As far as I understand, @argel1200 is using an INI file for the
second reason, filling it with their own list of "geographically
dispersed servers", hoping to get DNSBench to seek out and
query if those servers can be 'found' via DNSBench searching,
querying, from inside their "internal network".

How does the ping command work in this setup?

So in this case, the DNSBench [ DNS Server ], [ Names ] tab
would have only one entry - their internal DNS Server.

Then, using a command line of
/DOMAINS MY-geographically-dispersed-servers.INI
... @argel1200 hopes to test the performance of their one single
internal DNS Server's ability to find their "geographically dispersed
servers".

I think.

And it would be nice to also have DNSBench scan the world for
additional DNS Servers "out there", but Build Custom List is
returning nothing - which I suspect is because their internal DNS
Server is a FILTERING server that hijacks all DNS queries and
replaces DNS queries with it's own scripted results.

Have I got that right, @argel1200?

Am I getting close to understanding your situation?

If your internal DNS Server is FILTERING, then DNSBench is being
blinded, never getting a direct answer to it's queries from the
intended external target.

You can try comparing to the results from DNSBench 1, but
essentially, FILTERING must be turned off for DNSBench to 'see'.

Turning off filtering is not how the system is used normally, but will /
should allow getting some insight on the system's capabilities by
letting DNSBench do it's 'thing'.

Then you can turn filtering back on, confident that you have verified
at least that part of the internal DNS Server's functions.

The filtering is then testable by some other means, not DNSBench.

Am I getting near a fuller understanding of the conditions under test?

Does this make sense?

 

[AlanD]

@AlanD "... using your own .ini file ..."

DNSBench uses 2 different types of INI files in 2 different ways:

- as IP addresses of DNS Servers, which appear as a list in the
[ DNS Server ], [ Names ] tab, sourced from [ Add/Remote ]
- - System,
- - non-System GRC Defaults,
- - manually entered DNS Server addresses,
- - and INI files of DNS Server addresses.

These are the servers that you want to use to answer your queries.

- as human-friendly domain names in the form of name.tld to be
searched via those DNS Servers using the command line:
DNSBENCH /DOMANNS MY.INI
... replacing the DNSBench in-built default visible here:

https://www.grc.com/dns/domains.txt

These are the domains that you want answers to for your benchmark

As far as I understand, @argel1200 is using an INI file for the
second reason, filling it with their own list of "geographically
dispersed servers", hoping to get DNSBench to seek out and
query if those servers can be 'found' via DNSBench searching,
querying, from inside their "internal network".

As I understood it, he was trying to query a list of internal servers specified in an .ini file for a list of (expected to be known) names specified in domains.txt.

How does the ping command work in this setup?

So in this case, the DNSBench [ DNS Server ], [ Names ] tab
would have only one entry - their internal DNS Server.

Then, using a command line of
/DOMAINS MY-geographically-dispersed-servers.INI
... @argel1200 hopes to test the performance of their one single
internal DNS Server's ability to find their "geographically dispersed
servers".

I think.

NO, my understanding was the opposite. The command would be:-

dnsb /DOMAINS My-list-of domains.txt /INI My-internal_DNS-Server_list.ini

I am not sure whether his list of domains to be queried are all "internal" domains, or if it includes some well-known ones.

As I read it, his aim was to test some internal DNS servers currently used as DNS proxies within the company, albeit in different locations. The response times should give some indication of the internal network performance/bottlenecks as well as the response time of individual servers.
Perhaps @argel1200 can confirm what he is trying to achieve.

 

[peterblaise]

Wild guess. example using made-up names and numbers:

System DNS Server for DNSBench to test through, DNSB.INI contains:

192.168.0.1

Domains for DNSBench to search for, through that one DNS Server
above, DOMANS.INI contains:

myremote1.dns.com
myremote1.dns.com
myremote1.dns.com
... and so on.

Command line:

DNSBENCH.EXE /Remove All /Add DNSB.INI /Domains DOMAINS.INI

/Remove All and /Add DNSB.INI may be unnecessary or redundant,
and the functional DNS Server - example of 192.168.0.1 - can also be
manually entered inside the DNSBench program menus.

If that is anything close to the challenge, is the 'problem' that the
DNS Server entered stays red and never lets DNSBench get "out
there" over the Internet, so DNSBench sits and does not offer to
Benchmark?

- - - - -

See also free web tools, such as
https://dnschecker.org/
https://www.whatsmydns.net/

 

[argel1200]

AlanD has it. . \DNSBench.exe /nosend /remove all /add .\my-nameservers.ini /domains .\my-domains.ini. I've also used /add system but it doesn't change the results. But, the /domains part is irrelevant because (as per below) DBench never makes it that far.

Trying with just one nameserver (one of the green donut ones), this is what I'm seeing in the response logs for my IP address (disclaimer: data extracted from a CSV using copilot):

12:53:14.362 — UDP: query: isc.org IN A NOERROR
12:53:14.610 — UDP: query: isc.org IN A NOERROR
12:53:14.862 — UDP: query: isc.org IN A NOERROR
12:53:15.111 — UDP: query: isc.org IN A NOERROR
12:53:15.360 — UDP: query: isc.org IN A NOERROR
12:53:15.608 — UDP: query: isc.org IN A NOERROR
12:53:15.870 — UDP: query: isc.org IN A NOERROR
12:53:16.118 — UDP: query: isc.org IN A NOERROR
12:53:16.380 — UDP: query: isc.org IN A NOERROR
12:53:16.630 — UDP: query: isc.org IN A NOERROR
12:53:16.880 — UDP: query: isc.org IN A NOERROR
12:53:17.132 — UDP: query: isc.org IN A NOERROR
12:53:17.381 — UDP: query: isc.org IN A NOERROR
12:53:17.631 — UDP: query: isc.org IN A NOERROR
12:53:17.878 — UDP: query: isc.org IN A NOERROR
12:53:18.126 — UDP: query: isc.org IN A NOERROR
12:53:18.375 — UDP: query: isc.org IN A NOERROR
12:53:18.622 — UDP: query: isc.org IN A NOERROR
12:53:18.871 — UDP: query: isc.org IN A NOERROR
12:53:19.135 — UDP: query: isc.org IN A NOERROR
12:53:19.456 — UDP: query: evslxxlwzhwbswzob3ronwqtmc.com IN A NXDOMAIN
12:53:19.784 — UDP: query: www.2qcg45ntx3jnf4ea3utuvhcj2f.com IN A NXDOMAIN
12:53:20.042 — UDP: query: net10.rebindtest.com IN A NOERROR
12:53:20.042 — UDP: query: net10.rebindtest.com IN AAAA NOERROR
12:53:20.042 — UDP: query: net127.rebindtest.com IN A NOERROR
12:53:20.042 — UDP: query: net127.rebindtest.com IN AAAA NOERROR
12:53:20.042 — UDP: query: net172.rebindtest.com IN A NOERROR
12:53:20.042 — UDP: query: net172.rebindtest.com IN AAAA NOERROR
12:53:20.042 — UDP: query: net192.rebindtest.com IN A NOERROR
12:53:20.042 — UDP: query: net192.rebindtest.com IN AAAA NOERROR
12:53:20.042 — UDP: query: net4.rebindtest.com IN A NOERROR
12:53:20.042 — UDP: query: net4.rebindtest.com IN AAAA NOERROR

These all look like expected results. Even more confusing!

EDIT: Looks like Copilot took out the word "response:". To be clear, I do not have queries, only responses.