FW: NOTIFY-triggered Auto-slaving

[David Botham]

Oops, I think I left the list addy off this last night... sorry....


Dave...




I have been thinking about this issue.  Some of what I have come up with
is:

Primary Master sends "ASLAVE" packet to the slave(s).  Here is the
packet breakdown:

HEADER...
queryID= <id>
qr=0
z=0
opcode= ASLAVE (5)
rcode= noerror
flags= aa
qdcount= 1
ancount= 0 or >3 
nscount= <variable... number of master ns>
arcount= <variable... number of zone specific options sent>

QUESTION...
qname= <zone name to load>
qclass= <class to which this zone will be added> 
qtype= LDZONE (251) [this is a new QTYPE]

ANSWER... [the view data]
(If specified, there should be at least 4 RR here,
first one is always view name & class, and three others for the 
mandatory args to the view statement.  Other TXT RRs can 
be added for the view statement optional args)
name= <name of view | arg to view>
type= TXT (16)
class= IN
ttl= 0
rdlength= <as required>
rdata= <class for view | arg data>

AUTHORITY... (one entry for each master)
name= <dname of name server>
type= NS (2)
ttl= <as required>
rdlength= <as required>
rdata= <ip address of ns>

ADDITIONAL... (one for each option being sent)
name= <name of option being sent>
type= TXT (16)
ttl= 0
rdlength= <as required>
rdata= <args to option>

Upon receipt of this message, the slave would:
1.  Add the zone def to named.conf.
2.  Zone to be added is in qname.
3.  Class of zone is in qclass.
4.  View to whish zone is added is optionally specified in ANSWER
section in the form of TXT RR.  If not specified, ancount=0, zone is
added to the default view and the ANSWER section MUST be ignored.
5.  AUTHORITY section provides IP address of the master name servers.  
6.  ADDITIONAL section provides the options for the zone in named.conf
in the form of TXT RRs.


There are of course a bunch of other considerations like (these are of
course the ones that come to mind quickly):

1.  What about slave acknowledges?
2.  Is there a better way to handle the views data?
3.  TSIG should handle the trust issues... right???.... :)
4.  Should there be some limitation on the options that the master can
send.  If so, do we specify it in rfc or do we leave it up to the slave
to decide what options are allowed.  This section is a whole can of
worms.  One way might be something like:  The slave has a named.conf
section for ASLAVE configs that uses ACLs or TSIGs to define templates
for acceptable options.  By default

What do you think?

Thanks,


Dave...