On 7 February 2016 at 00:36, Paul Hoffman <paul.hoff...@vpnc.org> wrote:
> Greetings again. While doing some testing, I came across something that is > both consistent across implementations but that I do not find in RFC 4033, > 4034, or 4035. If a query for a properly-signed zone is sent to > BIND-as-recursor, Unbound, or Google DNS, and the AD bit in the request is > set to 1, the answer returned has the AD bit set to 1. However, if the > query has the AD bit set to 0, the response always has the AD bit set to 0, > even though the requested zone is properly signed. > > This happens regardless of whether or not there is an EDNS0 extension with > the DO bit set to 1. > > I can't find anywhere in 403[3:5] that says that the AD bit in the request > means anything. Did I miss that? Or is it specified in a different RFC? > > RFC6840 5.7. Setting the AD Bit on Queries The semantics of the Authentic Data (AD) bit in the query were previously undefined. Section 4.6 of [RFC4035] instructed resolvers to always clear the AD bit when composing queries. This document defines setting the AD bit in a query as a signal indicating that the requester understands and is interested in the value of the AD bit in the response. This allows a requester to indicate that it understands the AD bit without also requesting DNSSEC data via the DO bit. 5.8. Setting the AD Bit on Replies Section 3.2.3 of [RFC4035] describes under which conditions a validating resolver should set or clear the AD bit in a response. In order to interoperate with legacy stub resolvers and middleboxes that neither understand nor ignore the AD bit, validating resolvers SHOULD only set the AD bit when a response both meets the conditions listed in Section 3.2.3 of [RFC4035], and the request contained either a set DO bit or a set AD bit. -- Dick Franks
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
