Does a Duckduckgo privacy equivalent exist for DNS servers?

[Werner Obermeier]

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)?

[Mayayana]

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.

[VanguardLH]

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.

[David W. Hodgins]

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.)

[Werner Obermeier]

"Mayayana" <maya...@invalid.nospam> wrote in mlih21$p7$1...@dont-email.me:

> 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 here:
http://sourceforge.net/projects/acrylic/

[Werner Obermeier]

VanguardLH <V...@nguard.LH> wrote in cu3vp3...@mid.individual.net:

> 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)

[Werner Obermeier]

VanguardLH <V...@nguard.LH> wrote in cu3vp3...@mid.individual.net:

> 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).

[Werner Obermeier]

VanguardLH <V...@nguard.LH> wrote in cu3vp3...@mid.individual.net:

> 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?

[Werner Obermeier]

"David W. Hodgins" <dwho...@nomail.afraid.org> wrote in
op.xz62fxb...@hodgins.homeip.net:

> 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

[David W. Hodgins]

On Sat, 13 Jun 2015 22:39:27 -0400, Werner Obermeier <spamf...@arcor.de> wrote:

> "David W. Hodgins" <dwho...@nomail.afraid.org> wrote in
> op.xz62fxb...@hodgins.homeip.net:
>> 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

[Werner Obermeier]

"David W. Hodgins" <dwho...@nomail.afraid.org> wrote in
op.xz62fxb...@hodgins.homeip.net:

> 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/how-to-install-and-configure-domain-name-service-dns-in-ubuntu-linux/

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

[Werner Obermeier]

"Mayayana" <maya...@invalid.nospam> wrote in mlih21$p7$1...@dont-email.me:

> 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/list-of-public-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

[David W. Hodgins]

On Sat, 13 Jun 2015 23:13:21 -0400, Werner Obermeier <spamf...@arcor.de> 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.

[Werner Obermeier]

"David W. Hodgins" <dwho...@nomail.afraid.org> wrote in

op.xz7bqlc...@hodgins.homeip.net:

> 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

[Werner Obermeier]

"David W. Hodgins" <dwho...@nomail.afraid.org> wrote in

op.xz7bqlc...@hodgins.homeip.net:

> 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.

[David W. Hodgins]

On Sat, 13 Jun 2015 23:52:59 -0400, David W. Hodgins <dwho...@nomail.afraid.org> wrote:

> 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

I forgot to add. An up-to-date list of the name servers, and their
addresses can be obtained using the command ...
dig +bufsize=1200 +norec NS . @a.root-servers.net

[David W. Hodgins]

Strange I get ...

$ dig +trace abc.com ANY

; <<>> DiG 9.9.6-P2 <<>> +trace abc.com ANY
;; global options: +cmd
. 378190 IN NS m.root-servers.net.
. 378190 IN NS b.root-servers.net.
. 378190 IN NS j.root-servers.net.
. 378190 IN NS g.root-servers.net.
. 378190 IN NS c.root-servers.net.
. 378190 IN NS e.root-servers.net.
. 378190 IN NS k.root-servers.net.
. 378190 IN NS l.root-servers.net.
. 378190 IN NS f.root-servers.net.
. 378190 IN NS d.root-servers.net.
. 378190 IN NS i.root-servers.net.
. 378190 IN NS a.root-servers.net.
. 378190 IN NS h.root-servers.net.
;; Received 755 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com. 86400 IN RRSIG DS 8 1 86400 20150623170000 20150613160000 48613 . aGh9jU5tVvL+nxICfdPAWNtnfTZLhq4zxpTvCK5IIFONpEC9paAF498G RNOstk21yV+xPzIHevnrYscvfXxhsVa13hZe7akUZiU25EZQFh1cjgBH BBVvhdNZcv37NG490c+lnYneywdqRuBjKu3ip4cSl/bI/0coCx7Bd93C Fpk=
;; Received 731 bytes from 192.36.148.17#53(i.root-servers.net) in 214 ms

abc.com. 172800 IN NS sens01.dig.com.
abc.com. 172800 IN NS sens02.dig.com.
abc.com. 172800 IN NS orns01.dig.com.
abc.com. 172800 IN NS orns02.dig.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0QFMDQRCSRU0651QLVA1JQB21IF7UR NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20150617050222 20150610035222 33878 com. BmRR63rU6MqGAP9OAIhSPYjyM6iA1luC5NmUC3+GVlu2al8QbB2e5qAj cVZnVsV3+GmRY0XPm1p2dEwW1tlMai2zU0Z+bo8EnMK7l95riZ/CRrQz /btectiRyve7gL1jYgUrprivGuA5lHHCaHDufqcphbqOBQc2vGgf5b0Q msM=
KD6RVCED1ISEMEFVU1JS8FFNSMAVV8QM.com. 86400 IN NSEC3 1 1 0 - KD6V1RN93GSA02459NIB8JU7SA48G9O6 NS DS RRSIG
KD6RVCED1ISEMEFVU1JS8FFNSMAVV8QM.com. 86400 IN RRSIG NSEC3 8 2 86400 20150620042402 20150613031402 33878 com. gLyguO9FZ9rFnjwPm/ZjwpFR33wUZNVjZG+qwoopJCuHO8sW0CdCWguF e3SDLBJ7s5fYPfD6j1rhhzCOr+gLAXMcD9rkJJ6AyQpdZVviiTBHXWEO QrxvZ0VglNsVX5JHCQWVgtd17dxriZmbKq3top9cC1O/jRvkYql0FUZn M+g=
;; Received 673 bytes from 192.26.92.30#53(c.gtld-servers.net) in 35 ms

abc.com. 0 IN SOA sens01.dig.com. dns-ops.dig.com. 2015011400 1200 180 1209600 300
abc.com. 300 IN NS orns01.dig.com.
abc.com. 300 IN NS orns02.dig.com.
abc.com. 300 IN NS sens01.dig.com.
abc.com. 300 IN NS sens02.dig.com.
abc.com. 300 IN A 199.181.132.250
abc.com. 300 IN MX 5 cluster6.us.messagelabs.com.
abc.com. 300 IN MX 20 cluster6a.us.messagelabs.com.
abc.com. 300 IN TXT "/1/rOIB3t1pigzf8khjFRjNy05UiC/kANB/vyk40qlZid/H4osE+qil2vo6K7atBZ9L48IujPJ97CAkU3LpItA=="
abc.com. 300 IN TXT "v=spf1 mx ip4:204.128.192.17 ip4:204.128.192.36 ip4:204.128.192.43 ip4:192.195.66.26 ip4:192.195.66.28 ip4:192.195.66.36 -all"
abc.com. 300 IN TXT "MS=ms24761496"
;; Received 579 bytes from 139.104.186.14#53(sens02.dig.com) in 51 ms

[Werner Obermeier]

"David W. Hodgins" <dwho...@nomail.afraid.org> wrote in

op.xz7b4pd...@hodgins.homeip.net:

> Strange I get ...
> $ dig +trace abc.com ANY

I thought it was strange also as your note implied there was a lot
to dig through, but I had almost nothing.

Thanks for comparing. Much apprecated. It helps me to try to figure
out what's going on.

[Werner Obermeier]

Werner Obermeier <spamf...@arcor.de> wrote in mlitkt$m4n$1...@solani.org:

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

Here's a much shorter list of only 28 common public dns servers.
DNS Servers http://pcsupport.about.com/od/tipstricks/a/free-public-dns-servers.htm

107.150.40.234 = OpenNIC8 public dns server
109.69.8.51 = puntCAT12 public dns server
156.154.70.1 = DNS Advantage public dns server
156.154.71.1 = DNS Advantage public dns server
195.46.39.39 = SafeDNS7 public dns server
195.46.39.40 = SafeDNS7 public dns server
199.85.126.10 = Norton ConnectSafe5 public dns server
199.85.127.10 = Norton ConnectSafe5 public dns server
208.67.220.220 = OpenDNS Home4 public dns server
208.67.222.222 = OpenDNS Home4 public dns server
208.76.50.50 = SmartViper public dns server
208.76.51.51 = SmartViper public dns server
209.244.0.3 = Level31 public dns server
209.244.0.4 = Level31 public dns server
209.88.198.133 = GreenTeamDNS6 public dns server
216.146.35.35 = Dyn public dns server
216.146.36.36 = Dyn public dns server
37.235.1.174 = FreeDNS9 public dns server
37.235.1.177 = FreeDNS9 public dns server
50.116.23.211 = OpenNIC8 public dns server
74.82.42.42 = Hurricane Electric11 public dns server
81.218.119.11 = GreenTeamDNS6 public dns server
8.20.247.20 = Comodo Secure DNS public dns server
8.26.56.26 = Comodo Secure DNS public dns server
84.200.69.80 = DNS.WATCH3 public dns server
84.200.70.40 = DNS.WATCH3 public dns server
8.8.4.4 = Google public dns server
8.8.8.8 = Google public dns server

[Werner Obermeier]

"David W. Hodgins" <dwho...@nomail.afraid.org> wrote in
op.xz7b0qw...@hodgins.homeip.net:

> I forgot to add. An up-to-date list of the name servers, and their
> addresses can be obtained using the command ...
> dig +bufsize=1200 +norec NS . @a.root-servers.net

This one outputs 13 servers, which, from what you wrote, is
just about what I would have expected!
Thanks for that hint!

$ dig +bufsize=1200 +norec NS . @a.root-servers.net

; <<>> DiG 9.9.5-3ubuntu0.2-Ubuntu <<>> +bufsize=1200 +norec NS . @a.root-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7180
;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 25

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;. IN NS

;; ANSWER SECTION:
. 518400 IN NS f.root-servers.net.
. 518400 IN NS k.root-servers.net.
. 518400 IN NS a.root-servers.net.
. 518400 IN NS h.root-servers.net.
. 518400 IN NS e.root-servers.net.
. 518400 IN NS i.root-servers.net.
. 518400 IN NS l.root-servers.net.
. 518400 IN NS j.root-servers.net.
. 518400 IN NS c.root-servers.net.
. 518400 IN NS g.root-servers.net.
. 518400 IN NS m.root-servers.net.
. 518400 IN NS b.root-servers.net.
. 518400 IN NS d.root-servers.net.

;; ADDITIONAL SECTION:
f.root-servers.net. 3600000 IN A 192.5.5.241
f.root-servers.net. 3600000 IN AAAA 2001:500:2f::f
k.root-servers.net. 3600000 IN A 193.0.14.129
k.root-servers.net. 3600000 IN AAAA 2001:7fd::1
a.root-servers.net. 3600000 IN A 198.41.0.4
a.root-servers.net. 3600000 IN AAAA 2001:503:ba3e::2:30
h.root-servers.net. 3600000 IN A 128.63.2.53
h.root-servers.net. 3600000 IN AAAA 2001:500:1::803f:235
e.root-servers.net. 3600000 IN A 192.203.230.10
i.root-servers.net. 3600000 IN A 192.36.148.17
i.root-servers.net. 3600000 IN AAAA 2001:7fe::53
l.root-servers.net. 3600000 IN A 199.7.83.42
l.root-servers.net. 3600000 IN AAAA 2001:500:3::42
j.root-servers.net. 3600000 IN A 192.58.128.30
j.root-servers.net. 3600000 IN AAAA 2001:503:c27::2:30
c.root-servers.net. 3600000 IN A 192.33.4.12
c.root-servers.net. 3600000 IN AAAA 2001:500:2::c
g.root-servers.net. 3600000 IN A 192.112.36.4
m.root-servers.net. 3600000 IN A 202.12.27.33
m.root-servers.net. 3600000 IN AAAA 2001:dc3::35
b.root-servers.net. 3600000 IN A 192.228.79.201
b.root-servers.net. 3600000 IN AAAA 2001:500:84::b
d.root-servers.net. 3600000 IN A 199.7.91.13
d.root-servers.net. 3600000 IN AAAA 2001:500:2d::d

;; Query time: 331 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Sat Jun 13 21:39:36 PDT 2015
;; MSG SIZE rcvd: 755

[David W. Hodgins]

On Sun, 14 Jun 2015 00:41:26 -0400, Werner Obermeier <spamf...@arcor.de> wrote:

> dig +bufsize=1200 +norec NS . @a.root-servers.net

Note that any of the root servers can be used, just in case it's the 'a'
server that changes ip address. So
dig +bufsize=1200 +norec NS . @m.root-servers.net
will work too. The m can be any letter from a to m.

[mireero]

Sorry in advance, i haven't read the full thread.

Why not just using your isp dns, anyway they know what you do (and in
case of vpn stuff it doesn't matter).

Just thought, interesting question if using a hotspot, I may read finally :)

--
mireero

[Werner Obermeier]

"David W. Hodgins" <dwho...@nomail.afraid.org> wrote in

op.xz7layb...@hodgins.homeip.net:

> Note that any of the root servers can be used, just in case it's the 'a'
> server that changes ip address. So
> dig +bufsize=1200 +norec NS . @m.root-servers.net
> will work too. The m can be any letter from a to m.

So, if I understood you, any one of these 13 servers is the backbone
of the Internet in that THEY are the master DNS servers?

For example, if all 13 were to fail at once (just theoretical), would
the Internet stop working?

[Werner Obermeier]

mireero <mir...@free.fr> wrote in 557d47d9$0$3314$426a...@news.free.fr:

> Why not just using your isp dns, anyway they know what you do (and in
> case of vpn stuff it doesn't matter).

That's a valid point that the ISP *already* knows everything, and, in the
case of VPN or Tor, you're using the DNS server of the VPN or Tor account.

I really have no good counter to that argument.
I'm not sure why *anyone* uses any other server, except for speed reasons.

[John Hasler]

Werner Obermeier writes:
> I'm not sure why *anyone* uses any other server, except for speed
> reasons.

Because some ISPs are remarkably inept. Others do things like
redirecting failed lookups to a crappy search engine full of ads.
--
John Hasler
jha...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

[Stan Brown]

On Sun, 14 Jun 2015 11:22:33 +0200, mireero wrote:
> Why not just using your isp dns, anyway they know what you do (and in
> case of vpn stuff it doesn't matter).
>

Because, at least in the case of Time Warner, when you type an
invalid domain instead of saying it's invalid they take you to some
site of their choosing. Sometimes it's Time Warner's own site; other
times it's some site that they decided I should see.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com
Shikata ga nai...

[David W. Hodgins]

Yes and yes. If one of the servers goes down, the domain names it stores
would not be accessible, until it was replaced and restored, but any of
the root servers can be used to find all of the root servers that are working.

[David W. Hodgins]

On Sun, 14 Jun 2015 08:44:24 -0400, John Hasler <jha...@newsguy.com> wrote:

> Werner Obermeier writes:
>> I'm not sure why *anyone* uses any other server, except for speed
>> reasons.

> Because some ISPs are remarkably inept. Others do things like
> redirecting failed lookups to a crappy search engine full of ads.

Heh. I'd forgotten about that. If I remember correctly, that was why
I installed, and learned how to use bind ten years ago. The faster
response was just a side benefit.

[Andy Burns]

Werner Obermeier wrote:

> So, if I understood you, any one of these 13 servers is the backbone
> of the Internet in that THEY are the master DNS servers?
>
> For example, if all 13 were to fail at once (just theoretical), would
> the Internet stop working?

Yes, but just because there are 13 names of root DNS servers, most names
have many actual servers (e.g. there are 150 L servers) in widely spaced
locations using anycast routing.

e.g. there are three L's, two D's and one each of A, E, F, K and I in
the UK.

[David W. Hodgins]

On Sun, 14 Jun 2015 09:16:37 -0400, Andy Burns <usenet....@adslpipe.co.uk> wrote:

> Yes, but just because there are 13 names of root DNS servers, most names
> have many actual servers (e.g. there are 150 L servers) in widely spaced
> locations using anycast routing.

Ah, yes. I'd forgotten about that. Thanks for the reminder.

[John Hasler]

Werner Obermeier writes:
> So, if I understood you, any one of these 13 servers is the backbone
> of the Internet in that THEY are the master DNS servers?
> For example, if all 13 were to fail at once (just theoretical), would
> the Internet stop working?

David W. Hodgins writes:
> Yes and yes. If one of the servers goes down, the domain names it
> stores would not be accessible, until it was replaced and restored,
> but any of the root servers can be used to find all of the root
> servers that are working.

DNS would not stop working immediately. Every nameserver at every level
caches every lookup that it does for a period noted in the entry. The
root servers do not get consulted all that often.

[David W. Hodgins]

On Sun, 14 Jun 2015 10:13:21 -0400, John Hasler <jha...@newsguy.com> wrote:

> DNS would not stop working immediately. Every nameserver at every level
> caches every lookup that it does for a period noted in the entry. The
> root servers do not get consulted all that often.

True, but there are normally only three levels. The server being used, the root servers, and the domain severs. The longest cache setting I've seen is
1 day, though it's also not unusual to see short time like 10 minutes, or
less.

If the root servers were down, the dns server being used would only have
entries in it's cache for sites that had been looked up within the expiry
time of those entries.

For example, a site registered with dyndns.org typically has a timeout
of 600 seconds (10 minutes), so it would stop being accessible if the
root severs, or the dyndns servers were down for longer than that.

[s|b]

On Sat, 13 Jun 2015 20:17:32 -0400, Mayayana wrote:

> | 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,

Their HQ is based in the US, so I wouldn't use it.

--
s|b

[John Hasler]

David W. Hodgins writes:
> For example, a site registered with dyndns.org typically has a timeout
> of 600 seconds (10 minutes), so it would stop being accessible if the
> root severs, or the dyndns servers were down for longer than that.

The root servers only handle top level domains (com, net, org, biz,
info, etc.) org has a TTL of 86400.

[Lew Pitcher]

On Sunday June 14 2015 09:16, in alt.os.linux, "Andy Burns"

<usenet....@adslpipe.co.uk> wrote:

> Werner Obermeier wrote:
>
>> So, if I understood you, any one of these 13 servers is the backbone
>> of the Internet in that THEY are the master DNS servers?
>>
>> For example, if all 13 were to fail at once (just theoretical), would
>> the Internet stop working?
>
> Yes,

Yes and No.

No, the internet would not stop working. The TCP/IP protocols do not depend on
DNS; they are quite happy with IP addresses.

No, even the Domain Name System would keep going, just under a different set
of root servers. You can even use these alternative root servers now; check
out the UnderNIC project, for instance.

Yes, most Internet "users" would be unable to use the Internet, because they
depend on the official root servers, and don't know how to change to the
alternates. Anyone who gets their DNS resolved through their ISP or
through "public" DNS servers like Google would likely be unable to use the
Internet should the official root servers die.

> but just because there are 13 names of root DNS servers, most names
> have many actual servers (e.g. there are 150 L servers) in widely spaced
> locations using anycast routing.
>
> e.g. there are three L's, two D's and one each of A, E, F, K and I in
> the UK.

As for the idea of running Bind (or one of the other DNS server packages) on
your own systems, I think that it is a great idea (and I do it myself). Many
ISPs now "inject" their own IP addresses in response to unresolvable DNS
names, should you use their DNS service. With these sorts of "helpfull" ISPs,
you might point your web browser at http://www.GOUGGELE.COM/ and, instead of
getting a "server not found" message, get someone's ad service, or MITM of
google.com.

Running your own caching DNS server bypasses all that, and is often faster at
resolving names than your ISP's DNS (because of the lower traffic and smaller
hop-count).

--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

[John Hasler]

Lew Pitcher writes:
> Running your own caching DNS server bypasses all that, and is often
> faster at resolving names than your ISP's DNS (because of the lower
> traffic and smaller hop-count).

There are better choices for a caching-only server than BIND, though.

[David W. Hodgins]

On Sun, 14 Jun 2015 12:23:38 -0400, John Hasler <jha...@newsguy.com> wrote:

> There are better choices for a caching-only server than BIND, though.

If you only want a caching only name server, that's true. I also want
to be able to use the name server for dns within my lan. It took a
while to learn how to configure bind to do that, but it works. I did
provide a list earlier in this thread of other name servers, most of
which are caching only servers, not suitable for setting up dns within
a lan.

[Werner Obermeier]

Andy Burns <usenet....@adslpipe.co.uk> wrote in
8_idnSv_YvEo4-DI...@brightview.co.uk:

> (e.g. there are 150 L servers)

Just to understand, are these 150 "L" servers all duplicates
of the master "L" server?

[Werner Obermeier]

Lew Pitcher <lew.p...@digitalfreehold.ca> wrote in
iChfx.91361$iI1....@fx09.iad:

> Yes, most Internet "users" would be unable to use the Internet, because they
> depend on the official root servers, and don't know how to change to the
> alternates.

To better understand that statement, I ask whether I am in that category
of "user" above.

I have the typical operating systems (Windows & Linux) on laptops & desktops.
On those PCs, I do not touch any DNS settings (I don't know how to anyway).

On my home broadband router, when I set it up initially, it asked for DNS
servers so I gave it a primary & secondary (and maybe even tertiary) that
I plucked off the net (probably from this ng).

I'm sure my ISP has a DNS server - but I have no idea if I'm using it.

Having said that, am I one of those Internet "users" who will not be able
to use the Internet once the 13 a-m servers go down (theoretically)?

[Lew Pitcher]

On Sunday June 14 2015 12:55, in alt.os.linux, "Werner Obermeier"

In theory, yes.
Sorry.

[Pascal Hambourg]

Werner Obermeier a écrit :

>
> I just found 168 public DNS servers here.
> http://www.linuxinternetworks.com/list-of-public-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

These are RFC 1918 private addresses. How can they be public servers ?

[Pascal Hambourg]

Mayayana a écrit :

>
> OpenDNS
>
> 208.67.222.222
> 208.67.220.220
>
> I don't know for sure how trustworthy they are,

They have been known for lying, e.g. provide bogus wilcdard replies when
records did not exist.

[VanguardLH]

Werner Obermeier wrote:

> VanguardLH wrote:
>
>> 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

Well, they want to know how your reached them. There is also an API
that programs can use to access a Google search (e.g., search provider
add-ons in web browsers).

> b. Request type, e.g. A (which stands for IPv4 record), AAAA (IPv6 record), NS, MX, TXT, etc.

Seems odd they record anything other than the A record which is what you
use to find the IP address for the hostname you specified. Must be for
how you reach them, not how you reach a search result.

Google track to where you navigated from their search results by making
the clickable links into refs links. The link actually goes to Google
with parameters that specifies the target site from the search result on
which you click. That way, they could track how many users were going
to the same site.

For example, on a Google search on "window air conditioner", one of the
search results (and not a sponsored one) was for Walmart. When you
hover the mouse over the link using IE, its status bar makes you think
that link goes directly to Walmart at:

http://www.walmart.com/c/kp/window-air-conditioners

Nope, instead the actual href for the <A> HTML tag for the link goes to:

http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&sqi=2&ved=0CEYQFjABahUKEwiWztud74_GAhUMGowKHQR4AK0&url=http%3A%2F%2Fwww.walmart.com%2Fc%2Fkp%2Fwindow-air-conditioners&ei=Qc99VdapFYy0sASE8IHoCg&usg=AFQjCNGcP8IBW4wb1jHZ-wf90ww9QEpZ-g&bvm=bv.95515949,d.cWc

You'll notice the Walmart URL is buried as a parameter (and uses ISO
entities for the special characters not allowed in parameters, like
slash, colon, etc). That's how Google tracks to where you go. They
pass the connection to their own server which records the tracking info
and then their server passes the connect to the target site. When there
are problems at Google getting to the target site, I copy the URL
(right-click, Properties, copy the URL), paste it into the address bar
of the web browser, edit out the Google stuff, and replace the ISO
entities with their characters, and go directly to the target site.

Somehow, at least in IE, Google figured out how to make IE lie in its
status bar as to where a URL actually points. Peculiarly, once I
right-click on their redirection URL, IE's status bar then shows the
real URL instead of the one that Google wanted me to see that pretended
it was the short and direct URL to the site. I suspect it has something
to do with Javascript and using the onmousedown event (which probably
means any mouse button pushed). The <A> tag for the HTML link has an
onmousedown="return rwt(<parms>)" event for it. Apparently after I
right-click on the link, the onmousedown script ran and the URL the web
browser then sees is the real target.

That's Google tracking which result you clicked on. Lets them know who
went where. As for DuckDuckGo, yep, they do the SAME THING. I went to
duckduckgo.com and searched on "window air conditioner" and there was
the Walmart hit in the results. When I hover over the link, it looks
like it is a direct link to Walmart's site. Nope. When I right-click
on the link (and without having to do anything else), BOOM, I see the
following redirection and tracking link just like Google uses, which
was:

http://r.duckduckgo.com/l/?kh=-1&uddg=http%3A%2F%2Fwww.walmart.com%2Fcp%2Fair-conditioners-heaters-fans%2F133032

So DuckDuckGo is also tracking which results their users are clicking
on. It is the logistics they need to determine if there are problems
with their own search site, what types of sites their users are hitting,
if their users are clicking on sponsored links or not (and perhaps
deliberately clicking on the result hits that target the same site but
are not the "AD" sponsored links at the top), and so on.

I then went to the Ixquick search site. Someone had mentioned that
their searches are not tracked there. I searched there on "window air
conditioner" and hovered over a search hit. The web browser's status
bar showed a direct URL to the target site. Well, as shown above, that
is not necessarily the URL you end up using when you click on that link.
I right-clicked on the URL but the status bar didn't changed. I looked
at the Properties of the URL and it was a direct URL, not a redirection
back to the search engine with parameters that would let it track my
clicks on their search results.

It was more obvious when inspecting the link element that they were
fooling around with the web browser's status bar. They use the
onmouseover event to set the web browser's status bar to show what THEY
want you to see. They use the onclick event to run a script that has
something to do with rating the hit. While I did not see a redirection
URL (back to their server to track the click and then pass the client to
the target site), they do not take you directly to the site when you
click on their URL. Instead they use an openResult() function with the
target URL as parameters that will eventually connect you to the target
site. So they are just using different events and scripts to track on
what hits you click in their search results.

It's their service. They want the logistics to know how well or badly
their site is performing, to where their users are going, what types of
sites their visitors will go, the load on their service at different
times of day or from different geographic locations, and so on. After
all, without logistics, how would they know if their service was working
okay or what to do if there are problems?

> c. Transport protocol on which the request arrived, i.e. TCP or UDP

Probably has to do whether you used HTTP[S] or their API that programs
can use to access their service.

> 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)

Again, the logistics they need to know how their service is performing.
Anyone not tracking the operation of their server doesn't know how to
manage it, doesn't care about its operation, has a tiny load compared to
these huge online search services, or is too lazy to bother making sure
it is working at peak performance.

[VanguardLH]

Werner Obermeier wrote:

> VanguardLH wrote:
>

>> 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?

Actually I think that is why many of the search providers have gone to
HTTPS so your communication with them is encrypted. The ISP would still
see to where you connect but can't see the content.

Even if you specify http://www.google.com/, their server will switch you
to an HTTPS connection. DuckDuckGo and Ixquick do the same. Your ISP
(or any node between you and the search engine site) cannot see on what
you are searching but they can see you are visiting those search engine
sites.

DNS requests are not encrypted. So any node (host) between you and the
DNS server can not only see to where you visited (the DNS server) but
also see for what hostname you requested an IP address from the DNS
server. Well, when you connect to that site you got after the DNS
lookup told your client what IP address to use, your ISP can also see
when you connect to that target site. Even when using Tor, your ISP can
see the Tor exit node to which you connect. Since the ISP's have not
been kowtowing to provide a log of those Tor connects, the FBI instead
runs their own Tor exit nodes to map backwards into the Tor net. I
don't know if they've really been successful in that versus them seeing
the content a Tor gets when they happen to use an FBI-operated Tor exit
node. Do a search on "FBI Tor". I haven't bothered using the Dark Web
but my understanding is that, yes, you use HTTPS to encrypt you
connection to the Tor exit node but that means the Tor exit node is
where the scrambling stops (and has to be rescrambled to cross the Tor
mesh network to reach another Tor exit node). You have to hope the Tor
exit node to which you connect isn't being used for nefarious purposes,
like one ran by the FBI. From my reading, Tor is about being anonymous,
not about protecting the content of your traffic, plus you have to trust
the Tor exit node which is your entry into the Tor mesh network.
Perhaps someone that has used Tor for awhile and actually is familiar
with its security measures (versus someone that just uses Tor and thinks
they are safe) can explain how HTTPS to a Tor node does not then reveal
the source of that connection along with the content of that traffic.
The encrypted connection is encrypted in the nodes between the endpoints
of the connection, not at the endpoints.

VPN will also not hide to where you connect, only the content of your
traffic to the other endpoint. It is a security protocol, not a privacy
protocol. If you use VPN from home to your company's network, your ISP
can still see you (your IP) connecting to your company (their IP).
There are online VPN services that will try to hide to where you
eventually connect but your ISP (or anyone sniffing your network
traffic) can still see your IP connected to their IP. In a similar way
that the Tor network hides what is your true target site (versus your
ISP seeing your IP connect to a Tor exit node's IP), a VPN provider
would hide to where their network eventually connected. Of course, as
with the Tor exit node, you have to trust the VPN service provider
doesn't track your connections and sniff your content when you connect
to them to push that traffic to the endpoint.

Your ISP or anyone sniffing your network traffic will still see to where
you connect. Whether they can interrogate the traffic content depends
on whether it is encrypted or not. Any site to which you connect even
when encrypted is where you have to trust they don't look at your
traffic before sending it on. There's security of your communication
versus the privacy of where you visit. They're not the same thing.

[Stan Brown]

On Sun, 14 Jun 2015 14:28:30 -0500, VanguardLH wrote:
>
> Well, they want to know how your reached them. There is also an API
> that programs can use to access a Google search (e.g., search provider
> add-ons in web browsers).

True dat. And many Web sites, including my BrownMath.com and
OakRoadSystems.com, have domain-specific Google searches.

[VanguardLH]

Werner Obermeier wrote:

> mireero wrote:
>
>> Why not just using your isp dns, anyway they know what you do (and in
>> case of vpn stuff it doesn't matter).
>
> That's a valid point that the ISP *already* knows everything, and, in the
> case of VPN or Tor, you're using the DNS server of the VPN or Tor account.
>
> I really have no good counter to that argument.
> I'm not sure why *anyone* uses any other server, except for speed reasons.

I have had my ISP's DNS server go down or become unreachable (a node in
the route from me to their DNS server was very slow or unresponsive so I
could use my ISP's DNS server). Also, not every DNS server offered by
my ISP is a full function one. I don't remember the term for how one
DNS server is more robust than another. When I perform a 'dig' using
the DNS server that my ISP offers me for my region via their DHCP
server, it can't do a proper 'dig'. So I use Google's DNS server
(8.8.8.8) or OpenDNS (208.67.222.222).

While I could specify my ISP's DNS server (well, my router's IP address
to use its DNS server which is a fake one that merely fails all lookups
to pass them onto its upstream DNS server which is my ISP's DNS server)
as the first one in the list, I prefer to use OpenDNS. While I've seen
my ISP's DNS server go down about twice per year, I've yet to see
OpenDNS go down ever. Of course, I'm not making DNS requests every
millisecond every day every year. I don't know if there is a site that
tracks uptime (or downtime) for DNS servers. Tis probably why you
configure a primary and secondary DNS servers so one is the backup for
another; however, if the backup is from the same DNS provider, I have to
wonder if their primary goes down then perhaps might, too, their
secondary.

I'd rather have a fast and stable DNS server listed as my primary and
*if* it isn't reachable then use a secondary. I do specify the primary
and secondary as OpenDNS but also specify the third as my ISP DNS server
(via my router's WAN-side DNS assignment) and a fourth as Google's DNS.
Pretty hard to lose access to that many excepting for a network outage
which means I don't need DNS since I'm not going to connect anywhere,
anyway.

I do keep my ISP's DNS server in the list for one basic reason: you may
not be able to get beyond your ISP's own network but still need a DNS
server to access any of your ISP's hosts. There could be problems with
your ISP connecting to any other ISP. There could be problems with the
trunks to the network hubs. If you only specify 3rd party DNS servers,
you may not be able to reach them but may be able to reach your own
ISP's DNS server. I remember years ago a trunk line from Chicago was
dead for several hours that blocked any traffic from my region to the
west coast. If the DNS server you specified was over there, well, your
DNS lookups wouldn't just fail but they would never reach that DNS
server.

[VanguardLH]

Stan Brown wrote:

> mireero wrote:
>
>> Why not just using your isp dns, anyway they know what you do (and in
>> case of vpn stuff it doesn't matter).
>
> Because, at least in the case of Time Warner, when you type an
> invalid domain instead of saying it's invalid they take you to some
> site of their choosing. Sometimes it's Time Warner's own site; other
> times it's some site that they decided I should see.

Ah, the old "helper page redirection on what should've been a DNS
failure" ploy aka "DNS hijacking". Rather than fail a DNS lookup, they
make all of them succeed. They pretend the DNS lookup succeeded by
doling you an IP address for a helper web page (which is often just a
search page).

Not only is GRC's DNS Benchmark utility handy to testing performance of
DNS servers, it will identify those that do DNS hijacking. I don't know
which of Time Warner's DNS server is of focus, but I found 209.18.47.61
is one of theirs. I added it to the benchmark tool and reran it. Alas,
it could not connect to Time Warner's DNS server. Access is probably
restricted to client IP addresses that are within its allocation pool
(i.e., access is only by their customers).

As you noted, some ISP's think they are helping their customers by
presenting a search results list rather than showing the users that the
DNS lookup failed. My ISP (Comcast) was the same way except they
offered a means to opt out. You logged into your account with them and
set an option to opt out of the helper redirection on DNS fail. As soon
as I noticed my ISP was doing that crap, a little research showed they
had an opt out scheme. After opting out, it took 3 days before I was
really opted out and got the real DNS fails that were expected. No more
stupid search page on a DNS fail.

http://arstechnica.com/tech-policy/2009/08/comcasts-dns-redirect-service-goes-nationwide/

I'm not even sure that Comcast still does this. I opted out so I
wouldn't notice if suddenly I were not getting their helper/search page
on a DNS fail. I recall someone telling me that Comcast stopped their
DNS hijacking.

Verisign, the controller of .com registrations, tried the same crap over
a decade ago.

http://betanews.com/2003/09/16/verisign-redirects-unused-domains/

They got so many complaints, especially since they were only supposed to
act as a registrar, that they stopped that practice.

http://arstechnica.com/uncategorized/2008/05/verisign-gets-patent-for-dns-redirect-it-cant-use-itself/

I'm not sure how Verisign can patent a "feature" of DNS; however, the
Patent Office often grants patents that are either not enforceable or
have to be withdrawn, usually being much slower in that process than the
one in getting the patent. Of course, if the DNS providers stopped
being assholes by stopping their DNS hijacking practice then they can't
be sued by Verisign for patent infringement.

[Werner Obermeier]

VanguardLH <V...@nguard.LH> wrote in cu643q...@mid.individual.net:

> Even when using Tor, your ISP can
> see the Tor exit node to which you connect.

You mean entrance node, right?

[VanguardLH]

Werner Obermeier wrote:

> VanguardLH wrote:
>

>> Even when using Tor, your ISP can see the Tor exit node to which you
>> connect.
>
> You mean entrance node, right?

Correct. I would prefer to lump their entry and exit nodes as boundary
nodes to their mesh network. I'm not sure that anyone operating a Tor
exit node would not also be operating it as a Tor entrance node, so Tor
boundary node might be more accurate.

From what I've heard, the gov't goes after the exit nodes. Maybe
they're just the more spectacular stings due to the content they may be
trying to access versus the entrance nodes.

[David W. Hodgins]

On Sun, 14 Jun 2015 12:51:53 -0400, Werner Obermeier <spamf...@arcor.de> wrote:

> Andy Burns <usenet....@adslpipe.co.uk> wrote in

>> (e.g. there are 150 L servers)

> Just to understand, are these 150 "L" servers all duplicates
> of the master "L" server?

Yes.

[David W. Hodgins]

On Sun, 14 Jun 2015 12:55:53 -0400, Werner Obermeier <spamf...@arcor.de> wrote:

> Lew Pitcher <lew.p...@digitalfreehold.ca> wrote in
> iChfx.91361$iI1....@fx09.iad:
>> Yes, most Internet "users" would be unable to use the Internet, because they
>> depend on the official root servers, and don't know how to change to the
>> alternates.

> To better understand that statement, I ask whether I am in that category
> of "user" above.

If you don't know how to set up a dns server, or use the alternate root
servers, then yes.

> On my home broadband router, when I set it up initially, it asked for DNS
> servers so I gave it a primary & secondary (and maybe even tertiary) that

Note that a dns lookup will normally only use the first server. A second
or third sever will only be used if the prior server(s) either timed out
or responded with a server failure message.

[Jasen Betts]

qOn 2015-06-14, Werner Obermeier <spamf...@arcor.de> wrote:
> "David W. Hodgins" <dwho...@nomail.afraid.org> wrote in
> op.xz7layb...@hodgins.homeip.net:
>
>> Note that any of the root servers can be used, just in case it's the 'a'
>> server that changes ip address. So
>> dig +bufsize=1200 +norec NS . @m.root-servers.net
>> will work too. The m can be any letter from a to m.
>

> So, if I understood you, any one of these 13 servers is the backbone
> of the Internet in that THEY are the master DNS servers?
>
> For example, if all 13 were to fail at once (just theoretical), would
> the Internet stop working?

domain name service would soon stop working
IP would still work if you know the IP address you need.

--
umop apisdn

[Jasen Betts]

On 2015-06-14, David W. Hodgins <dwho...@nomail.afraid.org> wrote:

> On Sun, 14 Jun 2015 08:29:44 -0400, Werner Obermeier <spamf...@arcor.de> wrote:
>
>> "David W. Hodgins" <dwho...@nomail.afraid.org> wrote in
>> op.xz7layb...@hodgins.homeip.net:
>>> Note that any of the root servers can be used, just in case it's the 'a'
>>> server that changes ip address. So
>>> dig +bufsize=1200 +norec NS . @m.root-servers.net
>>> will work too. The m can be any letter from a to m.
>
>> So, if I understood you, any one of these 13 servers is the backbone
>> of the Internet in that THEY are the master DNS servers?
>> For example, if all 13 were to fail at once (just theoretical), would
>> the Internet stop working?
>

> Yes and yes. If one of the servers goes down, the domain names it stores
> would not be accessible, until it was replaced and restored, but any of
> the root servers can be used to find all of the root servers that are working.

those 13 only delegate the top level domains ( .com .net .us .au
.museum .sucks etc. ) off to the resonsible name servers.
which will likely delegate the next level to the server that actually
has the authoritative details.

jasen@fozzie:/etc/ssl/certs$ host -a www.google.com a.root-servers.net
Trying "www.google.com"
Using domain server:
Name: a.root-servers.net
Address: 198.41.0.4#53
Aliases:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18713
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 14

;; QUESTION SECTION:
;static.google.com. IN ANY

;; AUTHORITY SECTION:
com. 172800 IN NS m.gtld-servers.net.
[...]
com. 172800 IN NS a.gtld-servers.net.

;; ADDITIONAL SECTION:
m.gtld-servers.net. 172800 IN A 192.55.83.30
[...]
b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30
a.gtld-servers.net. 172800 IN A 192.5.6.30

so root-server points me to *.gtld-servers.net for information on .com

gtld-servers.net then points onwards to the DNS server with the
details for google.com

jasen@fozzie:$ host -a www.google.com m.gtld-servers.net.
Trying "static.google.com"
Using domain server:
Name: m.gtld-servers.net.
Address: 192.55.83.30#53
Aliases:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11888
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;www.google.com. IN ANY

;; AUTHORITY SECTION:
google.com. 172800 IN NS ns2.google.com.
google.com. 172800 IN NS ns1.google.com.
google.com. 172800 IN NS ns3.google.com.
google.com. 172800 IN NS ns4.google.com.

;; ADDITIONAL SECTION:
ns2.google.com. 172800 IN A 216.239.34.10
ns1.google.com. 172800 IN A 216.239.32.10
ns3.google.com. 172800 IN A 216.239.36.10
ns4.google.com. 172800 IN A 216.239.38.10

Received 171 bytes from 192.55.83.30#53 in 156 ms

and I have to ask one of them to get the ip address for static.

jasen@fozzie:/etc/ssl/certs$ host -a www.google.com ns3.google.com.
Trying "www.google.com"
Using domain server:
Name: ns3.google.com.
Address: 216.239.36.10#53
Aliases:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7943
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com.INANY

;; ANSWER SECTION:
www.google.com.300INA216.58.220.100
www.google.com.300INAAAA2404:6800:4006:801::2004

Received 76 bytes from 216.239.36.10#53 in 1174 ms


--
umop apisdn

[Jasen Betts]

On 2015-06-14, David W. Hodgins <dwho...@nomail.afraid.org> wrote:

> On Sun, 14 Jun 2015 10:13:21 -0400, John Hasler <jha...@newsguy.com> wrote:
>
>> DNS would not stop working immediately. Every nameserver at every level
>> caches every lookup that it does for a period noted in the entry. The
>> root servers do not get consulted all that often.
>
> True, but there are normally only three levels. The server being used, the root servers, and the domain severs. The longest cache setting I've seen is
> 1 day, though it's also not unusual to see short time like 10 minutes, or
> less.

I've seen 1 week.

> If the root servers were down, the dns server being used would only have
> entries in it's cache for sites that had been looked up within the expiry
> time of those entries.

it's have all the top level domains you've used recently.

probably .com .net and some others perhaps .io .me .us

> For example, a site registered with dyndns.org typically has a timeout
> of 600 seconds (10 minutes), so it would stop being accessible if the
> root severs, or the dyndns servers were down for longer than that.

No. .org has a TTL of 172800 which is 2 days. on "root-servers"

dyndns.org has a TTL of 1 day on b2.org.afilias-nst.org

so if the root servers fell over you'd still be able to find dyndns
sites for 48 hours
and if org.afilias-nst fell over too you'd still have access to dyndns
sites for 2 hours.

if dyndls fell on the other hand, the subdomains of dyndns.org would
be unavailable in under half a minute as ns1.dyndns.org gives a TTL of
20 for foobar.dnydns.org

--
umop apisdn

[John Hasler]

Jasen Betts writes:
> it's have all the top level domains you've used recently.

It'll have all the domains anyone who uses it has used recently.

[Jasen Betts]

On 2015-06-14, David W. Hodgins <dwho...@nomail.afraid.org> wrote:

> On Sun, 14 Jun 2015 12:23:38 -0400, John Hasler <jha...@newsguy.com> wrote:
>
>> There are better choices for a caching-only server than BIND, though.
>
> If you only want a caching only name server, that's true. I also want
> to be able to use the name server for dns within my lan. It took a
> while to learn how to configure bind to do that, but it works. I did
> provide a list earlier in this thread of other name servers, most of
> which are caching only servers, not suitable for setting up dns within
> a lan.

Dnsproxy does that too, It'll also serve all the names in /etc/hosts
to the lan, and possibly also the names announced in DHCP requests.

--
umop apisdn

[Char Jackson]

On Sun, 14 Jun 2015 02:20:20 +0000 (UTC), Werner Obermeier
<spamf...@arcor.de> wrote:

>"Mayayana" <maya...@invalid.nospam> wrote in mlih21$p7$1...@dont-email.me:
>
>> 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?)

This may have been corrected in a later post, but the Level 3 servers are
4.2.2.1 thru 4.2.2.6.


>208.67.222.222 (OpenDNS - who knows what they remember?)
>208.67.220.220 (OpenDNS - who knows what they remember?)

--

Char Jackson