Redefinition of DNS Authenticated Data (AD) bit
Note: This ballot was opened for revision 06 and is now closed.
(Randy Bush) Discuss
this 'discuss' is meant literally. i just think that there are some issues here worth discussing. the major issue here is that having a remote, often untrusted, server assert (often over an untrusted channel) that the data met its local policies is not overly useful and is possibly misleading. the counter is that the stub client may have a trust relationship, via tsig or whatever, with the server, which also provides a trustable channel. on the other hand, this is no worse, and arguably better than the current definition of the AD bit. this then devolves into the question of whether it is better to improve a weak assertion or to recover the bit and reserve it for future use. who is going to use this assertion? is it thought that application layers will learn the trust state of the dns data which they use? and then, there is the exciting question of what this means in the presense of the dreaded opt-in. the client can not tell if the server which set the AD bit is locally configured to like opted-out data.
(Allison Mankin) Discuss
The final paragraph of the Security Considerations is written in a way that obscures meaning, in contrast to the related final paragraph of Section 3. > Resolvers (full or stub) that blindly trust the AD bit without > knowing the security policy of the server generating the answer can > not be considered security aware. A better version would be "that blindly trust the AD bit MUST be used only in an environment in which configurations ensure that the security policy of the server is appropriate to the AD bit's information being valid for a decision on whether to use the information it applies to" Perhaps rather than obscuring meaning, it is actually wrong. But the above hasty attempt tried to express something less wrong.