--- andrew@accessplus.com.au wrote: From: Andrew Cox <andrew@accessplus.com.au> As a follow up to this, one of the large Australian ISP's has just introduced a DNS redirection "service" for all home customers. "/The BigPond-branded landing page provides BigPond customers with organic search results, sponsored links, display advertisements and intelligent recommendations, all derived from the invalid domain input - much more helpful and friendly than a nasty 404 page error./" http://www.crn.com.au/News/160923,bigpond-redirects-typos-to-unethical-brand... ------------------------------------------------------------------------------
From AUSNOG:
On Thu, Nov 19, 2009 at 2:08 PM, Paul Foote <pfoote@gmail.com> wrote: All that's left for them to complete the "404" strategy is to put transparent proxies in place that redirect on real 404's :P Did nobody learn the lessons from when Verisign did this with .com ? baah. In fairness (and I use that term loosly) to BigPond, this is probably a little different to what Verisign did. I haven't seen the BigPond details, but I have seen what Comcast are doing on my US cable connection, and I presume BigPond is doing something similar. The major differences between the two are : * Only responds for "www" addresses. a lookup for "non-existantdomain.com" will still return an NXDOMAIN, but "www.non-existantdomain.com" returns their search page. This means that (the majority of) things like RBL/anti-spam/etc things which broke under Verisign's redirection no longer break. * It's only home users. Business plans/etc are not redirected. Obviously this is different to Verisign where everyone was hit. * You can turn it off, and the page you end up on even gives you the details on how to turn it off. Also despite claims to the contrary, Comcast are not actually "intercepting" DNS traffic - or at least they aren't for me. They are only doing this for traffic sent directly to their DNS servers, and pointing to another DNS server works as expected, as does running your own resolver. I'm still not saying that it's a good thing for them to be doing, but it's not quite as bad or destructive as Verisign's move was...
Hi, Quoting Scott Weeks <surfer@mauigateway.com>:
From AUSNOG:
On Thu, Nov 19, 2009 at 2:08 PM, Paul Foote <pfoote@gmail.com> wrote:
All that's left for them to complete the "404" strategy is to put transparent proxies in place that redirect on real 404's :P
Telefonica is doing that here, and not onlw for www. hostnames... # nmap nonexist.merit.edu. Starting Nmap 4.68 ( http://nmap.org ) at 2009-11-19 23:44 ARST Interesting ports on smartbrowsebr-mx.terra.com (208.70.188.15): Not shown: 1712 filtered ports PORT STATE SERVICE 80/tcp open http 554/tcp open rtsp 1755/tcp open wms Nmap done: 1 IP address (1 host up) scanned in 28.324 seconds Cheers, Eduardo.- -- Eduardo A. Suarez Facultad de Ciencias Astronomicas y Geofisicas Universidad Nacional de La Plata ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
In message <20091119225005.v3lcpv1k9kwok4oo@fcaglp.fcaglp.unlp.edu.ar>, "Eduardo A. =?iso-8859-1?b?U3XhcmV6?=" writes:
Hi,
Quoting Scott Weeks <surfer@mauigateway.com>:
From AUSNOG:
On Thu, Nov 19, 2009 at 2:08 PM, Paul Foote <pfoote@gmail.com> wrote:
All that's left for them to complete the "404" strategy is to put transparent proxies in place that redirect on real 404's :P
Telefonica is doing that here, and not onlw for www. hostnames...
# nmap nonexist.merit.edu.
It would be intersting to see what would happen if MERIT issued a cease and decist request for using their domain name without permission.
Starting Nmap 4.68 ( http://nmap.org ) at 2009-11-19 23:44 ARST Interesting ports on smartbrowsebr-mx.terra.com (208.70.188.15): Not shown: 1712 filtered ports PORT STATE SERVICE 80/tcp open http 554/tcp open rtsp 1755/tcp open wms
Nmap done: 1 IP address (1 host up) scanned in 28.324 seconds
Cheers, Eduardo.-
-- Eduardo A. Suarez Facultad de Ciencias Astronomicas y Geofisicas Universidad Nacional de La Plata
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Telefonica is doing that here, and not onlw for www. hostnames...
# nmap nonexist.merit.edu.
It would be intersting to see what would happen if MERIT issued a cease and decist request for using their domain name without permission.
That's really bad, because by doing that they could redirect things like hardcoreporn.merit.edu creating huge liability for the rightful admin of any domain name without them knowing. This will not stop until a big pocket corp sends the legal dogs for hunting. Regards Jorge
Paul's article "What DNS Is Not" published in December's Issue of Communications of the ACM. Also ICANN publishes memorandum about Harms and Concerns Posed by NXDOMAIN Substitution: http://www.icann.org/en/topics/new-gtlds/nxdomain-substitution-harms-24nov09... What needs to be done to have ISPs and other service providers stop tampering with DNS ? Cheers Jorge
In message <202705b0911251258s3256434vf7864d212a1f1cf1@mail.gmail.com>, Jorge A modio writes:
Paul's article "What DNS Is Not" published in December's Issue of Communicati ons of the ACM.
Also ICANN publishes memorandum about Harms and Concerns Posed by NXDOMAIN Substitution:
http://www.icann.org/en/topics/new-gtlds/nxdomain-substitution-harms-24nov09... en.pdf
What needs to be done to have ISPs and other service providers stop tampering with DNS ?
Sign your response (DNSSEC). That makes it abundently clear that you don't want your answers to be tampered with. Send cease-and-desist letter for all namespaces you own, to all ISP that you are aware of that are doing this. Followup if they fail to take corrective action. Mark
Cheers Jorge
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 25/11/09 14:58 -0600, Jorge Amodio wrote:
Paul's article "What DNS Is Not" published in December's Issue of Communications of the ACM.
Also ICANN publishes memorandum about Harms and Concerns Posed by NXDOMAIN Substitution:
http://www.icann.org/en/topics/new-gtlds/nxdomain-substitution-harms-24nov09...
What needs to be done to have ISPs and other service providers stop tampering with DNS ?
Some options: Contact your local, state and federal legislators and convince them it's in the public interest for them to draft legislation to outlaw this practice - and hope among all hope that the end result resembles something technically benevolent. Contact ICANN/IANA and plead with them to stop assigning any more resources to said ISP. Publicize what said ISP is doing and let its customers decide if it's a significantly deplorable enough practice for them to find another ISP. -- Dan White
On 25/11/09 14:17 -0800, David Conrad wrote:
Hi,
On Nov 25, 2009, at 1:22 PM, Dan White wrote:
Contact ICANN/IANA and plead with them to stop assigning any more resources to said ISP.
ICANN/IANA doesn't assign resources to ISPs.
Indirectly they're responsible for assignment of IP address, enterprise numbers, domain names etc. Of course you're not going to get very far with that approach. My point was there isn't really an authority to enforce rules on ISPs when it comes to how they manage their DNS servers. Government and IANA won't be interested in fielding such complaints. Shining a flash light on the problem publicly is going to be the best best. -- Dan White
Hi, On Nov 25, 2009, at 4:41 PM, Dan White wrote:
On 25/11/09 14:17 -0800, David Conrad wrote:
On Nov 25, 2009, at 1:22 PM, Dan White wrote:
Contact ICANN/IANA and plead with them to stop assigning any more resources to said ISP.
ICANN/IANA doesn't assign resources to ISPs.
Indirectly they're responsible for assignment of IP address,
In the sense that they allocate /8s (and, in IPv6, /12s) to the RIRs, sure. I'm just guessing but I don't think the RIRs would be very happy if ICANN/IANA were to refuse to allocate a /8 (or a /12) to an RIR because one of the RIRs' customers was hijacking NXDOMAINs.
enterprise numbers,
Actually, ICANN/IANA assigns these directly (see http://pen.iana.org), but I suspect the folks in the IETF would get a bit distressed if ICANN/IANA started imposing restrictions on who could get PENs.
domain names
ICANN/IANA is directly responsible for (and has contractual relationships with folks who operate) gTLDs and has, to the distress of some folks on this list, imposed restrictions on wildcards/synthesis/etc. ICANN/IANA discourages wildcards/synthesis/etc for ccTLDs, but the operation of a ccTLD is considered a national sovereignty issue and thus, ICANN/IANA has no way to do anything other than point out the problems wildcards/synthesis/etc. can lead to. As I write this, there are 11 ccTLDs that do wildcards/synthesis/etc. and there will undoubtedly be more in the future. ICANN/IANA has no interaction with, much less control, over ISPs.
My point was there isn't really an authority to enforce rules on ISPs when it comes to how they manage their DNS servers.
Yep.
Government and IANA won't be interested in fielding such complaints.
Government might -- politicians like to be seen solving problems, even if they haven't the slightest idea what the problem is, whether it actually is a problem, or how to go about fixing it. With the exception of the gTLDs, ICANN/IANA simply can't -- it has no mechanism to do anything other than wag its finger.
Shining a flash light on the problem publicly is going to be the best best.
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. Regards, -drc
On 26/11/09 07:37 -0800, David Conrad wrote:
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. Of course I don't know what, if any, ICANN pressure has to do with that, but the flash light practice was apparently successful. -- Dan White
On Thu, 26 Nov 2009 12:25:49 CST, Dan White said:
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.
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?
On Nov 27, 2009, at 2:25 AM, Dan White wrote:
Anytime this issue has been brought up in a public setting (here, slashdot, etc.) has resulted in terrible press and even corrective action.
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? ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Dan White wrote:
On 26/11/09 07:37 -0800, David Conrad wrote:
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. Of course I don't know what, if any, ICANN pressure has to do with that, but the flash light practice was apparently successful.
I do know what, if any, ICANN pressure had to do with that. The pressure on ICANN was real, and the pressure ICANN put on VGRS was sufficient. Eric
Dan, On Nov 26, 2009, at 10:25 AM, Dan White wrote:
On 26/11/09 07:37 -0800, David Conrad wrote:
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 http://tools.ietf.org/html/draft-livingood-dns-redirect-00). Pretty large flash light... Regards, -drc
On Wed, Nov 25, 2009 at 02:17:37PM -0800, David Conrad wrote:
Hi,
On Nov 25, 2009, at 1:22 PM, Dan White wrote:
Contact ICANN/IANA and plead with them to stop assigning any more resources to said ISP.
ICANN/IANA doesn't assign resources to ISPs.
Regards, -drc
any more.... :) --bill
What needs to be done to have ISPs and other service providers stop tampering with DNS ?
Some options:
Contact your local, state and federal legislators and convince them it's in the public interest for them to draft legislation to outlaw this practice - and hope among all hope that the end result resembles something technically benevolent.
Do we really want big brother sniffing around ? What about net neutrality ?
Contact ICANN/IANA and plead with them to stop assigning any more resources to said ISP.
ICANN has no contractual relationship with the service providers abusing the DNS, but a far reaching idea could claim ICANN responsibility and commitment to preserve and enhance the operational stability, reliability, security, and global interoperability of the Internet, stated in one of its core values on its bylaws.
Publicize what said ISP is doing and let its customers decide if it's a significantly deplorable enough practice for them to find another ISP.
Well Time Warner/Road Runner does it at least here in San Antonio, at least the don't filter DNS traffic if you choose to use other name servers and don't have a nasty proxy like the guys from Telefonica in Argentina. Anyway some of this nasty behavior will go away when as Mark said DNSSEC is fully deployed (someday). Regards Jorge
In message <202705b0911251526n75194c46m30cdfcb4809b6de5@mail.gmail.com>, Jorge Amodio writes:
What needs to be done to have ISPs and other service providers stop tampering with DNS ?
Some options:
Contact your local, state and federal legislators and convince them it's in the public interest for them to draft legislation to outlaw this practice - and hope among all hope that the end result resembles something technically benevolent.
Do we really want big brother sniffing around ? What about net neutrality ?
It's fraud, theft or both. The ISP's doing this don't own these names and they are pretending to be someone they are not. Just because lots of them are doing it doesn't make it right. You should be able to go to your local police and report this and have action taken.
Contact ICANN/IANA and plead with them to stop assigning any more resources to said ISP.
ICANN has no contractual relationship with the service providers abusing the DNS, but a far reaching idea could claim ICANN responsibility and commitment to preserve and enhance the operational stability, reliability, security, and global interoperability of the Internet, stated in one of its core values on its bylaws.
Publicize what said ISP is doing and let its customers decide if it's a significantly deplorable enough practice for them to find another ISP.
Well Time Warner/Road Runner does it at least here in San Antonio, at least the don't filter DNS traffic if you choose to use other name servers and don't have a nasty proxy like the guys from Telefonica in Argentina.
Anyway some of this nasty behavior will go away when as Mark said DNSSEC is fully deployed (someday).
Regards Jorge
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On November 25, 2009, Jorge Amodio wrote:
What needs to be done to have ISPs and other service providers stop tampering with DNS ?
Cheers Jorge
And what is needed to have a consistant 'whois' reporting format :) Keeping adding to the list? -- -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors - President/CEO - LinuxMagic Products, Services, Support and Development Visit us at http://www.linuxmagic.com ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-589-0037 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company.
Jorge Amodio <jmamodio@gmail.com> writes:
What needs to be done to have ISPs and other service providers stop tampering with DNS ?
we have to fix DNS so that provider-in-the-middle attacks no longer work. (this is why in spite of its technical excellence i am not a DNSCURVE fan, and also why in spite of its technical suckitude i'm working on DNSSEC.) <http://queue.acm.org/detail.cfm?id=1647302> lays out this case. -- Paul Vixie KI6YSY
On Nov 25, 2009, at 8:16 PM, Paul Vixie wrote:
we have to fix DNS so that provider-in-the-middle attacks no longer work. (this is why in spite of its technical excellence i am not a DNSCURVE fan, and also why in spite of its technical suckitude i'm working on DNSSEC.)
As 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. Regards, -drc
From: David Conrad <drc@virtualized.org> Date: Thu, 26 Nov 2009 07:42:15 -0800
As 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!!"). 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).
On Nov 26, 2009, at 8:37 AM, Paul Vixie wrote:
From: David Conrad <drc@virtualized.org> Date: Thu, 26 Nov 2009 07:42:15 -0800
As 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
From: David Conrad <drc@virtualized.org> Date: Thu, 26 Nov 2009 13:25:39 -0800
At 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."
* Jorge Amodio:
What needs to be done to have ISPs and other service providers stop tampering with DNS ?
First, stop calling it "NXDOMAIN rewriting". These guys are rewriting everything they want, so that they can respond to your search queries, or serve different ads to you. Then try to opt out of rewriting for your own domains, asking the offenders to stop doing it in your namespace, and if that doesn't help, use the court system. Fight your own fights, and don't expect others to do it for you. (Oh, in case you wonder---I can't, because in Germany, registering a domain name does not grant you rights to that name, even if you've been using it for quite a while.)
On Wed, Nov 25, 2009 at 2:58 PM, Jorge Amodio <jmamodio@gmail.com> wrote: [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. -- As for ccTLDs performing wildcarding, One could consider patches to recursive resolvers to detect the IPs that are wildcarding, and substitute responses detected as the wildcard host IP addresses, with NXDOMAIN. For example, randomly generate 2 test lookups for domains that are unlikely to exist, eg afut429.ahfeai4728.xyz.xx . If both randomized lookups return A record responses for the same IP addresses, then you detected the wildcard method used by that ccTLD. Substitute NXDOMAIN in for any responses for the ccTLD that respond with the same list of A records. In other words: retaliating against NXDOMAIN substitution, by substituting response with those IPs back to NXDOMAIN. -- -J
On Thu, 26 Nov 2009 21:57:46 CST, James Hess said:
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.
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.
Quoting Mark Andrews <marka@isc.org>:
It would be intersting to see what would happen if MERIT issued a cease and decist request for using their domain name without permission.
well they can sue them in the US... # traceroute 208.70.188.15 traceroute to 208.70.188.15 (208.70.188.15), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 so-1-1-0-0-grtbueba2.red.telefonica-wholesale.net (213.140.51.73) 3.913 ms 3.911 ms 3.905 ms 14 Xe7-3-0-0-grtlurem4.red.telefonica-wholesale.net (213.140.49.18) 58.677 ms Xe8-0-0-0-grtlurem4.red.telefonica-wholesale.net (213.140.49.6) 59.780 ms Xe11-0-0-0-grtlurem4.red.telefonica-wholesale.net (213.140.36.150) 59.784 ms 15 Xe8-3-0-0-grtmiabr5.red.telefonica-wholesale.net.126.142.94.in-addr.arpa (94.142.126.113) 129.878 ms 129.878 ms Xe5-1-3-0-grtmiabr4.red.telefonica-wholesale.net (84.16.15.62) 130.615 ms 16 P9-0-0-0-gramiatc2.red.telefonica-wholesale.net (213.140.37.201) 131.945 ms 131.942 ms 131.936 ms 17 84.16.6.150 (84.16.6.150) 129.855 ms 129.850 ms 129.838 ms 18 tdcsdr11-vl-3.mia1.ustdata.net (66.119.65.19) 130.774 ms 130.761 ms 130.754 ms 19 terra-g-3-1-dsw01-mia.tc.terra.com (66.119.71.2) 130.724 ms 130.724 ms 130.719 ms 20 bsw01a-mia.tc.terra.com (208.70.191.245) 134.385 ms 135.200 ms 135.189 ms 21 bsw01a-mia.tc.terra.com (208.70.191.245) 127.450 ms 127.455 ms 127.451 ms Eduardo.- -- Eduardo A. Suarez Facultad de Ciencias Astronomicas y Geofisicas Universidad Nacional de La Plata ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Scott, If you're going to blatantly copy what others have written on another mailing list, please at least have the common decency to attribute it to the original author, and/or get the original authors permission first. Scott. On Thu, Nov 19, 2009 at 5:31 PM, Scott Weeks <surfer@mauigateway.com> wrote:
From AUSNOG:
On Thu, Nov 19, 2009 at 2:08 PM, Paul Foote <pfoote@gmail.com> wrote:
All that's left for them to complete the "404" strategy is to put transparent proxies in place that redirect on real 404's :P
Did nobody learn the lessons from when Verisign did this with .com ? baah.
In fairness (and I use that term loosly) to BigPond, this is probably a little different to what Verisign did.
I haven't seen the BigPond details, but I have seen what Comcast are doing on my US cable connection, and I presume BigPond is doing something similar.
The major differences between the two are : * Only responds for "www" addresses. a lookup for "non-existantdomain.com" will still return an NXDOMAIN, but "www.non-existantdomain.com" returns their search page. This means that (the majority of) things like RBL/anti-spam/etc things which broke under Verisign's redirection no longer break. * It's only home users. Business plans/etc are not redirected. Obviously this is different to Verisign where everyone was hit. * You can turn it off, and the page you end up on even gives you the details on how to turn it off.
Also despite claims to the contrary, Comcast are not actually "intercepting" DNS traffic - or at least they aren't for me. They are only doing this for traffic sent directly to their DNS servers, and pointing to another DNS server works as expected, as does running your own resolver.
I'm still not saying that it's a good thing for them to be doing, but it's not quite as bad or destructive as Verisign's move was...
participants (15)
-
bmanning＠vacation.karoshi.com -
Dan White -
David Conrad -
Dobbins, Roland -
Eduardo A. Suárez -
Eric Brunner-Williams -
Florian Weimer -
James Hess -
Jorge Amodio -
Mark Andrews -
Michael Peddemors -
Paul Vixie -
Scott Howard -
Scott Weeks -
Valdis.Kletnieks＠vt.edu