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

"Jeffrey A. Williams" <jwkckid1@ix.netcom.com> Tue, 26 October 2010 17:38 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E77573A69D2; Tue, 26 Oct 2010 10:38:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.914
X-Spam-Level:
X-Spam-Status: No, score=-0.914 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, SARE_RMML_Stock10=0.13]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yv++SbFw5bAR; Tue, 26 Oct 2010 10:38:38 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 43FEA3A68EE; Tue, 26 Oct 2010 10:38:38 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1PAnQw-000K94-9f for namedroppers-data0@psg.com; Tue, 26 Oct 2010 17:35:38 +0000
Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from <jwkckid1@ix.netcom.com>) id 1PAnQs-000K8k-Rg for namedroppers@ops.ietf.org; Tue, 26 Oct 2010 17:35:35 +0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=Jdfl7d37zNjkLK+M0GTie6w07JmrSJg6bwFBhcjc7sWAO9wbjjSYoToPdzUMBY4G; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Transfer-Encoding:X-Mailer:Content-Type:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.43] (helo=elwamui-norfolk.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <jwkckid1@ix.netcom.com>) id 1PAnQr-0006hj-TE; Tue, 26 Oct 2010 13:35:33 -0400
Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Tue, 26 Oct 2010 13:35:33 -0400
Message-ID: <27287413.1288114533903.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net>
Date: Tue, 26 Oct 2010 12:35:33 -0500
From: "Jeffrey A. Williams" <jwkckid1@ix.netcom.com>
Reply-To: "Jeffrey A. Williams" <jwkckid1@ix.netcom.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Subject: Re: [dnsext] Re: need new flag bit in EDNS, "do me no favours" (DMNF)
Cc: namedroppers@ops.ietf.org
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
X-Mailer: EarthLink Zoo Mail 1.0
Content-Type: text/html; charset="UTF-8"
X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688a157c353fc6632eccc39b365c6d09e52350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.43
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>

Phillip and all,

 

  I fully agree.


-----Original Message-----
From: Phillip Hallam-Baker
Sent: Oct 25, 2010 10:15 PM
To: Paul Vixie
Cc: namedroppers@ops.ietf.org
Subject: Re: [dnsext] Re: need new flag bit in EDNS, "do me no favours" (DMNF)

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 <vixie@isc.org> 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 <marka@isc.org>
> 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/" target="_blank" rel="nofollow">http://hallambaker.com/

Regards,
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com
Phone: 214-244-4827