Subject: Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-01.txt

From: 延志伟 <[email-masked]>
Date: Thu, 23 Jul 2015 12:50:37 +0800 (GMT+08:00)

Hi, Stephane,
Sorry for the delayed response.
Please find the in-line answers and welcome your further comments:

* the draft gives the impression that it authorizes a new behaviour. 
But auth. servers have been sending extra data (IP address of a MX target, for instance) for years.

#Z.W. Yan: Yup, auth servers have been including extra data for a long time, but
only certain sets of information -- things like IP for MX, CNAME
followups, etc. They haven't really been sending other answers, not
strictly in support of the original query. This is because receivers
have not been willing to accept this, *because they cannot trust it*.
Basically what we are saying is, now that DNSSEC exists, resolvers can
trust data in the additional section, so it is worth sending it
again...

* the draft says these extra data MUST (RFC2119-MUST) be validated with DNSSEC. 
Does it mean that the current behaviour of sending extra data for unsigned zones is now illegal?

#Z. W. Yan: Not illegal, as explained above, if we want to make well use of this function, we need to guarantee its security.

* followup off the previous question] should we instead say that
extra data should be sent (and should be accepted by clients) if and
only if (DNSSEC-validated _or_ in-bailiwick)? The current behaviors of
resolvers (accept extra data if in-bailiwick) does not seem to be
mentioned.

#Z. W. Yan: The background of the current situation will be added in the next version.

* the draft says "an authoritative name server operator can ensure
that the recursive server that the client is using has all the answers
in its cache". This is very dangerous because people may read it "we
now have a sure way to control what ends in the resolver's cache"
which is clearly not the case (the resolver may refuse some of the
extra data, the TTL of the extra data may mae it expire before the
"main" data, etc).

#Z. W. Yan: we will revised it as: "an authoritative name server operator can ensure that the recursive server that the client is using has all the answers in its cache from the authoritative point of view".

BR,
Zhiwei YAN

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 23 Jul 2015 18:46:06 +0200

On Thu, Jul 23, 2015 at 12:50:37PM +0800,
 延志伟 <[email-masked]> wrote 
 a message of 113 lines which said:

> #Z. W. Yan: we will revised it as: "an authoritative name server
> #operator can ensure that the recursive server that the client is
> #using has all the answers in its cache from the authoritative point
> #of view".

Sorry, but it is false, for the reasons explained in my first
message. You cannot ensure that.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 23 Jul 2015 19:32:58 +0200

> message. You cannot ensure that.

Yah, true. The recursive server is free to not accept responses, to
evict cache entries early, to <gulp> stretch TTL, etc.

An authoritative name server can provide information so that the
recursive server that the client is using can populate its cache if
wants to...?

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf