On 03/05/2016 07:21, Jiankang Yao wrote:
> when receiving an email from a...@example.com > <mailto:a...@example.com>, I often would like to visit the website of > www.example.com <http://www.example.com> too when I reply the email. IMHO it would be an incredibly unwise thing for any software to do this without it being explicitly requested by the user on a domain-by-domain basis. [imagine getting an email purporting to be from some illicit site that ends up with your system being logged as making DNS lookups for its website...] > another examples are : 1, when querying DNSSEC records for > www.example.com <http://www.example.com>, it normally needs querying > example.com too for DNSSEC verification. Hmm... Isn't "EDNS chain query" supposed to solve this? > 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) The RFC 5617 text following these examples describes those lookups as sequential - I'd defer to the authors of those (John Levine reads this list) as to whether it would be appropriate to perform those lookups in parallel. > 3, DMARC example when you query for example.com, you might look up > for _dmarc.example.com That doesn't seem unreasonable. >> 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" In which case the draft is (IMHO) severely lacking in guidance about how a recursive resolver is supposed to gather any results it doesn't have, nor how it might respond "I don't know (yet)" for entries that might exist but are not in cache. Ray _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
