Thanks for your detailed review. We¹ll reply when we start to work on the 01 update.
Regards Jason On 7/14/09 7:21 PM, "SM" <s...@resistor.net> wrote: > Hello, > > When I first read draft-livingood-dns-redirect-00, my first thought > was about how would it be received if the author was from some > country in the Far East. In September 2008, the IETF published BCP > 140 about preventing use of recursive nameservers in reflector > attacks. The discussion was mainly about recursive nameservers being > evil. There may be good reasons for so-called DNS Redirect > services. It has been argued that the closed model of the "walled > garden" simplifies security. Quoting RFC 3002: > > "carriers typically prefer to have complete (or as much as > possible) control over the entire service, including user access > device, transmission facilities, and service 'content'. This style > of service model appears to have been inherited from the classic > telephony provider model. The term "walled garden" was coined to > describe the resulting captive customer economic and service model. > That is, the user is constrained within the limits of the service > provided by the carrier with limited ability to extend features or > access services outside the provider. The 'walled garden' service > model is in stark contrast to the 'open' service assumed in > the Internet." > > RFC 3833 discusses about the betrayal by trusted (DNS) > server. Quoting some parts of it: > > "The (DNS) server itself may be configured to give back answers that are > not what the user would expect, whether in an honest attempt to help the > user or to promote some other goal such as furthering a business > partnership between the ISP and some third party." > > "Viewed strictly from the DNS protocol standpoint, the only difference > between this sort of betrayal and a packet interception attack is > that in this case the client has voluntarily sent its request to the > attacker." > > In Section 2: > > "ISPs and DNS ASPs have discovered over time that their users would > benefit via 'enhanced' DNS services, which often rely upon > DNS Redirect functionality". > > I suggest using "application service provider (ASPs)" in the > Introduction section and using "so-called DNS Redirect > functionality". It's debatable whether the DNS service offered is enhanced. > > "These enhanced services, which are > offered on an opt-in or opt-out basis (with the exception of where > legal mandates preclude this), can perform a number of value added > services for users, such as attempting to interpret web address > errors and protecting users from reaching domains or fully qualified > domain names (FQDNs, Section 5.1 of [RFC1035]) that would cause a > user to inadvertently access malware." > > Quoting RFC 4367: > > "People often make assumptions about the type of service that is or > should be provided by a host associated with that name, based on > their expectations and understanding of what the name implies." > > So-called DNS redirects are used for good reasons and also for > questionable purposes. If the authors are going to quote reasons, it > would be better to have a balanced view instead of mentioning malware > only. There has been a "safe browsing" incident that highlights the > problem when the user relies on these "enhanced" services. > > I suggest an addition to the sentence: > > These enhanced services, which are offered on an opt-in or opt-out basis > (with the exception of where legal mandates preclude this), can perform > a number of value added services for users, such as attempting to > interpret > web address errors and protecting users from reaching domains or > fully qualified > domain names (FQDNs, Section 5.1 of [RFC1035]) that would cause a user to > inadvertently access malware, or as a way to further a business > partnership between the ISP and some third party. > > In Section 4.1: > > "An Internet Service Provider, which provides Internet services, > including basic network connectivity." > > Could one of the authors of the document clarify off-list whether the > connectivity provided by an ISP using DNS redirect services is > labelled as Full Internet connectivity? > > Section 4.6 defines a "Web Error Landing Server" as the host that a > user is directed to when the DNS Recursive Server receives a NXDOMAIN > response. The Internet user will not be aware of the redirection > unless we assume that the user is a Web user. > > Section 5.1.3 accentuates the belief that any host with an A and AAAA > resource record is a web server. > > Section 5.3 discusses about regulatory organizations mandating or > otherwise compelling ISPs to perform DNS Redirection. I gather that > all IETF participants know about the effectiveness of such measures. :-) > > Section 5.3.3 mentions that ISPs should disclose openly that they > have been compelled to perform legally-mandated DNS Redirect. Why > isn't there a disclosure for any DNS redirect instead of having it > restricted to legally mandated DNS redirects only? > > Section 8.3 is about Web Browser Clients. There seems to be an > assumption that web access is done through Web browsers. Some Web > clients run as automated processes and they may be negatively > affected by those DNS redirects. > > In Section 8.4, it is mentioned that "the owner of example.com may > request that the ISP or DNS ASP not perform DNS Redirect for the > example.com domain". It will be a lot of work to contact all the > ISPs, if that is even possible, to submit such a request. > > Domain registrants will probably want to enable DNS wildcards to get > around DNS redirects. if the practice of DNS redirects by ISPs is > widespread. TLDs without DNS wildcards might resort to it too. The > authors of this document may wish to consider the long term effects. > > Regards, > -sm > > Regards, Jason Jason Livingood Executive Director Internet Systems Engineering National Engineering & Technical Operations Comcast Cable Communications 215-286-7813 jason_living...@cable.comcast.com
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
