-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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. 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. 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. 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. | ========== 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. | 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. 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. hth, Doug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJUb/5mAAoJEFzGhvEaGryEnYoH/1Lvs47zjL3/e6zIkeolzVGS bLgoPswAbnWB9fhQxaXwNTjoQDFT3ckiQEmUFvdlVPM3wPSKRbiwS89JsRL7nDWI /rGAlqD13mZJoc/gKWFbQor3GpBKSI1SBbqv4OMQuKf1TRaFkHb9rXimgqlQ0m7b 4nzqtPESWztC/1tZQ2r88mJV4Gs98oRyixrYggmrdZV7SQwa1xWrAM0K2FShRplC YuUL1r25TbLtTLj6hxy7LR9A6BuaTfGbAdbATwol0j8+8ZevdIEoJqka9bG3X6ma YNID0vHHpSMDz3WteYjEzgeN3zfHy8arpC4EIyhVmeLemlSP60wNkVoVLvX0Upg= =NWKA -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
