At Mon, 24 Oct 2016 21:58:42 +0800 (GMT+08:00),
"Jiankang Yao" <[email protected]> wrote:
> We have updated it to the new version, simplying the mechanism.
> pls kindly help to review it. any comments are welcome.
> If Seoul DNSOP meeting has some time slot for it, I will appreciate it.
A few comments on a quick read:
- Does it assume to be used for exchanges between stub and recursive
resolvers? If it's also intended to be used between recursive and
authoritative, how does it handle a delegation answer?
- Should we assume SOA('s) in the authority section for negative
answers?
- What if AQ-TYPE is ANY? I suspect the answer can be ambiguous in
that case (even though it may not be a big issue in practice). For
example, if the first AQ-TYPE is ANY and the second is AAAA, and the
answer section only contains one AAAA (in addition to the answer to
the main question), it's ambiguous for which AQ the AAAA answer is.
- Likewise, what if the result is a CNAME chain? For example, if the
answer to the first AQ is a CNAME and the name for the second AQ is
the CNAME's target, it can be ambiguous for which AQ the subsequent
answer (that follows the CNAME answer) is.
- I wonder whether there are other cases where the results can be
ambiguous and whether some of them can be more troublesome than the
above examples.
- Maybe I missed something obvious, but the purpose of the AQ bit, and
Count and Seq fields is not clear to me. Some more explanations
might help.
- Regarding the definition of "Prefix" in Section 3:
o Prefix field is a substring between the main domain name of the
main quesiton and the accompanying domain name of the accompanying
question.
what "substring" means is vague to me. It's not even clear whether
this is an ascii string or it's a complete wire-format domain name.
Likewise, the notation of "S-S1" is quite informal. Since this is
part of a formal definition, I'd suggest making it more formal and
precise, eliminating any ambiguity depending on the interpretation.
- This part of Section 4 seems to assume a responder implementation
generally echos back unrecognized EDNS options:
[...] An AQ
unaware responder is expected to ignore the AQ OPT of the query, and
may echo the received OPT back into additional section of the
response message.
and the following part of Section 5 seems to rely on that
assumption:
If the initial value of the AQ-RCODE is unchanged in the response, it
indicates that the responder is AQ unaware.
But, as far as I know actual implementations tend to NOT echo back
unrecognized options.
- Section 6: there's a missing period after 'example.com':
Answer | example.com IN A 192.168.0.1 |
--
JINMEI, Tatuya
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
