Dear JINMEI-san,
Thanks a lot for your kind review. All your comments/questions are very
helpful to improve the document.
More comments are followed below.
thanks a lot.
Jiankang Yao
From: 神明達哉
Date: 2016-10-25 02:47
To: Jiankang Yao
CC: dnsop; Paul Vixie
Subject: Re: [DNSOP] Fw: New Version Notification for
draft-yao-dnsop-accompanying-questions-01.txt
> A few comments on a quick read:
>
> - Does it assume to be used for exchanges between stub and recursive
> resolvers?
>
yes.
Intended for Both " between stub and recursive resolvers", and "between
recursive and authoritative"
>If it's also intended to be used between recursive and
> authoritative, how does it handle a delegation answer?
>
Most RRs needed to parallel query are normally located in the same zone.
In case of that some sub-domain names are delegated, the Delegation information
will be returned to the recursive server.
the recursive server then check the sub-domain based on the Delegation
information and get the answer.
> - Should we assume SOA('s) in the authority section for negative
> answers?
>
yes.
> - 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.
>
For each accompanying question, I suggest to remove AQ and Count/Seq bits,
and add AQ-ANCOUNT, AQ-NSCOUNT and AQ-ARCOUNT bits
AQ-ANCOUNT an unsigned 16 bit integer specifying the number of
resource records in the answer section.
AQ-NSCOUNT an unsigned 16 bit integer specifying the number of name
server resource records in the authority records
section.
AQ-ARCOUNT an unsigned 16 bit integer specifying the number of
resource records in the additional records section.
> - 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.
>
the proposed AQ-ANCOUNT, AQ-NSCOUNT and AQ-ARCOUNT bits can make it clear
> - 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.
>
pls see above.
>
> - 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.
>
If we describe the Prefix field as the domain name which uses the message
compression specified in section 4.1.4. of rfc1035, that may be easily
understood.
We will update this part of text.
> - 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.
>
yes.
> But, as far as I know actual implementations tend to NOT echo back
> unrecognized options.
>
In this case, the Initiator receiving no AQ OPT will assume that the Responder
does not support AQ.
We will clarify it in the new vesion. Thanks for catching it.
> - Section 6: there's a missing period after 'example.com':
>
> Answer | example.com IN A 192.168.0.1 |
>
will update it.
thanks.
Jiankang Yao
> --
> JINMEI, Tatuya_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
