We're looking for comments before Monday April 26th.
I'm sorry. Better slightly late than never, I suppose. The whole text seems good to me, except for a small issue:
In step (6) of the algorithm it might better be noted that in case xNAME is in ANSWER, the RCODE is irrelevant. Now the reading doesn't seem right e.g. if it returns a CNAME to an NXDOMAIN.
* we use 1-1-1-3-3-.. label steps, which is not exactly what section 2.3 describes
I consider that part of the draft as just an example how the number of queries could be reduced, so I can't see any problem.
In the stub&forwarding section it might be worth noting the case of validating stub or forwarder. There the final query does not suffice regardless of (non-)minimization, so the QNAME minimization approach can be "coupled" with a root-to-leaf direction of discovering the trust chain. We've been using one simple approach from this class for years (as the only option for forwarding with validation).
--Vladimir | knot-resolver.cz _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
