On Fri, Sep 11, 2020 at 1:01 PM Vladimír Čunát
wrote:
> On 9/11/20 9:14 PM, Randy Bush wrote:
> >> The main issue with having the discussion on github, is that it is a
> >> discussion on github, not on a major mailing list involving the
> >> operators and folks doing independent implementations.
On 9/11/20 8:29 PM, John Levine wrote:
> Are there any published numbers estimating how well the various DNSSEC
> algorithms are supported in DNS caches and client software?
Off the top of my head: https://dnsthought.nlnetlabs.nl/#ecdsa256
but 13 in particular feels quite deployed in zones - I kn
On 9/11/20 9:14 PM, Randy Bush wrote:
>> The main issue with having the discussion on github, is that it is a
>> discussion on github, not on a major mailing list involving the
>> operators and folks doing independent implementations.
> for cabals which like a bubble, this is a feature, not a bug
On 11/09/2020 13:29, John Levine wrote:
Are there any published numbers estimating how well the various DNSSEC
algorithms are supported in DNS caches and client software?
Or to put it another way, were I to switch from signing with
algorithm 8 to 13, how much would I regret it?
There are nice
On Fri, Sep 11, 2020 at 02:29:49PM -0400, John Levine wrote:
> Are there any published numbers estimating how well the various DNSSEC
> algorithms are supported in DNS caches and client software?
Yes. See this discussion thread:
https://github.com/NLnetLabs/unbound/issues/271#issuecomment-6
On 14:29 11/09, John Levine wrote:
> Are there any published numbers estimating how well the various DNSSEC
> algorithms are supported in DNS caches and client software?
>
NLNetLabs have this numbers using RIPE Atlas probes local
resolvers as vantage points:
https://dnsthought.nlnetlabs.nl/
Hu
> The main issue with having the discussion on github, is that it is a
> discussion on github, not on a major mailing list involving the
> operators and folks doing independent implementations.
for cabals which like a bubble, this is a feature, not a bug
randy
To quote the late Douglas Adams, from HHGttG:
>
> “There’s no point in acting surprised about it. All the planning charts
> and demolition orders have been on display at your local planning
> department in Alpha Centauri for 50 of your Earth years, so you’ve had
> plenty of time to lodge any formal
Are there any published numbers estimating how well the various DNSSEC
algorithms are supported in DNS caches and client software?
Or to put it another way, were I to switch from signing with
algorithm 8 to 13, how much would I regret it?
TIA,
John
--
Regards,
John Levine, jo...@taugh.com, Pri
On 9/11/20 4:44 PM, Paul Hoffman wrote:
> If this is really just a vendor-driven flag day, please be clearer about that
> on the web page.
The GitHub repo and other places have been open for *everyone* to
participate in the discussions. That's how I understand the "we",
similarly to "we DNSOP".
Hello.
On 2/8/20 8:33 AM, Viktor Dukhovni wrote:
> Unfortunately, I don't see a way to separately configure the *upstream*
> and *downstream* EDNS buffer sizes.
It's been long but for Knot Resolver we now merged that split, so since
the first post-flag-day release you can specify both values sepa
On 9/11/20 12:47 AM, Paul Vixie wrote:
> i don't think all of the people i intend to address here have heard
> my views. they may think that dns-oarc speaks for the community
> rather than for a small self selected team. they may also think that
> i as co-founder of dns-oarc can be relied upon to
--- Begin Message ---
Google Public DNS posted a message on github about our plans:
https://github.com/dns-violations/dnsflagday/issues/139#issuecomment-673489183.
Background: Similar to what Ralf Weber said, over the last couple of
years we have seen issues with large domains related to UDP
fragm
--- Begin Message ---
Google Public DNS posted a message on github about our plans:
https://github.com/dns-violations/dnsflagday/issues/139#issuecomment-673489183.
Background: Similar to what Ralf Weber said, over the last couple of
years we have seen issues with large domains related to UDP
fragm
Moin!
On 11 Sep 2020, at 10:29, Viktor Dukhovni wrote:
> Paul is not arguing against avoiding fragmentation, IIRC his name is on
> a draft recommending fragmentation avoidance. So I think the issue is
> really about which numbers to go with.
I think nobody is thinking that. We do have an agreeme
On Sep 11, 2020, at 12:38 AM, Petr Špaček wrote:
> My non-native-speaker reading suggests it is in both cases refering to
> "consensus between the vendors". Let's not get distracted.
The DNS Flag Day web site makes it seem like "we" should be authoritative
operators, resolver operators, and ven
Dear all,
Apologies for attaching a screen-dumped file through Google Drive; it’s my
local resolver, so this is the only way to show you my ‘symptom’.
The new Resolver Tester for this year Flag Day reports all my netblocks
wrong [Reference:
https://drive.google.com/file/d/1gIf-BFXpBBu7Y03VbJbtpc
On 11/9/20 01:47, Paul Vixie wrote:
[...]
1232 is a cargo-cult number. we must not revere as holy those things
which fall out of the sky.
there is a right way to deprecate fragmentation. it would not involve
adding config complexity.
there is a right way to reach consensus. it's an RFC dra
On Fri, Sep 11, 2020 at 09:38:30AM +0200, Petr Špaček wrote:
> > 1232 is a cargo-cult number. we must not revere as holy those things which
> > fall out of the sky.
>
> I disagree. That number is based on real-world experiance of today's
> DNS resolver vendors - based on their experience with un
On 11. 09. 20 6:47, Paul Vixie wrote:
> Ondřej Surý wrote on 2020-09-10 21:25:
>> Paul,
>>
>> do you actually believe that shouting the same thing over and over will
>> achieve anything?
>
> no, of course not.
>
>>
>> We’ve heard you before, we’ve listened to you, we’ve considered your
>> argum
Hi, Paul,
On 10/9/20 23:22, Paul Vixie wrote:
Petr Špaček wrote on 2020-09-08 03:04:
Dear DNS people.
We are happy to announce next step for DNS Flag Day 2020.
Latest measurements indicate that practical breakage caused by the proposed
change is tiny [1]. In other words we can conclude tha
21 matches
Mail list logo
