Subject: [DNSOP] Comments on draft-livingood-dns-redirect-00

From: SM <[email-masked]>
Date: Tue, 14 Jul 2009 16:21:25 -0700

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

---

From: Mark Andrews <[email-masked]>
Date: Wed, 15 Jul 2009 12:12:56 +1000

> ISPs, if that is even possible, to submit such a request.

If the zone is signed it can be reasonably assumed that the owner
doesn't want the answers modified as they have taken steps to ensure
that such modifications are detected.

Mark
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 14 Jul 2009 20:18:06 -0400

Thanks for your detailed review.  We¹ll reply when we start to work on the
01 update.

Regards
Jason

> authors of this document may wish to consider the long term effects.

Regards,
Jason
 
Jason Livingood
Executive Director
Internet Systems Engineering
National Engineering & Technical Operations
Comcast Cable Communications
215-286-7813
[email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 15 Jul 2009 08:18:38 +0200

On Wed, Jul 15, 2009 at 12:12:56PM +1000,
 Mark Andrews <[email-masked]> wrote 
 a message of 21 lines which said:

> doesn't want the answers modified

OK, if and only if the provider does *not* assume the opposite and
does not regard an unsigned zone as "free for anyone to modify".

---

From: "Antoin Verschuren" <[email-masked]>
Date: Wed, 15 Jul 2009 09:20:22 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Mark Andrews
> Subject: Re: [DNSOP] Comments on draft-livingood-dns-redirect-00
> 
> 

This actually bugs me as well.
I can imagine that with wide deployment of DNSSEC, applications like browsers, email, ftp, ssh, ntp, etc. etc.  clients, apps and ticker tools, will post warnings to users when validation for a domain name has failed. Validation will be done on the client. Same way as for SSL certification.
When it becomes practice to redirect DNS traffic for signed NXdomain responses, it will also become practice for ordinary users to click away such warnings, and they become used to clicking away the errors, perhaps even demanding a configurable option in the client to discard security warnings.

This does not help in educating the general public, who we are trying to protect from malicious content and forgeries.

Antoin Verschuren

Technical Policy Advisor SIDN
Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:[email-masked]  xmpp:[email-masked]  http://www.sidn.nl/

---

From: Tony Finch <[email-masked]>
Date: Wed, 15 Jul 2009 14:03:05 +0100

On Tue, 14 Jul 2009, SM wrote:
> connectivity provided by an ISP using DNS redirect services is labelled as
> Full Internet connectivity?

According to the definitions in RFC 4084, the only one that applies to an
ISP with lying resolvers as described in this draft is "web connectivity".
This could be extended to other protocols, but that depends on explicit
support from the landing server. In some respects the service model
described in the draft is less than web connectivity, because it doesn't
support https.

> around DNS redirects, if the practice of DNS redirects by ISPs is

Yuck.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 22 Jul 2009 18:03:37 -0700

>> authors of this document may wish to consider the long term effects.

Many techniques could allow actors to bypass name redirects erected to 
restrain exchanges with compromised systems or content.  It should be 
assumed no interchange is reliably constrained by DNS redirection.  For 
example, actors might leverage search domains and have these act as a 
substitute root zone.  This technique has caused some countries to take 
the next step of blocking labels, and not just FQDNs. :^(

When an ISP Blocks at the point of access (while still allowing egress 
for VoIP and other critical modes of communication) this would offer 
more comprehensive control, than obtained by name redirection.  When 
done at the access point, blocking might leverage IP address exceptions 
rather than the spoofing of domain names.  Much of this might also be 
done using BGP.

More comprehensive results could be achieved by modifying DSL/Cable 
modems, routers, or SOHO equipment rather than having ISPs block and/or 
modify DNS answers.  Name redirection, when defeated, will make problems 
more difficult.

-Doug