> -----Original Message----- > From: Evan Hunt [mailto:e...@isc.org] > > On Wed, Mar 29, 2017 at 12:41:26AM +0000, Woodworth, John R wrote: > > I believe this would ultimately be less efficient than generating > > the records on the fly. > > Unquestionably. This clearly wouldn't be the preferred behavior. > If the slave does understand BULK records, you'd just transfer those. > > > Assuming a relatively small range, say an IPv4 /16. You would > > need to sweep through similar logic and load _every_single_answer_ > > into memory rather than just the ones which are asked for. > > Sure, that's what $GENERATE does. The generated records are then > transfered normally. You con't end up with one auth server that > has generated records and another that doesn't. > > > I see no reason caching couldn't be used to hold the more > > commonly requested records in order to save on CPU. (apologies > > for double-neg) > > > > Additionally, the patterns could (and most likely should) be pre- > > parsed for simpler/ lower calorie processing. > > But if you have a primary that supports BULK and a secondary that > doesn't, then you have two authoritative servers for the same domain > with the same serial number but one of is saying NXDOMAIN when the > other one returns a positive answer. This is a significant problem, > and the draft ought to address it. (Or have I misunderstood > something?) >
Hi Evan, Thanks again for your continued feedback. A reasonable amount of inconsistency is expected and even tolerated in the wild today. As far as BULK RRs are concerned, we do touch on it in section 6.2. "Prior to widespread adoption on the authoritative side all generated records would be invisible if served on nameservers lacking support. Since generated records are generally NOT service impacting records this should be understood but not of great concern." Should BULK RRs gain wider adoption more quickly than expected perhaps this would not be a prolonged condition. Making support optional, while I do not strongly oppose, would definitely exacerbate the issue of consistency to some extent. Thanks, John > > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. > > -- THESE ARE THE DROIDS TO WHOM I REFER: This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
