That's a disagreement we'll have to have. Anytime this issue has been brought
up in a public setting (here, slashdot, etc.) has resulted in terrible press
and even corrective action. In particular, Network Solutions' attempt to
at this at the .com level was corrected. Of course I don't know what, if
any, ICANN pressure has to do with that, but the flash light practice was
apparently successful.
There's two types of in-flight editing of data by a provider:
1) The kind I've requested that they do.
2) The kind they're doing without my knowledge or consent.
The first should be monetized, the second needs a really bright flashlight.
Why is this distinction so hard for people to comprehend?
Does anyone have any idea of the financial 'rewards' SPs who do this kind of thing reap from it?
I'm wondering if the money is sufficient for the SPs in question to resist DNSSEC on the grounds that it will 'cost them revenue'.
If it isn't, then what's the economic case for doing it in the first place?
Dan White wrote:
From: David Conrad <drc@virtualized.org>
Date: Thu, 26 Nov 2009 07:42:15 -0800As you know, as long as people rely on their ISPs for resolution
services, DNSSEC isn't going to help. Where things get really offensive
if when the ISPs _require_ customers (through port 53 blocking, T-Mobile
Hotspot, I'm looking at you) to use the ISP's resolution services.the endgame for provider-in-the-middle attacks is enduser validators, which
is unfortunate since this use case is not well supported by current DNSSEC
and so there's some more protocol work in our future ("noooooooooooo!!").
Why not simply run a validating resolver locally?
i also expect to see DNS carried via HTTPS, which providers tend to leave
alone since they don't want to hear from the lawyers at 1-800-flowers.com.
(so, get ready for https://ns.vix.com/dns/query/www.vix.com/in/a&rd=1&ad=1).
To quote you, "noooooooooooo!!"
At some point, we may as well bite the bullet and redefine http{,s} as IPv7.
Regards,
-drc
Dan,
There are folks on this list who work for ISPs which are doing wildcards/synthesis/etc. They (or, more likely their management) can tell you there are obvious business reasons why they do wildcards/synthesis/etc. Perhaps I'm overly cynical, but I suspect that until those business reasons go away, shining a flash light will probably just result in more ISPs implementing wildcards/synthesis/etc.
That's a disagreement we'll have to have. Anytime this issue has been brought
up in a public setting (here, slashdot, etc.) has resulted in terrible press
and even corrective action. In particular, Network Solutions' attempt to
at this at the .com level was corrected.
Right. And since then, ICANN has contractually disallowed gTLD registries from doing SiteFinder like services (unless they can demonstrate such a service won't have a negative security/stability impact). However, as I said, ICANN has no control over what ccTLDs do and there are 12 doing wildcards/synthesis/NXDOMAIN redirection/etc. as I type this, namely:
CG (Congo) -- Web redirects to the registry website to register a .CG domain.
KR (South Korea) -- If it is a non IDNA-encoded IDN, converts to IDNA. For ASCII, generates a “fake” page-not-found error for web requests.
NU (Niue) -- Web requests solicit you to register the domain.
PH (Philippines) -- Web requests solicit you to register the domain.
PW (Palau) -- File not found error. Uses an invalid SSL certificate.
RW (Rwanda) -- Connection time out (wildcard site is down)
ST (Sao Tome) -- Web requests solicit you to register the domain. Uses an invalid SSL certificate.
TK (Tokelau) -- Connection refused (wildcard site is down)
VG (Virgin Is., UK) -- Web requests solicit you to register the domain.
VN (Viet Nam) -- Web requests solicit you to register the domain.
WS (Samoa) -- Web requests solicit you to register the domain.
CN (China) -- Uses synthesis for IDN labels. Returns NXDOMAIN for ASCII labels.
However, that's different than what I thought we were talking about. I thought we were talking about ISPs doing wildcards/synthesis/NXDOMAIN redirection/etc. There are a number of ISPs that do this, some of which are quite well known (there is even an Internet Draft on the techniques, see draft-livingood-dns-redirect-00). Pretty large flash light...
Regards,
-drc
From: David Conrad <drc@virtualized.org>
Date: Thu, 26 Nov 2009 13:25:39 -0800At some point, we may as well bite the bullet and redefine http{,s} as IPv7.
since products and services designed to look inside encrypted streams and
inspect, modify, or redirect them are illegal in most parts of the world:
"yes, inevitably."
[snip]
What needs to be done to have ISPs and other service providers stop tampering
with DNS ?
Well, NXDOMAIN substitution, on ISP provided DNS servers, is not
"tampering with DNS", anymore than spam/virus filtering/attachment
limits, disk quotas, or message expiration on ISP mail servers is
"tampering with E-mail",
It's ISPs providing their customers with a modified service. Their DNS
resolvers, their terms. They _could_ accomplish similar by
requiring all their customers utilize a custom web browser, but
that would be less convenient.
"Tampering with DNS" would be hijacking port 53 UDP packets a
customer sent directly to an outside authoritative DNS server, and
substituting their own answer.
That would be very harmful, especially if the ISP customer is
attempting to troubleshoot a DNS issue...
Just because someone registered EXAMPLE.COM with one particular
internet registry, doesn't mean they own the lookup result for every
DNS server in the world. All they have paid for is the creation
and maintenance of entries in one particular shared database, and
they only have control for the (large) subset of DNS servers that
utilize that particular database.
People can start new DNS roots, old DNS roots can be superceded,
there can even be multiple conflicting private roots.
In the long run, the only method to discourage might be a form of blacklisting.
If major DNS hosting providers discriminate in the authoritative
replies they give, based on asker:
*If the IP asking for a DNS record is in the IP range of an ISP that
you know substitutes NXDOMAINs with their own reply, then you
discriminate against that DNS query source, and don't give them
NXDOMAINs.
*Why hand them a NXDOMAIN response that they will just substitute?
If major DNS providers barred the ISP's overall range from getting
any NXDOMAIN replies from the authoritative nameservers, then the
ISP would derive no benefit from substituting them, since their
acts caused them to be deemed unfit to receive NXDOMAIN responses at
all.
In addition, their now lack of ability to get NXDOMAIN responses,
could be an inconvenience to them, esp. in the operation of mail
servers, since latency of certain mail server DNS requests will
increase, due to the delay to time out the query (that would be
NXDOMAIN if they were allowed to receive NXDOMAIN).
*That is: always reply SERVFAIL or send no reply to such blacklisted
IP ranges, when the database entry doesn't exist, instead of NXDOMAIN.
However, it doesn't really penalize the NXDOMAIN substitution
practice too much, unless the root and TLD servers also implement
the blacklisting, it only deprives them of benefit.
Those who didn't read RFC2826 are condemned to repeat it.
Of course, it's *your* help desk that gets to answer the phone and explain
to your users why www.giraffes-r-us.com went to a nice page of cute pictures
of giraffes when they were at Starbucks, but when they got home to show
their kids, it was giraffe pr0n.