Hi,
I try to use evdns for very common and simple task: get at least one IP address for a domain name and use it for connect. There are at least two examples of DNS replies that return a plenty of IP addresses but my application can't get them because the evdns treats the replies as empty or badly broken.
For example: video.sekindo.com. It is an alias for Naeu.geo.cloudwm-cdn.com. Therefore when I call evdns_getaddrinfo for the video.sekindo.com the DNS server tries to return:
1 CNAME record
21 A records for Naeu.geo.cloudwm-cdn.com
4 Authority (NS) records
4 Additional records, that are A records for nameservers above
But it is too big reply to send it in one UDP packet. Therefore the server leaves only
1 CNAME record
21 A records
3 Authority records
and sets TC (truncated) flag in such shortened reply.
If I could get these 21 A records to my application it would be a plenty of data for my task, but I can't. Because the evdns.c:reply_parse first of all checks the error bits together with TC bit in the flags field and discards the whole reply. My application gets the empty reply and the error code EVUTIL_EAI_NONAME "nodename nor servname provided, or not known". Note that the replay has nothing in the error bits but just is incomplete.
The another example is rtb.tubemogul.com. Its complete reply should have 2 CNAME, 14 A, 10 authority, 10 additional records. The truncated reply has 2 CNAME, 14 A, 8 authority records. I don't need anything from the discarded part. I would be happy to get al least one of 14 A records. But I get nothing and the error "there is nothing we can tell you about this domain name".
I know that RFC 1035 doesn't tell much about the TC flag. But it is clear that it doesn't mean "no data at all" but that the sent data is incomplete.
The fix is simple (edit error bit masks in three places). The evdns.c code (reply_parse and reply_handle) should not treat TC flag as another one error bit but continue processing and allow the apllication to decide if the truncated answer is enough for its task.
Ivan.
Sorry, I forget to mention the libevent version. I use the 2.0.22-stable. But it looks like the 2.1.5-beta should have the same problem because nothing were changed in TC bit check.