Re: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-accompanying-questions-00.txt

["Jiankang Yao" <[e-mail]>]

From: Ray Bellis
Date: 2016-04-29 17:38
To: draft-yao-dnsop-accompanying-questions
CC: dnsop
Subject: Re: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-accompanying-questions-00.txt


> I am unconvinced that the ability to specify multiple QNAMEs offers any
> benefits and can't think of any good use cases where the client knows a
> priori what the other QNAMEs might be.   [ I don't consider looking up
> example.com and www.example.com at the same time to be 'good' ].
> 

when receiving an email from [e-mail], I often would like to visit the website of www.example.com too when I reply the email.

another examples are :
1, when querying DNSSEC records for www.example.com, it normally needs querying example.com too for DNSSEC verification.

2, DKIM exmaple in Appendix A of rfc5617

Appendix A.  Lookup Examples

   aaa.example                  A     192.0.2.1        (1)
   _adsp._domainkey.aaa.example TXT   "dkim=all"       (2)

   bbb.example                  MX 10 mail.bbb.example (3)
   mail.bbb.example             A     192.0.2.2        (4)

3, DMARC example
when you query for example.com, you might look up for  _dmarc.example.com 



> The examples given all appear to show a recursor -> authority query, but
> I see no hint in the draft about whether it's only for that path or also
> for stub -> recursor.
>

I think that it works for both.

The hint is the name "responder", "initiator"

section  4.  Responder Processing  . . . . . . . . . . . . . . . . . . . .   5
section   5.  Initiator Processing  . . . . . . . . . . . . . . . . . . . .   6

Inititator can be stub or recursor
Responder can be authority server or recursor




Best regards.

Jiankang Yao

> Ray
> 

> p.s. I noticed a dangling reference to RFC1321 (MD5) ?
> 
typos. will remove it. thanks for catching it.