Mukund-san,
Thanks very much.
I updated my local version.
http://member.wide.ad.jp/~fujiwara/avoid-fragmentation.html
--
Kazunori Fujiwara, JPRS
> From: Mukund Sivaraman
> Fujiwara-san, Vixie-san,
>
> On Thu, Jan 19, 2023 at 12:13:02AM -0800, internet-dra...@ietf.org wrote:
>>
>> A New In
Thanks very much.
I updated my local version.
http://member.wide.ad.jp/~fujiwara/avoid-fragmentation.html
--
Kazunori Fujiwara, JPRS
> From: Peter van Dijk
> PowerDNS Authoritative Server, PowerDNS Recursor, PowerDNS dnsdist:
>
> * IP_PMTUDISC_OMIT with fallback to IP_PMTUDISC_DONT
> * defa
On Mon, Jul 03, 2023 at 08:25:08PM +0200, Peter Thomassen wrote:
> Now, assume a multi-signer setup of, say, algorithms 7 and 13. This is
> not an uncommon transition (ietf.org did it last month, except that
> they went unsigned). In such a scenario, a resolver on Red Hat would
> only consider the
> On 4 Jul 2023, at 04:25, Peter Thomassen wrote:
>
> Dear DNSOP,
>
> It's well-known that DNSSEC multi-signer setups are problematic when
> providers want to sign with different algorithms.
>
> In a hypothetical scenario where signing requirements would be relaxed, I
> have a very specific
The rules are there to ensure that if the resolver see an algorithm it
supports then it can validate the response. If you fail to follow the rules
answers won’t ALWAYS validate. If there is one level of validation happening
the validator should recover by trying other servers. If you have chain
Dear DNSOP,
It's well-known that DNSSEC multi-signer setups are problematic when providers
want to sign with different algorithms.
In a hypothetical scenario where signing requirements would be relaxed, I have
a very specific question about how resolvers should behave. Apologies for the
lengt
Hello Duane & others,
thank you for your response. Comments inline below.
On Thu, 2023-06-29 at 23:58 +, Wessels, Duane wrote:
>
>
> >
> > ## 2.2
> >
> > The first paragraph correctly mentions "policy reasons". The second
> > paragraph
> > correctly says "they are not authoritative". I
Hi Med,
Thanks for the responses, further comments in-line.
On Fri, Jun 30, 2023 at 9:24 PM wrote:
>
> Hi Matt,
>
> Thank you for the review.
>
> Please see inline. I let my co-author further comment as appropriate.
>
> Cheers,
> Med
>
> > -Message d'origine-
> > De : Matt Brown via Data
On 6/30/23 22:15, Paul Wouters wrote:
Section 13:
[...]
an attacker being able to provide a rogue trust anchor is potentially
This is not a very realistic attack.
The same section says:
On the other hand,
mishandling Trust Anchor is likely resulting in a validator unable to
