Dear dnsop,
In the course of discussing implementations of ECH I and Stephen
Farrel arrived at opposite conclusions about whether or not RFC 9460
prohibits or allows the following kind of configuration.
The zone puzzle.test.defo.ie has the following contents:
puzzle.test.defo.ie. 60 2a00:c6
Moin!
On 6 Oct 2024, at 0:16, Watson Ladd wrote:
> Dear dnsop,
>
> In the course of discussing implementations of ECH I and Stephen
> Farrel arrived at opposite conclusions about whether or not RFC 9460
> prohibits or allows the following kind of configuration.
>
> The zone puzzle.test.defo.ie ha
In your letter dated 5 Oct 2024 14:03:42 -0400 you wrote:
>> So I guess that any query that arrives at a recursive resolver with DO and
>> optionally CD set could be from an unmodified DNSSEC validator. So the
>> recursor has to obtain the NODATA result for a.b.c.d.example.
>
>Other way around, if
Paul and Tim,
Thanks for your comments. This submission was triggered by the Red Hat
snafu. Red Hat removed an algorithm from the library when they
determined it should not be used. However, as their users discovered
quickly, messages signed with that algorithm continued to arrive, with
consequ
but it did NOT advise how to introduce and how to remove an algorithm in
coordination with other algorithms.
On Sat, Oct 5, 2024 at 2:31 PM Steve Crocker wrote:
> Paul and Tim,
>
> Thanks for your comments. This submission was triggered by the Red Hat
> snafu. Red Hat removed an algorithm from
On Sat, 5 Oct 2024, Philip Homburg wrote:
Other way around, if the client doesn't understand NXNAME, the recursive
needs to get the real signed NXDOMAIN to pass along.
If a recursive resolver passes NXDOMAIN to a requesting validator, then
the result has to prove NXDOMAIN, so there has to be ei
Just to be clear, I agree with Eric and the text proposed is clear, I do not
want either to delay this document
My intervention in this email thread was simply to give support to Paul Vixie
and give real world information vs some of the statements I was reading in the
email thread.
Let’s move
Hi Erik,
Agree it is out of the scope of this draft, but we have another vehicle that
would be ideal to capture what you write
We didn’t push it too much in the past 9+ months as per agreement with ADs and
Working Group chairs, Eric and others to wait for ECH to be ratified first and
on our
If appropriate, we could pick up this issue in our ECH Deployment
Considerations draft. Happy to discuss in Dublin if there is interest in
adding to our existing text.
Andrew
On 4 Oct 2024, at 19:39, Salz, Rich wrote:
* I would not be in favor of this. This is been intensely controver
All,
During the Mailman 3 upgrade to the IETF mailing lists back in May, a
change was made to the behavior of the mailing lists, which ended up
causing document email notifications to not appear on the DNSOP mailing
list. In investigating this, it appeared that in the "Ban List" setting in
mailma
In your letter dated 4 Oct 2024 13:31:36 -0400 you wrote:
>>There is no reason to assume that clients are constructing names that they
>>don't want to the target zone to know.
>
>But the presumably don't want the TLD to know them. Query minimization would
>only show e.example to the example TLD,
On Sat, 5 Oct 2024, Philip Homburg wrote:
If a stub resolver askes for a.b.c.d.example and d.example does not exist
then example is the target zone. It is also a TLD, but if d.example does not
exist then any query for a.b.c.d.example is directed at the zone example.
Right.
The question then b
As an operator, I feel the implementers should have a strong say in this.
They have business decisions based on what customers wish to have
supported, and while they can guide customers, they need to think of the
long tail.
(I worked for a software company that supported Internet Explorer 6 into
th
13 matches
Mail list logo
