[ldns-users] Critical bug in ldns core lookup

[Henri Asseily]

>>
>> I've upgraded my source to 1.5.1... somewhat of a pain actually. If  
>> you
>> don't have SSL (the iPhone doesn't have OpenSSL available), there  
>> are a
>> number of places that fail because of missing ifdefs.
>
> ok that certainly needs to be fixed then, I'll look into it.

Let me know if you need my ugly diffs, but it's pretty straightforward  
to reproduce, obviously.
>>
>> Anyway, I think I've isolated the problem(s) to local nameservers  
>> being
>> broken (not supporting EDNS0), the iphone simulator needing a full  
>> quit
>> and restart to clear its memory between runs, and in GPRS/EDGE the
>> necessity to drop back to TCP because EDNS0 UDP will fail even using
>> well-behaved OpenDNS servers.
>>
>
> Hmm, if it's possible, could you send me a packet dump of an answer  
> that fails?
> If it's ldns that does not gracefully error on broken packets i want  
> to fix that.

Here's one thing on my provider's DNS server, using drill:

# ./drill -a henri.tel NAPTR IN
Bus error

On the other hand, on opendns servers:

# ./drill -a henri.tel NAPTR IN @208.67.222.222
error: answer section incomplete
;; No packet received

======

Now using -b 4000 flag:

# ./drill -b 4000 henri.tel NAPTR IN
error: answer section incomplete
;; No packet received

# ./drill -b 4000 henri.tel NAPTR IN @208.67.222.222
< CORRECT ANSWER, not reproduced here for brevity >

======

Finally, using -t flag, a query to the local DNS server times out,  
while a query to the opendns server returns a correct answer.
H