On Sat, Sep 25, 2010 at 10:34:15PM -0400, John R. Levine wrote:
Hmm. Are you talking about SiteFinder-like services?
Not really. There turn out to be a significant number of domains,
in the hundreds of thousands at least, that are purely evil.
IMHO, tens of millions is closer to reality.
On Tue, Sep 28, 2010 at 5:27 PM, Mark Andrews ma...@isc.org wrote:
In message
aanlktinbtpvjlqsl87v5xbd0kh_hn+t1wx2mhdfy2...@mail.gmail.comaanlktinbtpvjlqsl87v5xbd0kh_hn%2bt1wx2mhdfy2...@mail.gmail.com,
Phil
lip Hallam-Baker writes:
The most frustrating part about DNSSEC is that trying
On 28 Sep 2010, at 02:20, Phillip Hallam-Baker hal...@gmail.com wrote:
On Mon, Sep 27, 2010 at 10:48 AM, Tony Finch d...@dotat.at wrote:
On Fri, 24 Sep 2010, Phillip Hallam-Baker wrote:
DNSSEC is a mechanism for establishing inter-domain trust. It is not an
appropriate technology for
Because the root of trust for any enterprise is the enterprise itself.
Not ICANN.
On Mon, Sep 27, 2010 at 10:48 AM, Tony Finch d...@dotat.at wrote:
On Fri, 24 Sep 2010, Phillip Hallam-Baker wrote:
DNSSEC is a mechanism for establishing inter-domain trust. It is not an
appropriate
The most frustrating part about DNSSEC is that trying to pin down what it is
and what it is not, what it is trying to do and what it is not is like
trying to nail jello to a wall.
Whenever an issue is raised with the DNSSEC protocol, someone immediately
shoots back the reply 'well we are not
In message aanlktinbtpvjlqsl87v5xbd0kh_hn+t1wx2mhdfy2...@mail.gmail.com, Phil
lip Hallam-Baker writes:
The most frustrating part about DNSSEC is that trying to pin down what it is
and what it is not, what it is trying to do and what it is not is like
trying to nail jello to a wall.
DNSSEC
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi John,
On 09/26/2010 04:34 AM, John R. Levine wrote:
But we have real situtations where the opposite is true,
quite possibly more often than the other way around.
Not really. There turn out to be a significant number of domains, in
the
The point raised by John Levine is amongst my concerns.
And one of the reasons that I have been looking at a different approach to
the use of DNSSEC information that does not change the DNS model as
radically as the end to end DNSSEC model.
The idea of using DNS resolver as a proxy is a good one
That is not the right question.
The question should be, who chooses for me?
My answer to the question does not have to be the same as other people's.
Some people will want the full ICANN registry with every scammy malware site
and every DNS name registered five minutes ago. Others will prefer to
actually, it was the right questions... and the answers all distill
down to your reply. security and trust are in the eyes/validator
of the beholder. Sam Weiler borrowed the term local policy - which
trumps any middleman. Steve B. suggests VPNs (or their functioal
eqivalant) between the
I don't see why DNSSEC makes dropping out zones impossible.
All DNSSEC does is to enable the end point to know that there is data
missing. It does not provide the end zone with any way to find the missing
data, nor is there any user interaction that makes any real sense in that
situation.
But
On Fri, 24 Sep 2010, Phillip Hallam-Baker wrote:
DNSSEC is a mechanism for establishing inter-domain trust. It is not an
appropriate technology for intra-domain trust.
Why not?
Tony.
--
f.anthony.n.finch d...@dotat.at http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST
On 27September2010Monday, at 7:48, Tony Finch wrote:
On Fri, 24 Sep 2010, Phillip Hallam-Baker wrote:
DNSSEC is a mechanism for establishing inter-domain trust. It is not an
appropriate technology for intra-domain trust.
Why not?
Because the atomic unit of DNSSEC is a
On Sep 24, 2010, at 5:17 PM, John Levine wrote:
IANAL but would think that such practice should expose the operator
of the server or proxy to civil and/or criminal action, both from the
operators of the zones whose RRs are being misrepresented, and from
the users' whose applications are
[I suspect you may know much of this, but just in case...]
On Sep 24, 2010, at 5:16 PM, John Levine wrote:
Plan A: few consumers will use DNSSEC between their PCs and the ISP's
resolver, so they won't notice.
In general, consumers won't be using DNSSEC between their PCs and ISPs. PCs
Not sure I see the relationship between malware spam and DNSSEC.
See below.
But we have real situtations where the opposite is true,
quite possibly more often than the other way around.
Hmm. Are you talking about SiteFinder-like services?
Not really. There turn out to be a significant
Has the IETF (or rather then IAB) written any simple documents that
explain to less informed (i.e. marketing/product) managers why it is a
bad thing for a captive portal to spoof DNS replies?
(not just in regard to DNSSEC, but also in regards to just caching)
--
] He who is tired of Weird
At Fri, 24 Sep 2010 07:21:21 -0400, Michael Richardson wrote:
Has the IETF (or rather then IAB) written any simple documents that
explain to less informed (i.e. marketing/product) managers why it
is a bad thing for a captive portal to spoof DNS replies?
(not just in regard to DNSSEC, but
This document is probably relevant, although it goes the route of
providing guidelines for minimum breakage rather than forbidding.
http://tools.ietf.org/html/draft-livingood-dns-redirect-02
On Sep 24, 2010, at 8:38 AM, Alfred HÎnes wrote:
At Fri, 24 Sep 2010 07:21:21 -0400, Michael
c) draft-livingood-dns-redirect and draft-livingood-dns-malwareprotect
draft-livingood-dns-malwareprotect concerns what is primarily an opt-in
service to block known malware sites for end users. Hopefully that is
less controversial than the redirect one, but who knows.
At 6:18 PM + 9/24/10, Livingood, Jason wrote:
I'm a bit conflicted
though about whether to keep it as informational or consider historic.
If it describes something that you believe is currently deployed, even if you
think that deployment is non-optimal, it should be marked as Informational.
On Sep 24, 2010, at 8:38 AM, Alfred HÎnes wrote:
At Fri, 24 Sep 2010 07:21:21 -0400, Michael Richardson wrote:
Has the IETF (or rather then IAB) written any simple documents that
explain to less informed (i.e. marketing/product) managers why it
is a bad thing for a captive portal to spoof
IANAL but would think that such practice should expose the operator
of the server or proxy to civil and/or criminal action, both from the
operators of the zones whose RRs are being misrepresented, and from
the users' whose applications are affected.
I'm not a lawyer either, but I at least know
On Sep 24, 2010, at 5:17 19PM, John Levine wrote:
IANAL but would think that such practice should expose the operator
of the server or proxy to civil and/or criminal action, both from the
operators of the zones whose RRs are being misrepresented, and from
the users' whose applications are
It will be interesting to see what will happen to these services when DNSSEC
is used more widely.
Plan A: few consumers will use DNSSEC between their PCs and the ISP's
resolver, so they won't notice.
Plan B: consumers will observe that malicious impersonation of far away
DNS servers is
Plan A: few consumers will use DNSSEC between their PCs and the ISP's
resolver, so they won't notice.
Plan B: consumers will observe that malicious impersonation of far away
DNS servers is rare and exotic, but malware spam arrives hourly, so they
will make a rational tradeoff, take their ISP's
On 24September2010Friday, at 17:16, John Levine wrote:
Plan A: few consumers will use DNSSEC between their PCs and the ISP's
resolver, so they won't notice.
Plan B: consumers will observe that malicious impersonation of far away
DNS servers is rare and exotic, but malware spam arrives
27 matches
Mail list logo
