Great feedback, Dave. Thank you and we¹ll take it into account as we work
on a revision.
Jason
On 7/17/09 1:02 PM, Dave CROCKER d...@dcrocker.net wrote:
Jason, et al,
This note suggests changes in both style and detail in
draft-livingood-dns-redirect-00. All of the points made here
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
-Original Message-
From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of
David Conrad
Subject: Re: [DNSOP] Review of draft-livingood-dns-redirect-00
As far as I can tell, Comcast's network and their recursive
Livingood, Jason wrote:
TLDs, including your own zones. This is indeed not just Site Finder
all over again - it's far worse, and breaks far more applications than
Site Finder did.
Please do send me that list of applications. I would very much like to
describe these use cases in the
On 16 Jul 2009, at 13:32, Livingood, Jason wrote:
Please do send me that list of applications. I would very much like
to
describe these use cases in the next version of the draft.
Yet another example. Many mail servers (including mine) reject SMTP
connections from hosts that don't have
At 9:15 AM +0200 7/16/09, Stephane Bortzmeyer wrote:
On Mon, Jul 13, 2009 at 01:59:46PM +0200,
Roy Arends r...@dnss.ec wrote
a message of 33 lines which said:
SSAC's Report on DNS Response Modification
http://www.icann.org/en/committees/security/sac032.pdf
Indeed. Good document. There is no
At 8:16 AM -0400 7/16/09, Livingood, Jason wrote:
I'll speak for my parents here: a DNS resolver that reduces the chance that
they'll get a drive-by malware
infection is something they would happily use. Having said that, a DNS
resolver that gives them a page of
search results instead of
Along with these good suggestions, the next draft should include a
brief description of why the desired behavior (as seen by the user) is
better performed through DNS tricks than through HTTP tricks.
John
On 2009Jul17, at 12:04 PM, Paul Hoffman wrote:
At 8:16 AM -0400 7/16/09, Livingood,
Jason, et al,
This note suggests changes in both style and detail in
draft-livingood-dns-redirect-00. All of the points made here have been made or
suggested by others in this thread; my intent is to underscore and elaborate on
those points, rather than to challenge development and publication
On Mon, Jul 13, 2009 at 01:59:46PM +0200,
Roy Arends r...@dnss.ec wrote
a message of 33 lines which said:
SSAC's Report on DNS Response Modification
http://www.icann.org/en/committees/security/sac032.pdf
Indeed. Good document. There is no need to discuss about
draft-livingood-dns-lie, all
On Mon, Jul 13, 2009 at 12:01:51PM -0700,
Paul Hoffman paul.hoff...@vpnc.org wrote
a message of 17 lines which said:
Some of the services defined in the draft are highly desired by some
Internet users.
I did not hear them so this sort of users is obviously not in the
dnsop WG :-) More
* Alan Barrett:
I think that this sort of lying recursive resolver is a bad idea.
Instead, I suggest a new SUGGESTION RR type that could be returned
in the additional section of an error message. For example, if
you ask for www.example.invalid, you could get back an NXDOMAIN
error, with
* Paul Hoffman:
Paul: that's over the top. Some of the services defined in the draft
are highly desired by some Internet users.
Which ones?
Currently, when a user enters mcrsoft in the address bar, many
browsers will automatically send her to the Microsoft homepage. With
spoofed answers, he
On Thu, 16 Jul 2009, Mark Andrews wrote:
The problem is not resolving portal.isp.com. The problem is that
mail.xelerance.com resolves to portal.isp.com, but never makes
it because my validating stub resolver has a DNSSEC key loaded
for xelerance.com. A problem that in the future will become
Stephane Bortzmeyer wrote:
I regret one thing with SSAC 032: they mix wildcards in the zone and
lying resolvers. True, they have similarities but also differences
(for instance, wildcards in a zone follow the DNS protocol, and
therefore are compatible with DNSSEC) and I'm a bit tired of
At 9:22 AM +0200 7/16/09, Stephane Bortzmeyer wrote:
On Mon, Jul 13, 2009 at 12:01:51PM -0700,
Paul Hoffman paul.hoff...@vpnc.org wrote
a message of 17 lines which said:
Some of the services defined in the draft are highly desired by some
Internet users.
I did not hear them so this sort of
I'll speak for my parents here: a DNS resolver that reduces the chance that
they'll get a drive-by malware
infection is something they would happily use. Having said that, a DNS
resolver that gives them a page of
search results instead of the browser's error page when they mistype a URL
On Thu, Jul 16, 2009 at 08:07:50AM -0400,
Livingood, Jason jason_living...@cable.comcast.com wrote
a message of 76 lines which said:
FWIW, I think most ISPs that introduce such services see around a
0.1% opt-out rate.
What does it prove? Most ISP that introduces lying resolvers as an
opt-in
SSAC's Report on DNS Response Modification
http://www.icann.org/en/committees/security/sac032.pdf
Indeed. Good document. There is no need to discuss about
draft-livingood-dns-lie,
Is that really necessary?
all the issues raised here in this WG were
already in the SSAC document one year
TLDs, including your own zones. This is indeed not just Site Finder
all over again - it's far worse, and breaks far more applications than
Site Finder did.
Please do send me that list of applications. I would very much like to
describe these use cases in the next version of the draft.
FWIW, I think most ISPs that introduce such services see around a
0.1% opt-out rate.
What does it prove? Most ISP that introduces lying resolvers as an
opt-in service see a 0.1 % opt-out rate, too. It proves only that most
users do not dare to change the settings or are not informed or have
On Thu, 16 Jul 2009, Florian Weimer wrote:
(But I agree that a clean solution requires protocol development.)
No, it just requires browser user interface improvements.
Tony.
--
f.anthony.n.finch d...@dotat.at http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY
* Tony Finch:
On Thu, 16 Jul 2009, Florian Weimer wrote:
(But I agree that a clean solution requires protocol development.)
No, it just requires browser user interface improvements.
If you want to address the issue with hotspot doorway pages, you need
protocol changes.
Livingood, Jason wrote:
TLDs, including your own zones. This is indeed not just Site Finder
all over again - it's far worse, and breaks far more applications than
Site Finder did.
Please do send me that list of applications. I would very much like to
describe these use cases in the next
* Jason Livingood:
Actual consumer behavior doesn¹t really seem to work that
way, but I¹m not a behavioral psychologist. ;-) FWIW, I think most
ISPs that introduce such services see around a 0.1% opt-out rate.
I would expect a higher rate of Dnschange/Zlob infections at a typical
On Thu, 16 Jul 2009, Florian Weimer wrote:
If you want to address the issue with hotspot doorway pages, you need
protocol changes.
Better to use an intercepting proxy in that case, and for quarantining
infected hosts.
Protocol changes aren't sufficient because if you just extend DNS
without
On Jul 16, 2009, at 5:43 AM, Jeroen Massar wrote:
Livingood, Jason wrote:
Please do send me that list of applications. I would very much
like to
describe these use cases in the next version of the draft.
Please list The Internet as one of them, it kinda encompasses a
lot of
others too.
On Wed, Jul 15, 2009 at 09:16:06PM +0200, Roy Arends wrote:
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?
Yes, we
On Thu, 16 Jul 2009, David Conrad wrote:
I am *VERY* happy that DNSSEC is moving along perfectly fine
which will kill any kind of changing DNS results.
DNSSEC doesn't touch anything after the validator. It will have no effect on
the vast majority of Comcast (or other consumer oriented)
* Tony Finch:
On Thu, 16 Jul 2009, Florian Weimer wrote:
If you want to address the issue with hotspot doorway pages, you need
protocol changes.
Better to use an intercepting proxy in that case, and for quarantining
infected hosts.
Doesn't work if the user uses the employer's filtering
David Conrad wrote:
On Jul 16, 2009, at 5:43 AM, Jeroen Massar wrote:
Livingood, Jason wrote:
Please do send me that list of applications. I would very much like to
describe these use cases in the next version of the draft.
Please list The Internet as one of them, it kinda encompasses a lot
On Thu, 16 Jul 2009, Florian Weimer wrote:
* Tony Finch:
On Thu, 16 Jul 2009, Florian Weimer wrote:
If you want to address the issue with hotspot doorway pages, you need
protocol changes.
Better to use an intercepting proxy in that case, and for quarantining
infected hosts.
On Jul 16, 2009, at 11:43 AM, Jeroen Massar wrote:
Please. Enough hyperbole.
Unless you state that The Internet is only The Web, there are
other
users of The Internet though. Don't try and limit what other people
can do with this public resource.
Could we ratchet down the rhetoric?
DNS
On Jul 16, 2009, at 10:27 AM, Paul Wouters wrote:
DNSSEC doesn't touch anything after the validator. It will have no
effect on the vast majority of Comcast (or other consumer oriented)
ISPs' customers.
Fedora 12 is slated to run with a validator on every machine.
This is the right
In message 20090716110830.ga7...@shinkuro.com, Andrew Sullivan writes:
Well, I'd discuss it, anyway. I know that if someone came with a
document outlining the best way to do split-brain DNS -- which is
widely deployed and an alternative namespace if ever I've seen one --
and especially how
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 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
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.
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
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
In message alpine.lfd.1.10.0907151439100.31...@newtla.xelerance.com, 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
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.
- Original Message -
From: Roy Arends r...@dnss.ec
..
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.
On Thu, 09 Jul 2009, Livingood, Jason wrote:
I submitted this draft, which you can find at
http://tools.ietf.org/html/draft-livingood-dns-redirect-00, before
the =??00 cutoff on Monday, and it will be discussed in the DNSOP WG
meeting at IETF 75 (it is listed on the agenda).
I think that this
On 7/14/09 8:58 AM, Suzanne Woolf wo...@isc.org wrote:
In this case, we're talking about resolvers replacing
authoritative server data with their own.
Actually, I thought the case was resolvers providing an alternate response,
where NO authoritative data exists. ??
To the draft
Actually, I thought the case was resolvers providing an alternate
response,
where NO authoritative data exists. ??
An NXDOMAIN response is still authoritative data.
Ray
--
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: r...@nominet.org.uk, t: +44 1865 332211
On Mon, 13 Jul 2009, Andrew Sullivan wrote:
Section 7.5 seems to suggest that there are cases where it is
acceptable to intercept DNS queries and redirect them silently. These
cases are typified as being reasonable, justifiable, c. The
problem with any of this sort of thing is that it is
On Mon, Jul 13, 2009 at 09:55:42AM -0400, Livingood, Jason wrote:
On the topic of lying resolvers though, that seems a bit strong IMHO. But
perhaps I have missed a strong MUST statement (per RFC 2119) in a relevant
RFC that you could refer me to?
It's always seemed to me that it was implicit
On Tue, Jul 14, 2009 at 09:15:24AM -0400, Livingood, Jason wrote:
On 7/14/09 8:58 AM, Suzanne Woolf wo...@isc.org wrote:
In this case, we're talking about resolvers replacing
authoritative server data with their own.
Actually, I thought the case was resolvers providing an alternate
At 9:15 AM -0400 7/14/09, Livingood, Jason wrote:
On 7/14/09 8:58 AM, Suzanne Woolf wo...@isc.org wrote:
In this case, we're talking about resolvers replacing
authoritative server data with their own.
Actually, I thought the case was resolvers providing an alternate response,
where NO
On Tue, Jul 14, 2009 at 02:25:33PM +0100, Tony Finch wrote:
Captive portals come to mind, e.g. to authenticate to a wireless access
point, or to quarantine a customer's virus-infested computer.
There are in fact ways to do that without mucking with DNS answers.
Some portals do such things, and
On Sat, Jul 11, 2009 at 04:59:38PM -0700,
Paul Hoffman paul.hoff...@vpnc.org wrote
a message of 8 lines which said:
Having said that, the publication of a document such as this (with
more input from the community) as a Informational RFC could indeed
help the Internet.
I doubt it. IMHO,
On Mon, Jul 13, 2009 at 03:27:56PM +0100,
ray.bel...@nominet.org.uk ray.bel...@nominet.org.uk wrote
a message of 51 lines which said:
At least when you do it on your recursive servers you're only affecting
your own customers, who in most cases can vote with their wallets when
they don't
On Mon, Jul 13, 2009 at 04:29:49PM -0400,
Andrew Sullivan a...@shinkuro.com wrote
a message of 33 lines which said:
It is a fact that people are doingthese DNS tricks, and we will not
be saved from them by refusing totalk about them any more than we
were saved from the stupidestpossible NAT
On Mon, Jul 13, 2009 at 09:20:12PM -0400, Livingood, Jason wrote:
Great and detailed feedback on our first draft, Andrew. I'll take a reply
in detail, point-by-point, when I start working on -01 with my co-authors
and contributors.
Thanks
Jason
jason
andrew pretty much covered it
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 should not use a DNS server
that misbehaves as described in
Ralf Weber wrote:
No redirection on SERVFAIL seems to be a strange recommendation.
Wouldn't this be a very good reason to provide a diagnostics page,
especially if there's been a DNSSEC validation failure?
This sounds like an excellent idea to help DNSSEC adoption and
is something that should
* Ralf Weber:
That really is an issue and could be addressed, there are a lot of
case where a A record for a domain doesn't exists, but one for
www.domain does exist.
True, and some browser have code to deal with this.
Question then would be how that rewrite should be presented. As a
* Jelte Jansen:
Ralf Weber wrote:
No redirection on SERVFAIL seems to be a strange recommendation.
Wouldn't this be a very good reason to provide a diagnostics page,
especially if there's been a DNSSEC validation failure?
This sounds like an excellent idea to help DNSSEC adoption and
is
Florian Weimer wrote:
* Jelte Jansen:
Ralf Weber wrote:
No redirection on SERVFAIL seems to be a strange recommendation.
Wouldn't this be a very good reason to provide a diagnostics page,
especially if there's been a DNSSEC validation failure?
This sounds like an excellent idea to help
On Mon, 13 Jul 2009, Florian Weimer wrote:
* Jelte Jansen:
then a SERVFAIL will also result in an e-mail bounce that says
connection refused
Not a hard 5xx error?
No, both SERVFAIL and connection refused are equivalent to 4yz temporary
failures.
instead of DNS error (assuming there's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
-Original Message-
From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of
Stephane Bortzmeyer
Subject: Re: [DNSOP] Review of draft-livingood-dns-redirect-00
Disclaimer: I find the whole idea a very bad one
On Jul 13, 2009, at 1:53 PM, Antoin Verschuren wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
-Original Message-
From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On
Behalf Of
Stephane Bortzmeyer
Subject: Re: [DNSOP] Review of draft-livingood-dns-redirect-00
Good guidance on Informational vs. BCP. We may get there eventually, but I
thought that starting as a draft BCP might provoke more detailed and useful
debate. ;-)
On the topic of lying resolvers¹ though, that seems a bit strong IMHO. But
perhaps I have missed a strong MUST statement (per RFC
Good feedback, which I will take into consideration for our 01 revision.
Please do note that Section 10 is definitely immature, as we noted in the
Open Issues (#5) in Appendix B. We¹ll be developing this section quite a
bit.
Thanks
Jason
On 7/13/09 4:12 AM, Roy Arends r...@dnss.ec wrote:
On
Thanks for the suggestion, Tony. I will add that to my tracking list for
the next revision (and may email you to confirm what I have might be
satisfactory). I think we probably also need to address the fact that mail
servers should not use resolvers that perform DNS redirect (this was assumed
On Mon, 13 Jul 2009, Livingood, Jason wrote:
I think we probably also need to address the fact that mail servers
should not use resolvers that perform DNS redirect (this was assumed but
should be explicit).
I think you need to widen that caveat: anything that isn't a web browser
should not
I think we probably also need to address
the fact that mail servers should not use resolvers that perform DNS
redirect (this was assumed but should be explicit).
At least when you do it on your recursive servers you're only affecting
your own customers, who in most cases can vote with their
On Mon, 13 Jul 2009, Tony Finch 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 should not use a DNS server
that misbehaves as described in
Paul Hoffman wrote:
At 9:55 AM -0400 7/13/09, Livingood, Jason wrote:
On the topic of 'lying resolvers' though, that seems a bit strong IMHO. But perhaps I have missed a strong MUST statement (per RFC 2119) in a relevant RFC that you could refer me to?
I am not aware of an RFC that
Dear colleagues,
On Thu, Jul 09, 2009 at 11:23:48AM -0400, Livingood, Jason wrote:
If anyone is interested and has time before IETF 75, I¹m happy to take
feedback before then obviously. Please note that there is a list of open
items at the end, which we plan to address in subsequent versions.
Great and detailed feedback on our first draft, Andrew. I'll take a reply
in detail, point-by-point, when I start working on -01 with my co-authors
and contributors.
Thanks
Jason
On 7/13/09 4:29 PM, Andrew Sullivan a...@shinkuro.com wrote:
Dear colleagues,
On Thu, Jul 09, 2009 at 11:23:48AM
/presentation-ssac-prohibiting-redirection-22jun09-en.pdf.
this draft is more suitable for informational.
Yao Jiankang
CNNIC
- Original Message -
From: Livingood, Jason
To: dnsop@ietf.org
Sent: Thursday, July 09, 2009 11:23 PM
Subject: [DNSOP] Review of draft-livingood-dns-redirect-00
* Stephane Bortzmeyer:
Unless I'm wrong, the I-D about lying resolvers do not discuss the
issue of zone cuts.
If I type www.doesnotexistatall.com (the SLD does not exist and so I
should get a NXDOMAIN), I get the IP address of the ad Web server. If
I type .afnic.fr, I will get this IP
* Jason Livingood:
If anyone is interested and has time before IETF 75, I¹m happy to take
feedback before then obviously.
Few players perform NXDOMAIN rewriting. Instead, ANCOUNT=0 rewriting
is used. This causes all kinds of problems, including redirections
for example.com when it hasn't got
-Original Message-
From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org]
On Behalf Of Livingood, Jason
Sent: Thursday, July 09, 2009 8:24 AM
To: dnsop@ietf.org
Subject: [DNSOP] Review of draft-livingood-dns-redirect-00
I submitted this draft, which you can find at
http
It seems inappropriate for the IETF to bless lying resolvers as a Best Current
Practice. I doubt we as a community could have consensus on when lying is good,
when it is neutral, and when it is bad. Without such agreement, we can't agree
on how to run such servers. Having said that, the
On Thu, Jul 09, 2009 at 11:23:48AM -0400,
Livingood, Jason jason_living...@cable.comcast.com wrote
a message of 69 lines which said:
If anyone is interested and has time before IETF 75, I¹m happy to take
feedback before then obviously.
Disclaimer: I find the whole idea a very bad one, a
I submitted this draft, which you can find at
http://tools.ietf.org/html/draft-livingood-dns-redirect-00, before the 00
cutoff on Monday, and it will be discussed in the DNSOP WG meeting at IETF
75 (it is listed on the agenda).
If anyone is interested and has time before IETF 75, I¹m happy to
78 matches
Mail list logo
