Terry Manderson has entered the following ballot position for draft-ietf-dnsop-root-loopback-04: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-root-loopback/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for writing this document and describing how it is done and also the risks of doing this, and most importantly why it should not be done on a whim or by default. I concur that this is not a new idea. In fact I implemented a similar thing during my ISP days in the late 90's and it was certainly more beneficial then due to the low change rate of the root zone, and the absence of DNSSEC, along with slower network speeds, and less instances of anycasted root-serves. That said, the operational costs were the same and they have been well covered in the doc. Can you please pay a little attention to the first sentence of the security considerations? Its a doozy and I had to re-read it a couple time to be clear on its meaning. In the appendix, different locations to get the zone by AXFR are specified. Have you considered highlighting that the zone can be collected from authoritative points in other ways? e.g. - https://www.iana.org/domains/root/files (noting ftp and http methods. - https://http.l.root-servers.org (and plain http) (and of course there may well be others, but I'll refrain from boiling that ocean) I would also like to see the observation made that no public AXFR service (that I am aware of) uses TSIG, so the fetching party is at the general risk exposure of non-TSIG AXFR. Not so much in terms of modifying data in the zone (as it's signed and the DNSSEC support on the recursive resolver is a MUST) but in a MiTM effort to simply withhold new versions of the root zone in a DoS frame. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
