Does a Duckduckgo privacy equivalent exist for DNS servers?

I was debugging a certificate problem when I realized that my DNS
servers were set to Google servers 8.8.8.8 & 4.4.4.2 which, from
a privacy standpoint, may be a bad thing (they remember everything).

Is there a set of DNS servers with a philosophy of NOT remembering
everything ... (sort of like how Duckduckgo promises for browsing)?

|I was debugging a certificate problem when I realized that my DNS
| servers were set to Google servers 8.8.8.8 & 4.4.4.2 which, from
| a privacy standpoint, may be a bad thing (they remember everything).
|
| Is there a set of DNS servers with a philosophy of NOT remembering
| everything ... (sort of like how Duckduckgo promises for browsing)?

OpenDNS

208.67.222.222
208.67.220.220

I don't know for sure how trustworthy they are,
but they're the only one I know of. Also, 4.4.4.2
is not Google. It's Level3. That's a good one for
speed. It's a major Internet backbone company.
I don't know about spying with them.

Another thing you might find useful is Acrylic
DNS Proxy. It's a small program that acts as a
local DNS server and then forwards the call. You
can set it to use any DNS server. The nice feature
is that it has its own HOSTS file that accept
wildcards. For instance:

127.0.0.1 *.doubleclick.net
127.0.0.1 *.doubleclick.com

A handful of those covers most ad servers.

Werner Obermeier wrote:

I was debugging a certificate problem when I realized that my DNS
servers were set to Google servers 8.8.8.8 & 4.4.4.2 which, from
a privacy standpoint, may be a bad thing (they remember everything).

https://developers.google.com/speed/public-dns/privacy

That's what Google promises.

Is there a set of DNS servers with a philosophy of NOT remembering
everything ... (sort of like how Duckduckgo promises for browsing)?

DuckDuckGo makes their promises, too. As users, we never will know what
they actually do with recording how their service is used. That
DuckDuckGo does not track your specific web navigation does not preclude
them from gathering logistics on the use of their service. DuckDuckGo
hides behind a private domain registration so you cannot see who they
are according to the registrant information for a domain registration.
A traceroute shows they are webhosted at Amazon AWS. For them to be
"hiring" folks to work for them means there are salaries. They have to
be selling something to pay their employees. According to
https://en.wikipedia.org/wiki/DuckDuckGo#Business_model, ads are their
revenue. When you do a search through them, their sponsored results
show first, just like at Google. DuckDuckGo tags sponsored results with
"AD" in a gold box. Google used to use a background color that is a bit
dim for contrast but now they also put "AD" to the left of the sponsored
results. Google makes lots of money with their search engine.
DuckDuckGo makes money, too, just less of it.

Not collecting personally identifying information about you is not the
same as tracking how their service is used, what sites are most accessed
(perhaps to support DNS caching or just to monitor what type of sites
their users are mostly visiting). They (Google or DuckDuckGo) may sell
their logistics or merely use it for their own purpose, like tweaking
the operation of their site.

Customers can pay cash at a tire store to avoid being tracked regarding
their purchases or even of visiting the store. That does not preclude
the store from monitoring their inventory, tracking which tires are the
best sellers, if a sale worked or not, or other logistics about their
operation.

I setup my DNS config as follows:
- Primary OpenDNS
- Secondary OpenDNS
- My router (which fails and passes to my ISP)
- Google DNS

If OpenDNS is down then I use my ISP's DNS service. There have been
times when my ISP is down (just for DNS, not for networking) in which
case Google gets used. Using Google would require 3 failures before it
got used. OpenDNS is my primary DNS provider. Google is only used as a
backup if both OpenDNS and my ISP are down or their servers fail.

Be careful of suggestions regarding other DNS providers. Many still
incorporate a redirection on DNS failures. Rather than return an error
status to your client, they return a success on the DNS lookup but what
they do is present their own "helper" page. A lookup that should fail
instead succeeds but you end up at their helper page. If a DNS lookup
fails, I don't want a redirection to a spammy search/helper page. If a
DNS lookup succeeds then I should get the IP address for the target
site, not some helper page elsewhere. Comodo's DNS, Norton's DNS, or
UltraDNS use redirection to helper pages on what should be a failed DNS
lookup and why I don't use those.

OpenDNS used to employ a redirection on DNS fail but quit after many
complaints from their users. I know a two companies that ceased using
them. If you paid for an OpenDNS account, you had the option to disable
the "redirection on DNS fail" to their helper page. For free accounts,
disabling the redirection meant you lost some other features, like
selecting which categories of sites to block via DNS. Later they
removed that option so free accounts were stuck with redirection.
Eventually they dumped the redirection. Verisign tried the same
shenanigans and got severely blasted since their responsibility was for
the .com TLD (top-level domain) and redirection violated the intent and
definition of DNS standards. OpenDNS eventually realized their error
and ceased redirection of DNS failures. Intelligent users don't want a
redirection to a helper or search page. They want to know if the DNS
lookup failed. So, for a while, I quit using OpenDNS until I noticed
they ceased that nuisancesome practice with a free account.

One way to determine if a DNS server is lying about DNS failures by
instead returning a success status but redirecting you to their helper
page is to use GRC's DNS benchmark utility (a Windows program, noted
since you cross-posted to different operating systems). It will test if
a DNS server returns a valid fail status or lies by returning a success
but actually gives you an IP address to a helper page, not to the site
you wanted to target. You don't want a DNS server that GRC shows as an
orange donut or circle. Those are the ones that lie about what should
have been a failed DNS lookup.

Don't get too hung up on the benchmarks. It may make one DNS server
look much faster than another but you are doing single tests rather than
monitoring their response over, say, a day to see how they may vary.
Only look for big differences. Some pages may have hundreds of links to
other off-domain (non-relative) source and every one of those will
require a DNS lookup by your client to resolve them. Relative refs are
at the same web server so there are no further DNS lookups. External or
absolute refs require a DNS lookup. The more external resources a page
uses means the more DNS lookups. A really slow DNS server will affect
that page's load time.

To understand what the colorings mean in GRC's benchmark, read
https://www.grc.com/dns/benchmark.htm.

Also remember that whether using your ISP's DNS server or someone else's
DNS server that all that DNS traffic goes across your ISP's network.
That means they can monitor and track all DNS lookups made by you. Your
ISP and any DNS provider can track your use of DNS. DNSSEC does not
encrypt your DNS inquiries. It is used for authenticating responses,
not encrypting them. To make it clearer, you can digitally sign your
e-mails but that does not encrypt them. Your e-mail can be tested by
the recipient that its integrity has not been corrupted but anyone in
the path between sender and recipient can snoop on the content of the
message. So a DNS server saying it supports DNSSEC is not protecting
the content of your inquires along the path between you and it. Your
ISP can still see what DNS inquiries you are issuing to their DNS server
or over their network to someone else's DNS server. If they want, they
can still track you. More likely they want info on how their service is
used, especially if there are any problems regarding DNS which is so
important because us humans want names versus computers that demand
numbers.

On Sat, 13 Jun 2015 19:18:47 -0400, Werner Obermeier wrote:

I was debugging a certificate problem when I realized that my DNS
servers were set to Google servers 8.8.8.8 & 4.4.4.2 which, from
a privacy standpoint, may be a bad thing (they remember everything).
Is there a set of DNS servers with a philosophy of NOT remembering
everything ... (sort of like how Duckduckgo promises for browsing)?

Install bind, get it running, and use 127.0.0.1 for the dns address.
It will contact the root dns servers directly, and it's usually
faster then using an external dns server.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

"Mayayana" wrote in :

OpenDNS
Also, 4.4.4.2 is not Google. It's Level3.

Is this correct yet for the recommended DNS servers:
8.8.8.8 (Google - but they probably remember forever)
4.4.4.2 (Level3 - who knows what they remember?)
208.67.222.222 (OpenDNS - who knows what they remember?)
208.67.220.220 (OpenDNS - who knows what they remember?)

Another thing you might find useful is Acrylic
DNS Proxy.

I will look up more about it over he
http://sourceforge.net/projects/acrylic/

VanguardLH wrote in :

https://developers.google.com/speed/public-dns/privacy

That's what Google promises.

Nice find. They apparently have 3 levels of "perminancy".
1. Their temporary logs (48 hours) have your entire IP address plus metadata.
2. Their so-called permanent logs keep your meta data (see below) for 2 weeks.
3. Their forever logs are apparently "random" samples of #2 above.

The "forever" logs (my term) contain a dozen items of your metadata:
a. Request domain name, e.g. www.google.com
b. Request type, e.g. A (which stands for IPv4 record), AAAA (IPv6 record), NS, MX, TXT, etc.
c. Transport protocol on which the request arrived, i.e. TCP or UDP
d. Client's AS (autonomous system or ISP), e.g. AS15169
e. User's geolocation information: i.e. geocode, region ID, city ID, and metro code
f. Response code sent, e.g. SUCCESS, SERVFAIL, NXDOMAIN, etc.
g. Whether the request hit our frontend cache
h. Whether the request hit a cache elsewhere in the system (but not in the frontend)
i. Absolute arrival time in seconds
j. Total time taken to process the request end-to-end, in seconds
k. Name of the Google machine that processed this request, e.g. machine101
l. Google target IP to which this request was addressed, e.g. one of our anycast IP addresses (no relation to the user's IP)

VanguardLH wrote in :

I setup my DNS config as follows:
- Primary OpenDNS
- Secondary OpenDNS
- My router (which fails and passes to my ISP)
- Google DNS

This seems very reasonable and well thought out; but it requires you
to know how to set up each machine's DNS (which isn't something I know
how to do yet).

At the moment, I have DNS set up in my home router (because it's easy).
I don't know how to set up DNS on my laptops (windows & linux).

VanguardLH wrote in :

Your
ISP can still see what DNS inquiries you are issuing to their DNS server
or over their network to someone else's DNS server. If they want, they
can still track you.

Good point that the ISP sees everything that goes to the DNS server.

Would a public VPN service or Tor Browser Bundle encryption solve that?

"David W. Hodgins" wrote in
:

Install bind, get it running, and use 127.0.0.1 for the dns address.
It will contact the root dns servers directly, and it's usually
faster then using an external dns server.

Wow. Reading that sentence was like throwing a rock at the Christmas
tree, causing all sorts of preconceived notions to crack & crash.

Are you saying we don't have to set a DNS server?
How does a ping get out to the right host then?

BTW, bind doesn't exist, but something called "dnsutils" does.

$ sudo apt-get install bind
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package bind is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
dnsutils:i386 bind9:i386 dnsutils bind9 manpages

E: Package 'bind' has no installation candidate

On Sat, 13 Jun 2015 22:39:27 -0400, Werner Obermeier wrote:

"David W. Hodgins" wrote in
:
Install bind, get it running, and use 127.0.0.1 for the dns address.
It will contact the root dns servers directly, and it's usually
faster then using an external dns server.

Wow. Reading that sentence was like throwing a rock at the Christmas
tree, causing all sorts of preconceived notions to crack & crash.

LOL! Interesting expression.

Are you saying we don't have to set a DNS server?
How does a ping get out to the right host then?

You do have to set a dns server, but it can be on localhost, or another
computer on the lan.

BTW, bind doesn't exist, but something called "dnsutils" does.

On Mageia 4 ...
$ rpm -qa|grep bind
bind-9.9.6.P2-1.mga4

There are other dns server packages that can be used such as deadwood,
dnsmasq, maradns, and others. Mageia doesn't have a dnsutils package,
so I don't know if it's a name server or just a collection of programs
like host, nslookup, whois etc, which in Mageia are in the bind-utils
package.

Learning how to configure bind can take a while, but it allows things
like ...
$ nslookup x3.hodgins.homeip.net
Server: 127.0.0.1
Address: 127.0.0.1#53

Name: x3.hodgins.homeip.net
Address: 192.168.10.2

If the distribution you're using doesn't have bind, it can be downloaded
from https://www.isc.org/downloads/bind/

If you have multiple computers, you can have one running linux with bind
or one of the other name server programs, and have windows on the other
computer, configured to use the linux computer as it's name server.

Regards, Dave Hodgins

Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

"David W. Hodgins" wrote in
:

Install bind, get it running, and use 127.0.0.1 for the dns address.
It will contact the root dns servers directly, and it's usually
faster then using an external dns server.

I skimmed but with deeper read these references, but, I'm still
a bit confused what happens when/if I used "bind" on my laptop.

Where does my laptop get the IP address from when I ping abc.com?

That is, when I "ping abc.com", there needs to be a lookup that
finds that abc.com is located at 199.181.132.250.

That lookup file must be astoundingly huge since it has to contain
every system on the entire Internet.

Does it simply download nightly a huge lookup file?
Is it that simple?


1. An Introduction to DNS and DNS Tools
http://www.linuxjournal.com/article/4597

2. How to install and configure Domain Name Service (DNS) in ubuntu linux
http://www.linuxinternetworks.com/ho...-ubuntu-linux/

3. Linux DNS server BIND configuration
http://linuxconfig.org/linux-dns-ser...-configuration

"Mayayana" wrote in :

I don't know for sure how trustworthy they are,
but they're the only one I know of. Also, 4.4.4.2
is not Google. It's Level3.

I just found 168 public DNS servers here.
http://www.linuxinternetworks.com/li...dns-addresses/

So, one privacy option may be to rotate them every two days, so that
you rotate through them all in a year.

10.0.0.2 = hetnet public dns server
10.0.0.3 = hetnet public dns server
10.0.0.5 = hetnet public dns server
144.140.70.16 = qld public dns server
144.140.70.29 = qld public dns server
144.140.71.15 = qld public dns server
154.11.128.129 = telus public dns server
154.11.128.130 = telus public dns server
154.11.128.150 = telus public dns server
154.11.128.1 = telus public dns server
154.11.128.2 = telus public dns server
156.154.70.1 = dnsadvantage public dns server
156.154.71.1 = dnsadvantage public dns server
170.215.126.3 = (Tennessee, Georgia) frontiernet public dns server
170.215.126.3 = (West Virginia) frontiernet public dns server
170.215.184.3 = (Tennessee, Georgia) frontiernet public dns server
170.215.184.3 = (West Virginia) frontiernet public dns server
170.215.255.114 = (New York (areas other than Rochester)) frontiernet public dns server
170.215.255.114 = (Rochester, NY frontiernet public dns server
170.215.255.114 = (Wisconsin, Minnesota, Iowa, North Dakota and Nebraska) frontiernet public dns server
193.38.113.3 = blueyonder/telewest cable public dns server
194.117.134.19 = telewest cable public dns server
194.168.4.100 = ntl cable public dns server
194.168.8.100 = ntl cable public dns server
194.177.157.4 = blueyonder/telewest cable public dns server
194.72.9.44 = btinternet public dns server
194.73.73.172 = btinternet public dns server
194.73.73.173 = btinternet public dns server
195.117.6.25 = orsc public dns server
195.121.1.34 = planet internet public dns server
195.121.1.66 = planet internet public dns server
195.22.0.204 = tvtel dns
195.22.0.205 = tvtel dns
195.92.195.94 = wanadoo adsl public dns server
195.92.195.95 = wanadoo adsl public dns server
198.153.192.1 = nortondns public dns server
198.153.194.1 = nortondns public dns server
199.166.24.253 = orsc public dns server
199.166.28.10 = orsc public dns server
199.166.29.3 = orsc public dns server
199.166.31.3 = orsc public dns server
199.2.252.10 = sprintlink public dns server
200.79.192.3 = cablemas public dns server
202.188.0.132 = tmnet streamyx adsl public dns server
202.188.0.133 = tmnet streamyx adsl public dns server
202.188.0.147 = tmnet streamyx adsl public dns server
202.188.0.161 = tmnet streamyx adsl public dns server
202.188.0.181 = tmnet streamyx adsl public dns server
202.188.0.182 = tmnet streamyx adsl public dns server
202.188.1.23 = tmnet streamyx adsl public dns server
202.188.1.25 = tmnet streamyx adsl public dns server
202.188.1.4 = tmnet streamyx adsl public dns server
202.188.1.5 = tmnet streamyx adsl public dns server
202.27.156.72 = xtra dsl public dns server
202.27.158.40 = xtra dsl public dns server
202.75.44.18 = schoolnet adsl public dns server
202.75.44.20 = schoolnet adsl public dns server
203.10.1.9 = westnet (adsl) public dns server
203.106.3.171 = schoolnet adsl public dns server
203.21.20.20 = westnet (adsl) public dns server
203.96.152.12 = paradise dsl public dns server
203.96.152.4 = paradise dsl public dns server
204.117.214.10 = sprintlink public dns server
204.127.202.4 = (Denver, Colorado) comcast public dns server
204.57.55.100 = orsc public dns server
204.97.212.10 = sprintlink public dns server
205.152.144.24 = bellsouth fast access dsl public dns server
205.152.144.25 = bellsouth fast access dsl public dns server
205.152.37.23 = bellsouth fast access dsl public dns server
205.152.37.24 = bellsouth fast access dsl public dns server
205.152.37.25 = bellsouth fast access dsl public dns server
205.188.146.145 = aol public dns server
206.13.28.31 = sbc yahoo dsl public dns server
206.13.28.60 = sbc yahoo dsl public dns server
206.13.31.13 = sbc yahoo dsl public dns server
206.13.31.5 = sbc yahoo dsl public dns server
207.173.225.3 = (Arizona) frontiernet public dns server
207.173.225.3 = (California) frontiernet public dns server
207.69.188.185 = earthlink public dns server
207.69.188.186 = earthlink public dns server
207.69.188.187 = earthlink public dns server
208.67.220.220 = opendns public dns server
208.67.222.222 = opendns public dns server
209.53.4.150 = telus public dns server
209.86.63.217 = (Cable) – Charlotte, NC earthlink public dns server
210.80.60.1 = i-cable public dns server
210.80.60.2 = i-cable public dns server
212.216.112.112 = alice public dns server
212.216.172.62 = alice public dns server
212.74.112.66 = tiscali public dns server
212.74.112.67 = tiscali public dns server
212.74.114.129 = (Cambridge) tiscali public dns server
212.74.114.193 = (Cambridge) tiscali public dns server
213.208.106.212 = nildram adsl public dns server
213.208.106.213 = nildram adsl public dns server
213.228.128.5 = netvisao cable public dns server
213.228.128.6 = netvisao cable public dns server
216.104.64.5 = (Grants Pass, OR) unicom public dns server
216.104.72.5 = (Portland, OR unicom public dns server
216.114.114.130 = (Illinois) harrisonville telephone company public dns server
216.114.114.132 = (Illinois) harrisonville telephone company public dns server
216.148.227.68 = (Denver, Colorado) comcast public dns server
216.231.41.2 = (Washington DC – probably) speakeasy public dns server
216.254.95.2 = (NY, Massachusetts and Pennsylvania) speakeasy public dns server
216.27.175.2 = (Atlanta, Georgia. Serves Florida too) speakeasy public dns server
216.67.192.3 = (Arizona) frontiernet public dns server
216.67.192.3 = (California) frontiernet public dns server
24.113.32.29 = unicom broadband public dns server
24.113.32.30 = unicom broadband public dns server
24.25.195.1 = (San Diego, CA) roadrunner cable public dns server
24.25.195.2 = (San Diego, CA) roadrunner cable public dns server
24.25.195.3 = (San Diego, CA) roadrunner cable public dns server
24.48.217.226 = Santa Monica, CA adelphia public dns server
24.48.217.227 = Santa Monica, CA adelphia public dns server
24.93.1.119 = (Rochester, NY) timewarner public dns server
4.2.2.1 = verizon public dns server
4.2.2.2 = verizon public dns server
4.2.2.3 = verizon public dns server
4.2.2.4 = verizon public dns server
4.2.2.5 = verizon public dns server
4.2.2.6 = verizon public dns server
62.189.34.83 = pipex adsl public dns server
62.241.162.35 = pipex adsl public dns server
62.31.176.39 = telewest cable public dns server
62.55.96.109 = (unchecked) silvermead satellite dsl isdn public dns server
62.55.96.226 = silvermead satellite dsl isdn public dns server
64.59.144.16 = shaw cable public dns server
64.59.144.17 = shaw cable public dns server
64.81.111.2 = (Denver, Colorado) speakeasy public dns server
64.81.127.2 = (Dallas, Texas) speakeasy public dns server
64.81.159.2 = (Baltimore and Washington DC) speakeasy public dns server
64.81.45.2 = (Los Angeles, California) speakeasy public dns server
64.81.79.2 = (Sacramento, California) speakeasy public dns server
66.133.170.2 = (New York (areas other than Rochester)) frontiernet public dns server
66.133.170.2 = (Rochester, NY) frontiernet public dns server
66.133.191.35 = (Illinois) frontiernet public dns server
66.133.191.35 = (Wisconsin, Minnesota, Iowa, North Dakota and Nebraska) frontiernet public dns server
66.153.128.98 = horry telephone coop public dns server
66.153.162.98 = horry telephone coop public dns server
66.92.159.2 = (Washington DC) speakeasy public dns server
66.92.224.2 = (Philadelphia) speakeasy public dns server
66.92.64.2 = (Boston, Massachusetts) speakeasy public dns server
66.93.87.2 = (Washington state and Oregon) speakeasy public dns server
67.21.13.2 = Los Angeles, CA adelphia public dns server
67.21.13.4 = Los Angeles, CA adelphia public dns server
67.50.135.146 = (Illinois) frontiernet public dns server
68.10.16.25 = cox public dns server
68.10.16.30 = cox public dns server
68.116.46.70 = charter comms cable public dns server
68.12.16.25 = (Oklahoma – Primary) cox hsi cable public dns server
68.12.16.30 = (Oklahoma – Secondary) cox hsi cable public dns server
68.168.1.42 = Florida adelphia public dns server
68.168.1.46 = Florida adelphia public dns server
68.2.16.30 = (Oklahoma – Tertiary) cox hsi cable public dns server
68.42.244.5 = (Taylor, Michigan) comcast public dns server
68.42.244.6 = (Taylor, Michigan) comcast public dns server
68.57.32.5 = (Virginia) comcast public dns server
68.57.32.6 = (Virginia) comcast public dns server
68.62.160.5 = (Huntsville, Alabama) comcast public dns server
68.62.160.6 = (Huntsville, Alabama) comcast public dns server
68.87.64.196 = Comcast Secondary DNS Server. comcast public dns server
68.87.66.196 = Comcast (national) Primary DNS Server. comcast public dns server
68.87.96.3 = (Pennsylvania) comcast public dns server
68.87.96.4 = (Pennsylvania) comcast public dns server
68.9.16.30 = cox public dns server
69.44.143.245 = cablemas public dns server
8.8.4.4 = google public dns server
8.8.8.8 = google public dns server

On Sat, 13 Jun 2015 23:13:21 -0400, Werner Obermeier wrote:

Where does my laptop get the IP address from when I ping abc.com?

That is, when I "ping abc.com", there needs to be a lookup that
finds that abc.com is located at 199.181.132.250.
That lookup file must be astoundingly huge since it has to contain
every system on the entire Internet.

No, it doesn't. The domain name has what are called glue records in
one of the root servers. In this case, it's in m.gtld-servers.net,
which links the domain name to one of the four dns servers for that
domain, such as sens01.dig.com. The four name servers have all of the
hostname records for all of the hosts within the domain abc.com.

Does it simply download nightly a huge lookup file?
Is it that simple?

No. The root servers have glue records saying which dns server to use
for each registered domain name. There are currently 13 root name
servers, so bind or any other name server has to check each of those
to find out what name server(s) is/are authoritative for a given domain
until it finds out which one has the glue records. Part of the process
of registering a hostname, is having the glue records added to one of
the root dns servers. Note that the root servers only have entries for
domain names, not every host within every domain.

Skim through the output of "dig +trace abc.com ANY". You may need to
find out which package contains the dig command, and install it. On
Mageia, it's in the bind-utils package.

The dns server has a file with the hard coded ip addresses of the root
servers. For bind, that's /var/named/named.ca which contains entries like
M.ROOT-SERVERS.NET. 3600000 IN A 202.12.27.33
M.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:dc3::35

It will also have entries for any domain it's authoritative for, which
for bind go in /etc/named.conf, or into a file included by that config
file.

Those ip addresses rarely change, but when one of them does, all name
servers have to be updated, or they won't find the servers for domain
names in the server with the changed address.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

"David W. Hodgins" wrote in
:

Skim through the output of "dig +trace abc.com ANY". Y

$ dig +trace abc.com ANY

; DiG 9.9.5-3ubuntu0.2-Ubuntu +trace abc.com ANY
;; global options: +cmd
;; Received 17 bytes from 192.168.1.1#53(192.168.1.1) in 1 ms

"David W. Hodgins" wrote in
:

There are currently 13 root name
servers, so bind or any other name server has to check each of those
to find out what name server(s) is/are authoritative for a given domain
until it finds out which one has the glue records.

I guess this is the "key" to understanding the whole bind setup!
Thanks.