On Nov 21, 2014, at 7:09 PM, Doug Barton <do...@dougbarton.us> wrote: > On 11/21/14 6:12 PM, Paul Hoffman wrote: > | Clearly, different people view the "advantages" and "disadvantages" > | separately. The wording below tries to make the comparisons neutral > | while still fully stating what the differences are. Note that I > | made this wording specific to BIND: when we have other multi-view > | servers in the examples, I'll write specific wording for them. Is > | the following (re-)wording correct and complete? > > I chose the wording I did in the version I sent very carefully, > because the issues discussed are exactly the same if you use two views > in the same instance, or if you use multiple instances.
Good point. In fact, Evan made that point to me earlier and I forgot it. :-( > The latter > issue is particularly relevant at larger sites since I could easily > imagine a site setting up their own root instance with a slaved copy > of the zone that their resolvers are configured to forward to. That could be the case, but it is not relevant for this draft, which is only about slaving on a loopback address on the same box. > Bob's request was to outline the pros and cons of each method, so that > people who are less sophisticated about these things will know how to > make a decision about what method to choose. I think showing that two > views would operate the same as two different instances is important > for meeting that goal. As long as we are talking about two instances running on the same box, I agree. See below. > Regarding making the wording BIND specific, I'm not opposed to that > per se, I'm just curious if there is any other commonly used software > capable of doing both authority and recursion in the same instance. If > there is, we should not make the wording specific to BIND. I have been told informally that PowerDNS will be able to do both in the future. However, unless it has the exact same implementation considerations as BIND, trying to have one set of wording cover both will probably be impossible to read. I would rather fork the wording in the two sections and make sure it is succinctly about the specific software. > > | ========== BIND handles both DNSSEC validation and caching of > | changed authoritative information differently depending on the > | whether the configuration is to use two separate views (one for the > | authoritative zone, one for recurison) or to use the same view for > | both servers. > > The sentence above makes little sense, and could even be described as > misleading. If you want to leave the following two paragraphs the way > you have them, and account for what I discussed above, you could open > with something like this: > > Name server software that permits authoritative zones and recursion to > exist in the same instance (such as BIND) will treat the zone data > differently if it is slaved into a separate view (or a separate > instance of the software) versus slaving the zone into the same view > or instance that is also performing the recursion. I was trying to be specific about the differences, but I can see that being more general would make it more readable. > > | Validation: When using separate views, the DS records in the slaved > | zone will be validated as the zone is refreshed or updated. > > That is factually incorrect. They will be validated as they are used. Yeeps, good catch. > I'm not sure where this obsession came from about validating the zone > when it's transferred. That's never been a part of DNSSEC. > > Here's my previous paragraph on this, modified to fit your format a > bit better: > > When using a separate view in a recursor that is also performing > DNSSEC the DS records in the slaved zone will be validated as they are > used. In BIND this validation does not occur when the zone is slaved > into the same view where the recursion is occurring. > > | When using the same view, this validation does not occur for the > | slaved zone. > | > | Caching: When using separate views, the recursive server will cache > | all of the queries it looks up, just as it would using the > | traditional root hints method. Thus, as the zone in the other view > | is refreshed or updated, changed information will not appear in the > | recursive server until the TTL of the old record times out; > | currently the TTL for DS and delegation NS records is two days. > | When using the same view, as the zone is refreshed or updated, all > | zone data in the recursive server will be updated as soon as it > | receives its copy of the zone. > > There are several grammatical problems with this paragraph. Here's an > update with some other refinements: > > When using separate views the recursive server will cache all of the > queries for the slaved zone, just as it would using the traditional > root hints method. Thus, as the zone in the other view is refreshed or > updated changed information will not appear in the recursive server > until the TTL of the old record times out. Currently the TTL for DS > and delegation NS records in the root zone is two days. When using the > same view all zone data in the recursive server will be updated as > soon as it receives its copy of the zone. Put together, and still open to comment: When slaving a zone, BIND will treat zone data differently if it is slaved into a separate view (or a separate instance of the software) versus slaving the zone into the same view or instance that is also performing the recursion. Validation: When using separate views or separate instances, the DS records in the slaved zone will be validated as the zone data is accessed by the recursive server. When using the same view, this validation does not occur for the slaved zone. Caching: When using separate views or instances, the recursive server will cache all of the queries for the slaved zone, just as it would using the traditional root hints method. Thus, as the zone in the other view or instance is refreshed or updated, changed information will not appear in the recursive server until the TTL of the old record times out. Currently the TTL for DS and delegation NS records is two days. When using the same view, all zone data in the recursive server will be updated as soon as it receives its copy of the zone. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
