Hi Joe,
I think you need some more text in the description of pick-one-rrset,
something like:
A DNS responder which receives an ANY query MAY decline to provide
a complete response, and MAY instead choose to return only one of
the the RRsets present at the node specified in QNAME, and the
associated RRSIGs if any.
If this approach is chosen, the following limitations apply:
- If there is an NS, CNAME, or DNAME RRset present, then the
responder MUST return those RRsets. (Note that DNAME can
coexist with NS; if this is the case, both RRsets MUST be
returned.) *
- Otherwise, when multiple RRsets exist, the responder SHOULD
select an RRset to return using a deterministic mechanism,
so that subsequent queries of type ANY to the same server will
continue to receive the same data so long as the contents of
the node remain unchanged. For example, the responder MAY
choose the smallest RRset, in order to reduce the amplification
potential of a type ANY query.
- The responder MUST NOT choose to return an RRset of type RRSIG,
but MUST include the covering RRSIG RRs for whichever RRset is
chosen.
I'd suggest breaking this into a separate subsection of section 5.
I would also mention in security considerations that synthesizing
responses from a signed zone requires the private signing key to be online
and available to every responder; offline signing, or signing on the master
server only, are not possible.
* I'm not completely certain DNAME needs to be mentioned in the first
bullet point, but I'm concerned there may be unintended consequences
if it's present but omitted.)
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
