Maintained by: NLnet Labs

[Unbound-users] EDNS fallback

W.C.A. Wijngaards
Fri Jun 26 18:08:50 CEST 2009


Hi Jakub,

And when you try again a second later?

It worked for me right away.

dig @localhost -p 8989 bidmc.harvard.edu MX
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2606
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 2, ADDITIONAL: 1

;; QUESTION SECTION:
;bidmc.harvard.edu.		IN	MX

;; ANSWER SECTION:
bidmc.harvard.edu.	3588	IN	MX	20 speedracer.caregroup.harvard.edu.
bidmc.harvard.edu.	3588	IN	MX	5 rattlesnake1.caregroup.org.
bidmc.harvard.edu.	3588	IN	MX	5 rattlesnake2.caregroup.org.
bidmc.harvard.edu.	3588	IN	MX	10 tumbleweed1.caregroup.org.
bidmc.harvard.edu.	3588	IN	MX	10 tumbleweed2.caregroup.org.
bidmc.harvard.edu.	3588	IN	MX	10 tumbleweed5.caregroup.org.
bidmc.harvard.edu.	3588	IN	MX	15 tumbleweed3.caregroup.org.
bidmc.harvard.edu.	3588	IN	MX	15 tumbleweed4.caregroup.org.
bidmc.harvard.edu.	3588	IN	MX	20 racerx.caregroup.harvard.edu.

;; AUTHORITY SECTION:
bidmc.harvard.edu.	3576	IN	NS	ns2.bidmc.harvard.edu.
bidmc.harvard.edu.	3576	IN	NS	ns1.bidmc.harvard.edu.

;; ADDITIONAL SECTION:
ns1.bidmc.harvard.edu.	3576	IN	A	134.174.104.11

;; MSG SIZE  rcvd: 358

In any case, the answer won't be coming very quickly, but it'll enter 
the cache.

Best regards,
    Wouter

On 06/26/2009 04:13 PM, Jakub Heichman wrote:
> Hi Wouter,
>
> Thanks - I have tried your patch and I get the MX records when used
> with unbound-host. However unbound doesnt seem to be returning these
> MX records when I use dig/other DNS lookup tools:
>
> # dig mx bidmc.harvard.edu @localhost
>
> ;<<>>  DiG 9.3.3rc2<<>>  mx bidmc.harvard.edu @localhost
> ; (1 server found)
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 65
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;bidmc.harvard.edu.		IN	MX
>
> ;; Query time: 3653 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Fri Jun 26 14:53:41 2009
> ;; MSG SIZE  rcvd: 35
>
> Thanks again,
>
> Jakub
>
> 2009/6/26 W.C.A. Wijngaards<wouter at nlnetlabs.nl>:
>> Hi Jakub,
>>
>> Here is a patch that solves your problem, I'll look into a more permanent
>> fix.
>>
>> The trouble is that unbound assumed, that once an EDNS answer is received,
>> then, the path actually works for bufsize=4k answers.  The patch makes it
>> reprobe once an answer starts to lag.
>>
>> Thanks for the bugreport!
>>
>> (With that patch, unbound-host bidmc.harvard.edu produces the MX records
>> after 10 seconds.)
>>
>> Best regards,
>>    Wouter
>>
>>
>> Index: services/outside_network.c
>> ===================================================================
>> --- services/outside_network.c  (revision 1683)
>> +++ services/outside_network.c  (working copy)
>> @@ -1234,7 +1234,7 @@
>>                 &edns_lame_known,&rtt))
>>                 return 0;
>>         if(sq->status == serviced_initial) {
>> -               if(edns_lame_known == 0&&  rtt>  5000) {
>> +               if(edns_lame_known == 0&&  rtt>  5000&&  rtt<  10001) {
>>                         /* perform EDNS lame probe - check if server is
>>                          * EDNS lame (EDNS queries to it are dropped) */
>>                         verbose(VERB_ALGO, "serviced query: send probe to see
>> "
>> @@ -1516,10 +1516,12 @@
>>         } else if(sq->status == serviced_query_UDP_EDNS&&
>>                 !sq->edns_lame_known) {
>>                 /* now we know that edns queries received answers store that
>> */
>> +               /*
>>                 if(!infra_edns_update(outnet->infra,&sq->addr, sq->addrlen,
>>                         0, (uint32_t)now.tv_sec)) {
>>                         log_err("Out of memory caching edns works");
>>                 }
>> +               */
>>                 sq->edns_lame_known = 1;
>>         }
>>         if(now.tv_sec>  sq->last_sent_time.tv_sec ||
>>
>>
>> On 06/26/2009 01:40 PM, Jakub Heichman wrote:
>>> Hello,
>>>
>>> I'm using unbound 1.3.0 and am unable to resolve MX record for (for
>>> example) bidmc.harvard.edu.
>>> I'm guessing that somewhere on the other side there might be a problem
>>> supporting DNS in UDP packets bigger that 512 bytes
>>>
>>> Asking the source:
>>>
>>> # dig +bufsize=513 mx bidmc.harvard.edu @134.174.104.11
>>>
>>> ;<<>>    DiG 9.2.4<<>>    +bufsize=513 mx bidmc.harvard.edu @134.174.104.11
>>> ; (1 server found)
>>> ;; global options:  printcmd
>>> ;; connection timed out; no servers could be reached
>>>
>>>
>>> # dig +bufsize=512 mx bidmc.harvard.edu @134.174.104.11
>>>
>>> ;<<>>    DiG 9.2.4<<>>    +bufsize=512 mx bidmc.harvard.edu @134.174.104.11
>>> ; (1 server found)
>>> ;; global options:  printcmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30368
>>> ;; flags: qr aa rd; QUERY: 1, ANSWER: 9, AUTHORITY: 2, ADDITIONAL: 10
>>>
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 4096
>>> ;; QUESTION SECTION:
>>> ;bidmc.harvard.edu.             IN      MX
>>>
>>> ;; ANSWER SECTION:
>>> bidmc.harvard.edu.      3600    IN      MX      5
>>> rattlesnake2.caregroup.org.
>>> [strip]
>>>
>>> However, from what I understood, in this case unbound would send a
>>> probe query with a sub-second timeout to see if the server responds
>>> without EDNS.
>>> Does the timeout apply to response time from the target nameserver, or
>>> the whole recursion time (which in my case takes more that a second)?
>>>
>>> Direct from source:
>>> # dig mx bidmc.harvard.edu @134.174.104.11 | grep time
>>> ;; Query time: 297 msec
>>>
>>> Recursion time from local Bind instance (on port 5300)
>>> # dig mx bidmc.harvard.edu @localhost -p5300 | grep time
>>> ;; Query time: 2241 msec
>>>
>>> Recursion from unbound:
>>> # dig mx bidmc.harvard.edu @localhost
>>> [..]
>>> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 63565
>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>>>
>>> Thanks very much,
>>>
>>
>
>
>