Subject: [DNSOP] Review of draft-livingood-dns-redirect-00

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 09 Jul 2009 11:23:48 -0400

I submitted this draft, which you can find at
http://tools.ietf.org/html/draft-livingood-dns-redirect-00, before the 00
cutoff on Monday, and it will be discussed in the DNSOP WG meeting at IETF
75 (it is listed on the agenda).

If anyone is interested and has time before IETF 75, I¹m happy to take
feedback before then obviously.  Please note that there is a list of open
items at the end, which we plan to address in subsequent versions.

Regards,
Jason

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Jul 2009 15:05:27 +0200

On Thu, Jul 09, 2009 at 11:23:48AM -0400,
 Livingood, Jason <[email-masked]> wrote 
 a message of 69 lines which said:

> feedback before then obviously. 

Disclaimer: I find the whole idea a very bad one, a violation of
network neutrality and certainly a service I would never accept from
my ISP.

1) There is a lot of vocabulary which is more propaganda than
technical description such as pretending in section 2 that it is an
"enhanced" DNS service, which is very questionable. 

2) "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."
You need to add "without delay or payment".

3) "Only A and AAAA resource records should be redirected, all other
resource record types must be answered as if there was no
redirection." Does it mean that a request for MX or SRV, with the same
owner name, will return NXDOMAIN? If so, it seems to me a strong
violation of the DNS protocol.

4) About DNSSEC, "This case doesn't have widespread deployment now and
could be mitigated by using trust anchor, configured by the applicable
ISP or DNS ASP, that could be used to sign the redirected answers."
That's the most newspeak sentence of the I-D. I suggest to call this
feature Authenticated Lie.
 
5) I find no reference to the two most relevant RFC here, RFC 4084 and
RFC 4924 (section 2.5.2). For instance, ISP in France which have these
"services" never advertise the fact to prospective customers, thus
violating RFC 4084.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 11 Jul 2009 14:38:31 +0200

Unless I'm wrong, the I-D about lying resolvers do not discuss the
issue of zone cuts. 

If I type www.doesnotexistatall.com (the SLD does not exist and so I
should get a NXDOMAIN), I get the IP address of the ad Web server. If
I type wwww.afnic.fr, I will get this IP address as well, since the
QNAME does not exist (four 'w' instead of three) despite the fact that
the SLD does exist.

This is a very serious problem: when rewriting the NXDOMAIN of
www.doesnotexistatall.com, you only harm the user. When rewriting the
NXDOMAIN of wwww.afnic.fr, you harm the holder of afnic.fr as well,
since the ad Web site will appear to be under this SLD.

Searching for a zone cut and not rewriting answers when there is a
non-delegation domain in the path may be a solution, although I'm not
sure it is possible to do it properly. (And I won't try since
modifying DNS answers is a bad idea, anyway).

---

From: Evan Hunt <[email-masked]>
Date: Sat, 11 Jul 2009 16:40:50 +0000

> since the ad Web site will appear to be under this SLD.

Not only is this a very good point, but it doesn't just apply at the
SLD level.  ICANN will be selling vanity TLD's someday soon, and it'll
be necessary to think about www.doesnotexistatall.ebay and .amazon and
.google and so forth.  Rewriting NXDOMAIN under *any* zone cut, not
just the SLD zone cut, could harm a domain owner.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 11 Jul 2009 16:59:38 -0700

It seems inappropriate for the IETF to bless lying resolvers as a Best Current Practice. I doubt we as a community could have consensus on when lying is good, when it is neutral, and when it is bad. Without such agreement, we can't agree on how to run such servers. Having said that, the publication of a document such as this (with more input from the community) as a Informational RFC could indeed help the Internet.

--Paul Hoffman, Director
--VPN Consortium

---

From: Florian Weimer <[email-masked]>
Date: Sun, 12 Jul 2009 09:34:40 +0200

> QNAME does not exist (four 'w' instead of three) despite the fact that

This also interacts very badly the subdomain-based web trust model, so
it should be mentioned in the Security Considerations section.

---

From: Florian Weimer <[email-masked]>
Date: Sun, 12 Jul 2009 10:30:46 +0200

> feedback before then obviously.

Few players perform NXDOMAIN rewriting.  Instead, ANCOUNT=0 rewriting
is used.  This causes all kinds of problems, including redirections
for example.com when it hasn't got an A record (where some browser
would just fall back to www.example.com), and bad interactions with
IPv6 deployment (because all IPv6-only hosts suddenly have got an A
record).

The malicious site protection does not work reliably because it can be
easily bypassed by the attacker, using IP addresses.

Section 5.3 is pretty explicit in that government-mandated filtering
decisions should be made by executive organs, and not the judiciary.
The IETF should not try to regulate this and should certainly show
more respect for separation of powers.  It should mention that
DNS-based filtering is not acceptable to many governments because it
can be bypassed easily, and it is not possible to block content on
popular sites where the collateral damage of a domain-wide block would
be problematic.

Section 7.1 should be more strongly worded.  Rewriting stuff like
search.msn.com (and reverse-proxying the HTTP traffic) must not be
condoned by a RFC.  Such things are just evil.

No redirection on SERVFAIL seems to be a strange recommendation.
Wouldn't this be a very good reason to provide a diagnostics page,
especially if there's been a DNSSEC validation failure?

As it stands, the product list in Section 8.3 serves no particular
purpose.  Some analysis which browser-based mechanisms are broken by
DNS redirection might be helpful, but this could be done in a
product-independet manner.

Section 8.4 should mention that some (most?) rewriters do not rewrite
subtrees which involve a delegation from the TLD level.  This
addresses a huge range of technical issues.

DNSSEC interoperability doesn't work the way you expect because once
the resolver is security-aware, it will set the DO bit queries, and
you cant tell the non-validating resolvers from the validating ones.
It's also not an all-or-nothing thing because validation depends on
availability of trust anchors.  So you'd have to spoof your answer
according what's permitted by the signed data (particularly the
NSEC(3) records; you don't have to validate the signatures yourself).

The draft must mention DNSBL interactions (and, more generally, the
impact on applications which use DNS as a transport for RPC).  It
should describe approaches how to mitigate issues identified (such as
the IPv6 problem), and show the impact in terms of increased query
count.

There's also a policy impact for ICANN.  Restricted TLDs such as .tel
are not feasible if DNS rewriting essentially removes restriction on
TLD contents.  This also applies to e164.arpa subtrees, where some
national regulators have requested that their subtrees can only be
used for ENUM (and not arbitrary DNS information).

While I'm mostly with Stephane regarding the merits of DNS rewriting,
I think the IETF could still publish a draft on this topic.  However,
it should present pretty stringent requirements which ensure that
rewriting does not adversely impact operations.  The current draft is
closer to a fig leaf, I'm afraid.

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 12 Jul 2009 12:32:35 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Livingood, Jason
> Sent: Thursday, July 09, 2009 8:24 AM
> To: [email-masked]
> Subject: [DNSOP] Review of draft-livingood-dns-redirect-00
> 
> http://tools.ietf.org/html/draft-livingood-dns-redirect-00, 
> before the -00 cutoff on Monday, and it will be discussed in 
> the DNSOP WG meeting at IETF 75 (it is listed on the agenda).
> 
> If anyone is interested and has time before IETF 75, I'm 
> happy to take feedback before then obviously.  Please note 
> that there is a list of open items at the end, which we plan 
> to address in subsequent versions.

The draft would benefit from a discussion of the interaction
with DNS64, draft-ietf-behave-dns64.  The specific case that
would be a problem is if the end user's host (or site) is
doing its own DNS64 AAAA synthesis, which is necessary if the
host (or site) is doing its own DNSSEC validation.

-d

---

From: Ralf Weber <[email-masked]>
Date: Mon, 13 Jul 2009 08:12:30 +0200

Moin!

> IPv6 deployment (because all IPv6-only hosts suddenly have got an A
That really is an issue and could be addressed, there are a lot of
case where a A record for a domain doesn't exists, but one for
www.domain does exist. Question then would be how that rewrite
should be presented. As a normal A answer or as CNAME referral which
might be better as the underlying web server might not answer for
the domain without www.

> easily bypassed by the attacker, using IP addresses.
Correct, but that hasn't stopped several governments from passing laws
that exactly mandate this.

> more respect for separation of powers.
That is not the intention and not what I read there. Diversion of
powers is a concept that is not even common among "western
democracies". The text tries to stay away from these political
issues, and instead makes clear that the local law, goverenment or
jurisdictions should be honored where appropriate.

>  It should mention that
Again this is out of scope of the document. There may be countries
that don't see it appropriate, but there are also countries that
see it as appropriate including the one we two live in.

[..]
> especially if there's been a DNSSEC validation failure?
This sounds like an excellent idea to help DNSSEC adoption and
is something that should go into the draft.

So long
-Ralf
---
Ralf Weber
Platform Infrastructure Manager
Colt Telecom GmbH
Herriotstrasse 4
60528 Frankfurt
Germany
DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780
Fax: +49 (0)69 56606 6280
Email: [email-masked]
http://www.colt.net/
Data | Voice | Managed Services

Schütze Deine Umwelt | Erst denken, dann drucken

*****************************************
COLT Telecom GmbH, Herriotstraße 4, 60528 Frankfurt/Main, Deutschland  
* Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 *

Geschäftsführer: Dr. Jürgen Hernichel (Vors.), Rita Thies *  
Amtsgericht Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400

---

From: Jelte Jansen <[email-masked]>
Date: Mon, 13 Jul 2009 10:02:58 +0200

> is something that should go into the draft.

then a SERVFAIL will also result in an e-mail bounce that says connection 
refused instead of DNS error (assuming there's no e-mail sink on the host that 
is redirected to). Fun times for the helpdesk.

I have the impression that even though it tries not to, the document still 
assumes that web==internet, mentioning problems 'non-web clients' only as a 
small side-effect, while imho it should be one of the main concerns (the 
www-case is the easy one).

Also, I don't see how the ISP trust anchor for DNSSEC would work (not knowing 
the actual zone that it is supposed to cover in advance); it might be a better 
idea to simply disable all redirects on DO==1.

Then again, I am of the persuasion that messing with a core protocol on the fly 
is simply asking for trouble, and disabling redirection should be top priority 
for everyone.

Jelte

---

From: Florian Weimer <[email-masked]>
Date: Mon, 13 Jul 2009 10:11:52 +0200

* Ralf Weber:

> www.domain does exist.

True, and some browser have code to deal with this.

> Question then would be how that rewrite should be presented. As a
> normal A answer or as CNAME referral which might be better as the
> underlying web server might not answer for the domain without www.

You can't create a CNAME alias to subdomain. And CNAMEs are not
type-specific, so this would obscure SOA/NS/etc. at the zone apex.

> jurisdictions should be honored where appropriate.

Can't you omit this stuff altogether?

---

From: Roy Arends <[email-masked]>
Date: Mon, 13 Jul 2009 10:12:17 +0200

On Jul 9, 2009, at 5:23 PM, Livingood, Jason wrote:

> I submitted this draft, which you can find at http://tools.ietf.org/html/draft-livingood-dns-redirect-00 
> , before the –00 cutoff on Monday, and it will be discussed in the  
> DNSOP WG meeting at IETF 75 (it is listed on the agenda).
>
> If anyone is interested and has time before IETF 75, I’m happy to  
> take feedback before then obviously.  Please note that there is a  
> list of open items at the end, which we plan to address in  
> subsequent versions.

This part of section 10 is troublesome:

     So the only case where DNS security extensions cause problems for  
DNS Redirect is with a validating stub resolver. This case doesn't  
have widespread deployment now and could be mitigated by using trust  
anchor, configured by the applicable ISP or DNS ASP, that could be  
used to sign the redirected answers.

This mitigation strategy just doesn't work, and for a very good  
reason, as it allows a downgrade attack.

As for the rest of the document, I think it overloads the term  
"redirection" by incorporating lawfully mandated filtering (whatever  
that means), and therefor wrongly justifying this practice altogether.

In general, this kind of muddling with the DNS protocol assumes that  
the sole purpose of the DNS is to allow a web-browser find the address  
of a web-server. Clearly it is not.

There are alternatives. I run unbound from my laptop. Windows users  
can do too: http://unbound.net/downloads/unbound_setup_1.3.1.exe

Other alternatives are OARC's ODVR: https://www.dns-oarc.net/oarc/services/odvr

Kind regards,

Roy Arends

---

From: Florian Weimer <[email-masked]>
Date: Mon, 13 Jul 2009 10:28:15 +0200

* Jelte Jansen:

> then a SERVFAIL will also result in an e-mail bounce that says
> connection refused

Not a hard 5xx error?

> instead of DNS error (assuming there's no e-mail
> sink on the host that is redirected to). Fun times for the helpdesk.

Only if the mail server falls back to the A record if the MX lookup
results in SERVFAIL, which seems like a questionable approach to me.

Anyway, I think DNS rewriting is mainly for folks who also block
25/TCP in- and outgoing or list the address space on the PBL and
similar DNSBLs, so the SMTP argument is not really valid anymore.

> Also, I don't see how the ISP trust anchor for DNSSEC would work (not
> knowing the actual zone that it is supposed to cover in advance); it
> might be a better idea to simply disable all redirects on DO==1.

You can't use trust anchors to guide rewriting.  You need to look at
the zone contents to see what can be done.  With NSEC3 opt-out,
there's still lots of wiggle room (at least initially).  Generally not
spoofing on DO==1 is easier, of course.

---

From: Jelte Jansen <[email-masked]>
Date: Mon, 13 Jul 2009 10:45:57 +0200

>> then a SERVFAIL will also result in an e-mail bounce that says

not unless there's also a specific 5xx error generator listening on the host 
that is redirected to, i guess.

> results in SERVFAIL, which seems like a questionable approach to me.

is it? (i'm asking, i don't know; even the updated smtp rfc seems a bit unclear 
about that)

> similar DNSBLs, so the SMTP argument is not really valid anymore.

well in that case it might be worth adding a section that your own services 
should definitely not have the same resolvers that you have set up for your 
customers, and that a separate non-lying resolver should be set up for those.

But this is just an example of an unintended side effect from assuming that only 
web browsers ask for A/AAAA.

Jelte

---

From: Tony Finch <[email-masked]>
Date: Mon, 13 Jul 2009 12:21:44 +0100

> > then a SERVFAIL will also result in an e-mail bounce that says

No, both SERVFAIL and connection refused are equivalent to 4yz temporary
failures.

> results in SERVFAIL, which seems like a questionable approach to me.

Yes, it would be wrong to do that.

> similar DNSBLs, so the SMTP argument is not really valid anymore.

The draft should probably say something like that explicitly.

However there's an unbounded number of similar problematic examples: what
if the user is running an XMPP server?

RFC 4084 is probably relevant.

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: "Antoin Verschuren" <[email-masked]>
Date: Mon, 13 Jul 2009 13:53:55 +0200

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stephane Bortzmeyer
> Subject: Re: [DNSOP] Review of draft-livingood-dns-redirect-00
> 

While I strongly agree with Stephane's sentiment here, I do see some merits in describing why it is a bad idea instead of describing how it should be done with as little problems as possible (but still with problems).

First thing that comes up is the lawyers and marketing concept that http is the Internet.
The document is trying to avoid that discussion by saying that deep packet inspection should occur to determine that an http request was made, but then we're not talking DNS anymore. I get the strong feeling this is fundamentally against what RFC4367 is arguing about.
Not only is it not true that the majority is only doing simple web browsing, but there are more and more applications and use of http, that would not allow a landing page to work.
I can think of alternative ports of web pages that do http, but also application that use http on port 80 without it being a web browser. Think of embedded http video streaming, or other applications that use the http protocol without being a browser. More and more apps work like that.

Another use case that I see a lot in small and medium size companies and even in the consumer market, and that I don't see described in the document is where a company runs 1 resolver on its own network and uses the resolver of its ISP as a backup or other redundancy reasons. If the ISP's resolver has a different truth than the own resolver, things will go very bad on the user experience side. The DNS is the DNS. There should not be multiple versions of the truth on the network.

And finally, I also don't see a description on how things might go wrong if resolvers are behind a load balancer, and the 2 or more resolvers behind it 
don't have the same filtering policy in place.

All in all I see more use cases where it degrades the user experience instead of improving it, and therefore it's a bad idea to do this in the network.
It will force end-users to deploy their own resolvers and validators to get a better user experience, and while that might seem infeasible today for ordinary users, I can't wait for the first app to arrive that has a resolver built in instead of using the default OS resolver to bypass that trouble.
Perhaps that built in resolver will even do DNS over http ! :-).
Because that will downscale the use of cached responses, I wouldn't want to go that path as it would increase the load on authoritative servers.

The only feasible use I see for a landing page is where it is invoked by an end-point in terms of a web browser that has it explicitly configured to go there when an NXDOMAIN is received by the application.

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: Roy Arends <[email-masked]>
Date: Mon, 13 Jul 2009 13:59:46 +0200

On Jul 13, 2009, at 1:53 PM, Antoin Verschuren wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> While I strongly agree with Stephane's sentiment here, I do see some  
> merits in describing why it is a bad idea instead of describing how  
> it should be done with as little problems as possible (but still  
> with problems).

SSAC's Report on DNS Response Modification
http://www.icann.org/en/committees/security/sac032.pdf

IAB Commentary Architectural Concerns on the use of DNS Wildcards
http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html

Kind regards,

Roy Arends

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 13 Jul 2009 09:55:42 -0400

Good guidance on Informational vs. BCP.  We may get there eventually, but I
thought that starting as a draft BCP might provoke more detailed and useful
debate.  ;-)

On the topic of Œlying resolvers¹ though, that seems a bit strong IMHO.  But
perhaps I have missed a strong MUST statement (per RFC 2119) in a relevant
RFC that you could refer me to?

Jason

On 7/11/09 7:59 PM, "Paul Hoffman" <[email-masked]> wrote:

> It seems inappropriate for the IETF to bless lying resolvers as a Best Current
> Practice. I doubt we as a community could have consensus on when lying is
> good, when it is neutral, and when it is bad. Without such agreement, we can't
> agree on how to run such servers. Having said that, the publication of a
> document such as this (with more input from the community) as a Informational
> RFC could indeed help the Internet.
> 
> --Paul Hoffman, Director
--VPN Consortium

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 13 Jul 2009 09:56:39 -0400

Thx for the feedback.  I will try to address your concern in the 01
revision.  If you have any specific textual recommendations, let me know.

Jason

Regards,
Jason
 
Jason Livingood
Executive Director
Internet Systems Engineering
National Engineering & Technical Operations
Comcast Cable Communications
215-286-7813
[email-masked]
 
This message and any attachments to it may contain PROPRIETARY AND
CONFIDENTIAL INFORMATION exclusively for intended recipients. Please DO NOT
FORWARD OR DISTRIBUTE to anyone else. If you are not the intended recipient,
please contact the sender and delete all copies of this e-mail from your
system.

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 13 Jul 2009 09:58:12 -0400

Thx for the **very detailed** and thoughtful feedback.  I will review &
respond in detail when I start working on the 01 revision.

Jason

Regards,
Jason
 
Jason Livingood
Executive Director

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 13 Jul 2009 10:02:23 -0400

Good feedback, which I will take into consideration for our 01 revision.
Please do note that Section 10 is definitely immature, as we noted in the
Open Issues (#5) in Appendix B.  We¹ll be developing this section quite a
bit.

Thanks
Jason

On 7/13/09 4:12 AM, "Roy Arends" <[email-masked]> wrote:

>> http://tools.ietf.org/html/draft-livingood-dns-redirect-00
>> > , before the 00 cutoff on Monday, and it will be discussed in the
>> > If anyone is interested and has time before IETF 75, I¹m happy to
> Other alternatives are OARC's ODVR:
> https://www.dns-oarc.net/oarc/services/odvr
> 
> Kind regards,
> 
> Roy Arends
>

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 13 Jul 2009 10:04:32 -0400

Thanks for the suggestion, Tony.  I will add that to my tracking list for
the next revision (and may email you to confirm what I have might be
satisfactory).  I think we probably also need to address the fact that mail
servers should not use resolvers that perform DNS redirect (this was assumed
but should be explicit).

Regards
Jason

---

From: Tony Finch <[email-masked]>
Date: Mon, 13 Jul 2009 15:08:10 +0100

On Mon, 13 Jul 2009, Livingood, Jason wrote:

> I think we probably also need to address the fact that mail servers
> should not use resolvers that perform DNS redirect (this was assumed but
> should be explicit).

I think you need to widen that caveat: anything that isn't a web browser
should not use a DNS server that misbehaves as described in this draft.

Tony.

---

From: "Rose, Scott W." <[email-masked]>
Date: Mon, 13 Jul 2009 10:19:19 -0400

> should not use a DNS server that misbehaves as described in this draft.
How would these servers identify themselves?  And should clients believe
servers that report they do not send back altered replies?

This might work, but there would need to be a way for DNS resolvers to
announce their configuration (e.g. redirect yes/no, DNSSEC yes/no, etc),
which isn't available today.

Scott

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
> 

===================================
Scott Rose
NIST
[email-masked]
ph: +1 301-975-8439
http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
===================================

---

From: [email-masked]
Date: Mon, 13 Jul 2009 15:27:56 +0100

> I think we probably also need to address 
> the fact that mail servers should not use resolvers that perform DNS
> redirect (this was assumed but should be explicit).

At least when you do it on your recursive servers you're only affecting 
your own customers, who in most cases can vote with their wallets when 
they don't like it.

When it's done on the authoritative servers no-one has a choice :(

Ray

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Jul 2009 09:19:01 -0700

At 9:55 AM -0400 7/13/09, Livingood, Jason wrote:
>On the topic of 'lying resolvers' though, that seems a bit strong IMHO.  But perhaps I have missed a strong MUST statement (per RFC 2119) in a relevant RFC that you could refer me to?  

I am not aware of an RFC that says something to the effect of "when you are responsible for translating addresses and you get some information that was requrested, you MUST NOT lie about it to the requester", but it might exist. But that's immaterial. Even if the resolver has a good reason to lie, it is lying, and your document should encourage the resolver to be honest about that fact. The recipient might not care, or might very much want to be lied to to protect the recipient from doing something dangerous, but it should be made aware, if possible, that it is talking to a lying resolver.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Jul 2009 13:48:19 -0400 (EDT)

> should not use a DNS server that misbehaves as described in this draft.

I think you need to widen that caveat: anything should not use a DNS server
that misbehaves as described in this draft.

Paul

---

From: Todd Glassey <[email-masked]>
Date: Mon, 13 Jul 2009 11:53:25 -0700

Paul Hoffman wrote:
> I am not aware of an RFC that says something to the effect of "when you are responsible for translating addresses and you get some information that was requrested, you MUST NOT lie about it to the requester", but it might exist. 
That would be in the SLA the provider agrees to provide service under. 
Its part of the warranty for fitness, so while its not in the Standard 
itself - the use of the Standard to commit electronic fraud with will 
have criminal blow-back as well Paul.
> But that's immaterial. Even if the resolver has a good reason to lie, it is lying, and your document should encourage the resolver to be honest about that fact. The recipient might not care, or might very much want to be lied to to protect the recipient from doing something dangerous, but it should be made aware, if possible, that it is talking to a lying resolver.
>
> --Paul Hoffman, Director
> --VPN Consortium
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.375 / Virus Database: 270.13.12/2234 - Release Date: 07/12/09 17:56:00
>
>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Jul 2009 12:01:51 -0700

>that misbehaves as described in this draft.

Paul: that's over the top. Some of the services defined in the draft are highly desired by some Internet users. You may not like them, and that's fine. Your statement is akin to, and as useful as, the "NATs are bad so we shouldn't talk about them" debate that flares in the IETF approximately biannually.

--Paul Hoffman, Director
--VPN Consortium

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 13 Jul 2009 16:29:49 -0400

Dear colleagues,

> items at the end, which we plan to address in subsequent versions.

I have read draft-livingood-dns-redirect-00.  I have some (actually,
many) comments.  I write as a contributor of the DNS Operations
working group and not in any other capacity (especially not as co-chair
of DNSEXT).  I will leave it for others to debate the extent to which
the document actually proposes changes to the DNS protocol.  I
apologise for the length of this mail, but it seemed best to me to go
over the document in detail.

To begin with, I must state that I am opposed to adopting the draft as
it stands as a working group item with a target of BCP.  That said, I
agree that if people are going to do these sorts of things, it'd be
better that we have a document to explain what the least bad way to do
them is (although one might be excused for wondering what "least bad"
means in a context such as this).  It is a fact that people are doing
these DNS tricks, and we will not be saved from them by refusing to
talk about them any more than we were saved from the stupidest
possible NAT implementations by the IETF's collective refusal to work
on NAT.  Still, I am not sure that the document as it currently stands
represents that "least bad", so there's some work to do.

First, in section 3 we have a note that there are alternative
strategies to DNS redirects.  It is one thing to rule discussion of
those alternatives out of scope; it is quite another to present the
alternatives as completely neutral.  This discussion should be
strengthened to point out that performing redirects in the DNS have
extremely wide consequences, and that the DNS-based approach is a
terribly blunt instrument to perform what is intended to be surgical
redirections, akin to doing an appendectomy with a club.  In addition,
I think the discussion should point out that DNS-based redirection
violates the basic principle of the DNS: it is supposed to be a
distributed, loosely-coherent database of records originally provided
by authoritative sources of data.  DNS redirections violate that
principle by design, even if they do it for the noblest reasons.  This
is an important factor in the discussion of DNSSEC, to which I'll turn
near the end of this message.

I note this text in section 5.1.3:

   Design considerations for the Web Error Search and Malicious Site
   Protection services should include properly and promptly
   terminating non-HTTP connection requests.

I would find it helpful if the draft included some text explaining how
to terminate "non-HTTP connection requests" (and make a subsequent
connection request operate correctly)?  There's nothing in the DNS
request that would tell a resolver whether the DNS query was happening
because the client planned to make an http connection as opposed to
something else.  Is the idea to monitor DNS requests, then sniff the
traffic to see if it's an HTTP request and then do something with that
knowledge?  (This sounds just shy of practically impossible to me, but
I'd be happy to be wrong.)  What about https requests?  Surely,
malware people will quickly learn to send the requests via https if
that's a clear path, so that won't work.  And anyway, one can't sniff
encrypted traffic.

In section 5.2.3, it says

   A range of resource records may be redirected, such as A,
   AAAA, MX, SRV, and NAPTR records, in order to fulfill the objective
   of preventing access to certain network elements containing malicious
   content or which and in some way used to transmit, relay, or
   otherwise transfer malicious content.  All other resource record
   types must be answered as if there was no redirection.

I think the last sentence is just a rhetorical flourish.  It seems to
say that any RR may be redirected, depending on the objective; but
other ones must (MUST?  I suppose this depends on where one stands on
2119 language in BCPs.  If the authors want 2119 language, there are
some other places that could do with it too) be answered as if there
were no redirection.  This boils down to, "Redirect whatever you think
you need to."  So the last sentence in the quoted bit is just
decoration: it merely makes the passage read as though the technique
isn't too invasive, but it has no practical effect.  (Section 5.5 has
this, too.)

Section 5.3 ought to point out that legally-mandated DNS redirect may
do harm, because the ability to send desirable traffic (such as
cease-and-desist emails, for instance) is lost (this is especially
important in light of the discussion of proxy servers at the end of
5.3.3).  Section 5.3.3 reads like it was written by actual lawyers
(note that in my idiolect, "lawyer" is not automatically a term of
derision): there are here a lot of and/ors, other slashes, and lists
of possible authorities.  For readability, I suggest that this be made
simpler and more neutral.  "Legal authority" probably covers
everything needed to encompass the various kinds of agencies in
question.  I'm also not sure the apparent requirement to disclose that
the redirection is enforced by law has any practical value, although I
think it's nice if my ISP tells me it's fooling with the bits because
of law enforcement rather than local policy.

What is the interaction between the manual DNS server reconfiguration
discussed at the end of section 6.3, and the persistence
recommendation in section 6.1?  It seems to me all but inevitable that
a manual modification will bumped out of the way by a subsequent
automatic configuration unless the automatic system is informed of the
manual changes.  Therefore, it seems to me that there needs to be a
mechanism by which manual configuration changes can be communicated
back up to the automatic assigner, so that the manual changes don't
later get undone.  (It'd probably be enough to specify the ability to
disable the manual changes, without perhaps needing to send all the
new configuration to the ISP.)

In section 6.4, the text appears to suggest that setting an attribute
in the browser will affect how the DNS lookups happen.  I suggest
removing that text or else including a pointer to the section in which
you explain why it is a bad (not to say "ludicrous") idea.  The
subsequent text is the right direction to go: to allow users to opt
out, just change their network configuration.  I think some more
exposition of the tradeoffs may be needed, however, since the current
text seems to be fairly narrowly tailored to the present-era
arrangement where the CPE has a single IPv4 address with a NATted LAN
sitting behind it.  Given that some other participants in the IETF are
busily telling everyone to assign fairly large IPv6 ranges to every
customer, the model in the draft probably needs some more refining.

I think the discussion in 7.1 isn't drawing the wanted distinction
quite as clearly as it might.  The proposal is that a _good_
redirection captures the query, detects it is one of the redirection
targets, and takes the user to a web page where the user is told that
they've been redirected.  The complaint in 7.1 is really that the
very same redirection has happened, but the user is not informed.  The
discussion of "valid reason for the redirection" is just a
distraction: the issue isn't whether the redirection is somehow
justified (since there are some of us who would reply that such a
redirection is _never_ justified), but whether the user is told about
it.

Section 7.4 would benefit from some characterization of what would be
acceptable additional latency introduced by a redirector.  Citations
of user-experience studies would help.  It seems to me the section is
talking about one of the trade-offs to be made when trying to decide
whether to add a redirector, and without some well-founded numbers,
this is just hand waving.

Section 7.5 seems to suggest that there are cases where it is
acceptable to intercept DNS queries and redirect them silently.  These
cases are typified as being "reasonable", "justifiable", &c.  The
problem with any of this sort of thing is that it is the ISP who gets
to decide what is "reasonable".  I presume that those ISPs who are
capturing and blocking or, worse, redirecting all DNS traffic think it
_is_ reasonable and justifiable.  Since what is reasonable and
justifiable is right at the core of disagreement, reasonableness and
justifiability can't be the criteria.  I suggest that discussion be
removed: there just is no reason to capture the DNS traffic.  If you
want to turn someone off, _turn them off_.

Section 8 could be improved considerably by discussing the way that
redirection breaks other protocols.  A diagram that looks very like
(e.g.) Figure 5, only with no place in the protocol where the Web
response box goes, might make clearer why the redirection is
problematic.

Section 9.7 says, "This example represents an improper redirect
occurring when a valid DNS RR should have been returned in response to
a DNS recursive query for an example website, the resulting HTTP
transaction, and that no DNS query or HTTP traffic was sent to the
valid authoritative DNS server and valid web server."  This makes it
sound like there should be an HTTP request going to the DNS server.  I
know that's not the intent, but given that the target audience is
presumably confused about the relationship between DNS servers and web
servers (to the point that they're willing to break every other
application in the interests of supporting the web servers), this
should be cleared up.

Section 10's consideration of DNSSEC seems to have some fairly deep
misapprehensions of the DNS protocol.  First, it has a completely
naive idea of the actual DNS ecosystem.  It starts by shutting down
any discussion of non-stub resolvers on the grounds that "DNS
redirections take place on the recursive server", as though only one
recursive server could be involved in a resolution request from a
stub.  But previously in the draft there was some discussion of
networks in households, and so on.  One model of deployment there is
surely a gateway server that runs its own DNS recursive resolver, and
provides service to all the systems behind it, often with a single
IPv4 anddress and an RFC1918-addressed NAT.  Such gateways are obvious
targets for DNSSEC deployment.  Now, since they usually get the
address from the ISP via automatic means, they will get the DNS
configuration from the ISP.

There is nothing whatever about a given query that could tell you,
"Oops, this one's not from a stub; better give it the real DNS."  So,
the draft should address the case of a full-service recursing
validating resolver inside the redirect boundary.

It is interesting to compare bullet 2 with the advice we editors of
the DNS64 document (over in BEHAVE) have received.  In our case, the
suggestion has been that, if the security-aware translator validates
the answer from the DNS containing an A record, and is going to
provide the querying resolver (which set DO=1 and CD=0) an answer, it
is perfectly acceptable to set the AD bit in the answer.  This is
because of the language in RFC 4035: "The name server side SHOULD set
the AD bit if and only if the resolver side considers all RRsets in
the Answer section and any relevant negative response RRs in the
Authority section to be authentic."  In the case of DNS64/NAT64, the
trick here is to expand the definition of "authentic" to include the
NAT64 technique.  I suspect this is really acceptable to people
because the DNS64 knows about the NAT64 configuration, and is
attempting to hook the querying host up with the target host (and is
just compensating for the fact that the v4 and v6 networks are really
different networks).  But strictly, the justification for setting the
AD bit is that the DNS64 host knows about the NAT64 configuration, and
therefore is in a position to assert the authenticity of that address
(having assured itself of the authenticity of the destination address).

The redirection case is on purpose sending the querying client to some
target host _other than_ the requested one.  In some sense, then, the
decision in the draft not to set the AD bit on these responses is
praiseworthy.  However, the redirector presumably is tightly coupled
to the configuration of redirection and the host that is used to offer
landing pages.  Therefore it seems to me by the logic used above,
setting the AD bit would not strictly be a violation of the protocol,
if it isn't in DNS64.  I confess this conclusion makes me extremely
uncomfortable.  

I think a great deal of additional text will be needed to explain how
the ISP-provided "mitigating" trust anchor is supposed to help solve
the issue that the redirector's answers will fail validation by a
downstream validator.  Part of the point of DNSSEC is supposed to be
that we can prove delegations haven't been mucked with along the chain
between resolvers, and also that the trust across zone cut boundaries
is not broken.  This is the cryptographic assurance of the integrity
of the distributed database I mentioned at the beginning of this
message.  The goal of redirection is to subvert that integrity (never
mind whether it's justified -- that's the goal).  

The only way, it seems to me, that a redirector can use an alternative
trust anchor is to get its clients to accept an alternative (or,
rather, "additional") root key.  Then any validation chain can be
produced using that key, at the cost of a considerable increase in
state on the part of the redirector (because presumably the redirector
is going to need to remember what queries need supporting keys chasing
all the way down from the root.)  If such a system could be built such
that it could be reliably deployed, it would amount to a frontal
assault on DNSSEC itself, and on the principle of the single root.

And so we arrive at the really fundamental problem of the draft: it
presents a plan to fracture the namespace selectively.  Sometimes,
just in cases reflected in the redirector's own configuration, the
namespace delegation points are _not_ those as reflected in a common
hierarchy descended from a root (let's leave aside the "unique root"
for the moment, since it's not precisely relevant to this argument),
but instead a delegation to some other point.  Under such a model, a
coherent distributed database becomes totally unreliable.  We might
say DNSSEC is designed to foil the sort of attempt redirection makes
precisely because this kind of fracturing undermines the database
itself, and that the result of being able to prove you've arrived at
the right host is just a happy instantiation of the more general
principle.

It is therefore mind-boggling that there is nothing in the Security
Consideration sections of the draft to say, "Oh, and we've broken the
DNS Security Extensions, too."  Section 11 also includes the following
text, which probably needs to say "no-one" where it says "someone":

   Security best practices should be followed regarding access to the
   opt-in and opt-out functions, in order that someone other than the
   user is able to change the user's DNS Redirect settings.

These are all the remarks I have at the moment.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 13 Jul 2009 21:20:12 -0400

Great and detailed feedback on our first draft, Andrew.  I'll take a reply
in detail, point-by-point, when I start working on -01 with my co-authors
and contributors.

Thanks
Jason

> Dear colleagues,

On Thu, Jul 09, 2009 at 11:23:48AM -0400, Livingood, Jason
> wrote:
> take

I
> have read draft-livingood-dns-redirect-00.  I have some (actually,
many)
> comments.  I write as a contributor of the DNS Operations
working group and
> not in any other capacity (especially not as co-chair
of DNSEXT).  I will
> leave it for others to debate the extent to which
the document actually
> proposes changes to the DNS protocol.  I
apologise for the length of this
> mail, but it seemed best to me to go

To begin
> with, I must state that I am opposed to adopting the draft as
it stands as a
> working group item with a target of BCP.  That said, I
agree that if people
> are going to do these sorts of things, it'd be
better that we have a document
> to explain what the least bad way to do
them is (although one might be excused
> for wondering what "least bad"
means in a context such as this).  It is a fact
> that people are doing
these DNS tricks, and we will not be saved from them by
> refusing to
talk about them any more than we were saved from the
> stupidest
possible NAT implementations by the IETF's collective refusal to
> work
on NAT.  Still, I am not sure that the document as it currently
> stands

First, in
> section 3 we have a note that there are alternative
strategies to DNS
> redirects.  It is one thing to rule discussion of
those alternatives out of
> scope; it is quite another to present the
alternatives as completely neutral.
> This discussion should be
strengthened to point out that performing redirects
> in the DNS have
extremely wide consequences, and that the DNS-based approach
> is a
terribly blunt instrument to perform what is intended to be
> surgical
redirections, akin to doing an appendectomy with a club.  In
> addition,
I think the discussion should point out that DNS-based
> redirection
violates the basic principle of the DNS: it is supposed to be
> a
by
> authoritative sources of data.  DNS redirections violate that
principle by
> design, even if they do it for the noblest reasons.  This
is an important
> factor in the discussion of DNSSEC, to which I'll turn
near the end of this
> message.

   Design considerations for the
> Web Error Search and Malicious Site
   Protection services should include
> properly and promptly

I would
> find it helpful if the draft included some text explaining how
to terminate
> "non-HTTP connection requests" (and make a subsequent
connection request
> operate correctly)?  There's nothing in the DNS
request that would tell a
> resolver whether the DNS query was happening
because the client planned to
> make an http connection as opposed to
something else.  Is the idea to monitor
> DNS requests, then sniff the
traffic to see if it's an HTTP request and then
> do something with that
knowledge?  (This sounds just shy of practically
> impossible to me, but
I'd be happy to be wrong.)  What about https requests?
> Surely,
malware people will quickly learn to send the requests via https
> if
that's a clear path, so that won't work.  And anyway, one can't
> sniff
encrypted traffic.

   A range of resource
> records may be redirected, such as A,
   AAAA, MX, SRV, and NAPTR records, in
> order to fulfill the objective
   of preventing access to certain network
> elements containing malicious
   content or which and in some way used to
> transmit, relay, or
   otherwise transfer malicious content.  All other
> resource record

I
> think the last sentence is just a rhetorical flourish.  It seems to
say that
> any RR may be redirected, depending on the objective; but
other ones must
> (MUST?  I suppose this depends on where one stands on
2119 language in BCPs.
> If the authors want 2119 language, there are
some other places that could do
> with it too) be answered as if there
were no redirection.  This boils down to,
> "Redirect whatever you think
you need to."  So the last sentence in the quoted
> bit is just
decoration: it merely makes the passage read as though the
> technique
isn't too invasive, but it has no practical effect.  (Section 5.5
> has
this, too.)

Section 5.3 ought to point out that legally-mandated DNS
> redirect may
do harm, because the ability to send desirable traffic (such
> as
cease-and-desist emails, for instance) is lost (this is
> especially
important in light of the discussion of proxy servers at the end
> of
(note
> that in my idiolect, "lawyer" is not automatically a term of
derision): there
> are here a lot of and/ors, other slashes, and lists
of possible authorities.
> For readability, I suggest that this be made
simpler and more neutral.  "Legal
> authority" probably covers
everything needed to encompass the various kinds of
> agencies in
question.  I'm also not sure the apparent requirement to disclose
> that
the redirection is enforced by law has any practical value, although
> I
of law
> enforcement rather than local policy.

What is the interaction between the
> manual DNS server reconfiguration
discussed at the end of section 6.3, and the
> persistence
recommendation in section 6.1?  It seems to me all but inevitable
> that
a manual modification will bumped out of the way by a
> subsequent
automatic configuration unless the automatic system is informed of
> the
manual changes.  Therefore, it seems to me that there needs to be
> a
back up
> to the automatic assigner, so that the manual changes don't
later get undone.
> (It'd probably be enough to specify the ability to
disable the manual changes,
> without perhaps needing to send all the

In
> section 6.4, the text appears to suggest that setting an attribute
in the
> browser will affect how the DNS lookups happen.  I suggest
removing that text
> or else including a pointer to the section in which
you explain why it is a
> bad (not to say "ludicrous") idea.  The
subsequent text is the right direction
> to go: to allow users to opt
out, just change their network configuration.  I
> think some more
exposition of the tradeoffs may be needed, however, since the
> current
text seems to be fairly narrowly tailored to the
> present-era
arrangement where the CPE has a single IPv4 address with a NATted
> LAN
sitting behind it.  Given that some other participants in the IETF
> are
busily telling everyone to assign fairly large IPv6 ranges to
> every

I
> think the discussion in 7.1 isn't drawing the wanted distinction
quite as
> clearly as it might.  The proposal is that a _good_
redirection captures the
> query, detects it is one of the redirection
targets, and takes the user to a
> web page where the user is told that
they've been redirected.  The complaint
> in 7.1 is really that the
very same redirection has happened, but the user is
> not informed.  The
discussion of "valid reason for the redirection" is just
> a
justified
> (since there are some of us who would reply that such a
redirection is _never_
> justified), but whether the user is told about
it.

Section 7.4 would benefit
> from some characterization of what would be
acceptable additional latency
> introduced by a redirector.  Citations
of user-experience studies would help.
> It seems to me the section is
talking about one of the trade-offs to be made
> when trying to decide
whether to add a redirector, and without some
> well-founded numbers,

Section 7.5 seems to suggest
> that there are cases where it is
acceptable to intercept DNS queries and
> redirect them silently.  These
cases are typified as being "reasonable",
> "justifiable", &c.  The
problem with any of this sort of thing is that it is
> the ISP who gets
to decide what is "reasonable".  I presume that those ISPs
> who are
capturing and blocking or, worse, redirecting all DNS traffic think
> it
justifiable
> is right at the core of disagreement, reasonableness and
justifiability can't
> be the criteria.  I suggest that discussion be
removed: there just is no
> reason to capture the DNS traffic.  If you
want to turn someone off, _turn
> them off_.

Section 8 could be improved considerably by discussing the way
> that
redirection breaks other protocols.  A diagram that looks very
> like
(e.g.) Figure 5, only with no place in the protocol where the
> Web
response box goes, might make clearer why the redirection
> is
problematic.

Section 9.7 says, "This example represents an improper
> redirect
occurring when a valid DNS RR should have been returned in response
> to
a DNS recursive query for an example website, the resulting
> HTTP
valid
> authoritative DNS server and valid web server."  This makes it
sound like
> there should be an HTTP request going to the DNS server.  I
know that's not
> the intent, but given that the target audience is
presumably confused about
> the relationship between DNS servers and web
servers (to the point that
> they're willing to break every other
application in the interests of
> supporting the web servers), this
should be cleared up.

Section 10's
> consideration of DNSSEC seems to have some fairly deep
misapprehensions of the
> DNS protocol.  First, it has a completely
naive idea of the actual DNS
> ecosystem.  It starts by shutting down
any discussion of non-stub resolvers on
> the grounds that "DNS
redirections take place on the recursive server", as
> though only one
recursive server could be involved in a resolution request
> from a
stub.  But previously in the draft there was some discussion
> of
surely
> a gateway server that runs its own DNS recursive resolver, and
provides
> service to all the systems behind it, often with a single
IPv4 anddress and an
> RFC1918-addressed NAT.  Such gateways are obvious
targets for DNSSEC
> deployment.  Now, since they usually get the
address from the ISP via
> automatic means, they will get the DNS

There is
> nothing whatever about a given query that could tell you,
"Oops, this one's
> not from a stub; better give it the real DNS."  So,
the draft should address
> the case of a full-service recursing
validating resolver inside the redirect
> boundary.

It is interesting to compare bullet 2 with the advice we editors
> of
the DNS64 document (over in BEHAVE) have received.  In our case,
> the
the
> answer from the DNS containing an A record, and is going to
provide the
> querying resolver (which set DO=1 and CD=0) an answer, it
is perfectly
> acceptable to set the AD bit in the answer.  This is
because of the language
> in RFC 4035: "The name server side SHOULD set
the AD bit if and only if the
> resolver side considers all RRsets in
the Answer section and any relevant
> negative response RRs in the
Authority section to be authentic."  In the case
> of DNS64/NAT64, the
trick here is to expand the definition of "authentic" to
> include the
NAT64 technique.  I suspect this is really acceptable to
> people
because the DNS64 knows about the NAT64 configuration, and
> is
just
> compensating for the fact that the v4 and v6 networks are really
different
> networks).  But strictly, the justification for setting the
AD bit is that the
> DNS64 host knows about the NAT64 configuration, and
therefore is in a position
> to assert the authenticity of that address
(having assured itself of the
> authenticity of the destination address).

The redirection case is on purpose
> sending the querying client to some
target host _other than_ the requested
> one.  In some sense, then, the
decision in the draft not to set the AD bit on
> these responses is
praiseworthy.  However, the redirector presumably is
> tightly coupled
to the configuration of redirection and the host that is used
> to offer
landing pages.  Therefore it seems to me by the logic used
> above,
setting the AD bit would not strictly be a violation of the
> protocol,
if it isn't in DNS64.  I confess this conclusion makes me
> extremely
uncomfortable.  

I think a great deal of additional text will be
> needed to explain how
the ISP-provided "mitigating" trust anchor is supposed
> to help solve
the issue that the redirector's answers will fail validation by
> a
that we
> can prove delegations haven't been mucked with along the chain
between
> resolvers, and also that the trust across zone cut boundaries
is not broken.
> This is the cryptographic assurance of the integrity
of the distributed
> database I mentioned at the beginning of this
message.  The goal of
> redirection is to subvert that integrity (never
mind whether it's justified --
> that's the goal).  

The only way, it seems to me, that a redirector can use
> an alternative
trust anchor is to get its clients to accept an alternative
> (or,
rather, "additional") root key.  Then any validation chain can
> be
state on
> the part of the redirector (because presumably the redirector
is going to need
> to remember what queries need supporting keys chasing
all the way down from
> the root.)  If such a system could be built such
that it could be reliably
> deployed, it would amount to a frontal
assault on DNSSEC itself, and on the
> principle of the single root.

And so we arrive at the really fundamental
> problem of the draft: it
presents a plan to fracture the namespace
> selectively.  Sometimes,
just in cases reflected in the redirector's own
> configuration, the
namespace delegation points are _not_ those as reflected in
> a common
hierarchy descended from a root (let's leave aside the "unique
> root"
but
> instead a delegation to some other point.  Under such a model, a
coherent
> distributed database becomes totally unreliable.  We might
say DNSSEC is
> designed to foil the sort of attempt redirection makes
precisely because this
> kind of fracturing undermines the database
itself, and that the result of
> being able to prove you've arrived at
the right host is just a happy
> instantiation of the more general
principle.

It is therefore mind-boggling
> that there is nothing in the Security
Consideration sections of the draft to
> say, "Oh, and we've broken the
DNS Security Extensions, too."  Section 11 also
> includes the following
text, which probably needs to say "no-one" where it
> says "someone":

   Security best practices should be followed regarding
> access to the
   opt-in and opt-out functions, in order that someone other
> than the

These
> are all the remarks I have at the moment.

Best regards,

Andrew

-- 
Andrew
> Sullivan
[email-masked]
Shinkuro,
> Inc.
DNSOP mailing
> list
[email-masked]

---

From: Alan Barrett <[email-masked]>
Date: Mon, 13 Jul 2009 22:13:45 +0200

On Thu, 09 Jul 2009, Livingood, Jason wrote:
> http://tools.ietf.org/html/draft-livingood-dns-redirect-00, before
> the =??00 cutoff on Monday, and it will be discussed in the DNSOP WG
> meeting at IETF 75 (it is listed on the agenda).

I think that this sort of lying recursive resolver is a bad idea.
Instead, I suggest a new "SUGGESTION" RR type that could be returned
in the additional section of an error message.  For example, if
you ask for www.example.invalid, you could get back an NXDOMAIN
error, with "SUGGESTION URL=http://10.2.3.4/www.example.invalid"
in the additional section, and if you ask for censored.example.
you could get back a SERVFAIL response with "SUGGESTION
URL=http://10.2.3.4/why-we-censor.html" in the additional section.

Clients who want to follow such suggestions can then do so, without
harming clients who don't want to be lied to.

--apb (Alan Barrett)

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 14 Jul 2009 09:15:24 -0400

On 7/14/09 8:58 AM, "Suzanne Woolf" <[email-masked]> wrote:

> In this case, we're talking about resolvers replacing
> authoritative server data with their own.

Actually, I thought the case was resolvers providing an alternate response,
where NO authoritative data exists.  ??

> To the draft specifically: the goal behind it is laudable, and a lot
> of the complaints about it are in the nature of shooting the
> messenger.  I'm one of the people who shares the belief that there's
> no "Best" in this space to justify the "BCP" tag, but an informational
> document will be useful. I look forward to the -01 and the discussion
> in Stockholm.

Yes, I suspect you may well be right on Informational vs. BCP.  But I'm
pleased with the detailed feedback I have thus far received.

Jason

---

From: [email-masked]
Date: Tue, 14 Jul 2009 14:20:01 +0100

> where NO authoritative data exists.  ??

An NXDOMAIN response is still authoritative data.

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: Tony Finch <[email-masked]>
Date: Tue, 14 Jul 2009 14:25:33 +0100

> want to turn someone off, _turn them off_.

Captive portals come to mind, e.g. to authenticate to a wireless access
point, or to quarantine a customer's virus-infested computer.

Tony.

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 14 Jul 2009 12:58:03 +0000

On Mon, Jul 13, 2009 at 09:55:42AM -0400, Livingood, Jason wrote:
> On the topic of "lying resolvers" though, that seems a bit strong IMHO.  But

It's always seemed to me that it was implicit in the DNS model that
properly delegated authoritative servers determine what's "true" about
a given portion of the namespace. That's why they're "authoritative".
Recursive resolvers ask for data, and they use data they got from
authoritative servers to answer queries. They don't generate data from
whole cloth.

In contexts where I'm a domain owner, or responsible for the correct
propagation of zone data from authoritative servers, I'm not going to
be happy about intermediate resolvers rewriting my data on the fly. It
renders the whole concept of the hierarchical namespace, with
delegations of authority over various pieces of it, pretty much
meaningless.

"DNS redirect" is a fundamental violation of the assumptions behind
the protocol....a philosophical violation, if you will. This means
that it's esthetically unpleasant to a lot of people, but more to the
point, that it's impossible to do cleanly.

It's understood that service providers live in a world where such
philosophical violations occur regularly, for all kinds of
reasons. But you can't make people like it, particularly not by trying
to dress it up. In this case, we're talking about resolvers replacing
authoritative server data with their own. If you believe the model of
DNS that I asserted above, "lying" is a defensible description.

Suzanne

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 14 Jul 2009 13:49:59 +0000

> where NO authoritative data exists.  ??

"I'm authoritative for this domain, and there's no such RR in it." The
assertion there's no data at that name is part of the scope of
authority, and NXDOMAIN is an authoritative answer. (See also the
various tussles over "empty non-terminals," "authenticated proof of
non-existence," and the precise semantics of DS records alongside a
delegation in the parent zone.)

> pleased with the detailed feedback I have thus far received.

Documented is better than not. Carry on. :)

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 14 Jul 2009 08:17:52 -0700

>where NO authoritative data exists.  ??

The draft in question covers multiple scenarios, including the one in section 5.2, "Malicious Site Protection". In that scenario, the lying resolver is purposely provides an alternate response authoritative date exists but the service provider wants to protect the querier from being harmed. Thus, your response above is wrong.

By grouping different scenarios together in one document, it is difficult to differentiate obviously dangerous behaviors from potentially valuable behavior that queriers might want.

--Paul Hoffman, Director
--VPN Consortium

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 14 Jul 2009 11:52:18 -0400

> point, or to quarantine a customer's virus-infested computer.

There are in fact ways to do that without mucking with DNS answers.
Some portals do such things, and I contend that such approaches are
always preferable.

Ay

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 14 Jul 2009 23:15:53 +0200

On Sat, Jul 11, 2009 at 04:59:38PM -0700,
 Paul Hoffman <[email-masked]> wrote 
 a message of 8 lines which said:

> Having said that, the publication of a document such as this (with
> more input from the community) as a Informational RFC could indeed
> help the Internet.

I doubt it. IMHO, giving the amount of money at stake, there is a big
risk that *any* RFC published on this topic, even Experimental or
Historic, will be used by Comcast (or Verizon or Road Runner or
another) in its advertisments "The IETF approved today the RFC written
by Comcast about the DNS Helper service".

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 14 Jul 2009 23:23:19 +0200

On Mon, Jul 13, 2009 at 03:27:56PM +0100,
 [email-masked] <[email-masked]> wrote 

> your own customers, who in most cases can vote with their wallets when 

No, as I explained here:

 
> When it's done on the authoritative servers no-one has a choice :(

But at least you do not violate the DNS protocol (unlike what the DNS
lying resolvers do).

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 14 Jul 2009 23:26:42 +0200

On Mon, Jul 13, 2009 at 04:29:49PM -0400,
 Andrew Sullivan <[email-masked]> wrote 
 a message of 33 lines which said:

> It is a fact that people are doingthese DNS tricks, and we will not
> be saved from them by refusing totalk about them any more than we
> were saved from the stupidestpossible NAT implementations by the
> IETF's collective refusal to workon NAT.

There is a huge difference here: NAT was a solution to an existing
problem, the lack of IPv4 addresses (remember that, when NAT started,
the RIR were not even distributing IPv6 addresses, not to mention
actual routing).

Therefore, whatever the opinion of the IETF was, NAT were going to be
a success.

DNS lying resolvers are not a solution to an actual problem
(otherwise, doing it as an opt-in service would be sufficient).

---

From: k claffy <[email-masked]>
Date: Tue, 14 Jul 2009 16:48:11 -0700

On Mon, Jul 13, 2009 at 09:20:12PM -0400, Livingood, Jason wrote:
  Great and detailed feedback on our first draft, Andrew.  I'll take a reply
  in detail, point-by-point, when I start working on -01 with my co-authors
  and contributors.
  
  Thanks
  Jason

jason

andrew pretty much covered it but just to be explicit, 
my two biggest issues:

(1) for each proposed scenario, need to explain why not only is 
it possible to incur some collateral benefits by falsifying 
DNS responses, but why falsifying DNS responses is the Best 
or Only way to achieve those benefits.  

(2) especially given its legalistic tone, should acknowledge
that the legal territory this behavior occupies is unresolved,
and will likely be answered differently by different national
laws. somewhere near where you acknowledge explicitly "this does 
violate the intended use of this protocol \cite{}, and here 
are the bad things that can happen as a result."

k

  > Dear colleagues,

  On Thu, Jul 09, 2009 at 11:23:48AM -0400, Livingood, Jason >
  wrote: > If anyone is interested and has time before IETF 75,
  I??m happy to > take > feedback before then obviously.  Please
  note that there is a list of > open > items at the end, which we
  plan to address in subsequent versions.

  I > have read draft-livingood-dns-redirect-00.  I have some
  (actually, many) > comments.  I write as a contributor of the DNS
  Operations working group and > not in any other capacity (especially
  not as co-chair of DNSEXT).  I will > leave it for others to
  debate the extent to which the document actually > proposes changes
  to the DNS protocol.  I apologise for the length of this > mail,
  but it seemed best to me to go over the document in detail.

  To begin > with, I must state that I am opposed to adopting the
  draft as it stands as a > working group item with a target of
  BCP.  That said, I agree that if people > are going to do these
  sorts of things, it'd be better that we have a document > to
  explain what the least bad way to do them is (although one might
  be excused > for wondering what "least bad" means in a context
  such as this).  It is a fact > that people are doing these DNS
  tricks, and we will not be saved from them by > refusing to talk
  about them any more than we were saved from the > stupidest
  possible NAT implementations by the IETF's collective refusal to
  > work on NAT.  Still, I am not sure that the document as it
  currently > stands represents that "least bad", so there's some
  work to do.
  
  First, in
  strategies to DNS
  principle by
  is an important
  near the end of this

  
  I would
  to terminate
  connection request
  encrypted traffic.

     A range of resource
  
  I
  say that
  other ones must
  2119 language in BCPs.
  this, too.)
  
  derision): there
  of possible authorities.
  
  later get undone.
  
  In
  in the
  removing that text
  you explain why it is a
  
  I
  quite as
  redirection captures the
  redirection is _never_
  it.

  justifiability can't
  
  problematic.
  
  sound like
  know that's not
  should be cleared up.
  
  Section 10's
  misapprehensions of the
  provides
  IPv4 anddress and an
  targets for DNSSEC
  address from the ISP via
  
  There is
  "Oops, this one's
  the draft should address
  
  provide the
  is perfectly
  because of the language
  different
  AD bit is that the
  
  uncomfortable.  
  
  between
  is not broken.
  of the distributed
  message.  The goal of
  
  is going to need
  all the way down from
  
  coherent
  say DNSSEC is
  precisely because this
  principle.

  
  These
  
  Best regards,
  
  Andrew
  
  -- 
  Andrew
  [email-masked]
  Shinkuro,
  [email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Wed, 15 Jul 2009 00:08:46 -0400 (EDT)

> Paul: that's over the top. Some of the services defined in the draft are highly desired by some Internet users. You may not like them, and that's fine. Your statement is akin to, and as useful as,…

There is a huge difference here. With NAT, one is putting some
inconvenience to the end user and the server administrator that requires
some clarifications in protocols and some support with detecting it
and working with it. With manipulating my laptop's DNS asking for MY
OWN cryptographically signed data, you are asking me to throw out the
crypto protection and make me accept a downgrade attack.

The IETF allowing or endorsing any kind of DNS forging in the age of
DNSSEC is simply wrong. There can be other methods, such as DHCP related
options, that can be used to notify or redirect a user without resorting
to crippling DNSSEC security.

I have serious problems with:

Validating stub resolvers will become the norm, with more and more
devices connecting to whatever they can get (and not trust). Modifying
DNS answers was a hack because there is no "Please go here first with
a browser" DHCP option. We need to phase outsuch practises, and not
endorse them in any way.

In fact, most hotspots now grab port 80 for their redirects and allow
DNS requests to go out unmodified, which is a much better way of handling
the hot spot scenario.

As for the various commercial races on who gets to sell ads on typoed
domains, non-existing domains et. all, I think the IETF should not
participate either. These fall in the same domain as the MIME type wars,
the search engine setting wars, the home page changing wars, the file
extension changing wars. Whatever the IETF would recommend, some vendor
will override it because they are losing revenue because of it.

Paul

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 15 Jul 2009 12:29:47 -0400

> (otherwise, doing it as an opt-in service would be sufficient).

I cannot agree, as much as I would like to.

If there weren't an "actual problem" here to be solved, nobody would
be trying to do it.  Just because I don't think typos in DNS names are
hard to fix does not mean that there isn't a service there some people
like (I have no idea whether they actually like it; I have seen zero
studies of actual user impressions of these things).  Just because I
know how to avoid going to phishing and malware sites does not mean it
is within the competence of the average user.  And just because I
think the cost of running a DNS server that generates no revenue is
"just the cost of doing business" does not mean that the CFO of my
favourite ISP agrees.

Dismissing the things that people are actually doing on the network as
solutions to non-problems is, I say, _exactly_ how we got to the point
where NATs are used even when they're not needed, how we got firewalls
that refuse to allow TCP over port 53, and so on.  We can either
listen to those who are proposing to do things, and try to come up
with ways to limit the harm while pointing out the harm that is
thereby done, or we can stamp our little feet and insist that they run
their networks by our rules.  I have little faith that path 2 will work.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 15 Jul 2009 11:34:33 -0700

>crypto protection and make me accept a downgrade attack.

Then use a different DNS resolver. This document is about how to do one type of resolution, not all types.

>DNSSEC is simply wrong.

This is more hyperbole that does not help the discussion. The IETF is not in the position to "not allow" anything, and it never has been. An Informational RFC is not "endorsing" anything.

If you want to endorse not doing what this proposed Informational RFC describes, write such a document and have it on standards track, or BCP.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tony Finch <[email-masked]>
Date: Wed, 15 Jul 2009 19:46:17 +0100

On Wed, 15 Jul 2009, Andrew Sullivan wrote:
>
> Just because I know how to avoid going to phishing and malware sites
> does not mean it is within the competence of the average user.

A better way for ISPs to address that problem is to run an intercepting
web proxy that traps connections to infested web servers. The proxy can
then intercept HTTP requests to malware-carrying URLs. (The UK's IWF
blacklist is often implemented this way.) The intercept can be made
specific to particular ports so it doesn't affect non-web protocols. It is
consistent with what RFC 4084 calls "firewalled internet connectivity".

Even better would be for users to upgrade to a browser that implements its
own safe browsing checks, and which has a decent user interface when DNS
lookups fail. It's probably cheaper for ISPs to provide a local download
site for a supported web browser than to implement a lying DNS resolver.

Tony.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 15 Jul 2009 15:17:21 -0400

At 2:47 PM -0400 7/15/09, Paul Wouters wrote:
>Tell me, what is the goal of this informational rfc?

I can only tell you my goal, and I am not the author. My goal is to describe different types of lying resolvers so that someone can ask "what type of resolver is that, based on the RFC WXYZ langauge?" and get a reply.

>To list common methods
>for not adhering to standards and how to classify them?

That works for me.

>and condemn some
>of them as bad?

That works for me too, although I think it is not that useful to do so in an Informational RFC.

>Some marketing person is going to wave the RFC number and say "It's allright",
>and my saying "But it was only an informational" is not going to make a
>difference.

Oh, please. If you want to re-ignite the period flamewar about what RFCs should and should not be published, that's fine, but don't waste our time here with it. The DNSOP WG has no control over that issue. RFC 2026 is the reference, and repeated attempts to change it have met with failure.

--Paul Hoffman, Director
--VPN Consortium

---

From: Roy Arends <[email-masked]>
Date: Wed, 15 Jul 2009 21:16:06 +0200

> their networks by our rules.  I have little faith that path 2 will  

There is something fundamentally wrong with your statement, besides  
the incredible pedantic remark about stamping our little feet that  
seems to completely dismiss the overall sentiment of the WG. Dare I  
say consensus.

If you want a real analogy, think alternative roots. From the users  
perspective, that is what is happening here: an alternative namespace  
is created. Would we have a discussion at all if this perspective was  
used?

I would like to see some guidance from the WG chairs here. What is the  
next step. In lieu I propose the following: [1] Gauge consensus about  
adopting draft-livingood-dns-redirect-00 as a WG document. [2] if this  
draft is not adopted, we should at least get another work item on the  
list that documents the necessity to preserve the consistency of the  
namespace, adhering to the end to end principle, and educate folk that  
the DNS is not the web.

We might not be able get folks to listen to our stamping little feet,  
but that is just far more preferable then to add to the tragedy of the  
commons and seeing rcode=3 go extinct.

Not that we should sit still and let this one go by. I actually think  
that the effort of writing a new draft might be lesser than the effort  
of trying to change draft-livingood-dns-redirect. I'll wait for  
redirect-01 and decide if its worth spending time on draft-arends-dns- 
response-modification-considered-harmful-00.

Kind regards,

Roy Arends
Nominet UK

---

From: Paul Wouters <[email-masked]>
Date: Wed, 15 Jul 2009 14:47:57 -0400 (EDT)

On Wed, 15 Jul 2009, Paul Hoffman wrote:

> Then use a different DNS resolver.

If I use my own validating stub resolver I can't make it to the portal page.
If I use the dhcp supplied dns server, i cannot securely get to my sites.

> This document is about how to do one type of resolution, not all types.

The document seems to list what it considers tolerable and intolerable DNS
manipulations. My whole point is that no one will ever agree on those
categorisations, and it is easier to draw the line at "no endorsements".

> If you want to endorse not doing what this proposed Informational RFC describes, write such a document and have it on standards track, or BCP.

Tell me, what is the goal of this informational rfc? To list common methods
for not adhering to standards and how to classify them? and condemn some
of them as bad? Who is meant to be informed, and what is the goal of this
information to such a person? Will this person be better able to design
new protocols? deal with the current standards-breaking?

Some marketing person is going to wave the RFC number and say "It's allright",
and my saying "But it was only an informational" is not going to make a
difference. So I can clearly see the abuse of such an informational RFC,
but I have yet to understand who this draft will benefit the community. And
by classifying some DNS rewrites as bad and some as non-bad, this rfc
becomes more then just a bit of information. It becomes an endorsement.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 15 Jul 2009 17:12:35 -0400 (EDT)

> That works for me too, although I think it is not that useful to do so in an Informational RFC.

Then merge Section 7 Practices to Avoid with Section 8 Functional Design
and leave out any (intended or not) judgement on what kind of DNS lying
is to be avoided or tolerated, as there is clearly no concensus on which
to avoid and which to tolerate.

And change the title from "Recommended Configuration and Use of DNS
Redirect" to something like "Recommended Configuration to limit harm of
DNS Redirect", and preface the document with a statement that all DNS
manipulation is error prone, disfunctional with DNSSEC, and better done
in other ways.

> Oh, please. If you want to re-ignite the period flamewar about what RFCs should and should not be published, that's fine, but don't waste our time here with it. The DNSOP WG has no control over tha…

This "informational" is suggesting via the "recommended configuration" to be
a BCP document, not an informational.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Thu, 16 Jul 2009 10:16:50 +1000

In message <[email-masked]>, Paul Wou
> If I use my own validating stub resolver I can't make it to the portal page.

With proper configuration of the validating stub resolver and the
recursive servers your validating stub resolver are using you should
be able to make it to the portal page.

I do agree that it makes it more complicated.

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

---

From: Paul Wouters <[email-masked]>
Date: Thu, 16 Jul 2009 00:41:34 -0400 (EDT)

> I do agree that it makes it more complicated.

With DNS redirection? I can see it with http redirection, but with
my validating resolver, I would only be getting servfails? They
either modify the data and invalidate the signature, or they strip
out the DNSSEC and cause my validating to servfail?

How would this work?

I just wish there was a dhcp option for this. Then we could signal
a landing page, and we could even signal the browser to wait and
not try to reload (and destroy) all my tabs into 20 copies of the
landing page.

Paul

---

From: "George Barwood" <[email-masked]>
Date: Thu, 16 Jul 2009 05:56:20 +0100

----- Original Message ----- 
From: "Roy Arends" <[email-masked]>
..
> perspective, that is what is happening here: an alternative namespace  is 
> created. Would we have a discussion at all if this perspective was  used?

I agree. This document is describing an alternative namespace, and this 
practice is harmful. It should be made clear that the IETF is firmly opposed 
to this practice.

> We might not be able get folks to listen to our stamping little feet,  but 
> that is just far more preferable then to add to the tragedy of the 
> that the effort of writing a new draft might be lesser than the effort  of 
> trying to change draft-livingood-dns-redirect. I'll wait for  redirect-01 
> and decide if its worth spending time on draft-arends-dns- 

+1

I believe that draft-livingood-dns-redirect-00 is fundamentally misconceived 
and wrong.
I oppose it's adoption as a WG document.

"You can put lipstick on a pig, but it's still a pig."

Best wishes,
George Barwood
UK

---

From: Mark Andrews <[email-masked]>
Date: Thu, 16 Jul 2009 14:59:17 +1000

In message <[email-masked]>, Paul Wouter
> out the DNSSEC and cause my validating to servfail?

With portals that are only available to internal servers you are
grafting on namespace and you configure your validator to know about
it and potentially not validate that namespace.

zone "portal.isp.com" {
	type forward;
	forward only;
	forwarders { ISP'r recursive servers; };
};

this is really no different to internal namespace.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 16 Jul 2009 02:14:43 -0400 (EDT)

> this is really no different to internal namespace.

The problem is not resolving portal.isp.com. The problem is that
mail.xelerance.com "resolves" to portal.isp.com, but never makes
it because my validating stub resolver has a DNSSEC key loaded
for xelerance.com. A problem that in the future will become worse
when the majority of the domains (and the root) is signed.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Thu, 16 Jul 2009 16:20:41 +1000

In message <[email-masked]>, Paul Wouter
> when the majority of the domains (and the root) is signed.

	Well if xelerance.com is signed then internal (split dns)
	representations also need to be signed.

	Mark

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 16 Jul 2009 09:15:53 +0200

On Mon, Jul 13, 2009 at 01:59:46PM +0200,
 Roy Arends <[email-masked]> wrote 

> http://www.icann.org/en/committees/security/sac032.pdf

Indeed. Good document. There is no need to discuss about
draft-livingood-dns-lie, all the issues raised here in this WG were
already in the SSAC document one year ago.

I regret one thing with SSAC 032: they mix wildcards in the zone and
lying resolvers. True, they have similarities but also differences
(for instance, wildcards in a zone follow the DNS protocol, and
therefore are compatible with DNSSEC) and I'm a bit tired of Slashdot
discussions starting with "Comcast == Sitefinder".

> http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html

Irrelevant since it talks only about wildcards in the zone.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 16 Jul 2009 09:22:56 +0200

On Mon, Jul 13, 2009 at 12:01:51PM -0700,
 Paul Hoffman <[email-masked]> wrote 
 a message of 17 lines which said:

> Some of the services defined in the draft are highly desired by some
> Internet users.

I did not hear them so this sort of users is obviously not in the
dnsop WG :-) More seriously, noone mentioned here any survey about
this. So, we can just guess and speculate.

If there is really a demand of some users, I have no problem with a
opt-in service, honestly explained to the users ("We will modify
legitimate DNS responses to blacklist some domains, to redirect you to
other sites, if you agree, click here").

---

From: Florian Weimer <[email-masked]>
Date: Thu, 16 Jul 2009 10:08:02 +0200

> URL=http://10.2.3.4/why-we-censor.html" in the additional section.

This would be protocol development, so it's out of the scope of this
WG.  There's also the problem that some folks want to do DNS rewriting
*now*.  If client-side changes are required, they fear that they will
out of business before they are implemented.

(But I agree that a clean solution requires protocol development.)

---

From: Florian Weimer <[email-masked]>
Date: Thu, 16 Jul 2009 10:18:00 +0200

* Paul Hoffman:

> Paul: that's over the top. Some of the services defined in the draft
> are highly desired by some Internet users.

Which ones?

Currently, when a user enters "mcrsoft" in the address bar, many
browsers will automatically send her to the Microsoft homepage.  With
spoofed answers, he reaches some intermediate page instead, which may
or may not be helpful.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 16 Jul 2009 02:40:29 -0400 (EDT)

> 	representations also need to be signed.

I am not talking about internal. I am talking about a single DNSSEC
signed zone that becomes unreachable because I'm behind a hotspot.

this has nothing to do with split DNS and signing internal/eternal zones.

Paul

---

From: Andreas Gustafsson <[email-masked]>
Date: Thu, 16 Jul 2009 11:50:27 +0300

> discussions starting with "Comcast == Sitefinder".

Another difference compared to Site Finder is that while Site Finder
only added wildcards to the zones of certain top-level domains, "web
error redirection" as described in the draft effectively behaves as if
a wildcard had been added to every single zone in the DNS, not just
every TLD but also the root zone and every zone delegated from the
TLDs, including your own zones.  This is indeed not just Site Finder
all over again - it's far worse, and breaks far more applications than
Site Finder did.
-- 
Andreas Gustafsson, [email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 16 Jul 2009 06:37:30 -0400

>this. So, we can just guess and speculate.

I'll speak for my parents here: a DNS resolver that reduces the chance that they'll get a drive-by malware infection is something they would happily use. Having said that, a DNS resolver that gives them a page of search results instead of the browser's error page when they mistype a URL is something the *do not* want because it increases their confusion.

--Paul Hoffman, Director
--VPN Consortium

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 16 Jul 2009 07:08:31 -0400

[As before, my hat is off.  Especially to Roy Arends and Tony Finch.]

On Wed, Jul 15, 2009 at 07:46:17PM +0100, Tony Finch wrote:

> A better way for ISPs to address that problem […]

I am not trying to argue that the proposed solution is right; I am
just pointing out that there is in fact a problem, as is shown by
people trying to do something about it.

On Wed, Jul 15, 2009 at 09:16:06PM +0200, Roy Arends wrote:

> There is something fundamentally wrong with your statement, besides the 
> incredible pedantic remark about stamping our little feet that seems to 
> completely dismiss the overall sentiment of the WG. Dare I say consensus.

I apologise: I'm not trying to suggest anyone here is having a
tantrum.  I assuredly do not wish to cast aspersions on Stephane or
any other participant in DNSOP.  I regard it entirely as a privilege
to participate in these debates, and I have nothing but the deepest
respect for other participants.  I _am_, however, attempting to point
out that there are some people interested in this topic who will think
we are (collectively) having a tantrum.  Hence the "stamping" remark.  I
want to argue, very strongly, that we need to be aware of the audience
of which I am thinking, and be prepared to address their concerns too.
Saying the identified issues are a non-problem is a good way to be
dismissed as foolish purists who can't be taken seriously.  Some of
the use cases in the draft are not completely insane.  I may not agree
with the solution proposed, but I think one needs a better response
than, "The DNS messages are sacrosanct," because we already accept
some violations of the uniform namespace.

> created. Would we have a discussion at all if this perspective was used?

Well, I'd discuss it, anyway.  I know that if someone came with a
document outlining the best way to do split-brain DNS -- which is
widely deployed and an alternative namespace if ever I've seen one --
and especially how _not_ to do it, I would take it to be a serious
contribution.  Similarly, I am listed as one of the authors of the
DNS64 draft, which is (let's face it) a way to configure an
interative-mode resolver so that it consistently replaces one kind of
answer with another kind (or "lies", if you like).  Yet nobody seems
to have thought so far that _that_ is an especially bad idea.

There is a legitimate issue in all this, and it is the deep
philosophical one that Suzanne called out explicitly and to which I
attempted to refer in my review of the draft.  But the issues are
subtle and not just simple things about namespace control and such
like, because we have a lot of deployed systems and because the early
standards documents don't offer anything in the way of definition of
terms like "authoritative" or even, really, "answer". 

Our ultimate response to the proposal in the draft may well be, "It is
a bad idea, and in its own terms here is why."  But I feel very
strongly that a response of, "That's not a real problem," is how we
DNS weenies get to be dismissed as "ivory tower" types who don't
understand how the world works.  We can engage this problem face on
now, or we can charter the DNS-BEHAVE working group in the future.
The draft under discussion is our chance to decide.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 16 Jul 2009 08:07:50 -0400

On 7/16/09 3:22 AM, "Stephane Bortzmeyer" <[email-masked]> wrote:
> You can probably safely assume that any large ISP, as with any large company
> that is relatively deliberate in their service offerings, might choose to
> conduct usability studies, focus groups, and other user surveys prior to
> introducing such services...
> 
          > opt-in service, honestly explained to the users

         Actual consumer behavior doesn¹t really seem to work that way, but
I¹m not a behavioral psychologist.  ;-)  FWIW, I think most ISPs that
introduce such services see around a 0.1% opt-out rate.

Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 16 Jul 2009 08:16:14 -0400

>> > I'll speak for my parents here: a DNS resolver that reduces the chance that
>> they'll get a drive-by malware
>> > infection is something they would happily use. Having said that, a DNS
>> resolver that gives them a page of
>> > search results instead of the browser's error page when they mistype a URL
>> is something the *do not* want
>> > because it increases their confusion.
> 
> IMHO malicious bots are an extremely concerning problem, and the problem of
> bot infections is much more widespread than many people realize.  I¹m in the
> early stages of contributing to a bot-related draft at
> http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-00 in case
> anyone is interested in providing private feedback (haven¹t really found a WG
> appropriate for the work).
> 
> Jason

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 16 Jul 2009 08:17:40 -0400

Folks,

I'd like to see descriptions of the major isp-initiated intercepts:

o cn's provisioning of a name space that includes two entries not 
present in the iana root (ok, this may be less of a dynamic re-write 
feature),
o idns's provisioning of name spaces with "idns",
o other actors provisioning of name spaces with "other stuff" (new.net 
and its cognates),
o vendor intercepts where (apparently) non-cached data is (apparently) 
pre-replaced with monitized data (ask for google, get google, ask for 
odd, get ppc, repeat twice to get odd instead of ppc),
o ...

Descriptions. Discussion of incoherence issues. Author-of-dork-asserted 
necessity-and-value.

I also want to point out to recursive resolver opeators that there is a 
vehicle for policy development at ICANN, the ISP Constituency, which to 
date is simply been where major ISPs clutter up the landscape with their 
trademark lawyers and ignore all operational issues other than 
trademarks in the DNS. I'm always happy to learn what TimeWarner's 
trademarks portfolio manager's views are, but those happy moments have a 
home in the Intellectually Property Constituency and need not elbow all 
the operator issues out to ... the security and stability box of 
last-responders.

Eric

Livingood, Jason wrote:
> http://tools.ietf.org/html/draft-livingood-dns-redirect-00, before the 
> –00 cutoff on Monday, and it will be discussed in the DNSOP WG meeting 
> at IETF 75 (it is listed on the agenda).
>
> If anyone is interested and has time before IETF 75, I’m happy to take 
> feedback before then obviously. Please note that there is a list of 
> open items at the end, which we plan to address in subsequent versions.
>
> Regards,
> Jason

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 16 Jul 2009 14:20:45 +0200

On Thu, Jul 16, 2009 at 08:07:50AM -0400,
 Livingood, Jason <[email-masked]> wrote 
 a message of 76 lines which said:

> FWIW, I think most ISPs that introduce such services see around a
> 0.1% opt-out rate.

What does it prove? Most ISP that introduces lying resolvers as an
opt-in service see a 0.1 % opt-out rate, too. It proves only that most
users do not dare to change the settings or are not informed or have
no time to play with settings.

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 16 Jul 2009 08:31:01 -0400

> draft-livingood-dns-lie,

Is that really necessary?

> all the issues raised here in this WG were

Indeed.  **However,** the SSAC document seems to me to speak to TLD
operators and registries, not ISPs.  To wit, please refer to page 16,
Preliminary Recommendations.  With the exception of recommendation #4, these
appear to me to all be related to actions by registrars and TLD operators.

And Preliminary Recommendation #4 states that "Third parties [defined in the
paper to include ISPs] should disclose that they practice NXDomain response
modification and provide opportunities for customers to opt out."

You may wish to note that I expand at length on this preliminary
recommendation from the SSAC paper in my draft.
 
Regards,
Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 16 Jul 2009 08:32:49 -0400

> all over again - it's far worse, and breaks far more applications than

Please do send me that list of applications.  I would very much like to
describe these use cases in the next version of the draft.

Thanks
Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 16 Jul 2009 08:43:52 -0400

> no time to play with settings.

With respect, I am not trying to "prove" anything.  I am merely providing
data which you and others may find interesting and which may just inform
debate a tiny bit. 

In terms of notifying users, I agree that this is important, and that
settings (opt-out and opt-in) should be both easy to use and not take much
time.  I believe we even describe this in some detail in the draft, and I am
happy to take specific feedback on those areas, as I would be delighted to
be able to use your and others feedback to improve them.

Thanks
Jason

---

From: Tony Finch <[email-masked]>
Date: Thu, 16 Jul 2009 15:31:18 +0100

> (But I agree that a clean solution requires protocol development.)

No, it just requires browser user interface improvements.

Tony.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 16 Jul 2009 16:34:29 +0200

> No, it just requires browser user interface improvements.

If you want to address the issue with hotspot doorway pages, you need
protocol changes.

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 16 Jul 2009 14:43:49 +0200

> describe these use cases in the next version of the draft.

Please list "The Internet" as one of them, it kinda encompasses a lot of
others too. I am *VERY* happy that DNSSEC is moving along perfectly fine
which will kill any kind of changing DNS results.

Just a little example that even clued operators(*)  get it wrong:
https://lists.dns-oarc.net/pipermail/dns-operations/2009-July/004217.html

Btw it also does it for IPv4 IPs:
$ dig +short @208.67.220.220 127.0.0.1
67.215.65.132
$ dig +short @208.67.220.220 1.2.3.4
67.215.65.132

For that matter when the Internet in general gets too filtered by the
ISPs in the middle, people will start using other methods.
Crypting&signing data to avoid modification will be the first steps.
Those kind of applications, like BitTorrent which is a great example
will rise outside of any IETF and get deployed and there is nothing that
an ISP will be able to do about it unless they wall-garden the whole
thing to just allow direct talking to specific servers and nothing else,
but that won't be the Internet anymore of course....

Greets,
 Jeroen

* = IMHO OpenDNS folks are doing a good job and they definitely know
about the technical problems/challenges involved in the service they are
providing, but they, like everybody else, are simply unable to catch all
problems and foresee how applications (mis)use the DNS.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 16 Jul 2009 16:37:12 +0200

* Jason Livingood:

>          Actual consumer behavior doesn¹t really seem to work that
> way, but I¹m not a behavioral psychologist.  ;-) FWIW, I think most
> ISPs that introduce such services see around a 0.1% opt-out rate.

I would expect a higher rate of Dnschange/Zlob infections at a typical
U.S. ISP.  IOW, the 0.1% number doesn't seem to include users who just
use some external DNS service.

Anyway, for many users, the browser interface really doesn't change
much.  That's why it's hard for me to believe that this is done to
improve user experience.

---

From: Tony Finch <[email-masked]>
Date: Thu, 16 Jul 2009 15:45:29 +0100

> If you want to address the issue with hotspot doorway pages, you need

Better to use an intercepting proxy in that case, and for quarantining
infected hosts.

Protocol changes aren't sufficient because if you just extend DNS
without adding restrictions then cunning people can obtain connectivity
via your resolver.

I think these cases are qualitatively different from the main goal of this
draft. A captive portal completely blocks normal connectivity, whereas
this draft talks about selective blocks.

Tony.

---

From: David Conrad <[email-masked]>
Date: Thu, 16 Jul 2009 09:07:03 -0700

On Jul 16, 2009, at 5:43 AM, Jeroen Massar wrote:
> others too.

Please.  Enough hyperbole.

> I am *VERY* happy that DNSSEC is moving along perfectly fine

DNSSEC doesn't touch anything after the validator.  It will have no  
effect on the vast majority of Comcast (or other consumer oriented)  
ISPs' customers.

Regards,
-drc

---

From: Suzanne Woolf <[email-masked]>
Date: Thu, 16 Jul 2009 16:14:38 +0000

> is created. Would we have a discussion at all if this perspective was  

Yes, we would.

Well, maybe not "we" who have been contributing to this discussion on
this list. But I've observed that telling people something they want
to do is "evil" doesn't really help them decide not to do it. Telling
them what harm will be done, or telling them that there's a better way
to accomplish their business or operational objectives, is often more
productive.

I find myself in discussions of alternate roots on a regular basis.
The most effective ones neither begin nor end with anyone being
accused of anything except trying to meet legitimate objectives by the
most effective means available. I'll go further and say that most of
the time, they'd even prefer to minimize harm to others along the
way. Even when the discussion is a disguise for an extortion play
("Give us what we want or we'll take our toys and go home"), asserting
that the subject is not even to be raised merely gives it more power
as a threat.

Some people are going to read an informational RFC documenting use
cases and mechanisms for DNS redirect as endorsement by the IETF. I
submit, however, that the same people were going to do it anyway,
probably in ignorance that there was any particular downside to it or
really with any more knowledge about it than they get from their
vendors.

> namespace, adhering to the end to end principle, and educate folk that  

All important points, and all belong in a discussion of the downsides
of DNS redirect.

> response-modification-considered-harmful-00.

I hope redirect-01 is more strictly descriptive and can drop defensive
terms for DNS redirect, like "enhancement" of the "user experience",
since it's by no means agreed that crippling DNSSEC (for example)
enhances the value of the Internet for anyone.

(My defense of the draft is by no means to be read as endorsing DNS
redirect. I don't, for reasons I believe are so compelling that I'm
willing to try to work with others to articulate them and let people
decide for themselves.)

---

From: Paul Wouters <[email-masked]>
Date: Thu, 16 Jul 2009 13:27:54 -0400 (EDT)

On Thu, 16 Jul 2009, David Conrad wrote:

> DNSSEC doesn't touch anything after the validator.  It will have no effect on 
> the vast majority of Comcast (or other consumer oriented) ISPs' customers.

Fedora 12 is slated to run with a validator on every machine. I would
not be surprised if OSX and Microsoft go in the same direction. And the
reason for that move is precisely because the enduser cannot distinguish
malicious DNS modifications and beneign DNS modifications. So it is
better to accept none.

We are looking at how to resolve the DNS portal issues and non-dnsssec
aware resolvers in the forwarder chain. There are some ideas that need
more attention and thoughts.

Paul

---

From: Florian Weimer <[email-masked]>
Date: Thu, 16 Jul 2009 20:12:05 +0200

> Better to use an intercepting proxy in that case, and for quarantining

Doesn't work if the user uses the employer's filtering proxy for web
access.

> without adding restrictions then cunning people can obtain connectivity

This would have to be part of DHCP, I think.  DNS s too late.

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 16 Jul 2009 20:43:49 +0200

> Please.  Enough hyperbole.

Unless you state that "The Internet" is only "The Web", there are other
users of "The Internet" though. Don't try and limit what other people
can do with this public resource.

I suggest that "Internet Providers" that are going to do these kind of
"filtering techniques" rename themselves to "Limited Web Providers".
That is much more appropriate it seems.

Or we'll just have to change IETF into OIETF for the Open Internet ETF.

> effect on the vast majority of Comcast (or other consumer oriented)

"The vast majority" aha, so discrimination of the people who do want to
actually have real truthful Internet is acceptable????

I know that certain countries claim to be all about 'freedom' and
'democracy' and I don't know what, but clearly those countries and the
network operators in those countries want to restrict people more than
the countries which simply state that they are doing that on purpose.

As a user of the Internet I *am* running a validating DNSSEC recursor on
my hosts. Thanks to ISC for the DLV :)

I am fairly sure that a lot of other people will also want to do this.

Greets,
 Jeroen

---

From: Tony Finch <[email-masked]>
Date: Thu, 16 Jul 2009 20:10:07 +0100

> Doesn't work if the user uses the employer's filtering proxy for web

I don't see why not, but even so, if they're already using a filtering
proxy they are already safe, and the proxy is responsible for handling
DNS lookup failures.

Which reminds me, another way to solve this problem is using a proxy
auto-config file.

Tony.

---

From: David Conrad <[email-masked]>
Date: Thu, 16 Jul 2009 12:49:38 -0700

> can do with this public resource.

Could we ratchet down the rhetoric?

DNS redirection does not break the Internet.  DNS redirection can  
result in unanticipated responses.  Some applications can behave in  
sub-optimal ways in the face of these unanticipated responses.  This  
is a far cry from breaking "the Internet".

As far as I can tell, Comcast's network and their recursive servers  
are not a "public resource".  As folks on Comcast's network are not  
forced to be Comcast's customer nor (as far as I know) are they  
required to use Comcast's name servers, I don't see where you, this  
working group, or the IETF has a right to determine what Comcast does.

The point Andrew tried to make is that the lesson we (should have)  
learned with NAT is that folks are going to deploy technologies that  
some may consider ill-advised or impure or "evil" or whatever if they  
find it to be in their interests to do so, regardless of what this  
working group or the IETF may say.  In order to limit the  
proliferation of 'solutions', it is in the best interests of operators  
to standardize on an agreed upon approach and document the  
implications of that approach (both positive and negative) to ensure  
everyone understands what they're doing.  Blocking these efforts  
resulting in various broken ways of doing the same thing are far more  
detrimental to the Internet than the existence of the standardized  
solution.

> actually have real truthful Internet is acceptable????

Might I suggest switching to decaffeinated?

My statement is merely the truth.  The vast majority of consumer  
oriented ISPs supply the DNS resolver settings to their customers.  As  
such, validation would occur prior to the insertion of redirected  
responses.  The exceptionally few applications that try to do  
validation on their own are so far in the noise as to be irrelevant.

> I am fairly sure that a lot of other people will also want to do this.

A little perspective please.  I'm fairly sure that you and everyone  
else who runs a validating DNSSEC recursor on their host are an  
infinitesimal minority of Internet users.

More to the point, DNS redirection does not imply running your own  
recursor is disallowed.  Yes, it can be implemented in such a way as  
break running your own recursor, but if this occurs, the right answer  
is to vote with your feet.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Thu, 16 Jul 2009 12:58:28 -0700

On Jul 16, 2009, at 10:27 AM, Paul Wouters wrote:
> Fedora 12 is slated to run with a validator on every machine.

This is the right direction to go.

> I would
> not be surprised if OSX and Microsoft go in the same direction.

I would be.  Quite.

> And the

Except for most users, accepting none means "the Internet is broken"  
which will result in ISP or OS vendor support calls which will  
undoubtedly result in users being instructed to turn off validation  
(like they get told to turn off IPv6 today).

> more attention and thoughts.

Yep.  It is annoying to have to stop using my local (validating)  
resolver any time I use T-Mobile hotspot service.  I've given up using  
T-Mobile hotspot (where possible) for precisely that reason.

Regards,
-drc

---

From: Jim Reid <[email-masked]>
Date: Thu, 16 Jul 2009 21:30:21 +0100

> (like they get told to turn off IPv6 today).

OTOH, one might hope that if customer support got flooded with such  
calls the message that Tampering With DNS Responses Is A Very Bad  
Thing would eventually get through to those responsible for that  
behaviour and they'd take action to stop doing that. I can dream,  
can't I?

BTW, almost all of the scenarios in Section 5 of draft-livingood-dns- 
redirect-00 are concerned with browser activity and HTTP redirection.  
So it seems to be wrong to (ab)use the DNS to solve what looks like a  
web problem. That appears to be a layering violation. I'm not sure  
it's wise to document DNS redirection as a BCP. [DNS redirection may  
well be a current practice, but is it a best practice?] I think this  
draft's next iteration should say a *lot* more about the dangers of  
fiddling with DNS data, particularly in the context of the impact on  
Internet applications that are not web browsers.

---

From: David Conrad <[email-masked]>
Date: Thu, 16 Jul 2009 13:58:02 -0700

Jim,

On Jul 16, 2009, at 1:30 PM, Jim Reid wrote:
>> Except for most users, accepting none means "the Internet is  
>> broken" which will result in ISP or OS vendor support calls which  
>> will undoubtedly result in users being instructed to turn off  
>> validation (like they get told to turn off IPv6 today).

Sure, but I was talking about was doing DNSSEC in a local resolver in  
the general case, not DNS redirection.

> redirect-00 are concerned with browser activity and HTTP  
> redirection. So it seems to be wrong to (ab)use the DNS to solve  
> what looks like a web problem. That appears to be a layering  
> violation.

Sure.  I would agree with those who argue that DNS redirection is the  
wrong answer, pretty much regardless of what the question is. However,  
I'd prefer to have _one_ wrong answer instead of a myriad slightly  
different wrong answers.  If you have a single wrong answer, you have  
a much better chance of being able to programmatically get around it.

Regards,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Fri, 17 Jul 2009 14:20:02 +1000

> to have thought so far that _that_ is an especially bad idea.

The big difference is that you still ultimately go to the machine
that you are looking up.  You are not changing the namespace by
adding or removing names.  Additionally the amount rewriting of
AAAA queries will reduce over time as the world moves to IPv6.
There is very little collateral damage being done by DNS64.

There is a lot of collateral damage when you map NXDOMAIN/NXRRSET
to a search page.

Mark

---

From: "Antoin Verschuren" <[email-masked]>
Date: Fri, 17 Jul 2009 10:46:47 +0200

> David Conrad

I tend to disagree with you here.
If Comcast is selling it's service as "Internet service" the general public might think that that's the way it should work, and we would all suffer from that general public's perception. If it would break some applications, a general user would think that the application is broken, not "The Internet" as offered by Comcast. So application builders will design their products to work on the "broken" Comcast network, or go bankrupt.

I'm actually thinking that we are fighting this war on a wrong battleground.
Just because DNS is wrongly considered to be the easiest hammer doesn't mean it fits every nail.

I very much see the benefits of protecting innocent users from the bad of the Internet.
But if it's web pages that are the bad thing, fight that.
I'm very much in favor of writing a 
draft-arends-dns-response-modification-considered-harmful-00
I'll explain further on.

At the same time, if I had enough knowledge of http(s), I would even want to contribute to a draft
draft-verschuren-http(s)-intercept-and-redirect-00
Because I think that is the right battleground for this.
I don't know where such a discussion should take place though, but certainly not here.

So for harmful content of web pages, intercept and redirect http(s) traffic.
For unclear errors in browsers when typos are made, fix the browsers.

I'll explain where I see the conflicts.
The "Internet" has gone above a technical definition.
It's considered a brand name or at least a steady concept. (forgive my searching for the correct term as non-native speaker)

The same is true, or even more, for domain names.
TLD's and domain owners consider their domains as brand names, and might fight if somebody is affecting their autonomy.
Since the game that's being played here is not about technology but about dollars, image, politics and policy, consider where this fight might end.

The suggestion I'm making is not one I favor, but just as an indication of where the DNS redirection path might end:
If ISP's start to mess up the authoritative answers for my TLD, I might consider protecting my brand name with a split view on my TLD.
One view for "proper" resolvers, with real answers and NXdomains.
The other view would be for "lying" resolvers where I would enter a wildcard so that my "brand name" TLD would show a proper error message without adds, preferred search engines or harmful content instead of the one from the lying resolver. I would do this to protect the image of the TLD as being a "safe" TLD to register your name in. It would protect my TLD against redirects that are not considered "appropriate" for the image or local policy under my TLD.
I would make a blacklist of resolvers I know are lying, and redirect them to the wildcard view of the DNS infrastructure.
This might even be imposed by ignorant local governments.

This would be a war without an end, so again, I don't want to go this path.
It will be a war between the ones with power and the ones with money, and in the end, it does not help the "Internet" user.

So please, if harmful web content is the problem, fix that. Perhaps we need a screwdriver instead of a hammer.
If unclear error messages in browsers are the problem, fix that. Perhaps we need a saw instead of a hammer.

The dollars against politics war is one we're not going to win on instable technical solutions.

Antoin Verschuren

---

From: Andreas Gustafsson <[email-masked]>
Date: Fri, 17 Jul 2009 12:12:42 +0300

> describe these use cases in the next version of the draft.

No one said anything about a list.  I'm merely making the general
point that the more zones affected, the more applications affected.
But to give one concrete example, DNS-based blacklists and whitelists
will be impacted as they rely on NXDOMAIN responses to indicate that
an address or name is not listed.
-- 
Andreas Gustafsson, [email-masked]

---

From: Jim Reid <[email-masked]>
Date: Fri, 17 Jul 2009 11:10:28 +0100

> an address or name is not listed.

To give another, Internet Explorer uses NXDOMAIN responses to do a  
google search of what was in the browser bar and display the results  
of that search IIUC. This is equally as evil IMO as doing DNS  
redirection and sending the user to some ISP-supplied landing page.  
There's no need to explore this rat-hole. so please don't. The point  
here is that DNS redirection breaks the default, expected behaviour of  
a very commonly used application because the browser no longer sees  
NXDOMAIN.

---

From: Jim Reid <[email-masked]>
Date: Fri, 17 Jul 2009 11:22:26 +0100

> describe these use cases in the next version of the draft.

Yet another example. Many mail servers (including mine) reject SMTP  
connections from hosts that don't have reverse DNS. That's usually a  
strong indicator of a likely spam source. If some DNS redirector  
changes those NXDOMAIN/NOHOST responses to something else, those mail  
servers will accept inbound mail from places they wanted to reject.

Many anonymous FTP servers behave(d)this way too, at least in the pre- 
web era. IIRC, some of the most useful/popular FTP servers did this to  
encourage people to fix their reverse DNS setup.

---

From: Eric Brunner-Williams <[email-masked]>
Date: Fri, 17 Jul 2009 08:10:37 -0400

> I tend to disagree with you here.

I would be happy with some statement that the use of unique identifiers 
created by the IANA function, and delegated to parties which in turn 
delegate these assets to network operators, in particular AS numbers and 
address space, have some policy restrictions. I don't know what they 
are, but if operator X doesn't use directly, or consume transit that 
does use those assets (back to the pre-CIX world), then the conduct of 
operator X is not inherently subject to the union of policies of 
upstream providers, and ultimately, the policy associated with the IANA 
function. Note, I'm not asserting the existence of a policy exercised 
presently by the IANA function, only the possibility. In my fantasy life 
I'd like to see BCP38 mandatory, and the BGP trusted-chain-of-delegation 
rooted.

We have rfc1918 for "private" spaces. I wouldn't first appeal to the 
"general public perception" argument, though Antoin does point out in 
the same para (below) that the issue may not be "are operator X's 
facilities a public resource", but the market power of operator X to 
restrict third parties from offering services to operator X's 
subscribers. Note, "market power" is a local matter, applicable to the 
operator used as an example.
> This might even be imposed by ignorant local governments.

This idea has been discussed by others in the context of TLDs with 
"local scope", the largest examples of these are as you mention, 
associated with national governments which may impose, for local policy 
reasons, two or more "views" on a name space.

> If unclear error messages in browsers are the problem, fix that. Perhaps we need a saw instead of a hammer.

Years earlier I considered mechanisms to distinguish verifiable data 
collection practice assertions on HTTP cookies, so that jurisdictions 
(the FTC in the US, the data protection authorities in the EU member 
states, etc.) could "police" what in this conversation I'll call "lying 
cookies", where the "lie" covers not only the data collection policy 
asserted, but also the scope of the name space(s) for which the 
assertion was offered.

I'd like to see -dns-redirect- go forward, more or less for the same 
reasons Suzanne gave, and 
-dns-response-modification-considered-harmful-, as well as a 
-http(s)-intercept-and-redirect- .

However, I don't think there is sufficient public discussion of the 
underlying motivation, the details of the PPC business. In the ICANN 
policy arena the marks interests, eager to stamp out "lying resolution" 
at the lie-exists-in-published-string-space level, overlook the 
motivation of presumably rational economic actors, who manage portfolios 
of domain names, in aggregate, running well into the millions, mostly in 
the pre-ICANN name spaces. In the DNSOP policy arena (here) we're 
discussing "lying resolvers" at the lie-exists-in-resolvers level, and 
we can't be much smarter about why, not just how, what is asserted to be 
a problem exists, we may end up just as limited in our utility as the 
those lawyers.

So, if anyone wants to share PPC facts, I propose a -mumble-ppc-mumble-, 
to inform us, drop me a note or catch me at Stockholm.

> -----BEGIN PGP SIGNATURE-----
> Version: 9.6.3 (Build 3017)
>
> wsBVAwUBSmA6dzqHrM883AgnAQhTqggAsrRaGi/ZPuJ7ZnKUYtaKdxz7iaeyi2nU
> nCT/YXI4w/OudjyRapMmTvKGgb2tmGnN1nEPUXnwraDGV628HkqU/GJG6AwTq8X+
> k3S7YGC5MUjgUVG/O1fux7oSMY4YmHhMngJWpBzhsAosA1yRtAGW/9iKZTs01t1S
> hYWssFkjLh+MGNn2t+FD93p8HsY4fiYcO2QZh8KZOTHPMCeezyni+ODxEMftbD+L
> aQLk8Hw/xJEf3TIfR8NE1csL+jV32yWKBFAebjq3+cNtGgH7eHRHuetHjxl2L5nW
> X3NK+zHswu9vvckmg5mTAoJ5u188Hgv2njS0DKFe8YdUKNK0DgNoVg==
> =ib4t
> -----END PGP SIGNATURE-----
>

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 17 Jul 2009 09:05:26 -0700

>discussions starting with "Comcast == Sitefinder".

I noticed this as well. Can someone from SSAC discuss here why that is the case? It is fairly relevant to this thread, given that a few people have wanted to see SAC032 discussed in the draft, but it doesn't seem relevant because of the difference.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 17 Jul 2009 09:04:20 -0700

At 8:16 AM -0400 7/16/09, Livingood, Jason wrote:
> > I'll speak for my parents here: a DNS resolver that reduces the chance that they'll get a drive-by malware
>> infection is something they would happily use. Having said that, a DNS resolver that gives them a page of
>> search results instead of the browser's error page when they mistype a URL is something the *do not* want
>IMHO malicious bots are an extremely concerning problem, and the problem of bot infections is much more widespread than many people realize.  I'm in the early stages of contributing to a bot-related draft at <http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-00>http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-00 in case anyone is interested in providing private feedback (haven't really found a WG appropriate for the work).

I hope that redirection is not an indicator that the -01 draft will continue to talk about the two scenarios as if they are somewhat equivalent.

>enhances the value of the Internet for anyone.

+1. You can talk about why you are doing what you are doing without making it seem that the positive values are going to be be worth the negative side-effects.

--Paul Hoffman, Director
--VPN Consortium

---

From: John Schnizlein <[email-masked]>
Date: Fri, 17 Jul 2009 12:55:37 -0400

Along with these good suggestions, the next draft should include a  
brief description of why the desired behavior (as seen by the user) is  
better performed through DNS tricks than through HTTP tricks.

John

On 2009Jul17, at 12:04 PM, Paul Hoffman wrote:

>>> I'll speak for my parents here: a DNS resolver that reduces the  
>>> chance that they'll get a drive-by malware
>>> search results instead of the browser's error page when they  
>>> mistype a URL is something the *do not* want
>> IMHO malicious bots are an extremely concerning problem, and the  
>> problem of bot infections is much more widespread than many people  
>> realize.  I'm in the early stages of contributing to a bot-related  
>> draft at <http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-00 
>> >http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-00  
>> in case anyone is interested in providing private feedback (haven't  
>> really found a WG appropriate for the work).
>
> I hope that redirection is not an indicator that the -01 draft will  
> continue to talk about the two scenarios as if they are somewhat  
> equivalent.
>
> +1. You can talk about why you are doing what you are doing without  
> making it seem that the positive values are going to be be worth the  
> negative side-effects.
>
> --Paul Hoffman, Director
> --VPN Consortium

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 17 Jul 2009 10:02:15 -0700

Jason, et al,

This note suggests changes in both style and detail in
draft-livingood-dns-redirect-00.  All of the points made here have been made or
suggested by others in this thread; my intent is to underscore and elaborate on
those points, rather than to challenge development and publication of the draft.
  I’ve seen enough postings to convince me that there actual is existing practice
with significant deployment. The goal of the draft is to document that behavior.
  Debating whether the mechanism is ever reasonable or appropriate to deploy –
and what alternatives might be more reasonable and appropriate might be
productive, but not as part of the current exercise.  The current exercise is
one of technical specification.

Given the coincidental timing, however, it’s worth citing a paper being
presented at the CEAS conference today:

    Anti-Phishing Landing Page: Turning a 404 into a
    Teachable Moment for End Users

    <http://ceas.cc/papers-2009/ceas2009-paper-37.pdf>

A few specific points:

As with others, I think the draft needs to remove its promotional, persuasive or
legalistic vocabulary.  It’s a technical document, attempting to specify
existing practice. So it should focus on technical details and operational
trade-offs, without trying to sell the reader or protect against lawsuits.  When
the document recommends a particular choice, it should simply use RFC 2119
vocabulary.  To the extent that there are tradeoffs, simply state what they are
and which one(s) the document prefers (and possibly in what context.)  That is,
what technical or operational characteristics provide the basis for a particular
recommendation?

The long thread of discussion on the dnsop list has cited a  number of
alternative mechanisms for accomplishing the same, or similar, goals as the one
described in the draft.  To properly establish the context for use of this
particular mechanism, the draft should diligently include all of these in its
discussion of background, choices and tradeoffs.  Not to debate the
alternatives, and not to provide an extensive tutorial, but to explain the
pragmatic reasons that the mechanism being specified is (regularly?) chosen in
preference to those alternatives.

The thread discussion has also produced references to a small, but very
interesting, set of RFCs. These documents provide a rich background of relevant
material; so the draft should carefully include each of these citations and
discuss them in terms of the draft.  Besides being basic due diligence, such a
discussion might mitigate some people’s concerns about the mechanism specified
in the draft.

The draft’s discussion about the presence of DNSSec contains a nice case
analysis of various configurations and scenarios, explaining how the mechanism
works within each scenario.  However it is easy to miss a key fact that the
draft should provide in a simple, summary statement:  When DNSSec validation is
performed by the user’s resolver, this mechanism will fail. While the user will
be denied access to the potentially problematic address, they will not not land
at the alternative address.  That is, this mechanism has long-term viability
only when a user’s resolver does not implement DNSSec and, instead, relies on
their operational infrastructure to validate DNS data.

The draft specifies a mechanism that appears to work properly only for a single
application service, namely the Web. Yet it characterizes all other services as
exceptions.  Instead, the draft should cast the mechanism as intended only for a
single application and should provide substantive discussion about either how
other services will continue to operate or why disrupting them is acceptable.
This discussion is really the basis for understanding when the mechanism can be
practical to deploy and when it cannot.

A deeper issue:

The draft demonstrates some confusion about the architectural role of the
service it is specifyhing.  Various postings on the mailing list discussion have
offered a variety of alternative labels to refer to the mechanism; this serves
to highlight the potential for misunderstanding what the specified service
really is and when it is really reasonable to use.  This could be caused by a
pervasive confusion about the model for DNS service that this draft is affecting.

A cliché in the technical community is that the only lesson of the Internet is
scaling.  While scaling to the level of a global Internet does teach quite a
lot, its lesson does not seem to be as challenging as that of mediation.
Networking is about mediated exchange.  At every level, and for nearly all
services, mediation mechanisms come into play: Between two principals, there are
typically agents in the path, providing assistance. Some assistance is simply
routing and forwarding.  Other assistance plays with the payload.  Assistance
can be supplied by an agent of one of the principals – that is, at one end of
the path –  or by an independent operator along the path.  These are important
differences.

IP routers and email relays, for example, route and forward an object (and its
header) without modifying either.  NATs, v4/v6 gateways and email gateways dive
into the object (and its header) and make substantive – semantic – changes.
Changing the endpoint identifier – that is, specification of the target address
– is a major change, every bit as much as changing the “content”. The draft
specifies a mechanism that does both.

DNS vocabulary uses the word “resolver” to refer to one of the end-points and
potentially one or more of the mediators in an exchange.  This can be confusing.
Equally, the term “redirect” is historically used to refer to a response by a
principal, to specify an alternative address for the desired information. In
contrast, in the draft, the term is used by 1) an intermediary,  2) to change
the underlying nature of the provided information.  As such, the mechanism is
not a “resolver”.  It is something else.

In other words, the nature and details of the specified mechanism are quite
different than what its terminology is typically used for.  So I suggest
changing the vocabulary and discussion, to avoid the confusion. Getting a usable
term that is both noticeably different from “resolver” and meaningfully
descriptive appears to be a challenge.  “Intercept” is tantalizing but
semantically inaccurate.  “Proxy” might be the best compromise term, since other
proxies tend to do translations, too.  Personally, I’d wish for a word that is a
little more striking, since the function is striking, but “proxy” is the best
I’ve been able to come up with.

What is essential is to make sure that the label does not permit one to think
that this module is anything like a normal resolver.

As with others, I suspect it is important to have the document more strongly
distinguish between modified behaviors that occur because a government requires
it, versus those triggered by some sort of blocklist, versus a simple NXDomain
response.  While the draft already cites these distinctions, I suspect there are
design and/or operational differences for the different cases.  At the least,
the potential for differential handling should be discussed.  If they all result
in the same processing, that should be explained.

Most importantly, the specification needs to characterize the environments in
which it can be successfully deployed, versus others whereas it cannot.  My
current understanding is that the mechanism can work acceptably only in walled
gardens (edge networks), where the operator has defined a substantially
constrained user environment.  In such places, email and other services are
highly mediated by the operator.  So the describee mechanism does not get in
their way. Being clear about the pragmatic constraints that are required appears
to be an interesting challenge for the paper.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 20 Jul 2009 12:37:32 -0400

Great feedback, Dave.  Thank you and we¹ll take it into account as we work
on a revision.

Jason

On 7/17/09 1:02 PM, "Dave CROCKER" <[email-masked]> wrote:

>   I¹ve seen enough postings to convince me that there actual is existing
> practice
>   Debating whether the mechanism is ever reasonable or appropriate to deploy 
> Given the coincidental timing, however, it¹s worth citing a paper being
> legalistic vocabulary.  It¹s a technical document, attempting to specify
> discussion might mitigate some people¹s concerns about the mechanism specified
> in the draft.
> 
> The draft¹s discussion about the presence of DNSSec contains a nice case
> performed by the user¹s resolver, this mechanism will fail. While the user
> will
> only when a user¹s resolver does not implement DNSSec and, instead, relies on
> can be supplied by an agent of one of the principals  that is, at one end of
> the path   or by an independent operator along the path.  These are important
> differences.
> 
> into the object (and its header) and make substantive  semantic  changes.
> Changing the endpoint identifier  that is, specification of the target
> address
>  is a major change, every bit as much as changing the ³content². The draft
> DNS vocabulary uses the word ³resolver² to refer to one of the end-points and
> Equally, the term ³redirect² is historically used to refer to a response by a
> not a ³resolver².  It is something else.
> 
> term that is both noticeably different from ³resolver² and meaningfully
> descriptive appears to be a challenge.  ³Intercept² is tantalizing but
> semantically inaccurate.  ³Proxy² might be the best compromise term, since
> other
> proxies tend to do translations, too.  Personally, I¹d wish for a word that is
> a
> little more striking, since the function is striking, but ³proxy² is the best
> I¹ve been able to come up with.
>

---

From: Rob Austein <[email-masked]>
Date: Sun, 26 Jul 2009 13:32:26 +0200

Having just gone through this entire thread again as prep for
tomorow's WG meeting, I have a few minor comments that attempt to
answer a few of the dangling questions:

1) Stephane is correct that 

   is talking about wildcards rather than redirect, but is (IMHO)
   wrong that in saying that this makes it irrelevant.  That document
   includes a non-exhaustive list of things that were seen to break
   when RCODE 3 responses suddenly turned into redirections to an
   unexpected location.  While the mechanism involved was different,
   many of the effects are the same regardless of the mechanism, so
   that list may provide a partial answer to Jason's request for
   information about things that redirection hacks break.

2) Without getting into whether one -should- do any of this, I don't
   think the DNSSEC "workaround" for validating stub resolvers even
   "works" (please don't give me a hard time about that word in this
   context) at a technical level.  Others have hinted at this but not
   stated the reason, so, at least for Jason's benefit, here it is:
   unless I'm confused, this hack only "works" if the redirector
   strips off -all- DNSSEC data in -all- traffic to this resolver and
   replaces it with its own.  In other words, this hack pretty much
   requires sign-on-the-fly for all DNSSEC traffic, which is unlikely
   to scale well.  It also reduces the entire function of DNSSEC in
   this context to a weird and not very efficient form of channel
   security, and it seems unlikely that anyone would choose to get
   channel security this way.

3) As far as I can recall there is no explicit prohibition against
   modifying DNS data in transit in any standards track RFC, but
   there's something pretty close in an RFC old enough that it
   predates the current standards process.  See RFC 973, specifically
   the section "Making up data".  It doesn't talk about DNS redirect
   per se, but the overall intent seems reasonably clear (YMMV).

--Rob