[DNSOP] Re: DNSOPFwd: New Version Notification for draft-s ury-dnsop-rrsig-refused-00.txt

On Mon, Aug 24, 2026 at 9:04 AM, Wes Hardaker <[email protected]> wrote:

> Shumon Huque <[email protected]> writes:
>
> Maybe that behavior should be generalized to include other types that
> should not be allowed in queries too like RRSIG.
>
> I think coming up with a standard semantic for handling "you're clearly a
> broken client by making a request that makes no sense" is an excellent
> thing, and making the (future) RFC state "these are the RRTYPEs today
> that this covers" would be a good thing as well. I have an auth server for
> a popular-ish zone that receives a *lot* of ANY queries for the signed
> zone, which technically I should support (but I filter them). Lately I've
> noticed that likely the same behavior seems to be happening with queries
> for CNAME. Say what now?
>
> As to whether REFUSED or FORMERR I'll leave to the better minds that me
> (specifically resolver implementation folk), but I do think suggesting an
> EDE is critical.
>


I don't think that there is an exact answer, because the meaning of error
codes has kinda evolved over time, but if feels to more more like REFUSED.
It isn't (necessarily) that "The name server was unable to interpret the
query." (Form Error, RFC1035, 4.1.1), but rather that "The name server
refuses to perform the specified operation for policy reasons." (Refused,
RFC1035, 4.1.1). Yes, it could be that "Your query is dumb", but that's not
really the same as "cannot interpret".



> [TL;DR: I agree with what everyone else has said -- let's not try to
> figure out how to answer broken queries, but rather return a "your broken"
> response of some kind].
>

Yah.

W

>
> --
> Wes Hardaker
> Google
>
> _______________________________________________
> DNSOP mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]