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

[Phillip Hallam-Baker <[e-mail]>]

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.


On Mon, Oct 25, 2010 at 9:59 PM, Paul Vixie <[e-mail]> wrote:

> 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 <[e-mail]>
> > 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.
> >
> > 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.
>
> that's out of scope -- and would take more than five years to agree about.
>
> > 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.
> > ...
> > [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.
>
> 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)?
>
>


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