On 14. 10. 21 19:36, Dan Wing wrote:
We recently published -01 of Structured Data for Filtered DNS based on WG
feedback from IETF 111. We also incorporated both motivational and normative
text from draft-reddy-dnsop-error-page. New version at:
On 10. 11. 21 10:31, Giovane C. M. Moura wrote:
Ad the draft content:
2. Past solutions
This section somehow does not mention RFC 2308 section 7.1 which solves
most of the problem if implemented. In fact BIND has an implementation
of it and is not vulnerable to the TsuNAME attack (or at
Coming a bit late to the discussion
On 2021-11-09 22:53, Paul Wouters wrote:
On Tue, 9 Nov 2021, Peter Thomassen wrote:
Let's consider the bootstrapping namespace under _boot.ns1.desec.io.
There would usually be NS/DS records at this name.
However, it should be possible to introduce zone
> On 10 Nov 2021, at 09:35, libor.peltan wrote:
>
> Hi Roy,
>
>> Change 2) There was an observation by developers that some authoritative
>> servers do not parse (unknown) EDNS0 options correctly, leading to an
>> additional roundtrip by the resolver. It was suggested that authoritative
>>
Thanks Ralf,
> I fully agree here. Most of the current or older implementations
> solve this by resource limiting and had no problem with tsuName. Only
> some new cloud implementations had a problems. So please don’t
> require those that had working mitigations to change them.
Well, not only
Hi Roy,
Change 2) There was an observation by developers that some
authoritative servers do not parse (unknown) EDNS0 options correctly,
leading to an additional roundtrip by the resolver. It was suggested
that authoritative servers could return the new EDNS0 option
“unsolicited”. This is
Thanks a lot, Petr.
>
> If I understand this correctly, TL;DR summary essentially is
> """ make https://datatracker.ietf.org/doc/html/rfc2308#section-7.1
> mandatory """
> (even though your version is a bit stronger). Is that correct?
>
Thanks for pointing to this section. We missed it.
We
