In message , Paul
Wouter
s writes:
> On Thu, 16 Jul 2009, Mark Andrews wrote:
>
> >> How would this work?
> >
> > With portals that are only available to internal servers you are
> > grafting on namespace and you configure your validator to know about
> > it and potentially not validate that nam
On Thu, 16 Jul 2009, Mark Andrews wrote:
How would this work?
With portals that are only available to internal servers you are
grafting on namespace and you configure your validator to know about
it and potentially not validate that namespace.
zone "portal.isp.com" {
type forward;
In message , Paul
Wouter
s writes:
> On Thu, 16 Jul 2009, Mark Andrews wrote:
>
> >> If I use my own validating stub resolver I can't make it to the portal
> >> page.
> >
> > With proper configuration of the validating stub resolver and the
> > recursive servers your validating stub resolver ar
- Original Message -
From: "Roy Arends"
..
> If you want a real analogy, think alternative roots. From the users
> perspective, that is what is happening here: an alternative namespace is
> created. Would we have a discussion at all if this perspective was used?
I agree. This docume
On Thu, 16 Jul 2009, Mark Andrews wrote:
If I use my own validating stub resolver I can't make it to the portal page.
With proper configuration of the validating stub resolver and the
recursive servers your validating stub resolver are using you should
be able to make it to the portal page.
I
In message , Paul Wou
ters writes:
> On Wed, 15 Jul 2009, Paul Hoffman wrote:
>
> >> and working with it. With manipulating my laptop's DNS asking for MY
> >> OWN cryptographically signed data, you are asking me to throw out the
> >> crypto protection and make me accept a downgrade attack.
> >
>
On Wed, 15 Jul 2009, Paul Hoffman wrote:
and condemn some
of them as bad?
That works for me too, although I think it is not that useful to do so in an
Informational RFC.
Then merge Section 7 Practices to Avoid with Section 8 Functional Design
and leave out any (intended or not) judgement on
On Wed, 15 Jul 2009, Paul Hoffman wrote:
and working with it. With manipulating my laptop's DNS asking for MY
OWN cryptographically signed data, you are asking me to throw out the
crypto protection and make me accept a downgrade attack.
Then use a different DNS resolver.
If I use my own vali
On Jul 15, 2009, at 6:29 PM, Andrew Sullivan wrote:
On Tue, Jul 14, 2009 at 11:26:42PM +0200, Stephane Bortzmeyer wrote:
DNS lying resolvers are not a solution to an actual problem
(otherwise, doing it as an opt-in service would be sufficient).
I cannot agree, as much as I would like to.
If
At 2:47 PM -0400 7/15/09, Paul Wouters wrote:
>Tell me, what is the goal of this informational rfc?
I can only tell you my goal, and I am not the author. My goal is to describe
different types of lying resolvers so that someone can ask "what type of
resolver is that, based on the RFC WXYZ langau
On Wed, 15 Jul 2009, Andrew Sullivan wrote:
>
> Just because I know how to avoid going to phishing and malware sites
> does not mean it is within the competence of the average user.
A better way for ISPs to address that problem is to run an intercepting
web proxy that traps connections to infested
At 12:08 AM -0400 7/15/09, Paul Wouters wrote:
>On Mon, 13 Jul 2009, Paul Hoffman wrote:
>
I think you need to widen that caveat: anything that isn't a web browser
should not use a DNS server that misbehaves as described in this draft.
>>>
>>>I think you need to widen that caveat: anything
On Tue, Jul 14, 2009 at 11:26:42PM +0200, Stephane Bortzmeyer wrote:
> DNS lying resolvers are not a solution to an actual problem
> (otherwise, doing it as an opt-in service would be sufficient).
I cannot agree, as much as I would like to.
If there weren't an "actual problem" here to be solved
On Tue, 14 Jul 2009, SM wrote:
>
> Could one of the authors of the document clarify off-list whether the
> connectivity provided by an ISP using DNS redirect services is labelled as
> Full Internet connectivity?
According to the definitions in RFC 4084, the only one that applies to an
ISP with lyi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
> -Original Message-
> From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of
> Mark Andrews
> Subject: Re: [DNSOP] Comments on draft-livingood-dns-redirect-00
>
>
> In message <6.2.5.6.2.20090714124754.030b6...@elandnews
15 matches
Mail list logo
