On 14 apr 2012, at 01:50, Mark Andrews 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 external zone is
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* p
On 4/13/2012 2:19 PM, David Conrad wrote:
> Patrik,
>
> On Apr 13, 2012, at 2:00 PM, Patrik Fältström wrote:
>> What I am against is this *CHANGE* in who is responsible.
>
> I don't see NTAs changing who is responsible. I see it changing who
> absorbs the costs. Without NTAs, it is primarily the
In message <201204132230.q3dmupx9056...@bartok.nlnetlabs.nl>, Jaap Akkerhuis wr
ites:
> <...>
> 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 sur
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 a
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
https://www.ietf.org/mailman/
<...>
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 b
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
around the standards we created instead of helping Comcast.
On Apr 13, 2012, at 2:18 PM, Patrik Fältström 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 personal experience
On 13 apr 2012, at 23:34, David Conrad wrote:
>> http://kommunermeddnssec.se/maps.php
>
> Very interesting (and sad given the amount of red in relation to the amount
> of green). Any idea how many validation failures ISPs are seeing as a result?
Of course the red is more failures than validati
Patrik,
On Apr 13, 2012, at 2:22 PM, Patrik Fältström wrote:
> But if a validator suddenly see that something is costing them too much, they
> "just" turn off validation. Done!
Yes, however I don't think this is an outcome we want to encourage. At this
point in the deployment of DNSSEC, I'd th
On 13 apr 2012, at 23:22, Patrik Fältström wrote:
> On 13 apr 2012, at 23:19, David Conrad 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
On 13 apr 2012, at 23:19, David Conrad 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 no
Patrik,
On Apr 13, 2012, at 2:00 PM, Patrik Fältström wrote:
> What I am against is this *CHANGE* in who is responsible.
I don't see NTAs changing who is responsible. I see it changing who absorbs the
costs. Without NTAs, it is primarily the validator operator and those costs
can't be passed on
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 t
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 signatu
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
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
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 Consort
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 co
Doug Barton 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 BIND.
Tony.
--
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 attac
Stephan,
An interesting approach :
"if a parent removes DS information for a child, if it finds the child
to be in error,
then, can an attacker make the check fail (in order to get the DS
removed) ?"
At least one thing :
Unlike the "Dan Kaminsky" flavour of cache poisoning attach,
there is no w
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 "N
Hello,
Joe Abley wrote:
I think that we need a better mechanism to avoid lame delegations to the
AS112 servers, given their loosely-coordinated nature.
I like the idea that came up in Québec (which I shall attribute to
Warren Kumari since I've seen other people do that, although I was not
in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
FYI: This version adopts the review items from Alfred and Marc.
Best regards,
Matthijs
On 04/13/2012 09:11 AM, internet-dra...@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a wo
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations Working Group of
the IETF.
Title : DNSSEC Operational Practices, Version 2
Author(s) : Olaf M. Kolkman
27 matches
Mail list logo
