> On 24. 8. 2026, at 20:44, Warren Kumari <[email protected]> wrote:
>
> 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".
At the same time, FORMERR makes sense in a way "You sent me a query violating
the DNS protocol".
And there is a precedent:
$ for type in OPT TSIG TKEY $(seq 128 155 | xargs -I{} echo TYPE{}); do dig
+noall +comment IN -t $type . @ns1.isc.org | grep -p 'status: [^ ]*'; done;;
->>HEADER<<- opcode: QUERY, status: FORMERR, id: 22426
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 50399
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 61668
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 54131
[...]
So, I would say that FORMERR makes perfect sense for RRSIG.
(But for ANY, REFUSED is perfectly fine because that is a local policy.)
Ondrej
--
Ondřej Surý (He/Him)
[email protected]
A gentle nudge is always appreciated if I take a little longer to reply.
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
