The information you provided to me really helps me a lot,thank you.
2009-04-24
马迪
发件人： John Schnizlein
发送时间： 2009-04-23 18:48:04
收件人： 马迪
抄送： dnsop
主题： Re: [DNSOP] dns data exchanged between host and local dns-sever
RFC 2845 - Secret Key Transaction Authentication for DNS (TSIG)
T
On Thu, Apr 23, 2009 at 05:37:22PM +, bmann...@vacation.karoshi.com wrote:
> i happen to agree w/ David here. there really is no serious technical
I would generally encourage that trend.
> the downsides are the LEOS (protecting our security), and the Shylocks
> who need to
On 22-Apr-2009, at 14:13, Peter Koch wrote:
this is to initiate a working group last call on
"DNSSEC Trust Anchor Configuration and Maintenance"
draft-ietf-dnsop-dnssec-trust-anchor-03.txt
ending Friday, 2009-05-08, 23:59 UTC. The tools site gives easy
access to
diffs and
On 22-Apr-2009, at 15:17, Paul Hoffman wrote:
Yes. For example, Ubuntu server "long term stable" releases are only
put out every few years. If you pick one of them, you start off with
an old image, then *hopefully* update as soon as you install. But,
if you just turn on some services, this
On Apr 23, 2009, at 1:11 PM, John Schnizlein wrote:
My guess is that the solutions for updating (end) host software will
get trustworthy enough to be used for DNSSEC trust anchors, and the
validation will end up in the (end) host. Until the host OS
manufacturers realize this is worth their while
locus of control. centralization of resource control.
lack of autonomy in an end-to-end system. trust anchor placement
is "just another brick in the wall" here. but i have now dragged out
my soapbox and i'm pretty sure this is not speakers corner...
so i'll shut up and go back in the w
Locus of control? Or that pesky old trust anchor?
Separable issues: where the validation computations are done, and
setting (and updating) the trust anchor. For computation, the
advantage of caching after validation in the (shared) recursive
resolver probably does not keep up with the per
On Thu, Apr 23, 2009 at 12:52:37PM -0400, Edward Lewis wrote:
> At 8:43 -0700 4/23/09, David Conrad wrote:
>
> >root servers). However the point is that you need to do the validation
> >someplace you can talk securely to. The easiest answer is to simply do the
> >validation on the same host.
> >
At 8:43 -0700 4/23/09, David Conrad wrote:
root servers). However the point is that you need to do the validation
someplace you can talk securely to. The easiest answer is to simply do the
validation on the same host.
I figure stub resolvers were needed when cpu/bandwidth/memory were a bit
mor
On Apr 23, 2009, at 5:34 AM, Shane Kerr wrote:
Not really true. Many people think that the validating resolver
should
be on the host itself.
Many? I can only dream.
This would use DNSSEC to secure even the last mile.
Presumably it would still forward queries to a nearby recursive
resolve
On Thu, 23 Apr 2009, 马迪 wrote:
As we all know, DNSSEC provides origin authentication and integrity assurance
services for DNS
data exchanged between DNS resolver and name-sever, while DNSSEC fails to give
a means by
which the DNS queries or responses transmitted between a host and a recursive
On Thu, 23 Apr 2009, W.C.A. Wijngaards wrote:
Shane Kerr wrote:
Presumably it would still forward queries to a nearby recursive
resolver, so there would be some shared caching going on?
Has anybody ever written this down anywhere? (Sorry if I missed it.)
It is called a validating stub.
And
On Thu, 23 Apr 2009, Andrew Sullivan wrote:
On Thu, Apr 23, 2009 at 02:54:20PM +0200, Shane Kerr wrote:
Okay, that's defined in RFC 4033, but has anybody ever written down that
this is the way everybody should do DNSSEC from now on?
Given that the largest provider of host operating systems cu
On Thu, 23 Apr 2009, bmann...@vacation.karoshi.com wrote:
Other channel security ideas that are floating around (but have nto gained
traction in the
IETF or market) are:
EDNS-PING
DNS-CURVE
dnscurve can never work. It removes ALL caching infrastructure from the
internet. Plea
On Apr 23, 2009, at 8:26 AM, Andrew Sullivan wrote:
Given that the largest provider of host operating systems currently
deployed is not planning to do DNSSEC this way, won't we have some
trouble if we start suggesting it's the right way
We can't force anybody to do anything. However, if this
On Thu, Apr 23, 2009 at 06:32:38PM +0800, i),h?* wrote:
> Hi, folks.
>
> As we all know, DNSSEC provides origin authentication and integrity assurance
> services for DNS data exchanged between DNS resolver and name-sever, while
> DNSSEC fails to give a means by which the DNS queries or response
On Thu, Apr 23, 2009 at 02:54:20PM +0200, Shane Kerr wrote:
> Okay, that's defined in RFC 4033, but has anybody ever written down that
> this is the way everybody should do DNSSEC from now on?
Given that the largest provider of host operating systems currently
deployed is not planning to do DNSSEC
Wouter,
W.C.A. Wijngaards wrote:
> Shane Kerr wrote:
>> Presumably it would still forward queries to a nearby recursive
>> resolver, so there would be some shared caching going on?
>
>> Has anybody ever written this down anywhere? (Sorry if I missed it.)
>
> It is called a validating stub.
Okay
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Shane Kerr wrote:
> Presumably it would still forward queries to a nearby recursive
> resolver, so there would be some shared caching going on?
>
> Has anybody ever written this down anywhere? (Sorry if I missed it.)
It is called a validating stub.
I have read the doc and support it. Some minor comments/suggestions
based on Ed's message:
Edward Lewis wrote:
> At 20:13 +0200 4/22/09, Peter Koch wrote:
>>this is to initiate a working group last call on
>>
>>"DNSSEC Trust Anchor Configuration and Maintenance"
>> draft-ietf-dnsop-dnssec
Stephane,
Stephane Bortzmeyer wrote:
> On Thu, Apr 23, 2009 at 06:32:38PM +0800,
> wrote
> a message of 85 lines which said:
>
>> while DNSSEC fails to give a means by which the DNS queries or
>> responses transmitted between a host and a recursive server could be
>> guaranteed integrity
True, which is why it depends on what the local network. If the
clients and recursive server are all part of the same organization,
there may already be sufficient network security mechanisms in place
that additional message authentication techniques (like TSIG) will not
add any new value.
Scott
On Thu, Apr 23, 2009 at 07:10:13AM -0400,
Scott Rose wrote
a message of 65 lines which said:
> Those are the DNS protocol mechanisms in place. There is also lower
> level security technologies such as IPsec that could be used between
> stub clients and recursive servers that don't rely on DNS
On Thu, Apr 23, 2009 at 06:32:38PM +0800,
wrote
a message of 85 lines which said:
> while DNSSEC fails to give a means by which the DNS queries or
> responses transmitted between a host and a recursive server could be
> guaranteed integrity and authentication.
Not really true. Many peop
Those are the DNS protocol mechanisms in place. There is also lower
level security technologies such as IPsec that could be used between
stub clients and recursive servers that don't rely on DNSSEC at all.
It depends on the network the client and recursive server are on.
Scott
John Schnizlein w
RFC 2845 - Secret Key Transaction Authentication for DNS (TSIG)
This protocol allows for transaction level authentication using shared
secrets and one way hashing. It can be used to authenticate dynamic
updates as coming from an approved client, or to authenticate
responses as coming from a
Hi, folks.
As we all know, DNSSEC provides origin authentication and integrity assurance
services for DNS data exchanged between DNS resolver and name-sever, while
DNSSEC fails to give a means by which the DNS queries or responses transmitted
between a host and a recursive server could be guar
27 matches
Mail list logo
