Интернет медленный как черепаха

Grc’s | dns benchmark – features & operation walkthrough

Features & Operation Walkthrough
Familiarizing yourself with GRC’s DNS Benchmark.

“You can’t optimize it until you can measure it”

Our DNS Benchmark utility has been designed, as we design everything, so that the average user can just jump in without “reading the manual” and pretty much figure it all out for themselves. That is, after all, the whole point and wonderful benefit of a graphical user interface (GUI). So if you are willing to just read the text presented on the benchmark’s various tabbed pages — for example, please be sure to read the “Introduction” tab’s text just once and be sure to read the “Conclusions” tab after the Benchmark is finished — you can probably safely ignore the rest of these web pages.

On the other hand . . . if you have some time to invest, and your goal is to seriously adopt this powerful tool as a component of your permanent bag of tricks, there are sufficient subtleties and “extras” hidden inside this quite comprehensive application that taking some time to make sure you haven’t missed anything important might be time well spent.

And, besides . . . you’re already here! shifty

Two Notes About Terminology:

DNS resolving nameservers (the things this utility tests, characterizes, and benchmarks) are commonly referred to as “DNS servers”, “DNS nameservers”, or “DNS resolvers”, sometimes without the “DNS” prefix. These pages will continue this flexible practice, choosing whichever name seems to flow best in the context. So, when we refer to a DNS server, a nameserver, or a resolver, we always mean the same thing: an

Internet DNS resolving nameserver

that responds to and answers DNS queries at a given IP address.

“System” and “Public” Nameservers:
Throughout these pages, and throughout the DNS Benchmark, we use the term “System” nameserver to mean any DNS server that is currently configured for use by the local system upon which the Benchmark is being run. We use the term “Public” to refer to all other nameservers that are not currently configured for use by the local system.

We also sometimes refer to the system’s configured nameservers as “local” or “locally configured” nameservers because they are configured for use by the local machine even though this usage can be imprecise since such a “local” nameserver would usually be located remotely.

The Four Primary Tabs

dnsb-head

tab1The entire contents of the “Introduction” tab should be read top to bottom just once.

For example, it admonishes the benchmark’s user (that’s you) not to run DNS benchmarking operations while your network is busy doing anything else . . . such as downloading a large file. While it can be instructive to do this to see how things perform under stress, you at least need to be aware that your results will be significantly different than when the Benchmark is used on an idle network. As an example, the benchmark’s measurement of apparent reliability will almost certainly be quite erroneous (and worrisome) on a network that is busy enough to be dropping some percentage of Internet packets. That won’t be the remote DNS server’s fault. But the benchmark has no way of knowing why packets were dropped, only that some were. Knowing why is up to you. For other similarly important points, you should read the “Introduction” tab’s contents at least once.

tab2The “Nameserver” tab is where most of the action and excitement happens. The largest portion of this page will be devoted to describing the many features of this tab, and of its four sub-tabs, in quite some detail.

tab3While the benchmark is running, and after it has finished, the “Response Time” sub-tab on the “Nameserver” tab provides a real-time bar chart depicting each tested DNS server’s performance and reliability characteristics. All of that data is derived from a statistical database that is being continually updated, analyzed, and displayed in summary form on this “Tabular Data” tab. The “Response Time” chart gives you a pretty picture, but the “Tabular Data” tab provides you with the raw data from which the “Response Time” chart is created (and additional information as well). All timing values are in seconds, so the three decimal digits of precision provide resolution of milliseconds (thousandths of a second).

tab4During the course of the benchmarking, a surprising amount of information is collected and assembled by this program. This includes details about the environment’s current network configuration, how the currently configured DNS servers are performing, and how they compare with publicly available alternatives. These various detailed and interacting facts are distilled into a single coherent series of conclusions which are summarized and presented in a clear action oriented style on the “Conclusions” tab. As much fun as the “Response Time” tab is to watch while the benchmark is running, it’s the “Conclusions” tab that most users wind up finding most useful once the Benchmark is finished.

Inside the Nameserver Tab

dnsb-mid
(Note that the specific data shown above will differ for each user.)

ips1ips2ips3ips4ips5ips6ips7ips8

The main “Nameservers” tab contains the four “sub-tabs” shown above (“Name”, “Owner”, “Status” and “Response Time”). The IP address and status indicators in the first two columns are always present, whereas the four sub-tabs determine the contents of the chart’s third display column.

The Nameserver IP List (shown to the left) occupies the first of the chart’s three columns. This column list every DNS resolving nameserver currently configured for benchmarking. The list’s contents can be altered by the command line during application start-up, by using “System Menu” options, or with the Add/Remove dialog that is presented by clicking on the “Add/Remove” UI button located directly above the list. Right-clicking the mouse within the list will also provide a menu of options for managing the current list of nameservers to be benchmarked.

Unless altered by a command-line option, at start-up the list will initially be filled with the application’s internal list of possibly-useful publicly available alternative DNS nameservers, as well as with all of the nameservers currently configured for use by the system. Any changes made to the system’s configured nameservers will be immediately reflected in the list.

The Add/Remove Nameservers Dialog

ar-butThe “Add/Remove” button (above the nameserver IP list) displays the “Edit DNS Server IPs” dialog box shown to the left. It contains the following features and functions. Although their operation should probably be clear, some important terms and definitions, explained here, will appear throughout:

add-rem

  • Enter the IP to Add or Remove
    Once a valid nameserver IP address has been entered into the text field, the existing list of nameservers will be checked. If the IP already exists in the list, the “Remove” button will be enabled so that the existing resolver can be removed from the list. If the entered IP does not yet exist in the list, the “Add” button will be enabled so that this resolver IP can be added to the list.
  • Add System’s Nameservers
    This button immediately adds the nameservers that are currently configured for use by this system to the list of nameservers being benchmarked. Note that this is automatically done at the start-up of the Benchmark unless it is inhibited by a command-line parameter. Therefore, this button can be used at any time to restore the system nameservers, which may have been removed by any means, to the benchmarking list.
  • Add Default Nameservers
    The Benchmark contains a “default” built-in internal list of generally useful publicly available DNS resolving nameservers. This list is updated from time to time in new Benchmark versions, as needed, to keep the Benchmark’s built-in list current, relevant and most useful. The list is designed so that any of them might be worth considering as alternatives or additions for your system or network gateway. This button immediately adds all of these nameservers to the Benchmark’s list. Note that as with the “System” resolvers, all of these built-in nameservers are added to the Benchmark’s list, by default, at start-up.
  • Add .INI file Nameservers
    Personal lists of additional nameservers can be created for addition or removal to and from the Benchmarks server list. This button prompts for the selection of a file containing a list of nameservers to be added to the Benchmark’s current list. See the system menu and command-line pages for information about the file’s simple IP list format.
  • Remove System’s Nameservers
    As you can certainly guess, this button performs the reverse function of the “Add System’s Nameservers” button: It removes any of the system’s currently configured nameservers from the Benchmark’s IP server list.
  • Remove Default Nameservers
    While this button does remove any of the built-in default nameserver IPs from the benchmarking list, it does not remove any that are also currently in use by the system. So if, for example, the system was configured to use the OpenDNS nameservers that also occur in the Benchmark’s built-in list, this will not remove those from the list.
  • Remove .INI file Nameservers
    Given an IP list occurring in a file provided by the user, this removes any nameservers occurring in the list that are not also system nameservers.
  • Remove All Nameservers
    This quickly removes all DNS nameservers from the benchmark’s list. This is useful if you wish to only benchmark a few specific nameservers or prior to loading another .INI file.
  • Save Nameservers to .INI File
    The list of nameservers currently appearing in the Benchmark’s list is written to a file whose name is provided by the user. This will be a simple list of IP addresses followed by the nameserver’s reverse DNS (rDNS) domain name, if any, one per line. For documentation purposes, comments of any kind may later be added after each line’s IP address. (Only the initial IP address is significant on each line.)
  • Remove X Dead Nameservers
    It may be that some of the nameservers in the application’s built-in list will be “dead” in one way or another, colored red, and not benchmarked. This button, when enabled, will show how many dead nameservers are present (16 in the screen sample above) and will remove them from the active nameserver list when clicked.
  • Remove Redirecting Nameservers
    “Redirecting” nameservers are those that do not return errors when asked to lookup an invalid domain name. Instead, they redirect a web browser to another, often commercial marketing, page. Since many experienced users object to such behavior, the Benchmark identifies and colors these ORANGE (see below) and also offers to delete them all from the benchmark with a single click of this button.
  • Rebuild Custom List
    The custom “Fastest 50” nameserver list can be built or rebuilt at any time by clicking this button.

sortThe Sort Fastest First option determines whether the nameserver IP list is presented in numerical or best-performance-first order. The option remains unchecked and disabled until the first performance-measuring benchmark has been started, after which it is enabled and checked by default so that the fastest nameservers are always sorted to the top of the list. You may then uncheck and check this box to switch back and forth between IP and fastest-first sorting at any time.

dots-allThe second column of colored dots, donuts, circles and arcs provides a quick and comprehensive visual indication of the status of each respective DNS nameserver. Although the various configurations will likely be a bit overwhelming at first, once you get the hang of them you’ll find that they provide a convenient summary of each resolver’s important characteristics.

Regardless of its color, a filled-in dot indicates that the server is currently being used by the system and a hollow (donut) indicates that the server is not currently being used by the system.

2IPs

In the two-line sample above, the first line has a filled-in dot — meaning that the nameserver at this IP is currently configured for use. The text is also bold and the entire line has a black outline. The second line, with the hollow (donut) is not bold and has no outline because it is not currently being used by this system.

As for the colors of the INNER dots and donuts . . .

As you might expect, GREEN is good, whereas RED and ORANGE are not good in different ways:

dots-grnA green server is online, working, responding to DNS queries, and not misbehaving in any of the several ways the Benchmark detects and determines.

dots-redA server is given a red colored dot or donut when it simply refuses to reply to queries. In other words, the server is dead from the standpoint of being a useful resolver of DNS queries (which is what you really care about here). It might be that, depending upon your location or Internet Service Provider (ISP), some of the generally available public nameservers may be inaccessible to your computer, thus rendering them effectively dead, even though they might be accessible to other users elsewhere on the Internet.

You will definitely want to be certain that if anything is red, it is a hollow donut of red! A filled-in red dot would mean that one of the nameservers your system is currently configured to use is not replying to DNS queries . . . and NOTHING will slow down a system’s Internet access more than waiting for a non-responsive nameserver to answer DNS queries.

Note that you can “get the red out” by right clicking the mouse anywhere in the server listing and selecting “Remove X dead nameservers” from the pop-up menu (where ‘X’ will be replaced by the number of currently dead resolvers).

dots-orgOrange colored servers may be somewhat less desirable to use depending upon your feelings about the handling of typos and nonexistent domain names: The Benchmark colors a nameserver orange when it does not return an error in response to a query for a non-existent domain name. DNS nameservers are supposed to simply return a “Not Found” error to indicate that the requested domain name does not exist. But ISPs and third-party DNS service providers are adopting a new “revenue-enhancing” trick: Instead of returning an error, they redirect the user’s browser to their own marketing-related search page. This gives them a way of being “helpful” and of generating some additional marketing and advertising revenue from your typos or bad links — by causing you to confront a page you didn’t ask for and probably don’t want.

Many people (especially Internet purists) find this sort of thing quite annoying, so the Benchmark tests for it so that you will be informed. The good news is that people have been annoyed enough to induce most ISPs and providers who do this to offer the option of turning off this redirection. If your ISP, or a DNS provider you are using is doing this, you might wish to explore how to turn off the DNS redirection. Once that is done, you can quickly use this Benchmark to verify that your system’s DNS nameservers are all in the green and are neither red nor orange.

And as for the OUTER circles and arcs . . .

The outer circle of the resolver status icon shows what, if any, “DNS rebinding attack protection” the corresponding nameserver provides to its querying clients.

DNS rebinding attacksexternal reference utilize DNS to fool a browser’s scripting security into believing that local resources, such as the user’s own computer or router, are located in the same web domain as the script’s source. When this occurs, the browser’s “Same Origin Policyexternal reference protection is bypassed, giving scripts unrestricted access to the local resource. This allows scripts to do bad things such as change LAN router settings or access any resources and computers on the LAN. (That’s not good.)

Security conscious DNS nameservers are able to help block these attacks simply by never returning IP addresses that fall within the ranges of IP addresses commonly used with private LAN networks behind a router or the “Localhost IP” of 127.0.0.1 which computers use to refer to themselves.

GRC’s DNS Benchmark tests each nameserver to determine whether it blocks (filters) the return of these reserved private IP addresses — in both IPv4 and IPv6 formats. At the time of this feature’s release, only the OpenDNS nameservers can be configured to do this, and then only for IPv4, IPv6 versions of these queries are still able to sneak through. Since there is never any reason to return a private IP address from a public DNS request all nameservers should block the return of private IP addresses. Hopefully, more will in the future.

:/>  ‎App Store: EyeEm

As shown in the nearby diagram, the outer circle is divided into four quadrants with each quadrant associated with an IP address in non-routable private networks:

Интернет медленный как черепаха

The best possible protection is therefore represented by a full, unbroken, green outer ring signifying that all four network IP ranges are being blocked in both IPv4 and IPv6 formats. While no nameservers are providing this protection at the time of this new feature’s release, it is our hope that, with time, many nameservers will be updated to do so. No new programming is required to provide this feature. It is simply a matter of updating the nameserver’s configuration file.

Интернет медленный как черепаха

Temporary thin black arcs, as shown in the sample to the left, are presented while the detection of each nameserver’s rebinding protection is underway. If rebinding protection is proven not to be present the temporary arc will be removed. If either partial or full (both IPv4 and IPv6) protection is confirmed, the temporary black arc will be permanently replaced by either a thick green or blue arc for each network range.

The First Three Nameserver Sub-Tabs

(The “Response Time” tab is so brimming with features, goodies, details, tips & tricks, that it requires an entire section all to itself. So we’ll look at that one last.)

tab4aIf you think about it, you’ll realize that a DNS “Name” is an odd thing for a DNS server, itself, to have. Why? Because until you have a DNS server to perform DNS lookups you wouldn’t have any way of using the name to look up the DNS server’s IP address (and, come to think of it, if you could lookup the DNS server’s address, then you wouldn’t need to, since you’d apparently already have DNS services.) So, of course, that’s why we configure DNS nameservers by their IP addresses — because until we have the IP address(es) of DNS servers we have no way of looking up any DNS names.

However, it is convenient for network engineers to give names to the servers they manage. And it often turns out that the names given by engineers reveal additional interesting information about the server: what country they’re in, the domain name of their owner, their geographic location, their hierarchy in a ranking (primary, secondary, etc.) and all sorts of other possibly-interesting tidbits. So, naturally, the “Name” page of the DNS Benchmark brings this information to you, when it exists, to give you whatever information may be conveyed. More often than not, it’s useful to know, and it might help with any decision you might make about whether or not to use a particular DNS resolver for your own DNS lookups.

tab4bA freely available Internet database, provided by “senderbase.org”, can be used to lookup the owners of IP addresses and Internet address ranges. Although the information is not guaranteed to be complete, nor even completely accurate, it generally is, and it’s free. Like the reverse DNS name for servers, shown on the “Name” tab, we provided it to offer an “at a glance” reference to the DNS servers used by the Benchmark.

tab4cWhen the DNS Benchmark is started using its built-in list of nameservers, or whenever a nameserver IP is added to the benchmarking list, the Benchmark issues a series of DNS queries to verify the server’s availability and operational condition. As a result of this probing, the “Status” tab’s display will list each server’s status, as follows:

All nameservers start off with this status. The Benchmark sends each server a series of specially formed queries to determine and “characterize” various aspects of each server’s operation that would or could be important to anyone considering using the server for their own DNS resolution. Once that process has been completed the status will change to one of the alternatives below:

When all is well with a DNS server, this is the status that will be shown and most of the resolvers in the Benchmark’s list will have this status. In order to obtain this status, none of the many other behaviors (shown below) can have been detected . . .

“Test DNSSEC Authentication.” is an option located on the application’s “System Menu.” It is disabled by default (not checked) because some DNS servers completely collapse and fail when a DNSSEC-enabled query is presented to them. That’s not good, of course, and it might be good to know. Even more important for a benchmark is the fact that asking a nameserver to perform DNSSEC authentication can require additional time, thus affecting the Benchmark’s performance-measuring results. Since DNS Security (DNSSEC) is still more the exception than the rule on the Internet, we decided to leave it disabled by default, but also to definitely make it available.

When this option is enabled, the Benchmark will generate DNSSEC-formatted queries. Some servers will slow down, others will collapse and fail to reply. Both results are interesting and important. After you change the option you will be prompted and advised to “Re-Verify Internet Connectivity” to cause the Benchmark to re-characterize all nameservers under the new DNSSEC setting.

During our testing of nameserver behavior when deliberately confronted with an erroneous, undefined domain name (see the three “Bad Domain name”… statuses below), we discovered that some resolvers never replied at all to erroneous names. This really isn’t what you want, since a “typo” entered into a web browser will appear to “hang” while waiting for a reply from such a misbehavior nameserver. So this status advises you that this could happen if you were to depend upon such a resolver.

If, after many tries, the IP in question never replies in any way to any test DNS queries, its status will finally switch to this. The chart line will also be colored RED, since this server is certainly unsuitable for use as a DNS server from your location. Note that some ISP’s DNS servers are configured for access ONLY from within their own network, by their own customers. So it’s entirely possible, for example, for someone to give you the IP address of their blazingly fast DNS server, but for it to be inaccessible to you. (And it’s also possible for it to be fast for them mostly because it’s near to them on the Internet. That means that even if you could access their particular DNS nameserver, it might not be fast for you anyway.) And, finally, this is also what you would receive if the IP were entered incorrectly and the Benchmark was sending queries to a dead IP address, or one where no IP-resolving DNS server was present.

It is possible for a DNS server to actively refuse to answer a DNS query. One of the many “error codes” that can be returned is “Query Refused.” This error is typically returned when a DNS server exists at the IP being queried, but is configured to only permit use of its services from a certain subset of the Internet’s IPs, such as those belonging to an ISP’s customers.

Another variation of a DNS server which is not available or useful for performing DNS lookups is one that does not offer “recursion.” Recursion is the term used to mean that the server will, after receiving a query from a client, venture out onto the Internet on behalf of that client to lookup and find the entire answer. But not all DNS resolvers will do this. Some nameservers will only tell you about the domains they are configured to know about. They won’t go out and do any lookup work on a client’s behalf. Therefore, if the Benchmark detects such a server, it will flag it with this status, mark it red, and not bother benchmarking it, since it’s of no use to you.

During our extensive development testing of this Benchmark, we discovered nameservers that are simply broken in one way or another. Some return the “Server Error” error condition to report that they know they’re broken. Others apparently attempt to reply but their replies are invalid in significant ways. So, for whatever the reason, if the replies aren’t valid, the Benchmark makes sure you know with this status.

The “Response Time” Sub-Tab:

tab4dThe “Response Time” sub-tab contains the benchmark’s dynamic performance bar chart which graphically summarizes each DNS server’s performance. The primary features of the chart are detailed in the following annotated diagram:

setscaleBargraph Scaling: As noted in the annotated bargraph schematic above, the bargraph’s scale is dynamically set during the benchmark’s operation. This will have the effect of causing all bar lengths to rescale proportionally as the measured performance of the slowest nameserver is scaled to keep its longest bar within the bargraph’s extent. As the bargraph’s bars are resized, the underlying scale will follow the changes so that you can always relate the bar sizes to their time-delay value.

Although automatic scaling is normally what you’ll want, there are times when you may wish to override the bargraph’s automatic accommodation of the slowest nameserver (having the longest bar). For example, if you wished to compare bargraphs generated from different runs of the Benchmark, having them scaled identically would make a side-by-side comparison much easier. An option available on the application’s System Menu and also by right-clicking on the bargraph and selecting from the pop-up menu, will produce the small dialog box shown above-left. With it you can force any bargraph resolution you wish for the bargraph currently being displayed.

Power-User Tip: Some users prefer always locking the bargraph’s scaling to a fixed value, like 300 milliseconds full scale. If you hold down either of the keyboard’s SHIFT keys while you click the “Set Fixed Scale” button, the scale you set will be saved into the system’s registry and automatically remembered and used by the Benchmark every time it is run in the future. You may remove that “sticky” setting by holding down either SHIFT key when clicking on “Set Auto Scaling”.

The process of resolving a DNS query differs greatly depending upon whether or not the DNS nameserver being queried already knows the answer. One of the most important aspects of the Domain Name System (DNS) is the concept of local caching of slowly expiring information. By maintaining a “cache” (a local copy) of the IP addresses of frequently queried domain names, lookup times for the IPs of those domain names that are already present “in the cache” is absolutely minimized. Moreover, the load on other nameservers that would otherwise need to be queried for the answer is reduced, and overall Internet traffic is minimized.

When the IP address for a requested domain name is not already present in the local resolver’s cache, the resolver must perform a series of Internet queries to lookup and acquire the answer for the querying client. Once this new lookup has been performed, that information will then be cached and retained, often for many days or even weeks, under the assumption that someone else, or even the same client, might ask again before long. When that happens, the answer can be delivered much faster since the server being queried will have retained the answer from a sufficiently recent previous query.

What do the three different colored bars signify?

The three bars represent the differing performance
of cached versus uncached DNS lookup times.

As explained in the box above, any accurate and meaningful DNS performance measurement must consider the nature and importance of DNS caching. Ignoring the importance of caching blurs and muddies any benchmark’s results by mixing together the performance of cached and uncached lookups.

The GRC DNS Benchmark separately measures each DNS
server’s cached and uncached performance to yield much
more meaningful results than any other DNS benchmark.

red-barRED BAR = Cached Domain Name Lookup:
Thanks to the effectiveness of DNS caching, the most common type of lookup by far will be for domain name information that is already present in the local resolver’s cache storage. With public DNS servers being shared among tens of thousands of people, and with DNS records typically being valid for several days before expiration and renewal, popular domains such as Amazon.com, Yahoo.com, and others will be continually retained in the server’s cache for the fastest possible retrieval. In other words, when domains are looked up, the true measure of nameserver performance which most affects the average user is the speed of that server’s lookup and return of cached information, since cached “hit rates” are so high. For this reason, the Benchmark highlights the significance of this measured parameter by making its bar the largest of the three. And, although the sorting order can be changed from the System Menu, by default the Benchmark sorts nameserver performance by this cached name lookup performance first.

The Green and Purple bars are about your
local resolver’s Internet connectivity . . .

grn-barGREEN BAR = Uncached Domain Name Lookup:
In the less common —but definitely occurring— instances where a queried domain name has either never been looked up before, or has expired since it was last looked up (and the cache thus needs to be refreshed), the client’s local resolver must venture out onto the Internet to query other DNS nameservers for one or more pieces of information required to assemble the client’s answer. Not surprisingly, this can take significantly more time than simply retrieving the non-expired answer from the resolver’s own local cache storage.

It’s quite possible for your ISP to provide a local DNS resolver that is able to reply almost instantly to queries for data it has recently cached. But that same resolver could have a very slow —or overloaded & congested— connection to the Internet. That would cause it to be painfully slow whenever it needs to assemble an answer to a query it doesn’t already have in its local cache. If your Internet wanderings tend to take you off the beaten path, to domains less travelled, you could find yourself waiting a lot longer for a poorly-connected DNS resolver to obtain those IP addresses for you (since other users of the same DNS resolver would not have already asked for the IPs of the same domain names).

This DNS Benchmark separately measures and displays the time required by each DNS resolver to reach out onto the Internet and obtain an answer that’s not already in its cache.

The GREEN BAR shows the performance of each DNS resolver when it is forced to ask other Internet nameservers governing popular domains such as Google, Yahoo, YouTube, Live, Facebook, MSN, MySpace, etc. for their site’s IP addresses.

prp-barPURPLE BAR = DotCom Domain Name Lookup:
In order for a DNS resolver to query the nameservers for the most popular domains such as Google, Yahoo, and others, the resolver must first know the IP addresses of those nameservers. That information is looked up by asking the “Dot Com” nameservers for the IP addresses of the domain nameservers. As you might imagine, speedy and efficient access to the “Dot Com” nameservers is critically important too, since everything else depends upon it.

The PURPLE BAR shows the performance of each DNS resolver’s queries when they are forced to go directly to the “Dot Com” nameservers for the resolution of a lookup request for a dot COM domain name.

showuncachedSimplify the bargraph by showing only cached results: Interesting as the (green and purple bar) uncached results are, as mentioned above, we believe that the cached results are the most important. To reflect that, and to allow for a simplification of the bargraph presentation, the “Show Uncached” option may be unchecked to remove the two uncached (green and purple) bars and to rescale the chart as appropriate.

:/>  Настройка Почты Windows 10

Left and Right Clicking on the Bargraph

“Discoverable” Power-User Features

The overriding goal for the design of this —and all of GRC’s— software is, first and foremost, for the software to be truly easy to use. In the case of this Benchmark, you can just start it up and click on the red GRC “G” logo, and you’re running and watching the results. But there’s also much more . . .

We want the software to be useful to a wide range of users, casual and committed alike. So we have incorporated a carefully selected set of power-user features that are entirely optional. It is not necessary to know about them, understand them or ever use them. But they will serve to give the product much more depth and range of application.

To accomplish this secondary goal we have made many powerful features “discoverable” by the inquisitive user. Just poke around, try things, and you’ll find hidden goodies (all of which we will reveal on these pages.) Click on the System Menu at the application’s far upper left, or right-click on the bargraph, and you’ll see what we mean. There’s a huge amount of additional power and capability that you don’t need to worry about, but which can turn the Benchmark into a true power-user’s tool.

LEFT-Click and Drag to inspect the bargraph’s exact timing values:

inspectorAlthough the bargraph provides an instantaneous visual display comparison, it doesn’t show the underlying values. The “Tabular Data” tab does show these exact values, but that requires switching away from the graphical display. Left-clicking and dragging the mouse around the bargraph display will pop-up and display a “tracking inspector” (see the sample at the left) which will show the exact performance values of the bars for the server underneath the inspector.

Note that the pop-up inspector also serves to remind you what the three color bars represent. Also note that the pop-up inspector will operate upon any of the four sub-tabs of the Nameservers tab.

RIGHT-Click and release to display a menu of power-user features:

bg-popup

  • Remove this nameserver
    This provides a quick and direct way of removing a single nameserver. Just right-click on the nameserver you wish to remove and select “Remove this nameserver”. You could open the Add/Remove dialog and manually enter the IP address to remove, but this is much faster.
  • Remove X dead nameservers
    It may be that some of the nameservers in the application’s built-in list will be “dead” in one way or another, colored red, and therefore not benchmarked. This menu item, when enabled, will show how many dead nameservers are present (16 in the screen sample here) and will remove them when selected.
  • Remove slower nameservers
    This provides a fast means for dropping any nameservers which are slower than the nameserver clicked upon. This could be useful for re-testing with fewer nameservers, which will be faster. “Slower” is determined by the current sort choice, cached or uncached, which is also shown and selectable near the bottom of this menu.
  • Copy nameserver’s IP
    This quickly copies the IP of the nameserver clicked on to the system’s clipboard in textual format. It could then be pasted into a note or other application.
  • Set Graph Scale:XXX msec/auto
    This menu item shows both the current full-scale timing value (220 milliseconds (msec) in the sample above) and the current scaling mode, auto or fixed (manual). If this item is selected the “Set Bargraph Scale” dialog box mentioned above will be presented.
  • Export last results to CSV file
    Once a benchmark test has been run, a “spreadsheet” of fully detailed results (containing more detail than any other benchmark view) can be exported in CSV (Comma Separated Value) format. The DNS Benchmark’s CSV exportation is fully language localized. It will export using the proper field and numeric separators for the system’s locale. This fixed-format file can be imported into spreadsheets or processed by automated tools.
  • Copy All as Image to Clipboard
    A graphic bitmap image of the current sub-tab (Name, Owner, Status or Response Time), of the entire benchmark server list, will be copied to the system’s clipboard for subsequent pasting into any other graphic-capable application, document, or whatever. Note that this has the same function as the “Copy” button at the bottom-left of the Benchmark’s window.
  • Save All as Image to File
    This saves the same graphic image as the “Copy” option above, to a graphic file in either (uncompressed) Windows BMP or universal (compressed) PNG format. The PNG format file will be much smaller.
  • Sort by Cached Performance
    Shows the current sorting choice and, when selected, sorts by cached performance first, uncached performance second, and dotcom performance third.
  • Sort by Uncached Performance
    Shows the current sorting choice and, when selected, sorts by uncached performance first, cached performance second, and dotcom performance third.
  • Test DNSSEC Authentication
    DNSSEC is the “DNS SECurity” standard for securely (cryptographically) authenticating DNS data within the domain name system to prevent alteration and forgery. Since producing DNSSEC replies takes additional computation time (for the cryptography), benchmarking this aspect of a DNS server’s performance can be crucial. However, at the time of this Benchmark’s release, a surprising number of publicly available resolvers catastrophically fail when presented with valid DNSSEC-enabled queries. Therefore, the Benchmark’s use of DNSSEC is disabled by default. This option enables the Benchmark’s use of DNSSEC.After changing this setting you will be prompted and advised to re-characterize the nameservers under the new DNSSEC setting by re-verifying Internet connectivity.

What next?

Most likely, this is the only page you really need to read. Once you have read through the content above, you’ll have a very good idea of what the Benchmark does, how it works, and how to use it.

If you’re a casual user, just remember to check out the all-important “Conclusions” tab/page once the benchmark has completed. It will go a long way towards interpreting your results and help to keep you from missing anything important.

Additional System Menu Options:

dns-iconYou should also briefly familiarize yourself with the application’s System Menu. Just click on the application’s icon in the upper-left corner of the window the next time it’s running. You’ll find that most of its features duplicate those you already know because they are also available either on the Add/Remove nameservers dialog, or on the Nameserver’s tab right-click menu. But you should be aware of their existence.

Using the Command-Line:

Power-users who wish to alter the application’s default start-up behavior or who are interested in automating the entire DNS Benchmarking process, should also see the Command-Line Operation Reference page.

The additional pages, whose links are below, provide further detail and background that may be useful depending upon your needs:

Nslookup – работа с сервером dns из командной строки.

  
Утилита NSLOOKUP присутствует в операционных системах Windows, начиная с Windows NT , и предназначена для
формирования запросов к серверам DNS из командной строки. Фактически, утилита является аналогом службы DNS-клиент и
позволяет диагностировать проблемы с разрешением имен в системе DNS. По умолчанию, все запросы отправляются на DNS-сервер, адрес которого задан настройками сетевого подключения.
В терминах утилиты такой сервер является сервером по умолчанию (default server).
Команда ipconfig /all позволяет получить информацию о настройках протокола IP и,
в том числе, о серверах DNS, используемых в системе.

При запуске nslookup без параметров, утилита переходит в интерактивный режим, ожидая ввод команд пользователя.
Ввод знака вопроса или help позволяет отобразить справку о внутренних командах и опциях nslookup:

Команды nslookup:

(идентификаторы отображаются в верхнем регистре, квадратные скобки “[]” обозначают
необязательные параметры)

NAME – печать сведений об узле или домене NAME с помощью сервера по умолчанию
NAME1 NAME2 – та же операция, но в качестве сервера используется NAME2
help или ? – печать сведений о стандартных командах
set OPTION – установить параметр
all – печать параметров, текущего сервера и узла
[no]debug – печать отладочных сведений
[no]d2 – печать полных отладочных сведений
[no]defname – добавить имя домена ко всем запросам
[no]recurse – запрос рекурсивного ответа на запрос
[no]search – использовать список поиска доменов
[no]vc – всегда использовать виртуальную схему
domain=NAME – установить имя домена по умолчанию NAME
srchlist=N1[/N2/…/N6] – установить домен N1 и список поиска N1,N2 и т.д.
root=NAME – установить корневой сервер NAME
retry=X – установить число повторов X
timeout=X – установить интервал времени ожидания в X секунд
type=X – установить тип запроса (пр. A,AAAA,A AAAA,ANY,CNAME,MX ,NS,PTR,SOA,SRV)
querytype=X – то же, что и type
class=X – установить класс запроса ( IN (Internet), ANY)
[no]msxfr – использовать быструю зону MS для передачи
ixfrver=X – текущая версия, использующаяся в передаче запросов IXFR
server NAME – установить сервер по умолчанию NAME, используя текущий сервер по умолчанию
lserver NAME – установить сервер по умолчанию NAME, используя первоначальный сервер
root – сделать текущий сервер по умолчанию корневым сервером
ls [opt] DOMAIN [> FILE] – перечисление адресов в домене DOMAIN (необязательно: вывод в файл FILE)
-a – перечисление канонических имен и псевдонимов
-d – перечисление всех записей
-t TYPE – перечисление записей указанного типа RFC (пр. A,CNAME,MX,NS,PTR etc.)
view FILE – сортировка файла “ls” и его просмотр с помощью pg

exit – выход из программы

При запуске с некоторыми из выше перечисленных параметров, команда nslookup выполняется в не интерактивном режиме без
диалога с пользователем:

nslookup yandex.ru. – выполнить запрос к DNS-серверу, заданному по умолчанию, на разрешение доменного имени yandex.ru.
Для уменьшения количества ненужных запросов к серверам имен, имя домена нужно вводить в виде полностью определенного имени (fully qualified domain name) ,
т.е. с точкой в конце. Если этого не делать, то nslookup будет сначала выполнять запрос на разрешение имени относительно домена того
компьютера, на котором она выполняется, т.е. yandex.ru.mydomain.ru если имя локального домена – mydomain.ru.

nslookup -type=mx yandex.ru – то же, что и в предыдущем примере, но с указанием типа запрашиваемой записи -type=mx. Сервер DNS ответит на запрос утилиты nslookup перечислением почтовых серверов, обслуживающих домен yandex.ru

nslookup odnoklassniki.ru 8.8.8.8 – определить IP-адрес узла odnokassniki.ru с использованием DNS-сервера 8.8.8.8 (публичный DNS-сервер Google), вместо DNS-сервера, заданного в настройках сетевого подключения.

nslookup -type=mx -timeout=8 vk.com 208.67.220.220 – отобразить запись MX для домена vk.com из базы данных сервера с IP-адресом 208.67.220.220 (сервер OpenDNS). При выполнении команды, максимальное время ожидания ответа сервера – 8 секунд.

nslookup -type=any -timeout=8 vk.com 208.67.220.220 – то же, что и в предыдущем примере, но выполняется запрос на отображение любых типов записей.

Пример отображаемых данных:


Сервер: 208.67.220.220
Не заслуживающий доверия ответ:
vk.com internet address = 87.240.131.119
vk.com internet address = 87.240.131.99
vk.com nameserver = ns2.vkontakte.ru
vk.com nameserver = ns4.vkontakte.ru
vk.com nameserver = ns1.vkontakte.ru
vk.com nameserver = ns4.vkontakte.ru
vk.com nameserver = ns2.vkontakte.ru
vk.com nameserver = ns1.vkontakte.ru
ns1.vkontakte.ru internet address = 93.186.237.2
ns2.vkontakte.ru internet address = 93.186.224.100

Для разных версий nslookup и разных DNS-серверов, обслуживающих запрос, отображаемая информация может незначительно отличаться.
Тот же запрос, сформированный англоязычной версией утилиты nslookup.exe и направленный на обработку DNS-серверу компании Google приведет к отображению следующих данных:


Address: 8.8.8.8

Non-authoritative answer:
vk.com internet address = 87.240.131.120
vk.com internet address = 87.240.143.244
vk.com

primary name server = ns1.vkontakte.ru
responsible mail addr = ncc.vkontakte.ru
serial = 2022100501
refresh = 3600 (1 hour)
retry = 900 (15 mins)
expire = 604800 (7 days)
default TTL = 900 (15 mins)
vk.com AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:901
vk.com AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:902
vk.com AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:903
vk.com nameserver = ns1.vkontakte.ru
vk.com nameserver = ns2.vkontakte.ru
vk.com nameserver = ns4.vkontakte.ru
vk.com MX preference = 10, mail exchanger = mail.vk.com
vk.com text =”v=spf1 ip4:93.186.224.0/20 ip4:87.240.128.0/18 mx include:aspmx.googlemail.com ~all”

Сообщение “Не заслуживающий доверия ответ:”
(Non-authoritative answer: ) говорит о том, что выполняющий запрос DNS-сервер, не является владельцем зоны vk.com т.е.
записи для узла vk.com в его базе отсутствуют, и для разрешения имени использовался рекурсивный запрос
к другому DNS-серверу. Если отправить запрос DNS-серверу ns1.vkontakte.ru, то будет получен
авторитетный ответ (authoritative answer) :


Server: ns1.vkontakte.ru
Address: 93.186.237.2

vk.com

primary name server = ns1.vkontakte.ru
responsible mail addr = ncc.vkontakte.ru
serial = 2022100501
refresh = 3600 (1 hour)
retry = 900 (15 mins)
expire = 604800 (7 days)
default TTL = 900 (15 mins)
vk.com internet address = 87.240.131.118
vk.com AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:904
vk.com AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:905
vk.com AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:906
vk.com nameserver = ns4.vkontakte.ru
vk.com nameserver = ns1.vkontakte.ru
vk.com nameserver = ns2.vkontakte.ru
vk.com MX preference = 10, mail exchanger = mail.vk.com
vk.com text = “v=spf1 ip4:93.186.224.0/20 ip4:87.240.128.0/18 mx include:aspmx.googlemail.com ~all”
ns4.vkontakte.ru internet address = 93.186.239.253
ns4.vkontakte.ru AAAA IPv6 address = 2a00:bdc0:ff:4::2
ns1.vkontakte.ru internet address = 93.186.237.2
ns1.vkontakte.ru AAAA IPv6 address = 2a00:bdc0:ff:1::2
ns2.vkontakte.ru internet address = 93.186.224.100
ns2.vkontakte.ru AAAA IPv6 address = 2a00:bdc0:ff:2::2
mail.vk.com internet address = 93.186.236.94

Использование опции отладки (debug) позволяет получить дополнительную информацию, содержащуюся в заголовках запросов
клиента и ответов сервера (время жизни, флажки, типы записей и т.п.):

> server ns1.vkontakte.ru
————

Got answer:
HEADER:

opcode = QUERY, id = 5, rcode = NXDOMAIN
header flags: response, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 1, additional = 0

QUESTIONS:

ns1.vkontakte.ru, type = A, class = IN

AUTHORITY RECORDS:

-> (root)
ttl = 440 (7 mins 20 secs)
primary name server = a.root-servers.net
responsible mail addr = nstld.verisign-grs.com
serial = 2022101600
refresh = 1800 (30 mins)
retry = 900 (15 mins)
expire = 604800 (7 days)
default TTL = 86400 (1 day)

————
————
Got answer:

HEADER:

opcode = QUERY, id = 6, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 0, additional = 0

QUESTIONS:

ns1.vkontakte.ru, type = A, class = IN

ANSWERS:

-> ns1.vkontakte.ru
internet address = 93.186.237.2
ttl = 6350 (1 hour 45 mins 50 secs)

————
Default Server: ns1.vkontakte.ru
Address: 93.186.237.2

> vk.com
Server: ns1.vkontakte.ru
Address: 93.186.237.2

————
Got answer:
HEADER:

opcode = QUERY, id = 7, rcode = REFUSED
header flags: response, want recursion
questions = 1, answers = 0, authority records = 0, additional = 0

QUESTIONS:

vk.com, type = ANY, class = IN
————
————
Got answer:
HEADER:

opcode = QUERY, id = 8, rcode = NOERROR
header flags: response, auth. answer, want recursion
questions = 1, answers = 11, authority records = 0, additional = 7

QUESTIONS:

vk.com, type = ANY, class = IN

ANSWERS:

-> vk.com
ttl = 900 (15 mins)
primary name server = ns1.vkontakte.ru
responsible mail addr = ncc.vkontakte.ru
serial = 2022100501
refresh = 3600 (1 hour)
retry = 900 (15 mins)
expire = 604800 (7 days)
default TTL = 900 (15 mins)
-> vk.com
internet address = 87.240.131.99
ttl = 900 (15 mins)
-> vk.com
internet address = 87.240.131.119
ttl = 900 (15 mins)
-> vk.com
AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:901
ttl = 900 (15 mins)
-> vk.com
AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:902
ttl = 900 (15 mins)
-> vk.com
AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:903
ttl = 900 (15 mins)
-> vk.com
nameserver = ns1.vkontakte.ru
ttl = 900 (15 mins)
-> vk.com
nameserver = ns2.vkontakte.ru
ttl = 900 (15 mins)
-> vk.com
nameserver = ns4.vkontakte.ru
ttl = 900 (15 mins)
-> vk.com
MX preference = 10, mail exchanger = mail.vk.com
ttl = 900 (15 mins)
-> vk.com
text = “v=spf1 ip4:93.186.224.0/20 ip4:87.240.128.0/18 mx include:aspmx.googlemail.com ~all”
ttl = 900 (15 mins)
ADDITIONAL RECORDS:
-> ns1.vkontakte.ru
internet address = 93.186.237.2
ttl = 9000 (2 hours 30 mins)
-> ns1.vkontakte.ru
AAAA IPv6 address = 2a00:bdc0:ff:1::2
ttl = 9000 (2 hours 30 mins)
-> ns2.vkontakte.ru
internet address = 93.186.224.100
ttl = 9000 (2 hours 30 mins)
-> ns2.vkontakte.ru
AAAA IPv6 address = 2a00:bdc0:ff:2::2
ttl = 9000 (2 hours 30 mins)
-> ns4.vkontakte.ru
internet address = 93.186.239.253
ttl = 9000 (2 hours 30 mins)
-> ns4.vkontakte.ru
AAAA IPv6 address = 2a00:bdc0:ff:4::2
ttl = 9000 (2 hours 30 mins)
-> mail.vk.com
internet address = 93.186.236.94
ttl = 900 (15 mins)

————
vk.com
ttl = 900 (15 mins)
primary name server = ns1.vkontakte.ru
responsible mail addr = ncc.vkontakte.ru
serial = 2022100501
refresh = 3600 (1 hour)
retry = 900 (15 mins)
expire = 604800 (7 days)
default TTL = 900 (15 mins)
vk.com
internet address = 87.240.131.99
ttl = 900 (15 mins)
vk.com
internet address = 87.240.131.119
ttl = 900 (15 mins)
vk.com
AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:901
ttl = 900 (15 mins)
vk.com
AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:902
ttl = 900 (15 mins)
vk.com
AAAA IPv6 address = 2a00:bdc0:3:103:1:0:403:903
ttl = 900 (15 mins)
vk.com
nameserver = ns1.vkontakte.ru
ttl = 900 (15 mins)
vk.com
nameserver = ns2.vkontakte.ru
ttl = 900 (15 mins)
vk.com
nameserver = ns4.vkontakte.ru
ttl = 900 (15 mins)
vk.com
MX preference = 10, mail exchanger = mail.vk.com
ttl = 900 (15 mins)
vk.com
text = “v=spf1 ip4:93.186.224.0/20 ip4:87.240.128.0/18 mx include:aspmx.googlemail.com ~all”
ttl = 900 (15 mins)
ns1.vkontakte.ru
internet address = 93.186.237.2
ttl = 9000 (2 hours 30 mins)
ns1.vkontakte.ru
AAAA IPv6 address = 2a00:bdc0:ff:1::2
ttl = 9000 (2 hours 30 mins)
ns2.vkontakte.ru
internet address = 93.186.224.100
ttl = 9000 (2 hours 30 mins)
ns2.vkontakte.ru
AAAA IPv6 address = 2a00:bdc0:ff:2::2
ttl = 9000 (2 hours 30 mins)
ns4.vkontakte.ru
internet address = 93.186.239.253
ttl = 9000 (2 hours 30 mins)
ns4.vkontakte.ru
AAAA IPv6 address = 2a00:bdc0:ff:4::2
ttl = 9000 (2 hours 30 mins)
mail.vk.com
internet address = 93.186.236.94
ttl = 900 (15 mins)

:/>  Срок действия вашей лицензии Windows 10 истекает

nslookup 8.8.4.4 – отобразить имя узла, соответствующее IP-адресу 8.8.4.4

nslookup -ls -d mydomain.ru. > listdns.txt – отобразить все записи для домена mydomain.ru, обслуживаемого текущим
DNS-сервером. Вывод направляется в файл listdns.txt текущего каталога. Задавать абсолютный путь к файлу не следует, поскольку
все существующие на данный момент версии nslookup.exe успешно перенаправляют стандартный вывод в файл, только если он располагается в текущем каталоге.

При работе в интерактивном режиме, после старта на экран выводится приглашение к вводу команд – символ “>”
. При вводе команд необходимо учитывать регистр символов, например, LS -d mydomain.ru. будет воспринята как ошибочна команда,
а ls -D mydomain.ru. – как команда с ошибочной опцией.

Интернет медленный как черепаха

Final benchmark results, sorted by nameserver performance:

(average cached name retrieval speed, fastest to slowest)

208. 67.220.222 | Min | Avg | Max |Std.Dev|Reliab%|
—————- ——- ——- ——- ——- ——-
– Cached Name | 0.054 | 0.065 | 0.089 | 0.009 | 100.0 |
– Uncached Name | 0.056 | 0.201 | 0.380 | 0.110 | 100.0 |
– DotCom Lookup | 0.057 | 0.304 | 0.384 | 0.082 | 100.0 |
—<——–>— ——- ——- ——- ——- ——-
resolver4.opendns.com
OPENDNS – OpenDNS, LLC,US

198.153.194. 1 | Min | Avg | Max |Std.Dev|Reliab%|
—————- ——- ——- ——- ——- ——-
– Cached Name | 0.061 | 0.071 | 0.091 | 0.008 | 100.0 |
– Uncached Name | 0.065 | 0.160 | 0.411 | 0.088 | 100.0 |
– DotCom Lookup | 0.068 | 0.146 | 0.192 | 0.033 | 100.0 |
—<——–>— ——- ——- ——- ——- ——-
··· no official Internet DNS name ···
ULTRADNS – NeuStar, Inc.,US

208. 67.222.222 | Min | Avg | Max |Std.Dev|Reliab%|
—————- ——- ——- ——- ——- ——-
– Cached Name | 0.102 | 0.115 | 0.120 | 0.004 | 100.0 |
– Uncached Name | 0.074 | 0.259 | 0.402 | 0.113 | 100.0 |
– DotCom Lookup | 0.109 | 0.342 | 0.434 | 0.120 | 100.0 |
—<——–>— ——- ——- ——- ——- ——-
resolver1.opendns.com
OPENDNS – OpenDNS, LLC,US

208. 67.222.220 | Min | Avg | Max |Std.Dev|Reliab%|
—————- ——- ——- ——- ——- ——-
– Cached Name | 0.098 | 0.116 | 0.126 | 0.005 | 100.0 |
– Uncached Name | 0.092 | 0.261 | 0.402 | 0.112 | 98.0 |
– DotCom Lookup | 0.107 | 0.329 | 0.429 | 0.117 | 100.0 |
—<——–>— ——- ——- ——- ——- ——-
resolver3.opendns.com
OPENDNS – OpenDNS, LLC,US

156.154. 70. 1 | Min | Avg | Max |Std.Dev|Reliab%|
—————- ——- ——- ——- ——- ——-
– Cached Name | 0.118 | 0.124 | 0.131 | 0.003 | 100.0 |
– Uncached Name | 0.093 | 0.205 | 0.401 | 0.081 | 100.0 |
– DotCom Lookup | 0.128 | 0.196 | 0.250 | 0.037 | 100.0 |
—<——–>— ——- ——- ——- ——- ——-
rdns1.ultradns.net
ULTRADNS – NeuStar, Inc.,US

208. 67.220.220 | Min | Avg | Max |Std.Dev|Reliab%|
—————- ——- ——- ——- ——- ——-
– Cached Name | 0.102 | 0.127 | 0.159 | 0.014 | 100.0 |
– Uncached Name | 0.085 | 0.270 | 0.432 | 0.109 | 100.0 |
– DotCom Lookup | 0.106 | 0.335 | 0.452 | 0.119 | 100.0 |
—<——–>— ——- ——- ——- ——- ——-
resolver2.opendns.com
OPENDNS – OpenDNS, LLC,US

77. 88. 8. 8 | Min | Avg | Max |Std.Dev|Reliab%|
—————- ——- ——- ——- ——- ——-
– Cached Name | 0.159 | 0.171 | 0.194 | 0.009 | 100.0 |
– Uncached Name | 0.105 | 0.245 | 0.496 | 0.097 | 100.0 |
– DotCom Lookup | 0.164 | 0.183 | 0.231 | 0.016 | 100.0 |
—<——–>— ——- ——- ——- ——- ——-
dns.yandex.ru
YANDEX Yandex LLC,RU

77. 88. 8. 1 | Min | Avg | Max |Std.Dev|Reliab%|
—————- ——- ——- ——- ——- ——-
– Cached Name | 0.176 | 0.200 | 0.218 | 0.010 | 100.0 |
– Uncached Name | 0.059 | 0.284 | 0.612 | 0.129 | 100.0 |
– DotCom Lookup | 0.171 | 0.206 | 0.247 | 0.015 | 100.0 |
—<——–>— ——- ——- ——- ——- ——-
secondary.dns.yandex.ru
YANDEX Yandex LLC,RU

209.244. 0. 3 | Min | Avg | Max |Std.Dev|Reliab%|
—————- ——- ——- ——- ——- ——-
– Cached Name | 0.187 | 0.205 | 0.225 | 0.009 | 100.0 |
– Uncached Name | 0.092 | 0.261 | 0.447 | 0.087 | 100.0 |
– DotCom Lookup | 0.197 | 0.240 | 0.282 | 0.020 | 100.0 |
—<——–>— ——- ——- ——- ——- ——-
resolver1.level3.net
LEVEL3 – Level 3 Communications, Inc.,US

4. 2. 2. 3 | Min | Avg | Max |Std.Dev|Reliab%|
—————- ——- ——- ——- ——- ——-
– Cached Name | 0.195 | 0.213 | 0.231 | 0.008 | 100.0 |
– Uncached Name | 0.076 | 0.262 | 0.454 | 0.084 | 100.0 |
– DotCom Lookup | 0.201 | 0.252 | 0.298 | 0.027 | 100.0 |
—<——–>— ——- ——- ——- ——- ——-
c.resolvers.level3.net
LEVEL3 – Level 3 Communications, Inc.,US

4. 2. 2. 4 | Min | Avg | Max |Std.Dev|Reliab%|
—————- ——- ——- ——- ——- ——-
– Cached Name | 0.221 | 0.241 | 0.273 | 0.012 | 91.7 |
– Uncached Name | 0.088 | 0.321 | 0.510 | 0.107 | 93.2 |
– DotCom Lookup | 0.233 | 0.284 | 0.413 | 0.050 | 100.0 |
—<——–>— ——- ——- ——- ——- ——-
d.resolvers.level3.net
LEVEL3 – Level 3 Communications, Inc.,US

4. 2. 2. 2 | Min | Avg | Max |Std.Dev|Reliab%|
—————- ——- ——- ——- ——- ——-
– Cached Name | 0.250 | 0.267 | 0.283 | 0.007 | 100.0 |
– Uncached Name | 0.077 | 0.337 | 0.522 | 0.106 | 100.0 |
– DotCom Lookup | 0.259 | 0.370 | 0.450 | 0.056 | 97.9 |
—<——–>— ——- ——- ——- ——- ——-
b.resolvers.Level3.net
LEVEL3 – Level 3 Communications, Inc.,US

4. 2. 2. 1 | Min | Avg | Max |Std.Dev|Reliab%|
—————- ——- ——- ——- ——- ——-
– Cached Name | 0.267 | 0.280 | 0.294 | 0.007 | 100.0 |
– Uncached Name | 0.086 | 0.338 | 0.528 | 0.102 | 98.0 |
– DotCom Lookup | 0.274 | 0.316 | 0.356 | 0.025 | 100.0 |
—<——–>— ——- ——- ——- ——- ——-
a.resolvers.level3.net
LEVEL3 – Level 3 Communications, Inc.,US

50.116. 23.211 | Min | Avg | Max |Std.Dev|Reliab%|
—————- ——- ——- ——- ——- ——-
– Cached Name | 0.270 | 0.281 | 0.286 | 0.003 | 100.0 |
– Uncached Name | 0.078 | 0.309 | 0.472 | 0.080 | 100.0 |
– DotCom Lookup | 0.276 | 0.299 | 0.406 | 0.031 | 100.0 |
—<——–>— ——- ——- ——- ——- ——-
http://www.eqnic.net
SOFTLAYER – SoftLayer Technologies Inc.,US

74. 82. 42. 42 | Min | Avg | Max |Std.Dev|Reliab%|
—————- ——- ——- ——- ——- ——-
– Cached Name | 0.185 | 0.285 | 0.376 | 0.051 | 100.0 |
– Uncached Name | 0.064 | 0.350 | 0.524 | 0.087 | 100.0 |
– DotCom Lookup | 0.222 | 0.338 | 0.430 | 0.057 | 95.8 |
—<——–>— ——- ——- ——- ——- ——-
ordns.he.net
HURRICANE – Hurricane Electric, Inc.,US

4. 2. 2. 6 | Min | Avg | Max |Std.Dev|Reliab%|
—————- ——- ——- ——- ——- ——-
– Cached Name | 0.281 | 0.296 | 0.316 | 0.008 | 100.0 |
– Uncached Name | 0.115 | 0.387 | 0.902 | 0.152 | 100.0 |
– DotCom Lookup | 0.277 | 0.309 | 0.367 | 0.015 | 97.8 |
—<——–>— ——- ——- ——- ——- ——-
resolver8.Level3.net
LEVEL3 – Level 3 Communications, Inc.,US

107.170. 95.180 | Min | Avg | Max |Std.Dev|Reliab%|
—————- ——- ——- ——- ——- ——-
– Cached Name | 0.305 | 0.305 | 0.305 | 0.000 | 35.3 |
– Uncached Name | 0.004 | 0.078 | 0.295 | 0.145 | 83.3 |
– DotCom Lookup | 0.296 | 0.296 | 0.296 | 0.000 | 40.0 |
—<——–>— ——- ——- ——- ——- ——-
··· no official Internet DNS name ···
DIGITALOCEAN-ASN-NY2 – Digital Ocean, Inc.,US

198.153.192. 1 | Min | Avg | Max |Std.Dev|Reliab%|
—————- ——- ——- ——- ——- ——-
– Cached Name | 0.287 | 0.309 | 0.322 | 0.007 | 100.0 |
– Uncached Name | 0.074 | 0.364 | 0.606 | 0.113 | 100.0 |
– DotCom Lookup | 0.298 | 0.355 | 0.465 | 0.052 | 100.0 |
—<——–>— ——- ——- ——- ——- ——-
··· no official Internet DNS name ···
ULTRADNS – NeuStar, Inc.,US

156.154. 71. 1 | Min | Avg | Max |Std.Dev|Reliab%|
—————- ——- ——- ——- ——- ——-
– Cached Name | 0.288 | 0.312 | 0.325 | 0.008 | 100.0 |
– Uncached Name | 0.076 | 0.367 | 0.576 | 0.090 | 100.0 |
– DotCom Lookup | 0.305 | 0.347 | 0.386 | 0.021 | 100.0 |
—<——–>— ——- ——- ——- ——- ——-
rdns2.ultradns.net
ULTRADNS – NeuStar, Inc.,US

8. 8. 8. 8 | Min | Avg | Max |Std.Dev|Reliab%|
—————- ——- ——- ——- ——- ——-
Cached Name | 0.284 | 0.327 | 0.580 | 0.052 | 100.0 |
Uncached Name | 0.100 | 0.428 | 0.853 | 0.154 | 97.9 |
DotCom Lookup | 0.319 | 0.471 | 0.676 | 0.110 | 95.7 |
—<——–>— ——- ——- ——- ——- ——-
google-public-dns-a.google.com
GOOGLE – Google Inc.,US

75.127. 14.107 | Min | Avg | Max |Std.Dev|Reliab%|
—————- ——- ——- ——- ——- ——-
– Cached Name | 0.314 | 0.335 | 0.352 | 0.009 | 98.0 |
– Uncached Name | 0.077 | 0.366 | 0.551 | 0.102 | 100.0 |
– DotCom Lookup | 0.342 | 0.404 | 0.579 | 0.059 | 100.0 |
—<——–>— ——- ——- ——- ——- ——-
ns2.swedftp.com
AS-COLOCROSSING – ColoCrossing,US

8. 8. 4. 4 | Min | Avg | Max |Std.Dev|Reliab%|
—————- ——- ——- ——- ——- ——-
Cached Name | 0.279 | 0.338 | 0.662 | 0.078 | 98.0 |
Uncached Name | 0.072 | 0.438 | 1.180 | 0.201 | 95.8 |
DotCom Lookup | 0.317 | 0.492 | 1.112 | 0.195 | 100.0 |
—<——–>— ——- ——- ——- ——- ——-
google-public-dns-b.google.com
GOOGLE – Google Inc.,US

107.150. 40.234 | Min | Avg | Max |Std.Dev|Reliab%|
—————- ——- ——- ——- ——- ——-
– Cached Name | 0.262 | 0.354 | 0.410 | 0.039 | 100.0 |
– Uncached Name | 0.067 | 0.386 | 0.608 | 0.120 | 100.0 |
– DotCom Lookup | 0.297 | 0.388 | 0.472 | 0.042 | 100.0 |
—<——–>— ——- ——- ——- ——- ——-
mail.zee.li
DATASHACK – DataShack, LC,US

198. 46.156. 50 | Min | Avg | Max |Std.Dev|Reliab%|
—————- ——- ——- ——- ——- ——-
– Cached Name | 0.327 | 0.377 | 0.400 | 0.016 | 98.0 |
– Uncached Name | 0.081 | 0.402 | 0.676 | 0.121 | 97.9 |
– DotCom Lookup | 0.356 | 0.440 | 0.581 | 0.040 | 97.9 |
—<——–>— ——- ——- ——- ——- ——-
host.colocrossing.com
AS-COLOCROSSING – ColoCrossing,US

3.226.230. 72 | DNS queries are not answered at this IP.
—<——–>— ——- ——- ——- ——- ——-
n003-000-000-000.static.ge.com
··· unknown owner ···

4. 2. 2. 5 | DNS queries are not answered at this IP.
—<——–>— ——- ——- ——- ——- ——-
e.resolvers.level3.net
LEVEL3 – Level 3 Communications, Inc.,US

23. 90. 4. 6 | DNS queries are not answered at this IP.
—<——–>— ——- ——- ——- ——- ——-
dementia.virtual-dope.com
SERVERHUB-PHOENIX – Eonix Corporation,US

209.244. 0. 4 | DNS queries are not answered at this IP.
—<——–>— ——- ——- ——- ——- ——-
resolver2.level3.net
LEVEL3 – Level 3 Communications, Inc.,US

216.146. 35. 35 | The DNS server at this IP address does
not provide domain name service answering client queries.
It should not be used for normal client-based resolution.
—<——–>— ——- ——- ——- ——- ——-
resolver1.dyndnsinternetguide.com
DYNDNS – Dynamic Network Services, Inc.,US

216.146. 36. 36 | The DNS server at this IP address does
not provide domain name service answering client queries.
It should not be used for normal client-based resolution.
—<——–>— ——- ——- ——- ——- ——-
resolver2.dyndnsinternetguide.com
DYNDNS – Dynamic Network Services, Inc.,US

UTC: 2022-01-27, from 101031 to 101246, for 02:15.578

Interpreting your benchmark results above:

The following guide is only intended as a quick
“get you going” reference and reminder.

To obtain a working understanding of this program’s operation, and to familiarize yourself with its many features, please see the main DNS Benchmark web page by clicking on the “Goto DNS Page” button below.

Referring to this sample:

64. 81.159. 2 | Min | Avg | Max |Std.Dev|Reliab%
—————- ——- ——- ——- ——- ——-
– Cached Name | 0.001 | 0.001 | 0.001 | 0.000 | 100.0
– Uncached Name | 0.021 | 0.033 | 0.045 | 0.016 | 100.0
– DotCom Lookup | 0.021 | 0.022 | 0.022 | 0.001 | 100.0
—<O-OO—->— ——- ——- ——- ——- ——-
dns.chi1.speakeasy.net
Speakeasy

The Benchmark creates a table similar to the one above for each DNS resolver (nameserver) tested. The top line specifies the IP address of the nameserver for this table.

The first three numeric columns provide the minimum, average, and maximum query-response times in seconds. Note that these timings incorporate all network delays from the querying computer, across the Internet, to the nameserver, the nameserver’s own processing, and the return of the reply. Since the numbers contain three decimal digits of accuracy, the overall resolution of the timing is thousandths of a second, or milliseconds.

The fourth numeric column shows the “standard deviation” of the collected query-response times which is a common statistical measure of the spread of the values – a smaller standard deviation means more consistency and less spread.

The fifth and last numeric column shows the reliability of the tested nameserver’s replies to queries. Since lost, dropped, or ignored queries introduce a significant lookup delay (typically a full second or more each) a nameserver’s reliability is an important consideration.

The labels of the middle three lines are colored red, green, and blue to match their respective bars on the response time bar chart.

The “Cached Name” line presents the timings for queries that are answered from the server’s own local name cache without requiring it to forward the query to other name servers. Since the name caches of active public nameservers will always be full of the IPs of common domains, the vast majority of queries will be cached. Therefore, the Benchmark gives this timing the highest weight.

The “Uncached Name” line presents the timings for queries which could not be answered from the server’s local cache and required it to ask another name server for the data. Specifically, this measures the time required to resolve the IP addresses of the Internet’s 30 most popular web sites. The Benchmark gives this timing the second highest weight.

The “DotCom Lookup” line presents the timings for the resolution of dot com nameserver IP addresses. This differs from the Cached and Uncached tests above, since they measure the time required to determine a dot com’s IP, whereas the DotCom Lookup measures the time required to resolve the IP of a dot com’s nameserver, from which a dot com’s IP would then be resolved. This test presents a measure of how well the DNS server being tested is connected to the dot com nameservers.

The lower border of the table contains a set of eight indicators (O and -) representing non-routable networks whose IP addresses are actively blocked by the resolver to protect its users from DNS rebinding attacks: <O-OO—->. The “O” character indicates that blocking is occurring for the corresponding network, whereas the “-” character indicates that non-routable IP addresses are being resolved and rebinding protection is not present. The first four symbols represent the four IPv4 networks beginning with 10., 127., 172., and 192. respectively, and the second four symbols are the same networks but for IPv6.

The final two lines at the bottom of each chart duplicate the information from the Name and Owner tabs on the Nameserver page:

dns.chi1.speakeasy.net
Speakeasy

The first line displays the “Reverse DNS” name of the server, if any. (This is the name looked up by the nameserver’s IP address.) The second line displays the Ownership information, if any, of the network containing the nameserver

The final line of the automatically generated chart is a timestamp that shows the date and time of the start, completion, and total elapsed time of the benchmark:

UTC: 2009-07-15 from 164150 to 164459 for 03:08.703

All times are given in Universal Coordinated Time (UTC) which is equivalent to GMT. In the sample shown above, the entire benchmark required 3 minutes, 8.703 seconds to run to completion.

All, or a marked portion, of the Tabular Data results on this page may be copied to the Windows’ clipboard or saved to a file for safe keeping, sharing, or later comparison.
• • •

§

§

Знаете, как и всегда там бывает сначала всё не устраивало. Поменял квартиру, провайдер какой-то не государственный вроде бы, взял самый дорогой тариф на год. Первый месяц вообще пожалел, что связался с этим, позвал мастера, он немного улучшил скорость, но все равно меня скорость конкретно не устраивала. Прошел еще один месяц и я стал привыкать к интернету. Если найти нормальный торрент, то можно качать со скоростью чуть больше 1 мб, но это происходит не всегда, бывает отдельные какие-то фильмы, которые мало кто раздает качают от 700кб-до 1мб. А стандартно всё качает обычно на скорости от 100кб до 300кб, думаю еще от загруженности сети зависит ведь иногда вообще ничего не тянет. Что касается русских сайтов, mail порой не открывает,но не как у всех-чаще всего у меня он грузится, с контактом проблем вообще нет, но музыку не послушаешь и фильмы не посмотришь конечно же практически никак). Музыку правда если иногда можно прослушать , то надо предварительно подождать минут 5. В общем проблем с контактом нет никаких. Яндекс тоже всегда открывает нормально, ссылки тоже все открываются практически всегда. Если не открываются ,то использую hideme.ru. После включения открывает те ссылки,которые не открывались и закачивает фильмы, которые были по нулям без vpn’а, Без vpn’а в Китае жизнь не жизнь,полезная штука, иногда значительно увеличивает скорость, но опять таки это полупериодами ,то хорошо, то плохо.Полумера в общем. Не знаю когда Китае всё нормально будет с интернетом- наверное никогда. Их сайты-то летают так, что у меня в России так не летают.
Вопрос к тем, кто использовал hideme и перешел на другой сервис. Скажите, есть ли какая -то заметная разница?Или все примерно одинаково нестабильно?

Оставьте комментарий

Adblock
detector