What affect will Allegedly Secure DNS have on such provider
hijackings, both of DNS and crammed-in content?
[Assuming we ever get to such; I know ASD is in line to deploy just
after perpetual motion and honest politicians..]
If what Verizon is doing is rewriting NXDOMAIN at their caching servers, DNSSEC will _not_ help. Caching servers do the validation and the insertion of the search engine IP addresses in the response would occur after the validation.
Regards,
-drc
Depends on whether or not the endpoints delegate DNSSEC validation to
Verizon. They don't have to.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
Right. People can run their own caching servers and can set up those servers to do DNSSEC validation after setting up (and maintaining) trust anchors for any DNSSEC signed zone they might want to validate. Of course, if they do this, the NXDOMAIN redirection won't be an issue since the customer will be bypassing the caching server that is doing the redirection...
As an aside, I note that Verizon is squatting on address space allocated to APNIC. From the self-help web page offered to opt out of this "service" (specific to the particular hardware customers might be using, e.g., http://netservices.verizon.net/portal/link/help/item?case=c32535), they state:
"5. Change the last octet of the Primary & Secondary DNS Server addresses to 14.
Example:
You look up the DNS information and the server numbers are:
123.123.123.12 Primary DNS
123.123.123.12 Secondary DNS
You would change the addresses to the following when statically assigning them to the computer or modem/router.
123.123.123.14 Primary DNS
123.123.123.14 Secondary DNS
Note that the .14 is the special set of servers that will opt you out of the DSN Assistance program."
123.0.0.0/8 is delegated to APNIC who have allocated it to CNC Group in China:
% whois -h whois.apnic.net 123.123.123.0
% [whois.apnic.net node-1]
% Whois data copyright terms http://www.apnic.net/db/dbcopyright.html
inetnum: 123.112.0.0 - 123.127.255.255
netname: CNCGROUP-BJ
descr: CNCGROUP Beijing province network
descr: China Network Communications Group Corporation
descr: No.156,Fu-Xing-Men-Nei Street,
descr: Beijing 100031
country: CN
...
Regards,
-drc
David Conrad wrote:
As an aside, I note that Verizon is squatting on address space allocated
to APNIC. From the self-help web page offered to opt out of this
"service" (specific to the particular hardware customers might be using,
e.g., http://netservices.verizon.net/portal/link/help/item?case=c32535),
they state:
[ snip example ]
I believe you're reading into that too much - they're not squatting on
anything in 123/8, they're just using "123.123.123" as example first
octets to demonstrate the concept of changing the last octet. IE, their
"standard" DNS servers always live at x.y.z.12 and their "opt-out" DNS
servers for the same customers live at x.y.z.14.
I suspect that the example is confusing enough that plenty of customers
are making the same mistake you did in reading it, and entering
"123.123.123.14", but I don't believe they're actually USING those IPs,
as it is (if not clearly enough) labeled as "Example".
Regards,
Tim Wilde
Do common endpoints (Windows Vista/XP, MacOS X 10.4/5) support DNSSEC
Validation? If not, then do people have a choice?
Regards
Bora
Yes and no.
If you run your own caching server and that caching server supports DNSSEC and you enable DNSSEC and set up/maintain the trust anchors, then yes.
So yes, pedantically speaking, there is a choice. Pragmatically speaking, I doubt this is really an option for any but the geekiest and/or terminally paranoid. Even the first bit of the previous "if" statement is probably beyond most...
Regards,
-drc
P.S. From experience, running your own caching server can result in problems when connecting via T-Mobile hotspot and some hotel authentication abominations... (sigh).
In article <E64EBBA5-3520-4E6A-9F00-6A884C383FE7@virtualized.org> you write:
What affect will Allegedly Secure DNS have on such provider
hijackings, both of DNS and crammed-in content?If what Verizon is doing is rewriting NXDOMAIN at their caching
servers, DNSSEC will _not_ help. Caching servers do the validation
and the insertion of the search engine IP addresses in the response
would occur after the validation.Regards,
-drc
All you have to do is move the validation to a machine you
control to detect this garbage.
dnssec-enable yes;
dnssec-validation yes;
forward only;
forwarders { <Verizon's caching servers>; };
dnssec-lookaside . trust-anchor <dlv registry>;
All lookups which Verizon has interfered with from signed zones
will fail.
Mark
Mark,
All you have to do is move the validation to a machine you
control to detect this garbage.
You probably don't need to bother with DNSSEC validation to stop the Verizon redirection. All you need do is run a caching server.
dnssec-enable yes;
dnssec-validation yes;
forward only;
forwarders { <Verizon's caching servers>; };
Why bother forwarding?
dnssec-lookaside . trust-anchor <dlv registry>;
You forgot the bit where everybody you want to do a DNS lookup on signs (and maintains) their zones and trusts and registers with <dlv
(of which there is exactly one that I know of and that one
has 17 entries in it the last I looked). You also didn't mention that everyone doing this will reference the DLV registry on every non-cached lookup. Puts a _lot_ of trust (both security wise and operationally) in <dlv registry>...
All lookups which Verizon has interfered with from signed zones
will fail.
Yeah, and Verizon customers would get a timeout (after how long?) instead of a more quickly returned A (or maybe a AAAA) RR to a Verizon controlled search engine. Not really sure the cure is better than the disease. Also not sure what the point is -- most common typos are already squatted upon and validly registered to a adsense pay-per-click web page, typically a search engine (e.g., www.baknofamerica.com). Seems to me the slimeballs have won yet again...
Regards,
-drc
David Conrad wrote:
Do common endpoints (Windows Vista/XP, MacOS X 10.4/5) support DNSSEC
Validation? If not, then do people have a choice?Yes and no.
Of course, nobody supports the "Evil bit" today, so some change would be
necessary one way or the other to deal with this. One wonders whether
Verizon's behavior is enough to cause Microsoft to turn on a caching
resolver. One issue Dave didn't raise is that firewalls often block DNS
requests from OTHER than caching resolvers.
Cough. So, how much is that NXDOMAIN worth to you?
Eliot
Cough. So, how much is that NXDOMAIN worth to you?
So, here's the problem really... NXDOMAIN is being judged as a
'problem'. It's really only a 'problem' for a small number of
APPLICATIONS on the Internet. One could even argue that in a
web-browser the 'is nxdomain a problem' is still up to the browser to
decide how best to answer the USER of that browser/application. Many,
many applications expect dns to be the honest broker, to let them know
if something exists or not and they make their minds up for the upper
layer protocols accordingly.
DNS is fundamentally a basic plumbing bit of the Internet. There are
things built around it operating sanely and according to generally
accepted standards. Switching a behavior because you believe it to be
'better' for a large and non-coherent population is guaranteed to
raise at least your support costs, if not your customer-base's ire.
Assuming that all the world is a web-browser is at the very least
naive and at worst wantonly/knowingly destructive/malfeasant.
MarkA and others have stated: "Just run a cache-resolver on your local
LAN/HOST/NET", except that's not within the means of
joe-random-sixpack, nor is it within the abilities of many
enterprise/SMB folks, talking from experience chatting up misbehaving
enterprise/banking/SMB customers first hand. What's to keep the ISP
from answering: provider-server.com when they ask for Yahoo.com or
Google.com or akamai-deployed-server.com aside from (perhaps) a threat
of lawyers calling?
Anyway, hopefully someone gets their head on straight about this
before other problems arise.
-Chris
From MAILER-DAEMON Tue Nov 6 03:36:53 2007
Return-Path: <>
X-Original-To: hyper_nanog@trapdoor.merit.edu
Delivered-To: hyper_nanog@trapdoor.merit.edu
Received: from localhost (localhost [127.0.0.1])
by trapdoor.merit.edu (Postfix) with ESMTP id 714B54DF81
for <hyper_nanog@trapdoor.merit.edu>; Tue, 6 Nov 2007 03:36:52 -0500 (EST)
X-Virus-Scanned: amavisd-new at merit.edu
Received: from trapdoor.merit.edu ([127.0.0.1])
by localhost (trapdoor.merit.edu [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id tzonWL-aJ8GP for <hyper_nanog@trapdoor.merit.edu>;
Tue, 6 Nov 2007 03:36:32 -0500 (EST)
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
by trapdoor.merit.edu (Postfix) with ESMTP id 7C1564DF7F
for <hyper_nanog@trapdoor.merit.edu>; Tue, 6 Nov 2007 03:35:48 -0500 (EST)
Received: by segue.merit.edu (Postfix)
id A7C1B58282; Tue, 6 Nov 2007 03:35:45 -0500 (EST)
Delivered-To: hyper_nanog@segue.merit.edu
Received: from mozart.merit.edu (mozart.merit.edu [198.108.95.9])
by segue.merit.edu (Postfix) with ESMTP id 6919958280
for <hyper_nanog@segue.merit.edu>; Tue, 6 Nov 2007 03:35:45 -0500 (EST)
Received: from bach.merit.edu (bach.merit.edu [198.108.95.7])
by mozart.merit.edu (MOS 3.8.2-GA)
with ESMTP id ATQ99016;
Tue, 6 Nov 2007 03:35:44 -0500 (EST)
Received: from chopin.merit.edu (chopin.merit.edu [198.108.95.8])
by bach.merit.edu (MOS 3.8.2-GA)
with ESMTP id AFL48286;
Tue, 6 Nov 2007 03:35:44 -0500 (EST)
Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26])
by chopin.merit.edu (MOS 3.8.2-GA)
with ESMTP id AIP16452;
Tue, 6 Nov 2007 03:35:43 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix)
id D4D1C4DF7E; Tue, 6 Nov 2007 03:32:41 -0500 (EST)
Delivered-To: nanog-outgoing@trapdoor.merit.edu
X-Virus-Scanned: amavisd-new at merit.edu
Received: from trapdoor.merit.edu ([127.0.0.1])
by localhost (trapdoor.merit.edu [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id zayK2thjyXLX for <nanog-outgoing@trapdoor.merit.edu>;
Tue, 6 Nov 2007 03:32:36 -0500 (EST)
Received: from mozart.merit.edu (mozart.merit.edu [198.108.95.9])
by trapdoor.merit.edu (Postfix) with ESMTP id 895D24DF7D
for <nanog-outgoing@trapdoor.merit.edu>; Tue, 6 Nov 2007 03:32:17 -0500 (EST)
Message-Id: <200711060832.ATQ98000@mozart.merit.edu>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="ATQ98000.1194337937/mozart.merit.edu"
Auto-Submitted: auto-generated (failure)
X-Junkmail-Status: score=10/50, host=bach.merit.edu
X-Junkmail-SD-Raw: score=unknown,
refid=str=0001.0A090208.4730263E.0094:SCFONLINE515760,ss=1,fgs=0,
ip=198.108.1.26,
so=2006-09-22 03:48:54,
dmn=5.4.3/2007-10-18
This is a MIME-encapsulated message
--ATQ98000.1194337937/mozart.merit.edu
On this date, there were delivery failures where the associated
deliver status notification messages were suppressed.
--- The following addresses had suppressed delivery status notifications ---
nanog@trapdoor.merit.edu
----- Transcript of session is unavailable -----
--ATQ98000.1194337937/mozart.merit.edu
Content-Type: message/delivery-status
Reporting-MTA: dns; mozart.merit.edu
Arrival-Date: Mon, 5 Nov 2007 00:00:00 -0500 (EST)
Final-Recipient: RFC822; nanog@trapdoor.merit.edu
Action: failed
Status: 5.2.0
Diagnostic-Code: SMTP; 550 5.7.1 message content rejected
Last-Attempt-Date: Mon, 5 Nov 2007 23:59:59 -0500 (EST)
X-Suppressed-Delivery-Status-Count: 30
--ATQ98000.1194337937/mozart.merit.edu
Content-Type: text/plain
No information is available on specific messages.
--ATQ98000.1194337937/mozart.merit.edu--
Hey -- I can so run a cache/resolver...
More seriously: you're right; most people can't and won't. But a
majority of customers in that space are using small NATs. Those
certainly can; in fact, they often do. It's just that today, they
simply talk to their upstreams, rather than starting from the root and
going down.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
Since this is verizon, one wonders why this has never been tried on
wrong, non-working phone numbers?
Visit your local chevy dealer, no interest for 12 months! We're
sorry, the number you have reached....
is it illegal?
How long before they'll just make you sit thru a few seconds of pitch
before connecting any call? Or any website? How hard is it to stick up
a quick bit of flash (e.g.) and then fade to the page you requested?
I don't think this is quite slippery-slopism. If you've been in this
business 20+ years, a long time, you remember having computers you
owned and weren't designed to efficiently flash ads at you, no "Free
Trial of" this and "would you like to upgrade now?" that, etc.
It's as if there's a magical constant at work in personal computing:
The number of minutes per hour of productive work is constant,
despite technological improvements.
For many years it was limited by the number of reboots, now as systems
have become more reliable it's become limited by the number of ads and
similar distractions you have to wade through to get anything done.
It really all comes down to the same problem, a flat-rate pricing
model, and marketeers realizing they can exploit this mercilessly at
no incremental cost (spam, "site finder", whatever.)
Without any pricing feedback in the loop all you can really do is try
to implement more and and more somewhat arbitrary rules (and ways of
enforcing them) to try to control behavior, and by whose say-so?
One is basically forced into a role analogous to the neighborhood
association or zoning board perhaps telling people what they can and
cannot do with their property (granted the latter seems to work in a
similarly charged environment.)
This message brought to you by...