Re: Extending UPDATE to add/remove zones

In message <[email protected]>, Jay Daley writes
:
> 
> On 17/10/2013, at 10:08 AM, Mark Andrews <[email protected]> wrote:
> 
> > A zone, by definition, only contains records of a single class.
> 
> It's not that I doubt you but can you provide a reference to that so =
> that I can if there is any wriggle room there?


RFC 1034 4.2. How the database is divided into zones

I won't quote all of this but you can't achieve what is defined there
without zones being a single class.

RFC 1035 5.2. Use of master files to define zones

When a master file is used to load a zone, the operation should be
suppressed if any errors are encountered in the master file.  The
rationale for this is that a single error can have widespread
consequences.  For example, suppose that the RRs defining a delegation
have syntax errors; then the server will return authoritative name
errors for all names in the subzone (except in the case where the
subzone is also present on the server).

Several other validity checks that should be performed in addition to
insuring that the file is syntactically correct:

   1. All RRs in the file should have the same class.

   2. Exactly one SOA RR should be present at the top of the zone.

   3. If delegations are present and glue information is required,
      it should be present.

 
> And what would your solution be to signifying that a zone is to be =
> deleted?  Without one we have to abandon extending UPDATE and burn an =
> opcode.
> 
> Jay
> 
> --=20
> Jay Daley
> Chief Executive
> .nz Registry Services (New Zealand Domain Name Registry Limited)
> desk: +64 4 931 6977
> mobile: +64 21 678840
> linkedin: www.linkedin.com/in/jaydaley
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email protected]
_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext