When does BIND send queries with DO flag enabled?

[Kalman Feher]

On 29/09/10 10:30 PM, "Kevin Oberman" <oberman at es.net> wrote:

>> Date: Wed, 29 Sep 2010 15:51:55 -0400
>> From: "Taylor, Gord" <gord.taylor at rbc.com>
>> Sender: bind-users-bounces+oberman=es.net at lists.isc.org
>> 
>> 
>> We recently ran into an intermittent problem sending queries to a
>> business partner. Turns out they had CheckPoint firewalls with
>> SmartDefense turned of for DNS traffic. This was blocking traffic going
>> to them with DO flag enabled. I could duplicate the problem from a
>> command line by issuing "dig @partner hostname +DNSSEC" and this failed
>> everytime. When querying through the DNS server though using NSLOOKUP on
>> WinXP, the resolution was hit-and-miss. Watching a sniffer trace,
>> sometimes BIND 9.4.1-P1 would send with DO flag enabled, and other times
>> without.
>> 
>> I know this is an older version of BIND, and lots of bugs fixed in newer
>> versions. However, looking at sniffer traces from 9.7.0-P2 shows the
>> same behavior = sometimes DO is set and sometimes not set.
>> 
>> Can someone explain when BIND sets DO flag and when it won't? Most of my
>> client workstations are XPSP3, and NONE of the queries coming from those
>> clients have DO flag set.
>> 
>> Any help is appreciated...
>> 
>> Gord Taylor (CISSP, GCIH, GEEK)
> 
> Gee, an annoying and stupid legal notices at the end of a mail message
> is even more annoying when it is in several languages. (Yes, I
> understand that some totally clueless lawyer earning a LOT more for not
> thinking than you do for thinking is not your fault, but it's still
> REALLY ANNOYING!)
> 
> The DO bit is set by default for the simple reason that your server is
> DNSSEC capable. The DO bit says DNSSEC OK and is simply declaring that
> the server is capable of handing (though not necessarily validating)
> responses containing DNSSEC RRs. See RFC3225.
> 
> I assume that setting dnssec-enable to "no" will turn this bit off, but
> please get the broken firewall fixed!
This is actually not the case, although it is understandable you would think
it is the way things _should_ work. DO is set when the resolver has EDNS0
enabled. So that is the only way to turn it off (disable EDNS0). Turning off
EDNS0 is likely to effect a lot more than DNSSEC. I wouldn't recommend it.

A discussion on this topic was held within this mailing list (June 2010
IIRC) with Jinmei and Evan from ISC providing the insight regarding BIND's
behaviour. There was further discussion behind the reasoning for this choice
as well.

Nevertheless your point is valid, fixing the firewall is the only
alternative in my opinion. EDNS0 is not a new technology (10 years I think).
Would you use a security product still basing its policies on a time when
windows 98 was cutting edge?

> 
> As to not always sending DO, I believe that is dependent on the query
> from the client. It would depend on the source of the query. If it was
> from the server to get data that would not be sent back to the client, I
> imagine the DO bit would be set. (NS lookups during recursion would be
> an example), while queries for return to the client will probably
> follow the state of the DO bit seen in the query from the client. I'd
> guess WINXP is not setting DO. I suspect WIN7 would.
> 
> This last section is largely an educated guess. I don't have time now to
> read up on those details in the RFCs.
> 
> Again, get the @#$% firewall fixed! As time goes on, more and more
> queries will be blocked by it as DNSSEC moves to the mainstream.

-- 
Kal Feher