I am repeating what I have said earlier during WGLS that Section 5.9., Always set the CD bit on Queries, contains bad advice on how to set the CD bit. The setting of CD make little difference if all the machines involved are being correctly managed. In that case all responses will successfully validate. However if there is a off path attacker or one or more of the authorititive sources is returning stale records the setting of CD is critical to ensuring that the ultimate client can get the necessary records to ensure that the responses it gets validate. When there is a non-validating stub resolver all queries from that client come in with CD=0 and a validating recursive server try multiple authoritative servers until it gets a answer which validates as secure or insecure, in other words it rejects answers from attackers or from authoritative servers that return stale data. Now take a validating validating stub resolver, if all queries from that client come in the CD=1, them the recursive server returns the answer from upstream immediately without filtering out bad responses. If there is a off path attacker or if there is a stale authoritative server then there is no way to ensure that the stub client will ever get a answer that will validate. It can continue to re-query forever but there is no requirement for the recursive server to try a different authoritative source or to wait for a valid response from a authoritive source. A similar problem arises when a recursive server is talking through a second recursive server. The server is no longer talking to the authoritative servers directly and can't recover from getting answers that do not validate. Now sending CD=0 has its own set of problems caused by stale trust anchors and clocks being out of sync so I am not suggesting that we always send CD=0 queries either when incoming queries are sent with CD=0. Stub resolvers and recursive servers talking through other recursive servers need to be prepared to ask queries with both CD=0 and CD=1. CD=1 when talking to authoritative servers, CD=0 when talking to recursive servers falling back to CD=1 on SERVFAIL to handle stale trust anchors and out of sync clocks unless the incoming query was received with CD=1 in which case you MUST make CD=1 upstream queries. Now if the recursive server is not validating, validating down stream clients are vulnerable to all the failure modes caused by sending CD=1 queries. Fixing this will require protocol extensions to pass trust anchors, and maybe current time, along with the query and having on demand validation performed using those values in the recursive server for this client. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx