Subject: [dnsext] need new flag bit in EDNS, "do me no favours" (DMNF)

From: Paul Vixie <[email-masked]>
Date: Sun, 24 Oct 2010 16:52:01 +0000

i'm thinking we need a flag bit in edns to allow a client to opt out of
things like "web error redirection" (dns ad insertion).  the semantics
of it would just be, if server policy allows "clear path" dns for this
query, then the server is requested to provide same.

if server policy does not allow, for example if dns ad insertion isn't
optional or if the non-clear-path dns is for security reasons (blocking
malware C&C names), then "clear path" dns would not be provided.

so this would be opt-out rather than opt-in, to make it noncontroversial.
(those of us who previously wanted opt-in have learned that opt-in is
considered controversial by the companies already doing dns ad insertion
or similar non-clear-path dns.)

opin?  i can write a short i-d on it before beijing.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Sun, 24 Oct 2010 10:34:05 -0700

> query, then the server is requested to provide same.

Sounds like an ok idea, though it's hard to see operators honouring the bit
- but to meet your own burden of relevance; why should the DNS protocol be
complicated with an EDNS change to facilitate the users of shared-resolvers
when those users could simply run their own?

-- 
Colm

---

From: Paul Vixie <[email-masked]>
Date: Sun, 24 Oct 2010 17:49:27 +0000

> Date: Sun, 24 Oct 2010 10:34:05 -0700
> From: Colm MacCárthaigh <[email-masked]>
> 

if it's a single bit that specifies optional behaviour that some people want,
and it's unlikely to create market pressure on people who have no need for it
on their own but who would have to implement it anyway (as i think is true of
the google proposal for adding stub IP to the recursive/authority q-tuple) and
it's not a layering change (dare i say "violation") as is definitely true of
the google stub-IP proposal, then it's effectively an FYI rather than a STD.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 24 Oct 2010 17:07:09 -0400 (EDT)

On Sun, 24 Oct 2010, Paul Vixie wrote:

> Subject: [dnsext] need new flag bit in EDNS, "do me no favours" (DMNF)

> so this would be opt-out rather than opt-in

But would we really have a choice in the end? What about conflicting
"favours"?  What about services being withheld if I don't "opt-in"
to a certain service (say one that blocks ads based on DNS)

I have a feeling it is too late for a DMNF bit.....

Paul

---

From: Paul Vixie <[email-masked]>
Date: Sun, 24 Oct 2010 22:13:48 +0000

> Date: Sun, 24 Oct 2010 17:07:09 -0400 (EDT)
> From: Paul Wouters <[email-masked]>
> 
> But would we really have a choice in the end?

some "web error redirection" services offer opt-out.  this is a way to
standardize it in the protocol.  the fact that not every such service has
to offer this is an example of market force, not technically relevant.
some services do offer opt-out but there is no standardize in-band way
(today) for signalling this during query preparation.

> What about conflicting "favours"?  What about services being withheld if
> I don't "opt-in" to a certain service (say one that blocks ads based on
> DNS)

that's out of scope.

> I have a feeling it is too late for a DMNF bit.....

for many current users of current services, yes.  the standard is timeless.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 24 Oct 2010 18:25:00 -0400

I think that the probability of this being implemented or respected on
either end is low.

Applications will set the bit without asking the user and that will give the
DNS providers all the justification they need to ignore it.

I also think that the range of policy options needs to be richer than a
single bit. Many people are happy to accept advertising if they are getting
a real benefit in return. For example, having malware and phishing sites
filtered out. The problem with ISP interception is that the end user does
not get the choice.

I think that what we need to do is to abandon the idea that applications
take DNS service from the nearest DNS resolver. It is a trusted role
regardless of whether DNSSEC is in use or not.

The only sure fire way to avoid these issues is to apply guerilla tactics.
The platform needs to identify the service it is going to connect to in a
way that the user can easily understand - i.e. a DNS name. So to connect
through the Comodo Group Inc. curated DNS, you would type in 'comodo.com' as
your DNS resolver. Or for Google it would be google.com.

There might even be different resolver policies on offer. For example there
might be scada.comodo.com on offer for the most restrictive set of
resolution controls and use of that service might have a subscription fee.
That is not a service many people would want to subscribe to at home but
might make a lot of sense for connecting critical infrastructure control
systems to exactly the set of Internet resources that they need to contact
and no more.

In DPLS I propose a mechanism that allows DNS resolvers to advertise a
secure means of connecting via UDP. The architectural principles can be
extended so that the client attempts to connect by UDP if available but will
fall back to using SSL on the HTTPS port if that is blocked.

-- 
Website: http://hallambaker.com/

---

From: Roy Arends <[email-masked]>
Date: Sun, 24 Oct 2010 23:01:14 +0000

> opin?  i can write a short i-d on it before beijing.

The end-game will be applications doing their own resolving. Real control.
No third party dependencies. No favors to ask.

Roy

---

From: David Conrad <[email-masked]>
Date: Sun, 24 Oct 2010 16:24:54 -0700

>> opin?  i can write a short i-d on it before beijing.

I think a short i-d would be worthwhile.

> No third party dependencies. No favors to ask.

And greatly reduced caching.

The problem with applications doing their own resolving is that the 'real control' implies there is someone at the other end of the application that has the understanding and knowledge to make use of that control.  Haven't we seen the implications of this approach with browsers that ask the end user whether or not to accept an SSL cert?

Regards,
-drc

---

From: Roy Arends <[email-masked]>
Date: Sun, 24 Oct 2010 23:45:49 +0000

> And greatly reduced caching.

Yes, and greatly reduced impact of a spoofed cache.

> The problem with applications doing their own resolving is that the 'real
> control' implies there is someone at the other end of the application that has
> the understanding and knowledge to make use of that control.  Haven't we seen
> the implications of this approach with browsers that ask the end user whether
> or not to accept an SSL cert?

The DMNF bit is not user configurable?

Roy

---

From: Brian Dickson <[email-masked]>
Date: Sun, 24 Oct 2010 20:52:12 -0300

> And greatly reduced caching.
s/applications/hosts/, I think. The endgame is a local resolver or stub
resolver, or lwres library from a "real" dns package - not cobbled-together
application-centric "resolver" code.

And yes, caching would be reduced for no real benefit (other than presuming
to receive valid replies).

At the risk of sounding facetious, I think we already have a "DMNF" bit: DO
(plus CD bit, i.e. security-aware stub resolvers).

If DNSSEC answers are received, and authenticate properly, by definition, no
favors can have been done.

This is another reason to support DNSSEC, IMHO.

Brian

---

From: Mans Nilsson <[email-masked]>
Date: Mon, 25 Oct 2010 02:22:20 +0200

> (plus CD bit, i.e. security-aware stub resolvers).

++;

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Your CHEEKS sit like twin NECTARINES above a MOUTH that knows no BOUNDS --

---

From: Paul Vixie <[email-masked]>
Date: Mon, 25 Oct 2010 01:04:07 +0000

> From: Roy Arends <[email-masked]>
> Date: Sun, 24 Oct 2010 23:01:14 +0000
> 
> The end-game will be applications doing their own resolving. Real
> control.  No third party dependencies. No favors to ask.

since the end game for serious apps is stub validation, i tend to agree.
however, for non-serious apps i think ISP-level or even ASP-level rdns,
if an rdns operator wants to offer opt-out on web error redirection, i
think there ought to be an in-band way for stubs to opt out.

it's likely that the BIND resolver would implement DMNF defaulted to "on"
but allow it to be set to "off" in /etc/resolv.conf.  and it's likely
that opendns and possibly other ASP-level rdns operators would respect
this setting as part of their opt-out strategy and implementation.

and depending on the interpretation -- in other words, this would be left
loose deliberately in the standard for DMNF -- an rdns server who normally
hides AAAA RRsets from queries coming in on a non-IPv6 transport, would
turn this off in the presence of DMNF=1.  so there are other applications.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 25 Oct 2010 01:08:25 +0000

> Date: Sun, 24 Oct 2010 20:52:12 -0300
> From: Brian Dickson <[email-masked]>
> 
> At the risk of sounding facetious, I think we already have a "DMNF" bit:
> DO (plus CD bit, i.e. security-aware stub resolvers).

that's a workaround not a signal.  so, if there's a secure path from a 
trust anchor to the qname AND if the stub is validating THEN this has
the same effect as DMNF.

however, for unsecured names or nonvalidating stubs, i'd like an
explicit signal.  thus, DMNF.  so far david conrad thinks a short i-d
could be worthwhile, so that's two (me and him).  anybody else?

---

From: Paul Vixie <[email-masked]>
Date: Mon, 25 Oct 2010 01:24:01 +0000

among many critical defects in DNSSEC as specified, there's no good model
for stub validation, and as time goes on there are fewer and fewer
trustworthy rdns servers.  as kaminsky said, "i'm not going to trust
starbucks rdns to tell me the TLS key hash for my bank's HTTPS server".

so...

> From: David Conrad <[email-masked]>
> Date: Sun, 24 Oct 2010 16:24:54 -0700
> 
> control' implies there is someone at the other end of the application
> that has the understanding and knowledge to make use of that control.
> Haven't we seen the implications of this approach with browsers that ask
> the end user whether or not to accept an SSL cert?

...at the risk of being that guy who just won't shut up about something,
let me say that until DNSSEC is commonplace, DNSSEC is a failure.  when
every apple and microsoft and google and RIM platform including every
mobile phone can either validate end-to-end based on trust anchors (using
DNSSEC), or validate hop-by-hop based on transaction signatures (using
TSIG) from a trusted (and reachable!) rdns, then DNSSEC won't have been
worth its (considerable) engineering cost.

and it'll have to just work, out of the box, for nontechnical users, with
no more or at least no different popups than we get from X.509 failures.

but please everybody, don't dilute the DMNF thread with this argument.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 25 Oct 2010 01:35:49 +0000

> From: Paul Vixie <[email-masked]>
> Date: Mon, 25 Oct 2010 01:24:01 +0000
> 

s/won't/will/, sorry.

---

From: Brian Dickson <[email-masked]>
Date: Sun, 24 Oct 2010 22:43:56 -0300

> could be worthwhile, so that's two (me and him).  anybody else?
Sorry, I forgot to also say, I am not opposed, since there's the cases you
indicated.

I am in favor of an i-d as well, and would happily review it.

Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 24 Oct 2010 22:37:34 -0400

Only if the ISP concerned does not redirect all DNS traffic to their own
resolver.

That is not necessarily done for evil purposes either. A lot of ISPs are
doing that to try to reduce the scope for bots on their network performing
DDoS attacks on the DNS.

---

From: [email-masked]
Date: Mon, 25 Oct 2010 03:12:15 +0000

> And greatly reduced caching.

	well, at least a greatly reduced attack surface for any given cache that is 
	compromised.

> The problem with applications doing their own resolving is that the 'real control' implies there is someone at the other end of the application that has the understanding and knowledge to make use…

	yes and no.  if you posit that more than one application runs on a target platform,	
	then all apps that run there can use the same local resolver & validator. No real need
	for each app to take resolution into its own hands.  

	didn't we have this conversation about seven years ago?

--bill

---

From: David Conrad <[email-masked]>
Date: Sun, 24 Oct 2010 21:13:44 -0700

On Oct 24, 2010, at 6:24 PM, Paul Vixie wrote:
> for stub validation,

Stub validation never really made a lot of sense to me since it implies the stub to do all the work of an iterative resolver each and every time a lookup is done for each application that links in the stub resolver library.  It seems to me that a local rdns server makes way more sense.

> and as time goes on there are fewer and fewer trustworthy rdns servers.  

A separate issue. I have as much trust in the rdns server that runs on my local machine as I do in the application that linked the stub resolver library.  I have slightly less trust in the remote rdns server that exists within my administrative realm (assuming I can communicate with it via a trusted channel, e.g., (GSS-)TSIG, SIG(0), IPSEC, TLS, etc).  Even less for the remote rdns server outside of my administrative realm but with which I have some sort of contractual relationship (and a trusted channel).  Etc. 

> let me say that until DNSSEC is commonplace, DNSSEC is a failure.

I would argue that DNSSEC is a success if it protects against a cache poisoning attack in which a high value target is involved.  As DNSSEC deployment becomes more commonplace, the probability that it will be successful increases.

> but please everybody, don't dilute the DMNF thread with this argument.

Right.  Completely separate topics.

Regards,
-drc

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 25 Oct 2010 00:17:03 -0400

You probably don't want Starbucks to manage your network security.

But what about Symantec, MacAfee, Comodo, Kaspersky and the other companies
who specialize in providing security services?

The problem with making sense of DNSSEC data is that very little of it makes
much sense on its own. Any given observation can be the result of a
misconfiguration of a DNS server or an actual attack. It is very difficult
to decide how to react at the client end.

If instead we view a DNS recursive resolver as being a form of spam filter,
DNSSEC becomes one way to authenticate one form of input to that filter.
Cached data from previous requests becomes another. Blacklist and whitelist
data are yet more sources.

In this model the DNS resolver is not merely caching the result of a DNS
lookup, it is caching the result of a security risk analysis. And because it
is able to amortize that cost over multiple connections it is able to
perform a rather more thorough analysis than is possible in the pure end to
end discovery model.

In the PKI model we distinguish between path discovery and path validation.
For most purposes it is sufficient for the recursive resolver to perform
both. But for certain applications and certain platforms it makes better
sense to have discovery performed at the resolver and for the endpoint to
re-validate the path that is returned.

I agree on the problem of DNSSEC not being there until it is being used. One
of the problems has been that until the root was signed there were many
questions that many people did not want to hear raised lest they cast doubt
on the viability of DNSSEC as a whole.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 25 Oct 2010 14:03:07 +0900

Phillip Hallam-Baker wrote:

> But what about Symantec, MacAfee, Comodo, Kaspersky and the other
> companies who specialize in providing security services?

What about APNIC, ARIN, RIPE NCC and other NICs?

> The problem with making sense of DNSSEC data is that very little
> of it makes much sense on its own.

That's because DNSSEC is not secure end to end.

						Masataka Ohta

---

From: Jim Reid <[email-masked]>
Date: Mon, 25 Oct 2010 10:06:39 +0100

> I think a short i-d would be worthwhile.

+1

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 25 Oct 2010 11:45:23 +0200

On Sun, Oct 24, 2010 at 04:52:01PM +0000,
 Paul Vixie <[email-masked]> wrote 

> opin?  i can write a short i-d on it before beijing.

-1. The "Do not mess with my DNS resolution" bit is the default value
of the DNS from the beginning and changing this default value means
breaking many assumptions. I suggest instead to add a bit "I like
lies" for those who want to experience NXDOMAIN unauthorized
replacements and so on.

---

From: David Conrad <[email-masked]>
Date: Mon, 25 Oct 2010 09:51:44 -0700

Stephane,

On Oct 25, 2010, at 2:45 AM, Stephane Bortzmeyer wrote:
> I suggest instead to add a bit "I like lies" for those who want to experience NXDOMAIN unauthorized replacements and so on.

Are you aware of the term "closing the barn door after the horse has bolted"? 

Regards,
-drc

---

From: Paul Vixie <[email-masked]>
Date: Mon, 25 Oct 2010 16:57:15 +0000

> Date: Mon, 25 Oct 2010 11:45:23 +0200
> From: Stephane Bortzmeyer <[email-masked]>
> 
> -1. The "Do not mess with my DNS resolution" bit is the default value of
> the DNS from the beginning and changing this default value means breaking
> many assumptions. I suggest instead to add a bit "I like lies" for those
> who want to experience NXDOMAIN unauthorized replacements and so on.

while i'm not just sympathetic to that view but also passionately in love
with that view, it's not a reasonable or practical position to take.  the
internet economy recognizes first-mover advantage more often than not, and
the ISP's and ASP's who do "web error redirection" today are not going to
stop no matter what anybody says.  sometimes "web error redirection" is the
only source of revenue for an ASP, or sometimes it's the difference between
profitability or not for an ISP.  in practical terms, telling them they
should not do this and that the RFC's were the first movers, is meaningless.

opt-in would have been the better design choice had events not overtaken us.
opt-out, if it's explicit and in-band, is a carve-out.  those of us who know
that we never want "web error redirection" should be able to express this in
unambiguous terms, so that ISP's and ASP's who perform "web error
redirection" can be held to account for their conscious and deliberate
choice of whether to honour our expressed preferences or not.  that's what
we can actually still accomplish, while we wait for end-to-end DNSSEC that
will drive nails into the lid of the coffin containing "web error
redirection" and similar practices.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 25 Oct 2010 13:05:36 -0400 (EDT)

> And greatly reduced caching.

Why?

unbound already supports a changing forwarder statement via unbound-control, and
even deals with the forwarder changing between DNSSEC (in)capable forwarders. And
it also detects stripped DNSSEC data.

So why can't you use DHCP obtained resolvers as forwards (and thus their cache)
AND do DNSSEC processing yourself?

And if you'd have to remove a bad forwarder, well then that cache was malicious
anyway and it should not get any usage to begin with.

Paul

---

From: Alex Bligh <[email-masked]>
Date: Mon, 25 Oct 2010 19:16:12 +0100

+1

-- 
Alex Bligh

---

From: David Conrad <[email-masked]>
Date: Mon, 25 Oct 2010 13:32:58 -0700

Paul,

> it also detects stripped DNSSEC data.

Wouldn't this mean the application has to know that it is behind a forwarder?  If it isn't (or it can't figure out if it is), it'll have to implement the full iterative resolver goop.  As such, I'd think the safe approach for application developers would be to link in the full iterative resolver library into the application.  

Regards,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Tue, 26 Oct 2010 10:32:15 +1100

> redirection" and similar practices.

But we still can't be sure that they won't adapt to the presence
of such marked queries especially if we can get buy-in from a couple
of brower vendors along with something to help the proxies to decided
when they should should do the same thing.

Why don't we do both at once?  There is a range of address modifications
out there.  none, dns64, dns46[1], filter-aaaa, "bad" site, nxdomain.
A query may want some or all of these to be performed even in the
presence of DO or CD.  Only the querier really knows what is
acceptable.

I can see web browers setting dns64 (vendor), bad site (user control)
and nxdomain (user control).

Mark

[1] Give me a IPv4 address if the site doesn't have a IPv4 address
but has a IPv6 address.  It's the complement of dns64.

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

---

From: Paul Vixie <[email-masked]>
Date: Tue, 26 Oct 2010 01:59:54 +0000

updated informal proposal contained herein.  if you +1'd before, or -1'd, or
are still on the fence, this is worth reading and potentially commenting on.

> From: Mark Andrews <[email-masked]>
> Date: Tue, 26 Oct 2010 10:32:15 +1100
> 
> > opt-in would have been the better design choice had events not
> > overtaken us.  opt-out, if it's explicit and in-band, is a carve-out.
> > those of us who know that we never want "web error redirection" should
> > be able to express this in unambiguous terms, so that ISP's and ASP's
> > who perform "web error redirection" can be held to account for their
> > conscious and deliberate choice of whether to honour our expressed
> > preferences or not.  that's what we can actually still accomplish,
> > while we wait for end-to-end DNSSEC that will drive nails into the lid
> > of the coffin containing "web error redirection" and similar practices.
> 

that's out of scope -- and would take more than five years to agree about.

> out there.  none, dns64, dns46[1], filter-aaaa, "bad" site, nxdomain.  A
> query may want some or all of these to be performed even in the presence
> of DO or CD.  Only the querier really knows what is acceptable.
> ...

as long as it's clear that we're not changing the q-tuple between recursive
and authoritative, i'm fine with unlimited complexity in stub-to-recursive
(that is, RD=1) options.

> I can see web browers setting dns64 (vendor), bad site (user control) and
> nxdomain (user control).

so it sounds like we need a new edns option blob which is a variable length
mask (so, right now it would be one octet long), which would only be defined
for RD=1.  the first bit of the first octet would be "no web error redirect"
(NWED).  the name of the option would be "do me no favours" (DMNF).

this way we a rdns can be sure that the user has expressed no preferences if
there is no DMNF option at all, but that if the option is present, then every
bit therein is absolutely meaningful.  so, DMNF present means "user is aware
of the issues and is expressing a preference", in which case NWED=1 means the
user doesn't want web error redirection whereas NWED=0 means they do want it.
(note, we are expressing these as negatives, to ensure that rdns operators
know that the default (zero) is in favour of the potentially unwanted
practice.

there would be no ambiguity here, since someone who doesn't care at all can
just never add the DMNF option on anything, whereas someone who cares about
anything has to be explicit about every negative preference they could
potentially have.

i'm willing to write this up in this form, even given that i've missed the
-00 deadline for beijing (where i will not be present, by the way), and i'll
be happy to add any other preference bits if (1) they are only meaningful for
RD=1, (2) they do not affect the recursive-to-authoritative q-tuple at all,
(3) they can be expressed in a single binary digit ("bit"), and (4) there is
a simple unambigious one-paragraph english text that explains the meaning.

am i on the wrong track according to those (three) who have +1'd this so far?

is anyone else +1 for this approach (willing to review, etc)?

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 25 Oct 2010 19:46:35 -0700

> (NWED).  the name of the option would be "do me no favours" (DMNF).

Why doesn't that belong better in HTTP? The HTTP WG is probably better
placed to define whatever a "web error" is.

-- 
Colm

---

From: Brian Dickson <[email-masked]>
Date: Mon, 25 Oct 2010 23:57:14 -0300

> is anyone else +1 for this approach (willing to review, etc)?
I think this is heading in the right direction, IMHO.

+1 for the approach and review volunteer

At the risk of rat-holing here, I think some attention to the DO bit might
be warranted.

Specifically, this is an opportunity to encourage "good" behavior even for
unsigned zones, when DO is set.
If a stub resolver is security aware, it should expect whatever resolver it
uses (trusts?) to be benign.

So, while this would definitely add complexity, even in the instance of DMNF
not being set, any favors should also include "proof" that they are only
favors.

I.e. if web error detection/redirection occurs, where an NXDOMAIN would
otherwise have been returned, the recursive resolver SHOULD also include the
kind of DNSSEC stuff that would accompany an NXDOMAIN (NSEC/NSEC3 proof).

Thoughts?

Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 25 Oct 2010 23:15:08 -0400

I think you are creating an evil bit.

Or to be precise, a please do not be evil bit.

We have the means to allow the user to enforce their preferences in this
respect, that seems a more useful approach to me.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 26 Oct 2010 03:39:23 +0000

> Date: Mon, 25 Oct 2010 19:46:35 -0700

if you get an nxdomain you won't be connecting to any web server anywhere.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 26 Oct 2010 03:45:04 +0000

> Date: Mon, 25 Oct 2010 23:57:14 -0300

groovy, thanks.

> At the risk of rat-holing here, I think some attention to the DO bit
> might be warranted.
> 
> Specifically, this is an opportunity to encourage "good" behavior even
> for unsigned zones, when DO is set.  If a stub resolver is security
> aware, it should expect whatever resolver it uses (trusts?) to be benign.

DO doesn't signal security-aware, rather it signals security-format-aware.

> So, while this would definitely add complexity, even in the instance of
> DMNF not being set, any favors should also include "proof" that they are
> only favors.
> 
> otherwise have been returned, the recursive resolver SHOULD also include
> the kind of DNSSEC stuff that would accompany an NXDOMAIN (NSEC/NSEC3
> proof).
> 
> Thoughts?

i think that if the nxdomain is secure from the authoritative and if the
client sets DO then unsigned results will be treated as bogus by the RD=1
initiator, who will know by that time that the zone is signed.  so, this
is nonsequitur.

moreover, i'd like to open-and-shut this case.  please let's not innovate
beyond the small desire i began with, which is to add opt-out.  this WG has
a long history of multiyear drafts with 15 to 20 revisions.  let's please
not do that in this case.

---

From: Alex Bligh <[email-masked]>
Date: Tue, 26 Oct 2010 07:49:27 +0100

> am i on the wrong track according to those (three) who have +1'd this so

I am not convinced this is going to solve the problem, but I think it's
worth our time reviewing. I will review if that is helpful.

One potential problem is this: we might all want the bitfield to be
"don't be evil", but in practice it's per the draft title "do not futz".
I suspect some futzing may be not only non-evil but necessary (or
lesser of two evils). I /think/ WiFi hotspots no longer futz with
DNS to get users online (they intercept port 80), so that's not
a problem. However, I know that in the UK (and other places) it's
all-but-a-legal-requirement for consumer ISPs to block certain
web content (in the UK child porn), and anyone sane does this partly
at the DNS level. If I'm an SP I probably won't respect an "ignore
legal requirements" bit whereas I might respect a "no advertising"
bit; if I'm a user in $regime I may not want to set a DMNF bit
if that actually means "be targeted by security forces". My worry is
that the bits may end up attempting to encode policy rather than
protocol.

-- 
Alex Bligh

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 26 Oct 2010 09:14:21 +0200

On Mon, Oct 25, 2010 at 09:51:44AM -0700,
 David Conrad <[email-masked]> wrote 

> Are you aware of the term "closing the barn door after the horse has

I think so (except that in French, it is the stable door, not the barn
door). So do you suggest that, since DNS lies are presently common, we
should accept the fact that the semantics of the DNS changed (by
arm-twisting, not by bottom-up, transparent, open, IETF process), and
we now have to explicitely ask for the truth?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 26 Oct 2010 09:16:45 +0200

On Mon, Oct 25, 2010 at 04:57:15PM +0000,
 Paul Vixie <[email-masked]> wrote 
 a message of 28 lines which said:

> the internet economy recognizes first-mover advantage more often
> than not, and the ISP's and ASP's who do "web error redirection"
> today are not going to stop no matter what anybody says.

If you believe that ISPs and ASPs are bad guys that will do DNS lies
whatever the IETF says, then, what makes you think they will honor the
DMNF bit? (Specially since it is a new option so they will have to
actually act, develop stuff, etc, to honor it.)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 26 Oct 2010 09:19:26 +0200

On Tue, Oct 26, 2010 at 07:49:27AM +0100,
 Alex Bligh <[email-masked]> wrote 
 a message of 27 lines which said:

> However, I know that in the UK (and other places) it's
> all-but-a-legal-requirement for consumer ISPs to block certain web
> content (in the UK child porn), and anyone sane does this partly at
> the DNS level.

Same thing in France with the (not-yet adopted) LOPPSI law, which
mandates chinese-style filtering. I'm not sure that it will be "sane"
to do it in DNS rather than BGP (the law does not specify a technical
mean, just a goal) but, anyway, DNS lies by the State will become a
reality and I don't think we can standardize a "Do not abide by the
law" bit :-{

---

From: Paul Vixie <[email-masked]>
Date: Tue, 26 Oct 2010 07:25:59 +0000

> Date: Tue, 26 Oct 2010 09:16:45 +0200
> > the internet economy recognizes first-mover advantage more often than
> > not, and the ISP's and ASP's who do "web error redirection" today are
> > not going to stop no matter what anybody says.
> 
> whatever the IETF says, ...

i do not believe they are bad guys.

> ... then, what makes you think they will honor the DMNF bit? (Specially
> since it is a new option so they will have to actually act, develop
> stuff, etc, to honor it.)

because it's free PR for them and won't affect their revenues at all.  most
end users really don't care, and some end users really do like web error
redirection.  opendns could not succeed if everybody hated this stuff.  but
even though google doesn't do it and google has a more-recognizable IP addr
for its resolvers, opendns continues to thrive.  there's no pent up wave of
consumer hate for "web error redirection".  i thought there would be.  now
i just want there to be a standardzed in-band opt out mechanism.  i expect
that comcast and opendns, at least, will honour it.  various coffee shops
will not.  but if properly expressed, this signalling could enable google to
offer this as a service for those whose packets do explicitly request it.
(that is, google's default will probably remain "no", but if DMNF is present
and NWED=0 then they might treat this as an honest revenue opportunity.)

---

From: Alex Bligh <[email-masked]>
Date: Tue, 26 Oct 2010 09:23:14 +0100

--On 26 October 2010 07:25:59 +0000 Paul Vixie <[email-masked]> wrote:

> i just want there to be a standardzed in-band opt out mechanism

Is there a need for a standard discovery mechanism (of what DMNF bits
are honoured)? If my laptop DHCPs and receives DNS servers that
are going to futz with things, I might prefer to use known open
resolvers (Google, OpenDNS, whoever) or perhaps an authenticated
query to my own otherwise closed resolvers. That would just involve
putting the same bitfield in a DHCP option.

Indeed I wonder being able to detect a nameserver that futzes
with DNS is more useful than be able to ask it not to.

-- 
Alex Bligh

---

From: Jim Reid <[email-masked]>
Date: Tue, 26 Oct 2010 11:09:54 +0100

> if you get an nxdomain you won't be connecting to any web server  

Not long ago Colm was in favour of using DNS to solve a web problem.  
Paul was advocating the opposite. Now it's the other way round for  
both. Oh, the irony... :-)

BTW, I thought NXDOMAIN had been overtaken by response rewriting these  
days?

---

From: Florian Weimer <[email-masked]>
Date: Tue, 26 Oct 2010 10:39:17 +0000

> query, then the server is requested to provide same.

Does EDNS actually work on the last mile?

What about expressing this in terms of the trust anchors you're
willing to accept?

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Florian Weimer <[email-masked]>
Date: Tue, 26 Oct 2010 10:40:22 +0000

> Yes, and greatly reduced impact of a spoofed cache.

You can reduce caching of unstable records, to avoid the amplification
effect of a poisoned cache, too. 8-)

---

From: "Roosenraad, Chris" <[email-masked]>
Date: Tue, 26 Oct 2010 08:45:36 -0400

Paul,

>(NWED).  the name of the option would be "do me no favours" (DMNF).

Do we want to have a bit of a parallel effort to define the initial set of
such bits? If we're going to go through the trouble of defining this new
variable length mask, we probably should have > 1 options for it out of
the gate.

>is anyone else +1 for this approach (willing to review, etc)?

I think this could be useful for other types of client to server
preferences communications, so I'm definitely interested in the idea, and
will therefore be glad to provide editing/review/etc.

--
Chris R. Roosenraad
Principal Engineer
Time Warner Cable - ATG
13820 Sunrise Valley Drive
Herndon, VA  20171
+1 (703) 345 3438
[email-masked]

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 26 Oct 2010 12:22:34 -0400 (EDT)

On Tue, 26 Oct 2010, Paul Vixie wrote:

> beyond the small desire i began with, which is to add opt-out.

I'm still unsure how this would work when users with a mix of preference
for opt-in/opt-out for dns-rewrites connect to the same cache. Will caches
now keep multiple answers based on the new RD EDNS DMNF bit? How would this
work together with DNSSEC? And with the business model of TTL=0

I do think the standard should be "do me no favours" and any mechanism
for "doing me favours" should be done by the user. Possible a nice gui to
enable such services might help those services, but I'm still unconvinced
this needs to be addressed at the protocol layer. I kind of feel along
the lines of RFC-1984.

Paul

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 26 Oct 2010 11:11:24 -0700

Why would the misbehaving DNS authorities bother?

They either have clean opt-outs (eg, Comcast's is reasonably enough and permanent: it changes the DHCP config so that in the future you get a clean resolver.  Only if you change your cable-modem does this need resetting), or DELIBERATELY unclean opt-outs (Verizon's 'change your DNS resolver settings', Bell canada's for a while was even worse: it added a cookie which simply caused the wildcard page to display a fake browser error page!)

So in the former case, this is unnecessary, and in the latter case, why would they bother?  They've made a deliberate decision to make it hard and hostile.

Additionally, the comment elsewhere that "we have a 'don't bother me': use DNSSEC and/or local resolution" is correct.  

Comcast's is supposedly going away as they turn on DNSSEC (because its fundamentally incompatible in their opinion, http://www.dnssec.comcast.net/faq.htm#faq7 
http://tools.ietf.org/html/draft-livingood-dns-redirect-03#section-8.1
).

And I've argued repeatedly that the DNSSEC validation for "normal" records (A, AAAA, MX, etc) should be on the client as follows:

IF the chain validates, accept the record from the cache.

If, for any reason (no sig, broken sig, no root, whatever) the validation fails, do an independent fetch bypassing the recursive resolver.

And this policy eliminates the problem of the lying recursive resolver, AND creates an incentive for people to deploy DNSSEC without the penalties of deploying DNSSEC incorrectly.

---

From: Andreas Gustafsson <[email-masked]>
Date: Tue, 26 Oct 2010 22:34:46 +0300

> if you get an nxdomain you won't be connecting to any web server anywhere.

Maybe this can't be solved by the HTTP WG, but it could be solved by
the web browser vendors.

First of all, any improvement in "user experience" that the proponents
of web error redirection are claiming as a justification for doing DNS
rewriting can just as easily be implemented in the browser.  One
difference, of course, is that any ad revenue resulting from the
"improved experience" would then go to the browser vendor rather than
the ISP.

Second, browser vendors are in a position to defend against unwanted
DNS rewrites, by making the browsers bypass the system resolver and
directly query a recursive DNS server operated by the vendor or a
third party.  If enough browsers did this, NXDOMAIN rewriting in the
DNS would not longer be profitable.

Third, browser vendors could help raise awareness and exert pressure.
Imagine browsers detecting rewrites and displaying alerts along these
lines:

    [Insert browser name here] has detected that your computer is
    using a DNS server that tampers with the results of DNS lookups.
    Most likely, this is an attempt by your Internet Service Provider
    to replace the error message that would normally be displayed
    when you enter an incorrect URL with a pages containing paid
    advertisements.

    [Browser vendor] considers this practice harmful, not only because
    it alters your web browsing experience, but also because it can
    interfere with the operation of other Internet applications on
    your computer and other Internet-enabled devices on your network.

    [Browser] has automatically switched to a third-party DNS service
    operated by [company], but your other applications and devices are
    still affected.  If your Internet Service Provider allows you to
    opt out of DNS rewriting, we recommend that you do so.  Alternatively,
    you can change your DNS settings to use a third-party DNS provider
    by following the instructions at [this link].

-- 
Andreas Gustafsson, [email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Tue, 26 Oct 2010 16:00:16 -0400 (EDT)

>    by following the instructions at [this link].

This creates unneccessary warnings for users who want to opt-in their computer
and/or home network to use a trusted third party DNS rewriting vendor.

I'm not a fan of those services, but they are non-malicious
services. Spamming users with DNS warnings to get rid of spamming users
with CERT warnings does not seem like a good solution to me. Instead, all
these warning should ideally disappear from the enduser's experience.

Paul

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 26 Oct 2010 12:59:49 -0700

> "improved experience" would then go to the browser vendor rather than

In fact, this is the biggest problem with such rewriting: the browsers often DO have very good behavior on nxdomain in many cases.

EG, type in a random word into firefox.  The first thing it does is do a lookup for that word, and only after the nxdomains happen does it immediately redirect to google.

> DNS would not longer be profitable.

They can't do that so easily however:  the latency to third party resolvers suck, there are far too many networks that block/game outbound DNS on the packet level, and there is no solution for the 'akamai problem' [1]

[1] Well, there is.  EDNS0-client-subnet, but there are a lot here who object to that solution on religious grounds.

---

From: David Conrad <[email-masked]>
Date: Tue, 26 Oct 2010 18:10:36 -1000

> and authoritative, i'm fine with unlimited complexity in stub-to-recursive

Simple: good. Complex: bad.

> am i on the wrong track according to those (three) who have +1'd this so far?

I fear you've one foot on a slippery slope.

> is anyone else +1 for this approach (willing to review, etc)?

I'm willing to review, albeit the additional complexity now introduced makes it much less appealing to me.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Tue, 26 Oct 2010 19:02:20 -1000

On Oct 25, 2010, at 9:14 PM, Stephane Bortzmeyer wrote:
> So do you suggest that, since DNS lies are presently common, we

One could argue the market choice of accepting redirection is more bottom up than what a bunch of DNS geeks thinks is a good idea, but I won't :-).

The reality is that the vast majority of folks behind redirection either have no clue they are being subject to "lies" or they actually prefer it.  A bit in a stub-to-resolver packet requesting the resolver not muck with the response seems like a reasonable way for the minority to request a preference via the DNS that corresponds to the various redirecting operators' "opt out" mechanisms. Of course, resolver operators are free to disregard such a request (e.g., if they are required to redirect for legal reasons or whatever) so this isn't a perfect solution, but I figure it'd be useful...

Regards,
-drc

---

From: David Ulevitch <[email-masked]>
Date: Wed, 27 Oct 2010 09:08:04 -0700

> No third party dependencies. No favors to ask.

Agreed (and previously predicted).  And a few days ago, it happened to Chrome:

http://code.google.com/p/chromium/issues/detail?id=60149

"Provide facility for users to set the DNS resolver to use. This will
bypass the system DNS resolver, and will require improvements to
Chrome's in-browser DNS cache."

If it sits between the User and an Advertisement, Google wants to own it...

-David