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 a...@example.com, 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.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop