IETF Secretariat wrote: > The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state > Candidate for WG Adoption (entered by Tim Wicinski) > > The document is available at > https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/
Hi, I've read the -03 version of this draft and previous mailing list discussion about prior versions of the draft and I don't support its adoption. There doesn't seem to be a strong (preferably data-driven) reasoning to justify the mechanism described in the draft, and in previous discussion [0] it's described as being, essentially, just an interesting optimization. [0] https://mailarchive.ietf.org/arch/msg/dnsop/NruMO-whi7UW7gzXF-gu9OrYTMg For keeping popular records in cache, pre-fetching (e.g. draft-wkumari-dnsop-hammer) would seem like a less disruptive technique since it can be implemented entirely by the recursive name server, and it can also be applied to unsigned records, of which there are still quite a few. Pre-fetching probably doesn't help unpopular records as much (if at all), but unpopular records (by definition) don't have as many users as popular records. About the draft itself: I wondered why signalling is necessary. • RFC 1034 §4.3.2 “Algorithm”, step 6: 6. Using local data only, attempt to add other RRs which may be useful to the additional section of the query. Exit. This would seem to let an authoritative nameserver add any records deemed “useful” to the additional section of a response. (The RFC says “query” instead of “response” here, but that is almost certainly an erratum.) • RFC 2181 §5.4.1 “Ranking data”: Unauthenticated RRs received and cached from the least trustworthy of those groupings, that is data from the additional data section, and data from the authority section of a non-authoritative answer, should not be cached in such a way that they would ever be returned as answers to a received query. They may be returned as additional information where appropriate. Ignoring this would allow the trustworthiness of relatively untrustworthy data to be increased without cause or excuse. When DNS security [RFC2065] is in use, and an authenticated reply has been received and verified, the data thus authenticated shall be considered more trustworthy than unauthenticated data of the same type. […] This is the prohibition on promoting additional section RRs to answer section RRs in the responses returned to clients. But the prohibition only applies to unauthenticated RRs. It actually sub-divides the “Additional information from an authoritative answer” rank into two sub-ranks based on DNSSEC status. Is there anywhere else in the DNS/DNSSEC specs that would prohibit that promotion, where the additional record is DNSSEC secure? Otherwise I would think that nameservers could populate the additional section with whatever they want, and security-aware recursive name servers could pick up secure RRs from the additional section, and cache them such that they would be returned in the answer section to clients, all without any signalling. So the EXTRA bit could be eliminated? • Section 8 “Use of Additional information” from the draft: When receiving additional records in the additional section, a resolver follows certain rules: 1. Additional records MUST be validated before being used. 2. Additional records SHOULD be annotated in the cache as having been received as Additional records. 3. Additional records SHOULD have lower priority in the cache than answers received because they were requested. This is to help evict Additional records from the cache first (to help prevent cache filling attacks). 4. Recursive resolvers MAY choose to ignore Additional records for any reason, including CPU or cache space concerns, phase of the moon, etc. It may choose to accept all, some or none of the Additional records. is very confusing to me. I think it doesn't apply to additional records that are the normal result of additional section processing? I think it is actually talking about “extra” records that are undergoing an upgrade. Basically, this whole idea seems to me like something that can already be implemented today, without any specification work other than the format of the EXTRA RR. But the EXTRA RR is just configuration information and you don't strictly need it until you want to distribute it interoperably. -- Robert Edmonds _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
