Bug 608 - Receive malformed packet from authoritative name server when request with edns0, and retry with edns0 again
Receive malformed packet from authoritative name server when request with edn...
Status: ASSIGNED
Product: unbound
Classification: Unclassified
Component: server
unspecified
All All
: P5 enhancement
Assigned To: unbound team
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-08-27 10:15 CEST by chenfzh
Modified: 2014-08-29 04:22 CEST (History)
1 user (show)

See Also:


Attachments
example of malformed packet (1.05 KB, application/octet-stream)
2014-08-27 10:15 CEST, chenfzh
Details

Note You need to log in before you can comment on or make changes to this bug.
Description chenfzh 2014-08-27 10:15:50 CEST
Created attachment 260 [details]
example of malformed packet

Some authoritative name server doesn't support edns well, when unbound send a request to it, it response with a malformed packet. If I request this server without edns, it response with a normal packet.

unbound detect by checking NOTIMPL or FORMERR flag, but the malformed packet do not contain these flag, so function servied_udp_callback treat it like a normal packet, but unbound fail to parse this packet. Then unbound retry with edns0, and fail again, and again...

I'm not sure it's a bug, but I think it's better to send to the authoritative name server a request without edns after receiving a malformed packet from the server.

There's an example in the attachment.The domain name is 126.com.cn, and the authoritative name server is 121.10.242.101.
Comment 1 Wouter Wijngaards 2014-08-28 13:53:50 CEST
Hi Chenfzh,

Yes that is an interesting improvement in EDNS support detection.  The packet is malformed, but is good if the additional-rr-count had been 1.

Best regards,
   Wouter
Comment 2 chenfzh 2014-08-29 04:22:37 CEST
I tried to let the serviced_query.status do not be serviced_query_UDP_EDNS any more if unbound received malformed packet before, but I didn't find out a suitable way to implement it.

I modified function parse_section in util/data/msgparse.c to make it work (so far), but I think that's not a good solution.