At 10:05 +0100 12/20/06, Stephane Bortzmeyer wrote:
I would like to know if people here believe that this work is on-topic
for the WG. It does not change the protocol (so it does not seem
adapted to DNS Extensions) but it is not really "DNS operations".
Title : Requirments for the Nameserver Communication protocol
I don't know...the choice doesn't matter much to me I think. That's
all IETF politic talk.
I read the doc and couldn't help jumping in on the topic (some more).
What I've been screaming for (well, not loudly or even audibly in the
IETF) is for a way to alter configuration files remotely. This could
be the avenue for that. One question is whether this will also be a
run-time management tool also. I'll have to explain, but I'll do
that in how in a break down of the things the protocol might work on.
1) Zone management.
Zone lifetime management is already in the document. We would have
to formalize zone types beyond master and slave, such as forward and
stub (from the document). We'd have to also include all the options
settings that we want to make interoperable, like TSIG keys per zone.
I would also like to have the ability to send high-volume zone
updates in small batches before presenting the new zone to the
public. To tell the truth, I am not sure if this is practical, but
what makes me think of it is a potential change of salt in NSEC3.
2) Views.
Views is a concept that a lot of folks like, but is a BINDism. There
would need to be (mindful if intellectual property concerns) an open
definition of what views are and then a way to manage them. This is
something that is client-server in the management plane. Perhaps not
everyone able to manage a zone can manage a view. I.e., views may
only be manageable per IP addresses on the host, as opposed to being
able to add another slave zone within a view.
3) Nameserver configuration options.
Things like what IP addresses to listen on, port numbers, recursion
available, cache settings (as opposed to cache cleaning later),
logging details (as opposed to log level later). These
configurations are much different from zone management in the sense
that a commercial (not necessary for profit) name server operator may
allow a customer a range of zones to manage but not allow them to
touch the recursion settings. This begs the need for a multi-level
authorization model, akin to what we have seen for dynamic update
security.
4) Dynamic update security management.
This probably part of #3, but I wanted to call it out because it is
also like #2 in a way. We need to figure out the policy rules for
things like TKEY management.
5) Nameserver runtime options.
Things like cache clearing, logging detail, whether to log queries,
freeze/thaw dynamic updates. What I would like here is something
akin to what RNDC gives BIND 9.
6) Nameserver health and lifetime reporting.
The nameserver ought to remind the zone administrators of events,
including the termination of the name server's own domain name (if it
knows).
There are probably other pipe dreams to throw at this.
Other comments - I don't think that this protocol need to be
restricted to a client-server protocol in the requirements. It might
be best implemented that way once we understand the problem, but in
these modern times we have more options. Client-server is a
simplistic protocol model, simple is good but it can be constraining.
For example, I can see a scenario like this...I have a slave zone on
a server. First I can ask "what views do you have" and get back a
list and the criteria used to select the view for a packet. I would
then use this to decide if I want my zone to be in any specific view
on the server. (And there may only be one view on the server.)
This is client-server, but a multi-step, state eating operation.
After all, this is a connection-oriented, pre-arranged credential
situation.
It would also be good to figure out a way to string command paths
together. If I have 5 name server processes behind a load balancer,
I'd like to be able to send the commands to one and have it repeat
them to the peers. This can be repeated between sites too. IOW,
this is kind of like a permitted worm (see DARPA active nets research
projects for background).
This effort could be quite large or quite constrained. I'm
indifferent in how large a scope is desired, but whatever scope is
desired, it has to be made really clear.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Dessert - aka Service Pack 1 for lunch.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop
