| reply to ctg1701a
Re: [DNS] Comcast Launches Trial of Domain Helper Service I really do not like this and hope comcast rolls it back.
Also instead of 'opt-out' they should make it 'opt-in'.
And for 'opt-in' user they should provide some sort of compensation or reduction in bill (they are making money off this 'helper'). |
|
Reviews:
 ·Comcast
| reply to usa2k
Re: [DNS] Comcast Launches Trial of Domain Helper Service I agree with you it is sicking to see corp desire to only care about making as much $$$ as possible. However I am not so sure it will fail as others have how ever. Most users are ignorant when it comes to such a thing, even members on the very form.
--
Lead, Follow I do not care just get out of my way. |
|
| Maybe they can use the money from this to fund network expansion, and remove the 250gb cap? |
|
|
|
Reviews:
·Comcast
| said by nate1234:Maybe they can use the money from this to fund network expansion, and remove the 250gb cap? Not likely.
--
Lead, Follow I do not care just get out of my way. |
|
| I know, I was just joking... It would be nice though |
|
 koitsuPremium,MVM
join:2002-07-16
Mountain View, CA
kudos:14
1 edit | reply to ctg1701a
Re: [DNS] Comcast Launches Trial of Domain Helper Service I just finished reading the draft, and I'm left shaking my head. Your efforts are positive, but there is so much that's left open-ended that (in regards to the revision I just read, dated 2009/07/06) I hope the IETF rejects this.
Here are my comments:
Section 5.1.3 notes that the methodology described in Section 5.1.2 (returning an IP address of the Web Error Landing Server on NXDOMAIN) is error-prone, stating it can impact services unexpectedly such as "IMs, VPNs, FTP, Email filtering", and then goes to state:
"... special exclusions may need to be made in order to prevent unintentional side effects."
The only stipulation it notes for handling such exclusions is to ensure that "only A and AAAA record lookups are redirected". It provides absolutely no detail as to how the specification plans to prevent said side effects -- and these side effects are exactly what tick people off.
The same caveat is noted in Section 5.2.3 (specific to malware or malicious content Web sites), extending the result set from A/AAAA to A, AAAA, MX, SRV, and NAPTR records.
The same caveat is noted in Section 5.3.3 (specific to government or law-enforcement-centric DNS redirection services), noting that opt-out conditions may not be provided given outside-of-scope circumstances.
The same caveat is noted in Section 5.4.2 (specific to questionable Web content, Section 5.4.1 citing "illicit drugs, alcohol, hate speech, and weapons" as possible (not mandatory!) topics). In this situation the ISP is to analyse HTTP content and return a redirected DNS result based upon the content of said Web site the individual visits. How this is done is not discussed; it would require the ISP to have web caching servers, and require the user Web browser, after performing an A record lookup, sit and block (in English: sit and wait) for the ISP's web caching servers to pull down content from the site (specifically the GET URI combined with the HTTP Host: header) the user attempted to visit, analyse it, and if said content contains matching criteria, result in DNS redirection.
Things that make me happy to see covered
------------------------------------------
Section 7, mainly, made me smile. I'm glad to see the problems with the previously-implemented methods come to light.
Section 10 provides sufficient detail regarding how/why methods described in said draft will fail when DNSSEC stubs are in use. Readers (of my comments) should remember that there is a pretty substantial push towards DNSSEC, even on the TLD-level, so that brings into question how effective DNS redirection in general will be if/when we get to the point of widespread DNSSEC use.
Problems as I see them
-------------------------
1) In Sections 5.1.3, 5.2,3, and 5.3.3, there is no technical explanation provided as to how "side effects" can be alleviated. Sections 8.2, 8.5, and 8.6 are insufficient. Sections 9.3, 9.4, and 9.5 are equally insufficient.
2) In Section 5.4.2, there is no technical explanation provided as to how said methodology would be implemented, or how an ISP plans on implementing this technology. Essentially it would require an ISP to provide a way for DNS servers and Web caching servers to integrate, not to mention the DNS server itself would have to be custom-written or modified. There are other ways to do this at the packet level, but again, no technical explanation is provided so speculation runs rampant. Basically, Section 8.7 does not provide sufficient detail, nor does Section 9.6.
3) Section 5.3.3 statements conflict with Section 6, specifically:
Section 5.3.3: "Mandated DNS Redirect may not provide an opt-out capability, and in some jurisdictions they must not provide an opt-out capability."
Section 6: "ISPs and DNS ASPs must provide their users with a method to opt into (opt-in) or out (opt-out) of some or all DNS Redirect services." ... "Whether such services are offered on an opt-in or opt-out basis depends on a range of factors which are outside of the scope of this document."
4) Section 6.3 states:
"Such changes should also occur within a reasonable period of time."
But no definition of what "reasonable" is is provided. It is safe to assume users will want opt-in/out changes applied within 24 hours at maximum, but "the sooner the better".
Comments made in Section 6.4 implies (but does not state explicitly) that the method that should be used is changing the customers' DNS servers based on DHCP assignment (e.g. from DNS servers which utilise said draft methods to ones which do not). This is unacceptable, given that DHCP lease times vary from ISP to ISP, and there being absolutely no guarantee that said DHCP servers are available at the time of lease expiry.
So again, the duration depends greatly upon how said technology is implemented -- there is no technical reason why changing one's opt-in/out preferences cannot happen within seconds. So this is further evidence justifying technical implementation descriptions.
(Sidenote: It reminds me of ISPs "back in the day" who used to tell brand new customers "you'll be able to use your new account approximately 4 hours from now". What? 4 hours? Why 4 hours? Why not immediately? Why not 5 minutes? Why not 48 hours? Probably because the system creates accounts via a cronjob...  )
5) Section 6.4 provides too much ambiguity and leaves too much in the hands of the reader/implementer. (I am, however, happy to see that mention of cookies is brought up -- and shunned as a methodology, both in Sections 6.4 and 7.3)
By "ambiguity" I'm also referring to the use of the word "recommended" rather than "required". One of the problems with existing RFCs is that some are open-ended, and those "loopholes" have been abused in the past.
6) Section 7.5 continually uses the word "should" instead of "must" or "will". Again, this leaves too much in the hands of the implementer and can be abused.
7) Section 11 should advocate use of HTTPS (SSL), and should advocate falling back on manual review (by a human being) before changes can be made (if automated systems are working incorrectly). HTTP authentication (RFC2617) should probably also be avoided.
Cheers.
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer. |
|
 NOVA_GuyObamaCare Kills AmericansPremium
join:2002-03-05 | reply to ctg1701a
Full Disclosure, Please So just how much money does Comcast expect to make from this each year? And will users see a caption on the page that clearly describes the ads they are seeing as advertising? |
|
 jlivingoodPremium,VIP
join:2007-10-28
Philadelphia, PA
kudos:1 | reply to koitsu
Re: [DNS] Comcast Launches Trial of Domain Helper Service said by koitsu:I just finished reading the draft, and I'm left shaking my head. Your efforts are positive, but there is so much that's left open-ended that (in regards to the revision I just read, dated 2009/07/06) I hope the IANA rejects this. Here are my comments: Thanks for your comments. Understand that the IETF process is a very long one - if this was ever to become an RFC, it'd take 1, 2, or even 3 years of work. A recent draft I co-authored that will be an RFC soon went through 10 revisions and another one was on the order of 16 or 17 I think. So suffice it to say this is a first draft.
That being the case, there will be lots of feedback from the community to act on and factor into the draft. I'm on the agenda in the DNSOP working group to present at IETF 75 (I will probably get ~10 mins), so I'll get lots of feedback there and on the list.
I will take a look at your feedback next week and get back to you next week via PM. THANK YOU for performing such a detailed review of the document!
Jason
--
JL
Comcast |
|
 funchordsHelloPremium,MVM
join:2001-03-11
Yarmouth Port, MA
kudos:5 | reply to koitsu
said by koitsu:But no definition of what "reasonable" is is provided. It is safe to assume users will want opt-in/out changes applied within 24 hours at maximum, but "the sooner the better". Comments made in Section 6.4 implies (but does not state explicitly) that the method that should be used is changing the customers' DNS servers based on DHCP assignment (e.g. from DNS servers which utilise said draft methods to ones which do not). This is unacceptable, given that DHCP lease times vary from ISP to ISP, and there being absolutely no guarantee that said DHCP servers are available at the time of lease expiry. So again, the duration depends greatly upon how said technology is implemented -- there is no technical reason why changing one's opt-in/out preferences cannot happen within seconds. Sure there is, particularly when you're (the ISP) not in control of the physical layer.
A DHCP client isn't going to ask for or accept any input from a DHCP server until at least half of the lease is expired. One way to force it to happen is to drop the PHY and cause auto-sensing to reset the connection (and perhaps this is what Comcast has in mind for its solution) but even that won't work for wireless computers or computers behind a router.
All of the above assumes that the IP address for the DNS server that redirects is different from the one that works normally.
--
Robb Topolski -= funchords.com =- District of Columbia -- KJ7RL
Evil does seek to maintain power by suppressing the truth, or by misleading the innocent. --Spock and McCoy stardate 5029.5 |
|
AVonGaussPremium
join:2007-11-01
Boynton Beach, FL | reply to nate1234
Re: [DNS] Comcast Launches Trial of Domain Helper Service I am not really a fan of DNS redirection for many of the reasons already stated here and in the news article comments, but I do want to commend the process in which this system is being rolled out. Its good to see the trend of Comcast being more open and forthcoming about changes continuing.
The burden definitely is not all Comcast's, but what I would be much more interested in seeing from any IETF efforts is a plan to correct what is broken by DNS redirection. Marketing spins aside, DNS redirection by ISPs is really about additional ad revenue and name branding which means it is primarily (if not solely) targeting the user and more specifically browser related services such as http, https, ftp, ftps - gopher?
If DNS redirection is going to be implemented by ISPs as an opt-out system, there really should be efforts to address the issues caused at the browser level (caching, history, etc) and mechanisms established that allow other services such as SSH, POP, IMAP, SMTP and VPNs to continue to receive the NXDOMAIN responses as originally intended and currently specified in the standards. This is also something needed by networks such as WiFi hot spots or other semi-public networks that require a login and use DNS redirection to provide the user a login page. In this case, its not so much of the NXDOMAIN response as it is selectively redirecting browser requests vs all requests from all types of services.
Not trying to be preachy, but something I think all ISPs should remember; your customers are paying you for a service. They are not signing up to be an audience for ads that you are selling or reselling and while they will tolerate it to a point, there is definitely a threshold to that tolerance at which the customer will start to devalue your service no matter how well that service performs.
|
|
jlivingoodPremium,VIP
join:2007-10-28
Philadelphia, PA
kudos:1 | reply to funchords
Re: [DNS] Comcast Launches Trial of Domain Helper Service re DHCP, once the opt-out is processed, you can wait for lease renewal or, as Robb said, reset the physical connection (restart your modem).
--
JL
Comcast |
|
AVonGaussPremium
join:2007-11-01
Boynton Beach, FL | reply to funchords
Not that I am sure I would really recommend this, but they are definitely in control - there is always DocsDevResetNow... |
|
 ctg1701aVIP
join:2008-08-07
Philadelphia, PA | Agreed, resets are impacting and we would like to leave it to the users or their lease time to take effect so we don't impact users. |
|
koitsuPremium,MVM
join:2002-07-16
Mountain View, CA
kudos:14
1 edit | reply to funchords
said by funchords:Sure there is, particularly when you're (the ISP) not in control of the physical layer. A DHCP client isn't going to ask for or accept any input from a DHCP server until at least half of the lease is expired. One way to force it to happen is to drop the PHY and cause auto-sensing to reset the connection (and perhaps this is what Comcast has in mind for its solution) but even that won't work for wireless computers or computers behind a router. All of the above assumes that the IP address for the DNS server that redirects is different from the one that works normally. But all of this makes the assumption that the implementation is applied (to the user) via DHCP.
My point was that the draft "sort of" leaves it open to the implementer to decide how its done (which I suppose is fine), but then briefly mentions DHCP as the form of methodology used. I believe Section 7.1 implies use of things like in-wire packet manipulation being "bad", but it's not explicitly outlined. That's why I say "sort of".
I suppose that means Comcast plans on implementing this via DHCP (read: hand out DNS servers via DHCP to those who have not opted-out or those who have explicitly opted-in), but if you read the very end of the draft, you'll see an individual from Sandvine was involved in providing feedback (which I find both interesting and creepy. )
The one thing I should note (not to you, but to all customers/users) is that the draft does a decent job of explaining that content that is not what the user expects should be explicitly outlined as being such. For example, visiting www.yahooo.com instead of www.yahoo.com, taking you to a page that gives you "Did you mean...", which explicitly states that it is content provided by the ISP themselves and isn't "what's out on the Internet". Without explicitly defining that, essentially the ISP becomes equivalent to a domain squatter or registrar who puts up HTTP content on non-registered or expired domains (hopefully people will know what I mean by this).
The draft has good intentions I think, but is still too vague for approval. The more rigid an RFC is (IMHO), the better it is. There's nothing I hate more than reading an RFC to get details of something and find use of words like "could" or "might" or "may". Extension RFCs can be filed in the future.
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer. |
|
andyrossPremium,MVM
join:2003-05-04
Schaumburg, IL | reply to ctg1701a
I noticed my DNS changed from 68.87.72.130 and 68.87.77.130 to x.x.y.134. There no longer is a 3rd entry, which was 68.87.66.196. This is the DHCP settings grabbed by my router.
Is this DNS change the reason why I had no internet access Tuesday morning and had to reboot everything?
I have one computer here that has the DNS and local IP hard-coded, but other computers use DHCP from the router. Just how is everything affected?
I'm in agreement with others that this is mainly a revenue generating mechanism that may cause hard-to-figure-out issues with software or devices getting confused.
It also seems as if opt-out is based on the IP address?? What a crock. Who will remember to re-opt-out WHEN their IP changes, assuming they even know it changed? It should be tied to the account or modem's MAC address. |
|
funchordsHelloPremium,MVM
join:2001-03-11
Yarmouth Port, MA
kudos:5 | reply to AVonGauss
said by AVonGauss:Not that I am sure I would really recommend this, but they are definitely in control - there is always DocsDevResetNow... Which should reset the WAN end of a router but whether it does anything on the LAN side will be case-by-case dependent. Remember, they'll have leases too. On the good side is that, like many things, a reboot will usually fix it and this is a one-shot set-it-and-forget-it deal.
--
Robb Topolski -= funchords.com =- District of Columbia -- KJ7RL
Evil does seek to maintain power by suppressing the truth, or by misleading the innocent. --Spock and McCoy stardate 5029.5 |
|
ctg1701aVIP
join:2008-08-07
Philadelphia, PA | reply to andyross
said by andyross:I noticed my DNS changed from 68.87.72.130 and 68.87.77.130 to x.x.y.134. There no longer is a 3rd entry, which was 68.87.66.196. This is the DHCP settings grabbed by my router. Is this DNS change the reason why I had no internet access Tuesday morning and had to reboot everything? It also seems as if opt-out is based on the IP address?? What a crock. Who will remember to re-opt-out WHEN their IP changes, assuming they even know it changed? It should be tied to the account or modem's MAC address. If you are using DHCP to acquire your DNS servers we moved you over to the new IP addresses about a month ago and we removed the third DNS server at that time so I doubt this had anything to do with Tuesday morning issues.
The opt-out is tied to your provisioning at your modem, not your IP address. If your IP changes, you will still remain opted out. |
|
AVonGaussPremium
join:2007-11-01
Boynton Beach, FL | reply to funchords
Fair enough, and I agree most routers aren't very aggressive about propagating WAN changes to the LAN. |
|
andyrossPremium,MVM
join:2003-05-04
Schaumburg, IL | reply to ctg1701a
said by ctg1701a:said by andyross:I noticed my DNS changed from 68.87.72.130 and 68.87.77.130 to x.x.y.134. There no longer is a 3rd entry, which was 68.87.66.196. This is the DHCP settings grabbed by my router. Is this DNS change the reason why I had no internet access Tuesday morning and had to reboot everything? It also seems as if opt-out is based on the IP address?? What a crock. Who will remember to re-opt-out WHEN their IP changes, assuming they even know it changed? It should be tied to the account or modem's MAC address. If you are using DHCP to acquire your DNS servers we moved you over to the new IP addresses about a month ago and we removed the third DNS server at that time so I doubt this had anything to do with Tuesday morning issues. The opt-out is tied to your provisioning at your modem, not your IP address. If your IP changes, you will still remain opted out. Should I update the DNS on the one computer to the .134's? Or are those the redirect ones and I should keep the .130's? |
|
ctg1701aVIP
join:2008-08-07
Philadelphia, PA | reply to AVonGauss
said by AVonGauss:Fair enough, and I agree most routers aren't very aggressive about propagating WAN changes to the LAN. You are absolutely correct with this statement. It is also the case in the opposite direction and why we see so many issues with routers and folks having DNS issues when they are using them as a DNS proxy or stub resolver. When in doubt, reset the gateway and modem. |
|
