Okay, I thought whether my idea was too dumb to even receive any
reaction. Thank you for at least some comment.
But, I think each nameserver on path might have a bit different scope.
Therefore all those servers do not know the same information and are
*not* inter-changeable. EDSR is interestin
I don't think we should reuse SVCB records in this way. The records here do
not have SVCB semantics, so I think it would be very confusing.
In general, I have difficulty understanding the problem that is being solved
here. DNS forwarders can have arbitrarily complicated, customized policies
t
Hi Tommy,
The draft draft-ietf-dnsop-structured-dns-error includes appropriate
extensibility mechanisms. I reviewed the new draft,
draft-nottingham-public-resolver-errors-00, and it does not require any
updates to draft-ietf-dnsop-structured-dns-error. In the future, we may see
other drafts propos
Hi Ben,
The selected suberror codes are identified as threats by the IETF and would
potentially compromise the security posture of the endpoint (see Section
10.4 of the draft). The other common reasons you mentioned fall under the
category of 'censorship,' which could be perceived as an invasion o
I think we should take a closer look at draft-nottingham-public-resolver-errors
before proceeding to publish this document. That draft fixes this draft's
internationalization problem, but accepting both would result in duplicate
mechanisms for conveying error text.
Fixing internationalization
Moin!
On 8 Nov 2024, at 6:07, Ben Schwartz wrote:
> 1. Prevent DDoS attacks. A malicious DNS server could cause a large number
> of clients to fetch incident reports from an arbitrary victim server. (c.f.
> Great Cannon [A])
As the initial structured error draft requires encrypted DNS this is
