PATCH: dig warn user when querying ANY towards recursive server (fwd)
Kevin Darcy
kcd at chrysler.com
Mon Jul 23 22:49:28 UTC 2012
On 7/23/2012 6:23 PM, Kevin Darcy wrote:
> On 7/22/2012 7:27 PM, Andris Kalnozols wrote:
>> On 7/22/2012 10:19 AM, Paul Wouters wrote:
>>>
>>> (I don't think this made it to the list before, mixup of email
>>> addresses)
>>>
>>> Please consider including this patch,
>>>
>>> Paul
>>>
>>> ---------- Forwarded message ----------
>>> Date: Mon, 2 Jul 2012 17:45:08
>>> From: Paul Wouters <paul at nohats.ca>
>>> Cc: Paul Vixie <paul at redbarn.org>
>>> To: bind-users at lists.isc.org
>>> Subject: PATCH: dig warn user when querying ANY towards recursive
>>> server
>>>
>>>
>>> Hi,
>>>
>>> As recently came up, when querying a recursive caching server for ANY
>>> will only result on cached entries being returned, and not the whole
>>> possible set. For that you need to query the authoritative server.
>>>
>>> I wasn't aware of this, and since I'm sure I'll forget about this again
>>> too, I wrote a patch for dig to remind me. Please apply :)
>>
>>
>> Don't forget that recursive servers can also host the zone being
>> queried. Testing for the "aa" flag makes the message more accurate.
>>
>>> if ((query->lookup->rdtype ==
>>> dns_rdatatype_any) &&
>>> ((msg->flags & DNS_MESSAGEFLAG_RA) != 0) &&
>>> (msg->flags & DNS_MESSAGEFLAG_AA) == 0)
>>> printf("\n\n;; WARNING: Requested
>>> ANY data "
>>> "from a non-authoritative
>>> recursive "
>>> "server.\n;; The cached answer "
>>> "might be incomplete.\n\n");
>>
> The DNS_MESSAGEFLAG_AA conditional should completely replace the
> DNS_MESSAGEFLAG_RA conditional, since it's perfectly valid to deny
> recursion to a particular client (RA=0), while at the same time
> allowing it to access cached data -- Samba: An Introduction which
> might be an incomplete nameset and therefore should prompt the warning
> -- built up by other clients which are allowed to recurse from the
> same nameserver instance. The only thing that really matters is the AA
> flag.
Whoops, copy & paste error: please ignore the Samba stuff in the
paragraph above...
- Kevin
More information about the bind-users
mailing list