Hello,
(at the risk of launching a lot of weekend messages, again,
- which I read with great interest after some days of absence ...)
The draft on Negative Trust Anchor, section 7 : Use of a NTA
seems incomplete !
Actually, the validating caching name server is itself only an
intermediate step
-Original Message-
From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of
Warren Kumari
Sent: Monday, April 16, 2012 11:55 PM
To: Livingood, Jason
Cc: Joe Abley; Nick Weaver; Tony Finch; dnsop; Paul Vixie; Evan Hunt
Subject: Re: [DNSOP] on Negative Trust Anchors
At 21:03 15-04-2012, Ralf Weber wrote:
If the IETF or this group wants to ignore these operational facts
and not give new people guidance on how to deal with them, and do
nothing is not an acceptable advise here, I doubt that a lot of
people will adopt DNSSEC or move back after the first or
On Sun, Apr 15, 2012 at 09:24:35PM -0700, David Conrad wrote:
On Apr 15, 2012, at 6:28 PM, Scott Schmit wrote:
It's manual for now...until the utter lack of consequences for screwing
up (everybody can still get to the broken zones just fine) junks up the
NTA lists.
Given the implicit
Scott,
On Apr 16, 2012, at 4:52 AM, Scott Schmit wrote:
Given the implicit assertions associated with NTA (specifically, that
the validator operator is asserting that the zone in question is not
being spoofed despite the fact that validation is failing), I have
some skepticism that folks will
On 2012-04-15, at 20:02, Scott Schmit wrote:
On Fri, Apr 13, 2012 at 04:38:10PM -0700, David Conrad wrote:
On Apr 13, 2012, at 3:30 PM, Jaap Akkerhuis wrote:
More pragmatically, while I understand the theory behind rejecting NTAs,
I have to admit it feels a bit like the IETF rejecting NATs
Inline.
- JL
On 4/12/12 8:21 AM, Marc Lampo marc.la...@eurid.eu wrote:
The draft of Negative Trust Anchors does not mention anything about
informing the operator of the failing domain.
I'll make a note to call this out in the next version. Something about
making reasonable attempts to notify
On 4/13/12 1:43 PM, Paul Vixie p...@redbarn.org wrote:
we need to move quickly to the point where lots of large eyeball-facing
network operators are validating, such that any failure to properly
maintain signatures and keys and DS records, is felt most severely by
whomever's domain is thus
On 4/13/12 5:00 PM, Patrik Fältström
p...@frobbit.semailto:p...@frobbit.se wrote:
In a private chat I am asked to explain my +1.
Let me explain why.
Today, before negative trust anchors, the responsibility for whether a the
resolution that is basis for a connection establishment is with the
On 4/13/12 5:18 PM, Patrik Fältström
p...@frobbit.semailto:p...@frobbit.se wrote:
On 13 apr 2012, at 22:44, Nicholas Weaver wrote:
Because practice has shown that it is the recursive resolver, not the
authority, that gets blamed.
As you saw in my mail, I completely disagree from my own
On 4/13/12 9:51 PM, Doug Barton do...@dougbarton.us wrote:
The problem, and I cannot emphasize this highly enough, is that there is
absolutely no way for an ISP (or other end-user site doing
recursion/validation) to determine conclusively that the failure they
are seeing is due to a harmless
On 4/14/12 9:23 PM, Warren Kumari war...@kumari.net wrote:
Yes, but ATT, Verizon, Cox, BestWeb, RR, TW, etc are currently *not*
doing validation, and currently don't have much in the way of incentives
to start -- yes, NASA was an unusual event, but what was the standard
advice that kept popping
On 4/15/12 10:42 AM, Joe Abley joe.ab...@icann.org wrote:
Patrik,
Nobody is talking about creating NTAs. NTAs already exist. The question
for this group is whether or not they are worth standardising.
Joe
Quite true, Joe! We'll keep using NTAs as needed. But I've had enough
people ask me to
On Mon, Apr 16, 2012 at 08:32:59AM -0700, David Conrad wrote:
On Apr 16, 2012, at 4:52 AM, Scott Schmit wrote:
Please explain how operators will prevent this, and why they can
afford to remove a zone from the NTA list (while it is still
failing) but couldn't afford to leave it off the list
On 15 apr 2012, at 03:23, Warren Kumari wrote:
Once most ISPs are performing validation there should be fewer screwups, and
NTAs should be almost never needed -- but until we get to that point I think
that they are needed, and the net security wins outweigh the costs…
...and my point is
Patrik,
Nobody is talking about creating NTAs. NTAs already exist. The question for
this group is whether or not they are worth standardising.
Joe
Sent from my Ono-Sendai Cyberspace 7
On 2012-04-15, at 2:34, Patrik Fältström p...@frobbit.se wrote:
On 15 apr 2012, at 03:23, Warren Kumari
Doug,
On Apr 13, 2012, at 6:51 PM, Doug Barton wrote:
The problem is that there is absolutely no way for an ISP to determine
conclusively that the failure they are seeing is due to a harmless stuff-up,
vs. an actual security incident.
I suspect that in most cases, grepping through logs and
On 2012-04-15 4:09 PM, Patrik Fältström wrote:
On 15 apr 2012, at 16:42, Joe Abley wrote:
Nobody is talking about creating NTAs. NTAs already exist. The question for
this group is whether or not they are worth standardising.
Fair. I am the one that extrapolate from standardizing to wide
Patrik Fältström, Sunday, April 15, 2012 1:34 AM:
...and my point is that the effort should be spent on convincing ATT,
Cox and others to do validation just like Comcast. And to inform the
users, press and others that for example it was NASA and not Comcast
that had problems.
Convincing
On Apr 14, 2012, at 1:38 AM, David Conrad wrote:
On Apr 13, 2012, at 3:30 PM, Jaap Akkerhuis wrote:
More pragmatically, while I understand the theory behind rejecting NTAs,
I have to admit it feels a bit like the IETF rejecting NATs and/or DNS
redirection. I would be surprised if folks who
David Conrad, Sunday, April 15, 2012 11:15 AM:
I suspect that in most cases, grepping through logs and comparing past
(validated) results with current (unvalidated) results can provide
sufficient information to ensure to an arbitrary level of certainty
that the bad thing either is or is not
On 2012-04-15 4:20 PM, Stephan Lagerholm wrote:
... However, the open resolvers that don't support DNSSEC are a bigger
issue since the Service Providers' customer instantly can get what
he believes is a better working resolver by switching to one of those.
If we could convince 8.8.8.8
On 15 apr 2012, at 17:46, David Conrad wrote:
The decisions as to whether to deploy an NTA vs. whether to deploy DNSSEC are
made a different times and (I suspect) different places within the
organization. Obviously, an organization must decide to deploy DNSSEC before
the question of
Stephan,
On Apr 15, 2012, at 9:36 AM, Stephan Lagerholm wrote:
David Conrad, Sunday, April 15, 2012 11:15 AM:
I suspect that in most cases, grepping through logs and comparing past
(validated) results with current (unvalidated) results can provide
sufficient information to ensure to an
On Apr 15, 2012, at 9:37 AM, Paul Vixie wrote:
i'd tell validator operators who think they need NTA's in
order to control the risks posed by zone owner errors, if you can't
stand the heat then stay out of the kitchen.
Given the benefits provided by DNSSEC (to date) are largely invisible and
Patrik,
On Apr 15, 2012, at 10:19 AM, Patrik Fältström wrote:
I.e. with the help of standardized NTAs, it will be easier for parties to
always be able to give back responses, regardless of whether they validate or
not.
Or, more specifically, will be easier for parties to give back the same
On 2012-04-15 7:04 PM, David Conrad wrote:
On Apr 15, 2012, at 9:37 AM, Paul Vixie wrote:
i'd tell validator operators who think they need NTA's in
order to control the risks posed by zone owner errors, if you can't
stand the heat then stay out of the kitchen.
Given the benefits provided by
Paul,
On Apr 15, 2012, at 1:12 PM, Paul Vixie wrote:
I thought we'd learned that flag day deployments don't work on the Internet
anymore.
i thought so too until we had world ipv6 day last year.
I'm not sure how world IPv6 day changes anything. It's not like IPv6 saw a
significant (relative
On Fri, Apr 13, 2012 at 04:38:10PM -0700, David Conrad wrote:
On Apr 13, 2012, at 3:30 PM, Jaap Akkerhuis wrote:
More pragmatically, while I understand the theory behind rejecting NTAs,
I have to admit it feels a bit like the IETF rejecting NATs and/or DNS
redirection. I would be surprised
On Sun, Apr 15, 2012 at 02:07:20PM -0700, David Conrad wrote:
On Apr 15, 2012, at 1:12 PM, Paul Vixie wrote:
i seek to avoid legitimizing the igor hack in bind9, and
negative trust anchors.
My impression is that what is being proposed is standardizing on the
moral equivalent of a
Moin!
Not to answer anyone specific, as a lot of people seemed to spend their weekend
commenting on this and I don't want to increase the incoming mail folders too
much.
In general I agree with what David Conrad said, but want to spare you of a
couple of +1 mails and just want to add some
On 2012-04-15 9:07 PM, David Conrad wrote:
I guess in the end it boils down to the philosophical question of the
role of the IETF. If DNSOP declines to accept this topic, I suspect it
merely means each vendor will come up with their own implementation
with their own quirks that operators will
On Apr 15, 2012, at 9:05 PM, Paul Vixie wrote:
if you don't want something to live forever and get turned on by default
or left on across sysadmin churn, don't put it in an RFC.
Weren't we talking about requiring an explicit lifetime on NTAs? I'd be all for
SHOULDs/MUSTs that increase the
Scott,
On Apr 15, 2012, at 6:28 PM, Scott Schmit wrote:
It's manual for now...until the utter lack of consequences for screwing
up (everybody can still get to the broken zones just fine) junks up the
NTA lists.
Given the implicit assertions associated with NTA (specifically, that the
On 14 apr 2012, at 00:30, Jaap Akkerhuis wrote:
(paf)
But, all of this thinking leads me to think about DNSSEC validation
risks are very similar to the risk with deploying IPv6?
We have an IPv6 day, but why not a DNSSEC day? One day where
*many* players at
On 14 apr 2012, at 01:50, Mark Andrews ma...@isc.org wrote:
What one needs to do is validate answers from one's own zones
internally as well as answers from the rest of the world.
Unfortunately too many of the broken zones we have in Sweden are the ones where
split DNS is in use and the
On Apr 13, 2012, at 3:30 PM, Jaap Akkerhuis wrote:
More pragmatically, while I understand the theory behind rejecting NTAs,
I have to admit it feels a bit like the IETF rejecting NATs and/or DNS
redirection. I would be surprised if folks who implement NTAs will stop
using
On 2012-04-14 1:51 AM, Doug Barton wrote:
... The problem, and I cannot emphasize this highly enough, is that
there is absolutely no way for an ISP (or other end-user site doing
recursion/validation) to determine conclusively that the failure they
are seeing is due to a harmless stuff-up, vs.
On Apr 13, 2012, at 6:02 PM, Patrik Fältström wrote:
On 13 apr 2012, at 23:43, Nicholas Weaver wrote:
Likewise, comcast being blamed for...
Because (1) they seem to be the only large resolver operator that do
validation(?) and (2) people like us on this list try to work out end runs
Mark Andrews, Thursday, April 12, 2012 11:43 PM:
-Original Message-
From: Mark Andrews [mailto:ma...@isc.org]
Sent: Thursday, April 12, 2012 11:43 PM
To: Stephan Lagerholm
Cc: Ralf Weber; Marc Lampo; Nicholas Weaver; dnsop@ietf.org;
Livingood,
Jason
Subject: Re: [DNSOP] on Negative
-Original Message-
From: Stephan Lagerholm [mailto:stephan.lagerh...@secure64.com]
Sent: 13 April 2012 04:21 PM
To: Mark Andrews
Cc: Ralf Weber; Marc Lampo; Nicholas Weaver; dnsop@ietf.org; Livingood,
Jason
Subject: RE: [DNSOP] on Negative Trust Anchors
Mark Andrews, Thursday, April 12, 2012
Responding to a message at random ...
I skimmed the draft, and with respect to the authors this is a terrible
idea.
DNSSEC is pointless if it's not used as designed. Providing an easy way
to bypass validation makes many things worse instead of better ... not
the least of which is that if an
Doug Barton do...@dougbarton.us wrote:
Furthermore, the mechanism is not necessary, since if you somehow had
knowledge that it was safe to use the data even if it doesn't validate
you can temporarily set up a forward zone that points to a
non-validating resolver.
AFAIK that doesn't work in
the information economics of this draft are all wrong. with all possible
respect for the comcast team who is actually validating signatures for
18 million subscribers and is therefore way ahead of the rest of the
industry and is encountering the problems of pioneers... this is not
supposed to be
On Fri, Apr 13, 2012 at 05:43:42PM +, Paul Vixie wrote:
i'm opposed to negative trust anchors, both for their security
implications if there were secure applications in existence, and for
their information economics implications.
+1
--
Evan Hunt -- e...@isc.org
Internet Systems
On 13 apr 2012, at 22:09, Evan Hunt wrote:
On Fri, Apr 13, 2012 at 05:43:42PM +, Paul Vixie wrote:
i'm opposed to negative trust anchors, both for their security
implications if there were secure applications in existence, and for
their information economics implications.
+1
+1
On Apr 13, 2012, at 1:24 PM, Patrik Fältström wrote:
On 13 apr 2012, at 22:09, Evan Hunt wrote:
On Fri, Apr 13, 2012 at 05:43:42PM +, Paul Vixie wrote:
i'm opposed to negative trust anchors, both for their security
implications if there were secure applications in existence, and for
On 13 apr 2012, at 22:24, Patrik Fältström wrote:
+1
In a private chat I am asked to explain my +1.
Let me explain why.
Today, before negative trust anchors, the responsibility for whether a the
resolution that is basis for a connection establishment is with the zone owner.
If the signature
On 13 apr 2012, at 22:44, Nicholas Weaver wrote:
Because practice has shown that it is the recursive resolver, not the
authority, that gets blamed.
As you saw in my mail, I completely disagree from my own personal experience.
If I look at the number of failures, the number of cases where
...
More pragmatically, while I understand the theory behind rejecting NTAs,
I have to admit it feels a bit like the IETF rejecting NATs and/or DNS
redirection. I would be surprised if folks who implement NTAs will stop
using them if they are not accepted by
On Apr 13, 2012, at 2:39 PM, Patrik Fältström wrote:
http://kommunermeddnssec.se/maps.php
This is one of the coolest thing i have clicked in long time.. thanks for
sharing
mehmet
___
DNSOP mailing list
DNSOP@ietf.org
On Apr 13, 2012, at 3:30 PM, Jaap Akkerhuis wrote:
More pragmatically, while I understand the theory behind rejecting NTAs,
I have to admit it feels a bit like the IETF rejecting NATs and/or DNS
redirection. I would be surprised if folks who implement NTAs will stop
using them if they are not
Hello,
this is not a reply to any comment already made on this approach
of negative trust anchors.
(I just posted a reply with RFC4641bis in the subject, about this)
It holds an alternative possibility to overcome the problem
- for operators of validating name servers - of failing domains
Moin!
On 12.04.2012, at 14:21, Marc Lampo wrote:
It holds an alternative possibility to overcome the problem
- for operators of validating name servers - of failing domains
because of DNSSEC.
The alternative is to have a parent regularly (no frequency defined)
check the coherence of DS
Mark,
On 12.04.2012, at 14:21, Marc Lampo wrote:
It holds an alternative possibility to overcome the problem
- for operators of validating name servers - of failing domains
because of DNSSEC.
The alternative is to have a parent regularly (no frequency defined)
check the coherence of
On Thu, Apr 12, 2012 at 08:27:21AM -0600, Stephan Lagerholm wrote:
Specifically in this case, you are assuming that the parent knows the
algorithms used for the DS record. He would have to in order to
validate. That might not always hold true. Additionally, the record is
not 'yours', it is
In message dd056a31a84cfc4ab501bd56d1e14bbbd2e...@exchange.secure64.com,
Steph
an Lagerholm writes:
Mark,
On 12.04.2012, at 14:21, Marc Lampo wrote:
It holds an alternative possibility to overcome the problem
- for operators of validating name servers - of failing domains
because of
Mark Andrews Thursday, April 12, 2012 6:10 PM:
On 12.04.2012, at 14:21, Marc Lampo wrote:
It holds an alternative possibility to overcome the problem
- for operators of validating name servers - of failing domains
because of DNSSEC.
The alternative is to have a parent
In message dd056a31a84cfc4ab501bd56d1e14bbbd2e...@exchange.secure64.com,
Steph
an Lagerholm writes:
Mark Andrews Thursday, April 12, 2012 6:10 PM:
On 12.04.2012, at 14:21, Marc Lampo wrote:
It holds an alternative possibility to overcome the problem
- for operators of validating
59 matches
Mail list logo
