> On Aug 24, 2018, at 3:46 AM, Mark Andrews <ma...@isc.org> wrote: > > This is unnecessary. All the rule does is limit the process to class IN > zones. UPDATE, IXFR and AXFR are class agnostic. > > 1. TIMEOUT resource records are only defined for CLASS IN.
Ok, we will make them applicable to all classes. > > This seems overly restrictive. I would allow TIMEOUT records that > match added records to be accepted. > > 5. TIMEOUT resource records cannot be directly added, modified, or > deleted through DNS Update. This restriction is another consequence of not being able to query TIMEOUT records. In order to allow UPDATE of TIMEOUT records, the client has to be able to retrieve the record and merge changes before UPDATING it. The server can’t do the merging or the record would change underneath the client that created it when another client added a record with the same owner name. We haven’t been able to think of any significant downsides to allowing QUERY of TIMEOUT records and by doing so, it solves Joe’s issues so unless you can think of any, we’ll make that change in the next version and then be able to support UPDATE of TIMEOUT records. > > Secondary servers that are TIMEOUT aware should ignore TIMEOUT records > beyond storing them in case the server get promoted to being the master. > > Is the secondary going to be able regenerate the RRset as the records are > removed as well as generate and sign NSEC and NSEC3 records? I would expect a secondary server to treat them the same as it does any other record type. > > Sources of TIMEOUT Expiry Time > > Add matching TIMEOUT records added via UPDATE. Ok. Thanks! Tom _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
