[prev in list] [next in list] [prev in thread] [next in thread] 

List:       djbdns
Subject:    Re: Problem with umb.edu related to recursive queries
From:       Robin Bowes <robin-lists () robinbowes ! com>
Date:       2011-06-02 17:44:12
Message-ID: 4DE7CBEC.1020807 () robinbowes ! com
[Download RAW message or body]

On 06/02/2011 05:12 PM, Brandon Black wrote:
> On Thu, Jun 2, 2011 at 7:33 AM, Robin Bowes<robin-lists@robinbowes.com>  wrote:
>> I've got problems resolving queries to the umb.edu domain from our dnscache
>> resolver.  [...]
>
> I'm not using a dnscache cache, but FWIW this is what I observe about
> the situation from here:
>
> 1) The umb.edu data (and the delegations to reach it) appear sane.
> 2) The umb.edu authoritative servers (158.121.14.10, .20, .30) set the
> RA bit in responses, indicating that recursion (cache service) is
> available from them as well (IMHO, it's a poor and insecure choice to
> have nameserver software do double-duty as both an authority and a
> cache, but it can be a legal configuration that functions correctly).
> 3) When queried about umb.edu data (such as your MX query) *without*
> the RD (recursion desired) bit set in the query, the servers respond
> correctly.
> 4) When queried about *any* name I've tried (both known valid umb.edu
> names and random others like www.google.com) *with* the RD bit set,
> the servers do not respond at all.
>
> If I had to take a guess, I'd say umb.edu is trying to re-use the same
> servers as both auth and cache (hence the RA bit in responses), but
> the cache functionality is limited to certain address ranges local to
> themselves only and simply fails to respond at all to external
> recursive queries due to some configuration of their nameserver or
> perhaps of a local umb.edu firewall.  I think this behavior is broken.
>   umb.edu's servers should respond correctly with umb.edu authoritative
> data whether the query's RD bit is set or not, IMHO.  I'm not sure why
> dnscache would be setting the RD bit when querying an authority, that
> seems like a poor idea in general, but apparently it must be doing so
> in this case to trigger the issue.

Brandon,

Thanks for the analysis. I will pass this on to the umb.edu guys.

You may have seen in my reply to Paul that I got to the bottom of the 
problem - I had my external dnscache service mis-configured. It all 
works just fine now that I've fixed that up.

Thanks again,

R.
-- 
"Feed that ego and you starve the soul" - Colonel J.D. Wilkes
http://www.theshackshakers.com/
[prev in list] [next in list] [prev in thread] [next in thread]