I am the dnsdir stuckee to review this I-D.

The document is clear, concise and well written. If only all RFCs and I-Ds had those properties...

I particularly like the attention in Section 2.1 to the encoding of special characters. Consideration of using the dot character in a label greatly appeals to my poorly hidden DNS Bad Idea Fairy. Congratulations!

I think there are some nits:

1) A sentence could be added to say that CNAME chaining -- ie A's a CNAME pointing at B which is a CNAME pointing at....Z  -- should be avoided because it's a Bad Idea. It needlessly complicates resolving: more lookups, loop detection, etc. The outcome is implementation dependent too because not all resolvers handle CNAME chains in the same way. Implementations can set arbitrary limits on the length(s) of the CNAME chain(s) they follow.

2) If DNS info can't be validated, it seems bad/stupid/dangerous/wrong to use that to make security decisions. IMO the SHOULD NOT in Security Considerations would be better as a MUST NOT. Though I don't feel strongly enough about this.

3) It might be worth mentioning that a proxy could lie when it adds a next-hop-aliases parameter: ie claiming the next or previous hops are not the actual ones that were used. I don't know or care enough about web stuff to tell if that matters or not.

4) There's a tiny, tiny chance that DNAME RRs could get used instead of CNAMEs. I doubt these would ever feature in the proxies or the DNS names envisaged in the I-D. However from a theoretical (or DNS purist's) perspective, the I-D should explain this, if only for completeness.