> Here's a chart summarizing the situation: > > Timing of |Useful in|RFC 1034 |BIND 8 |BIND 9 |tinydns > data change |practice |compliant|support|support|support > ------------------+---------+---------+-------+-------+------- > Synchronized |Yes |Yes |No |No |Yes > Semi-synchronized |Yes |No |Yes |Yes |Yes > Unsynchronized |No |No |No |Yes |No This is not a accurate summary. > The BIND company observes that > > * synchronized changes are hard to do with BIND, even though they're > required by RFC 1034; and RFC 1034 requires the *administators* to keep the glue in sync. Section 4.2.2. Administrative considerations As the last installation step, the delegation NS RRs and glue RRs necessary to make the delegation effective should be added to the parent zone. The administrators of both zones should insure that the NS and glue RRs which mark both sides of the cut are consistent and remain so. This is a administrative action. If you can automate administrative actions well and good. Using a single file for all your PRIMARY zones is actually a useful way to partially achieve this. It will keep all PRIMARY zones on the server in sync. If you wish you can copy the contents of a SECONDARY into a PRIMARY provided you also change the SERIAL of the PRIMARY to reflect the change. I wouldn't encorage this as a default action however. However changing the contents of SECONDARY zones is not allowed. That action needs to be performed through the PRIMARY server for the zone. UPDATE could be used to facilitate this. Again I would not encourage this as a default action. A server ceases to be a SECONDARY if it changes the zones contents. > * unsynchronized changes can fail miserably with BIND 8 et al., which > account for the majority of DNS servers. Which is why we fixed our server. > The obvious solution is semi-synchronized changes, which work with the > entire installed base. I wouldn't object to modifying RFC 1034 to allow > semi-synchronized changes. You have to be kidding. Even if we were to go down that path (which I don't believe we should) it still leaves servers with the underlying problem in that they are not serving the zone contents as entered. > (To repeat the relevant definitions: A synchronized change happens at > the same time in all the parent servers and all the child servers. A > semi-synchronized change happens in the parent zone---specifically, the > parent serial is changed---after it happens in all the child servers.) > > I certainly _do_ object to allowing unsynchronized changes. They don't > work correctly with the installed base, and they have no advantages over > semi-synchronized changes. It's insane to demand massive redeployment of > DNS servers for the sake of a useless protocol modification. Nobody is demanding a massive redeployment. None of the changes require a massive redeployment. Mark -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@isc.org