Does a Duckduckgo privacy equivalent exist for DNS servers?

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.

| Have you heard of the Patriot Act? I know certain data can be collected,
| but I'm trying not to *give* it away!
|

Good point. I've seen article estimating how many
billions of dollars are being lost to US businesses
because foreign entities don't trust our gov't. But
I don't think anything will change. Just this week
Senator Mitch McConnell tried (but was stopped)
to sneak in a new pervasive spying law to replace the
Patriot Act law that didn't get renewed. Now that
we have the capability of unlimited data collection
I guess there will always be lots of bean counters
who think no amount of data is more than necessary.


| I don't see
| why not to use the DNS my ISP offers me. There's was a data retention
| law in my country, but that's history:
|
http://www.pcworld.com/article/2934792/belgian-data-retention-law-axed-by-constitutional-court.html
|

It does seem that Europe in general is more
civilized about these things. Your privacy laws
are the only thing helping us Americans. Our
Congress, President and courts certainly won't
do it. They're all currently in the pocket of
big business. We really don't even have the
kind of privacy and decency laws needed,
that *could* be enforced.

My hesitation with using an ISP, though, at
least in the US, is that there's nothing to stop
them from datamining and selling that data.
Many ISPs are also cable TV dealers. Cable TV
is on the verge of becoming spyware for
targetted ads. It gets tricky. Also, as Stan Brown
pointed out, ISPs often do sleazy things like
hijacking 404 errors and showing their own
advertising page to replace the default 404
page. That's in the US, anyway. You may have
better rules in place in Europe.

I wouldn't be at all surprised if, in the next few
years, someone with Verizon FIOS TV sees ads
bought by Ford, based on websites they've visited
and conversations they've had on their phone. (Or
even in front of their TV. There's already talk about
cable boxes that listen and watch in order to plan
targetted ads.)

In article , lid says...

On Sun, 14 Jun 2015 12:43:21 -0400, Mayayana wrote:

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

You avoid anything American?

I'm using a newsreader, "made in the USA", so, no. But I'm not going to
use a DNS which HQ's is based in the US.

I don't think
I've ever heard that view before.

Have you heard of the Patriot Act? I know certain data can be collected,
but I'm trying not to *give* it away!

Is there
another DNS server alternative? I've only
heard of OpenDNS.

There's Google's DNS, but I'm avoiding that too (obviously). I don't see
why not to use the DNS my ISP offers me. There's was a data retention
law in my country, but that's history:
http://www.pcworld.com/article/2934792/belgian-data-retention-law-axed-by-constitutional-court.html

I agree, if there's some alternative doesn't use anything based in the
US I'd prefer that also. Geez, I don't even want to travel there again
given that you become nothing more than an animal and treated as such at
the border (and that's both coming and going to-from Canada). I don't
even have any interest in some southern vacation because of the
likelyhood the plane will fly into US airspacea and likely land in the
US also. IMHO they've made a mockery of the ideals the country was
founded on and the obfuscation, deceit and lies they spout from their
mouths daily.

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

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.

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.

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

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.

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/2...es-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/veris...nused-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...nt-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.

On Sun, 14 Jun 2015 13:41:39 -0400, Mayayana wrote:

My hesitation with using an ISP, though, at
least in the US, is that there's nothing to stop
them from datamining and selling that data.
Many ISPs are also cable TV dealers. Cable TV
is on the verge of becoming spyware for
targetted ads. It gets tricky.

Belgium's a small country and there are two main players who have a
monopoly. Telenet (my ISP) offers cable, Belgacom (Skynet; I'm not
kidding :-) offers ADSL (some other, less important players offer ADSL
as well). They both offer Internet, (digital) TV, phone and mobile
phone.

Datamining is a possibility, but I just checked the general terms and
conditions and there's 3 pages about privacy in it. In short: they will
not sell data to a third party.

A court order could be used to access data, but with this data retention
(12 months!) law down the drain there's not going to be much to access.
I'm guessing that same data retention law costs a lot of money to those
providers, so I'm curious to what they're going to do now.

Also, as Stan Brown
pointed out, ISPs often do sleazy things like
hijacking 404 errors and showing their own
advertising page to replace the default 404
page. That's in the US, anyway. You may have
better rules in place in Europe.

I don't think our ISPs are allowed to do that. I haven't encountered
such a thing anyway. I just checked 'flanders123.be' and got a 'Server
not found'.

We /do/ have a (small) Belgian "Firewall". This is meant to block access
to, for example, Pirate Bay. You'll get to see this:

https://img707.imageshack.us/img707/4516/bigbelgianfirewall.png
(which is easily bypassed BTW)

The "firewall" is also meant to block access to pedophile sites /and/ to
sites that name certain pedophiles. The latter is (oh irony) forbidden
by privacy laws...

--
s|b

VanguardLH wrote in :

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

You mean entrance node, right?

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.

On Sun, 14 Jun 2015 22:48:02 +0200, "s|b" wrote:

The "firewall" is also meant to block access to pedophile sites /and/ to
sites that name certain pedophiles.

That's rough. I guess you've never heard of Tony Blair, then ?
He is certainly certain.
[]'s
--
Don't be evil - Google 2004
We have a new policy - Google 2012

qOn 2015-06-14, Werner Obermeier wrote:
"David W. Hodgins" wrote in
:

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

On 2015-06-14, David W. Hodgins wrote:
On Sun, 14 Jun 2015 08:29:44 -0400, Werner Obermeier wrote:

"David W. Hodgins" wrote in
:
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

On 2015-06-14, David W. Hodgins wrote:
On Sun, 14 Jun 2015 10:13:21 -0400, John Hasler 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