Keywords IetfDiscussionForumsneedflagbitEDNSampquotfavoursDMNFDnsext
| | | Author | Message |
|---|
| Jeffrey A. Williams |  Posted: Thu Jul 18, 2013 4:07 am Post subject: Re: Re: need new flag bit in EDNS, "do me no favours"(DMNF)Report Spam |
|
Alex and all,
From: Alex Bligh <alex (AT) alex (DOT) org.uk>
Sent: Oct 26, 2010 1:49 AM
To: Paul Vixie <vixie (AT) isc (DOT) org>, namedroppers (AT) ops (DOT) ietf.org
Cc: Alex Bligh <alex (AT) alex (DOT) org.uk>
Subject: Re: [dnsext] Re: need new flag bit in EDNS, "do me no favours" (DMNF)
--On 26 October 2010 01:59:54 +0000 Paul Vixie <vixie (AT) isc (DOT) org> wrote:
am i on the wrong track according to those (three) who have +1'd this so
far?
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.
Great thoughts here, many I share. Often times, perhaps too
often, policy in intemingled with protocol on more than one level,
if you catch my drift. Blocking content at the DNS level is IMO
a good place to do it IF it is necessary. Problem is what content
blocking IS necessary. The IETF should not involve themselves in such
matters when considering encoding protocols. So where possible as a
matter of policy, content blocking in some instances should be done
where possible at the App level, not at the protocol level even though
both potentials exist and one MAY have advantages over another depending
on the type of content in consideration.
Regards,
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!)
"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 (AT) ix (DOT) netcom.com
Phone: 214-244-4827
|
| | Back to top | |  | | Jeffrey A. Williams | | Posted: Thu Jul 18, 2013 4:07 am Post subject: Re: Re: need new flag bit in EDNS, "do me no favours"(DMNF)Report Spam |
|
body{font-size:10pt;font-family:arial,sans-serif;background-color:#ffffff;color:black;}p{margin:0px;}
Phillip and all,
I fully agree.
From: Phillip Hallam-Baker
Sent: Oct 25, 2010 10:15 PM
To: Paul Vixie
Cc: namedroppers (AT) ops (DOT) 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 (AT) isc (DOT) 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 (AT) isc (DOT) 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)?
|
| | Back to top | | | | Jeffrey A. Williams | | Posted: Thu Jul 18, 2013 4:07 am Post subject: Re: Re: need new flag bit in EDNS, "do me no favours"(DMNF)Report Spam |
| nick and all,
From: Nicholas Weaver <nweaver (AT) icsi (DOT) berkeley.edu>
Sent: Oct 26, 2010 1:11 PM
To: namedroppers WG <namedroppers (AT) ops (DOT) ietf.org>
Cc: Nicholas Weaver <nweaver (AT) icsi (DOT) berkeley.edu>
Subject: Re: [dnsext] Re: need new flag bit in EDNS, "do me no favours" (DMNF)
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
I was and remain more concerned about section 8.2 see:
http://tools.ietf.org/html/draft-livingood-dns-redirect-03#section-8.2
which suggests without defining that "the valid A record
contained valid, lawful, non-malicious content, and there would
otherwise appear to be no valid justification for a redirect to
occur."
What is 'Valid and non-malicious content' in such a
context? Would some content in say the WSJ.com's web pages be
'malicious' or perhaps playboy.com's web pages? Some would answer yes
other would answer no, but who decides, the service provider by virtue
of their omnipitant wisdoms use of DMNF, the user or perhaps the Apps
browser/developer/provider in their own near omnipitant wisdom? My answer is
the user at the browser level where such security settings options belong.
Seems very recently though that some browser developers are also not wanting
allow for this either, see Google:
http://www.prnewswire.com/news-releases/google-sued-for-violating-the-privacy-rights-of-millions-of-americans-105719403.html
and Firefox:
http://www.net-security.org/secworld.php?id=10042
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.
Agreed.
If, for any reason (no sig, broken sig, no root, whatever) the validation fails, do an independent fetch bypassing the recursive resolver.
Also agreed here.
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.
spot on IMO.
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 (AT) ix (DOT) netcom.com
Phone: 214-244-4827 |
| | Back to top | | | | Jeffrey A. Williams | | Posted: Thu Jul 18, 2013 4:07 am Post subject: Re: Re: need new flag bit in EDNS, "do me no favours"(DMNF)Report Spam |
| Andreas and all,
Previous Message From: Andreas Gustafsson <gson (AT) araneus (DOT) fi>
Sent: Oct 26, 2010 2:34 PM
To: IETF DNSEXT WG <namedroppers (AT) ops (DOT) ietf.org>
Subject: Re: [dnsext] Re: need new flag bit in EDNS, "do me no favours" (DMNF)
Paul Vixie wrote:
From: Colm MacCárthaigh <colm (AT) allcosts (DOT) net>
Why doesn't that belong better in HTTP? The HTTP WG is probably better
placed to define whatever a "web error" is.
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.
Well this would be goodness for the browser vendor/developer as you state
it. Also though it would be an opertunity for the ISP and the browser
vendor/developer to cooperate and have cross revinue sharing agreements
so that both can benifit, or conversly if the user option is to turn
doing DNS rewriting, than neither would benifit and the user would have
the option not the browser vendor or the IxP.
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.
This would be a good outcome IMO for some users.
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.
I love this alert message. >
[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.
This one might be ok in some instances, not in others...
[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].
This alert message would be acceptable as well in some instances, but
should be set by the user, not the IxP or third party DNS provider.
--
Andreas Gustafsson, gson (AT) araneus (DOT) fi
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 (AT) ix (DOT) netcom.com
Phone: 214-244-4827 |
| | Back to top | | | | Jeffrey A. Williams | | Posted: Thu Jul 18, 2013 4:07 am Post subject: Re: Re: need new flag bit in EDNS, "do me no favours"(DMNF)Report Spam |
| Paul and all,
Previous Message From: Paul Vixie <vixie (AT) isc (DOT) org>
Sent: Nov 5, 2010 10:31 AM
To: IETF DNSEXT WG <namedroppers (AT) ops (DOT) ietf.org>
Subject: Re: [dnsext] Re: need new flag bit in EDNS, "do me no favours" (DMNF)
Andreas Gustafsson <gson (AT) araneus (DOT) fi> wrote:
Florian Weimer wrote:
Redirection to search seems important because most users do not care
about the difference between DNS-based and search-engine-based
lookups.
Indeed - important enough that at least one browser is taking
defensive measures to ensure that this redirection to search is not
broken by NXDOMAIN spoofing:
http://groups.google.com/a/chromium.org/group/chromium-discuss/msg/5891e258e6015fc5
in the info-war over the ownership of eyeballs, we will all be collateral
victims.
Indeed we will be, if we already have not been.
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
Network Eng. SR. Eng. Network data security
ABA member in good standing member ID 01257402
E-Mail jwkckid1 (AT) ix (DOT) netcom.com
Phone: 214-244-4827 |
| | Back to top | | |
Related Topics |