On Thu, Feb 14, 2019 at 03:33:23PM -0500, Warren Kumari <war...@kumari.net> wrote a message of 388 lines which said:
> but how about: > "The majority of these extended error codes are primarily useful for > resolvers, to return to stub resolvers or to downstream > resolvers. Authoritative servers may also use this technique to > annotate errors (for example, REFUSED), but as of publication there > are not as many of these defined" OK > > > 4.4.1. NXDOMAIN Extended DNS Error Code 1 - Blocked > > > > > > The resolver attempted to perfom a DNS query but the domain is > > > blacklisted due to a security policy. > > > > I tend to think it would be a good idea to separate the case where > > the policy was decided by the resolver and the case where the > > policy came from outside, typically from the local law (see RFC > > 7725 for a similar case with HTTP). > > > > Rationale: in the first case (local policy of the resolver), the > > user may be interested in talking with the resolver admin if he or > > she disagrees with the blocking. In the second case, this would be > > useless. You did not reply to this one. It is inspired by a message from Petr Špaček <https://mailarchive.ietf.org/arch/msg/dnsop/b3wtVj_aWm24PXyHr1M9NMj3LJ0> explaining how extended DNS errors would be great to tell the user whose fault it is (signature expired == no need to tell the resolver's operator). I really think it is important to make the difference between: * I blocked your request because that's _my_ policy * I blocked your request because I'm compelled to do so, don't complain, it would be useless. > > NOERROR Extended DNS Error Code 3 - Forged answer > I'd really like to avoid the word "Forged" I did not know it was pejorative (in french, "forgée", which has the same origin, is not). So, what about "substituted answer"? Neutral enough? _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
