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

From: "Jiankang Yao" <[email-masked]>
Date: Tue, 3 May 2016 14:21:42 +0800

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 [email-masked], 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.

---

From: Ray Bellis <[email-masked]>
Date: Tue, 3 May 2016 08:43:55 +0100

On 03/05/2016 07:21, Jiankang Yao wrote:

> when receiving an email from [email-masked] 
> <mailto:[email-masked]>, 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?

> 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.
>> 
> 

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

---

From: Paul Wouters <[email-masked]>
Date: Tue, 3 May 2016 11:36:39 -0400 (EDT)

> Hmm...   Isn't "EDNS chain query" supposed to solve this?

Yes.

> list) as to whether it would be appropriate to perform those lookups in

It would be nice if you do a qtype=mx lookup that you could get the
related records. Whether it is dmarc or tlsa or ipseckey. But what
happened is that we moved those type of records to a different location
from the qname. So that made this proposed feature a lot less
interesting.

Paul

---

From: "Jiankang Yao" <[email-masked]>
Date: Mon, 16 May 2016 09:32:05 +0800

From: Paul Wouters
Date: 2016-05-03 23:36
To: Ray Bellis
CC: yaojk; dnsop

>related records. 

this is one possible solution.

but you have to design different rfcs for different similar use cases.
for examples:
for dmarc, you need to design one
for tlsa or ipseckey, you design another one.

in future, when similar use cases appear again, you have to produce another another rfc.
for example, https://tools.ietf.org/html/draft-ietf-uta-smtp-tlsrpt-00 
UTA is also a possible customer for draft-yao-dnsop-accompanying-questions-00.txt  

>Whether it is dmarc or tlsa or ipseckey. But what

our current suggested solution's benefit is that 

draft-yao-dnsop-accompanying-questions-00.txt  can work for most current use cases mentioned such as dmarc, tlsa or ipseckey.

it will also work for future use cases https://tools.ietf.org/html/draft-ietf-uta-smtp-tlsrpt-00.

If there is a solution which can kill two birds with one stone, why refuse to use it?

Best Regards

Jiankang Yao