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