One of our engineers discovered some interesting behavior while testing
bad EDNS RRs in Unbound. He discovered that Unbound properly checks and
identifies a truncated OPT RR as a FORMERR, but then returns the
truncated OPT RR, resulting in a malformed response to a malformed
request. I have attached a PCAP file that should contain the malformed
requests/responses.
Has anyone observed this behavior, and if so, had issues from it?
I'd also like to hear some opinions about this behavior.
One of our engineers discovered some interesting behavior while
testing bad EDNS RRs in Unbound. He discovered that Unbound
properly checks and identifies a truncated OPT RR as a FORMERR, but
then returns the truncated OPT RR, resulting in a malformed
response to a malformed request. I have attached a PCAP file that
should contain the malformed requests/responses.
There is a fix now, unbound will remove the EDNS section from that reply.
This may cause the sender to think the server does not support EDNS
and then drop EDNS from its queries - and that is exactly right
because its EDNS contents cannot be parsed.
One of our engineers discovered some interesting behavior while
testing bad EDNS RRs in Unbound. He discovered that Unbound
properly checks and identifies a truncated OPT RR as a FORMERR,
but then returns the truncated OPT RR, resulting in a malformed
response to a malformed request. I have attached a PCAP file
that should contain the malformed requests/responses.
There is a fix now, unbound will remove the EDNS section from that
reply.
This may cause the sender to think the server does not support
EDNS and then drop EDNS from its queries - and that is exactly
right because its EDNS contents cannot be parsed.
And fixed to reply with a valid EDNS record without options in it in
the FORMERR message. This is for RFC compliance, as Yuri points out.