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
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
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
Stephane,
Stephane Bortzmeyer wrote:
On Thu, Apr 23, 2009 at 06:32:38PM +0800,
m...@cnnic.cn 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
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
-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.
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, that's
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 responses
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, 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
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.
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 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
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
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.
I figure
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
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
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 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 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
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)
21 matches
Mail list logo
