On 11/12/2015 01:30 AM, Tim Wicinski wrote:
>
> (as chair)
>
> I was the one who told Mark I liked the document but we needed to do
> less badgering of TLDs (my words, not his) and more on giving them
> advice on the best practices.
>
+1
I'd like to add that they may be badgered just as hard f
On 2017-04-05 16:50, Mukund Sivaraman wrote:
>> Also, it is weird that a draft that is about having a fallback if a hash
>> algorithm becomes weakened uses the RSASSA-PKCS1-v1_5 signature scheme,
>> given that PKCS1 1.5 is already known to be weakened.
>
> It was to allow simple addition of the al
Joe Abley wrote:
>
>
> I think what is interesting to me is to examine EDNS0 availability
> amongst the class of queries that can reasonably be answered. I don't
> much care whether queries that can't be answered support EDNS0.
>
> But others may be interested in different things :-)
>
How imp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gervase Markham wrote:
> Florian Weimer wrote:
>> * Jamie Lokier:
>> Yes. I think Ebay suffers from these issues.
>
> Indeed. This is one of the reasons that livejournal switched from
> www.livejournal.com/name to name.livejournal.com. It prevented r
Jaap Akkerhuis wrote:
> On Tue, Aug 19, 2008 at 10:35:54AM -0700, David Conrad wrote:
>
> > it in their products or services. Peter Koch did provide an
> interesting
> > data point that warrants further investigation (20-35% of queries
> having DO
> > bit on seems a bit hi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
during some work on DNSKEY maintenance, I think i found a potential
operational issue. If we are going to do new work on DNSSEC Operational
Practices, I would like to suggest to add a text similar to that
attached to this message.
The issue lies
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark Andrews wrote:
> It's not a issue. You remove the DS's which have that
> algorithm then once they have expired from caches you can
> remove the DNSKEY.
That could still leave the zone itself in an inconsistent state... I'm
not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Resending my message because of the ietf mailing list problems
- Original Message
Subject: Re: [DNSOP] suggestion for 4641bis: key algorithm rollover section
Date: Fri, 05 Sep 2008 10:32:35 +0200
From: Jelte Jansen <[EM
t;[EMAIL PROTECTED]>
To: Dean Anderson <[EMAIL PROTECTED]>
CC: Jelte Jansen <[EMAIL PROTECTED]>, dnsop@ietf.org
> On Thu, 4 Sep 2008, Mark Andrews wrote:
>
> >
> > It's not a issue. You remove the DS's which have that
> > algorithm t
And Mark's reply to my previous message:
Original Message
Subject: Re: [DNSOP] suggestion for 4641bis: key algorithm rollover section
Date: Fri, 05 Sep 2008 18:39:49 +1000
From: Mark Andrews <[EMAIL PROTECTED]>
To: Jelte Jansen <[EMAIL PROTECTED]>
CC: dnsop@
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark Andrews wrote:
>
> What I'm getting from this is that the keyset at the apex must (at
> least) be signed by each algorithm in the DS referral, and every rrset
> in the zone must be signed by each algorithm in the apex keyset.
>
>> which is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Edward Lewis wrote:
> At 1:28 +0100 3/27/09, Holger Zuleger wrote:
>
>> So why doesn't an authoritative name server set the AD bit on answers
>> to queries with the DO flag set?
>
> Good question. Perhaps the authoritative server does not have DNSSE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Hoffman wrote:
>
> At 11:32 AM -0400 4/24/09, Paul Wouters wrote:
>> So it seems to me that using 1024 bit RSA keys for ZSK, and 2048 bit
>> keys for KSK, assuming RFC 4641 rollover periods, are still many orders
>> of magnitude safe for our use
Ralf Weber wrote:
No redirection on SERVFAIL seems to be a strange recommendation.
Wouldn't this be a very good reason to provide a diagnostics page,
especially if there's been a DNSSEC validation failure?
This sounds like an excellent idea to help DNSSEC adoption and
is something that should go
Florian Weimer wrote:
* Jelte Jansen:
Ralf Weber wrote:
No redirection on SERVFAIL seems to be a strange recommendation.
Wouldn't this be a very good reason to provide a diagnostics page,
especially if there's been a DNSSEC validation failure?
This sounds like an excellent id
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
i had asked for a small AOB slot at the dnsop meeting, but only just before, so
either it was forgotten or simply skipped because we were already late, so i'll
just misuse the mailing list instead. My apologies :)
A while back, a requirements do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
the slide that mentioned algorithm rollover mentioned it at a diagram of
double-signature rolls, which will probably not be sufficient
for that, see
http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis-01#section-4.2.4
(btw i agree with olaf t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Johan Ihren wrote:
>
> I don't remember exactly what I said, but what I meant was not that
> "double signature" is sufficient to accomplish an algorithm rollover,
> only that it was needed as part of one. So I think you and I agree hee.
>
I think so
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ok, so audio lag + jabber lag + trying to get a question into one line for
relaying does not a easygoing discussion make :)
My question was this; in the presentation I saw a list of issues that are
considered resolved and a list of issues that are st
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
the introduction suggests that the root has not been signed yet.
Jelte
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEUEARECAAYFAkxOp3AACgkQ4nZCKsdOncXkGQCYolq1E11tE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
forwarding this announcement here, since this list contains a lot of people
likely to be interested in the effort; if you also follow ietf-announce, my
apologies for the double message.
There is now a mailinglist for nameserver control protocol
On 11/09/2010 02:33 AM, Roy Arends wrote:
4.2.1 KSK Compromise (2nd paragraph)
A compromised KSK used by an attacker can also sign data in the zone other than
the key set. An attacker does not need to follow the definitions of KSK vs ZSK.
I wonder how different implementations handle this case
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/07/2010 12:36 PM, Stephen Morris wrote:
> At the WG meeting in Beijing, the somewhat inconclusive discussion on a
> nameserver control protocol was ended by the suggestion that the authors of
> the two drafts discussed should write a short piec
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/26/2011 06:58 PM, Stephen Morris wrote:
> To restart the dormant discussion on NSCP...
>
keeping it on life-support :)
> On 13 Dec 2010, at 08:51, Jelte Jansen wrote:
>
>> It has been said (perhaps by you) that perhaps
On 11/12/2013 09:20 AM, Tim Wicinski wrote:
>
> I've uploaded the minutes, with an initial editing pass. There are
> located here:
>
> http://www.ietf.org/proceedings/88/minutes/minutes-88-dnsop
>
I wasn't there, and wasn't able to follow remotely this time, but I
assume that "Evan Hunt: csync
On 03/03/2014 09:25 AM, Norbert Bollow wrote:
> Warren makes a strong argument in favor of .alt I think.
>
> Another related aspect is that if something like onion.notreallydns.org
> is used, with notreallydns.org registered for the specific purpose of
> providing a home for one or more non-resolv
On 03/03/2014 01:43 PM, Ted Lemon wrote:
> On Mar 3, 2014, at 1:32 PM, Tony Finch wrote:
>> As well as Joe's AS112 argument there is also the question of DNSSEC
>> validation - but perhaps we don't want non-DNS names to make any kind of
>> sense in this respect... cf. .local
>
> Indeed, it doesn'
On 03/03/2014 02:03 PM, Andrew Sullivan wrote:
> On Mon, Mar 03, 2014 at 01:56:20PM +0000, Jelte Jansen wrote:
>> I'd think that a domain name is only a domain name when whatever
>> protocol it is defined in defines it as a domain name (or whatever
>> undefined prot
On 03/05/2014 01:27 PM, Francis Dupont wrote:
>
> Personally I don't like the idea of DNS encryption but because I
> don't want to give a reason to ISPs to filter port 53.
>
This is something I worry about too. If we consider the resolver itself
out of scope, and only protect the wire, all the mo
On 03/05/2014 02:40 PM, João Damas wrote:
>
> perhaps there is a need to separate the problem into tractable
> chunks. For the part of the problem about authenticating the
> recursive resolver (the fake 8.8.8.8 problem) we probably a
> different solution than for the metadata snooping problem (who
On 03/06/2014 02:39 PM, Stephane Bortzmeyer wrote:
>> all the more reasons for ISPs to try and force you to use theirs
>> (perhaps even after some friendly coercion from the nearest
>> three-letter agency (four in the netherlands as well)). In which
>> case we'd need even better channel encryption,
On 04/01/2014 03:39 PM, Phillip Hallam-Baker wrote:
>
> Yes, I agree, but you are proposing a different DNSSEC model to the one
> they believe in.
>
> The DNS world has put all their eggs into the DNSSEC from Authoritative
> to Stub client model. They only view the Authoritative to Resolver as a
On 05/16/2014 02:18 PM, Andrew Sullivan wrote:
>
> First, if resolvers have expectations about consistency of zones and
> so on, then they're broken. The DNS has only ever been loosely
> coherent. You're simply _not allowed_ to make that assumption from
> any point in the network except inside t
On 05/18/2014 07:58 AM, Patrik Fältström wrote:
>
>> It might be worth actively pushing the CDN folks to go the SRV direction.
>> Even if ENAME were a good idea, which is not clear to me, it's an idea that
>> would require significant infrastructure changes, whereas SRV records appear
>> to b
On 05/20/2014 12:12 AM, David C Lawrence wrote:
>
> Looking at a random high-traffic DNS server on our network, I see
> practically no use at all of _http._tcp SRV requests. Over 6 days of
> logs on this machine, they are just over 0.7% of all requests.
> (Yes, that decimal point is right.)
On 01/05/2015 05:55 PM, Bob Harold wrote:
> Does anyone have actual data on how common it is, so we can make an
> informed decision?
>
> I would expect "www.something..." to be in the same zone as
> "something..." in most cases, so I think it is actually very common to
> have more than one level o
36 matches
Mail list logo
