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

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

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.


On Sun, Oct 24, 2010 at 1:49 PM, Paul Vixie <[e-mail]> wrote:

> > Date: Sun, 24 Oct 2010 10:34:05 -0700
> > From: Colm MacCárthaigh <[e-mail]>
> >
> > 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?
>
> 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.
>
>


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