Subject: [nscp] Welcome (and proposed charter)

From: Jelte Jansen <[email-masked]>
Date: Wed, 15 Sep 2010 11:28:40 +0200

First of all: Welcome, and thank you for joining, or at least not immediately
unsubscribing ;)

As you may or may not remember, we had an informal meeting at IETF 78 in
Maastricht, which I personally think went pretty well. I shall send out the
notes from that meeting shortly.

It has been a while since then, and I had hoped to get this list up before the
BoF Request had to be submitted, so we could discuss a charter to propose, which
is needed for a BoF request. However, getting the list to be set up took a bit
more time than expected (nearly 6 weeks, to be exact), and the deadline for
requesting BoF meetings at IETF 79 has passed by now.

Therefore, Stephen and I have written a proposed draft charter, which I sent in
with the BoF request. I'll add it below this message, and comments or
suggestions are very welcome. We do still have some time left before the next
IETF, so I trust we can get consensus on what it is we're trying to achieve here.

Jelte

NSCP (draft) Charter
- --------------------

Objective
- ---------

Specify an interoperable mechanism to monitor, control and configure common
functionality of DNS nameservers.

Problem statement
- -----------------

The problem statement that this working group seeks to address can be
summarised as follows:

  Management of name servers for the Domain Name System (DNS) [RFC1034]
  [RFC1035] has traditionally been done using vendor-specific
  monitoring, configuration and control methods.  Although some service
  monitoring platforms can test the functionality of the DNS itself
  there is not an interoperable way to manage (monitor, control and
  configure) the internal aspects of a name server itself.

  Previous standardization work within the IETF resulted in the
  creation of two SNMP MIB modules [RFC1611] [RFC1612] but they failed
  to achieve significant implementation and deployment.  The perceived
  reasons behind the failure for the two MIB modules are further
  documented in [RFC3197].

(From draft-ietf-dnsop-name-server-management-reqs-04)

Despite the failure to achieve acceptance of an SNMP-based solution,
there is a perceived need for an interoperable way to manage nameservers,
something that led to the aforementioned draft being written to document
the requirements. Although this draft was written under the auspices of
the DNSOP working group, work to develop a solution is outside its charter.

The NSCP working group will develop a protocol to fulfill these
requirements.  The aims of the group will be to:

1. Review work to date (such as draft-dickinson-dnsop-nameserver-control-00,
which proposes a solution based on Netconf and Yang) and the available
technologies and choose a suitable technology on which to base future work.

2. Produce document(s) specifying a name server control protocol that address
the requirements of interoperable management of nameservers.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 15 Sep 2010 08:30:42 -0700

>Objective

Probably the most common functionality is updating zone files. Is this in scope, out of scope, or not determined yet? There is clamoring for secure updating that is easier to configure and than SIG0 and its friends, and almost no one cares if this is done in the DNS protocol, so this WG might or might not be the right place for that.

--Paul Hoffman, Director
--VPN Consortium

---

From: jad <[email-masked]>
Date: Wed, 15 Sep 2010 17:53:15 +0100

> Probably the most common functionality is updating zone files. Is this in scope, out of scope, or not determined yet? There is clamoring for secure updating that is easier to configure and than SIG…

Our thinking at the time was that nscp would need some limited mechanism to create new zones. You need at least an SOA and filename after all. However, there are many ways that the zone data could be inserted into the zone. Dynamic updates,. AXFR, checkout from subversion, database..... 

So I do think that the bulk creation/insertion of zone data is out of scope. However, configuration of the nameserver so that it knows how to get that data is in scope.

John 

---
John Dickinson

http://sinodun.com

Sinodun Internet Technologies Ltd.
Stables 4, Suite 11
c/o HR Wallingford,
Howbery Park,
Wallingford,
Oxfordshire,
OX10 8BA,
U.K.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 15 Sep 2010 09:57:20 -0700

>So I do think that the bulk creation/insertion of zone data is out of scope. However, configuration of the nameserver so that it knows how to get that data is in scope.

If you think it is out of scope, the charter needs to day that.

OTOH, why not allow it using the same mechanism that is being used for the rest of the control? That is, don't prevent "Dynamic updates,. AXFR, checkout from subversion, database.....", but specify how to do it the same way as the rest of the control?

--Paul Hoffman, Director
--VPN Consortium

---

From: jad <[email-masked]>
Date: Wed, 15 Sep 2010 18:03:12 +0100

> OTOH, why not allow it using the same mechanism that is being used for the rest of the control? That is, don't prevent "Dynamic updates,. AXFR, checkout from subversion, database.....", but specify…

Sure, I wouldn't prevent nscp from updating zones. But I don't think nscp would be the best way or my first choice. So maybe saying "out of scope" is a bit strong.

John

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 15 Sep 2010 14:57:35 -0400

--On Wednesday, September 15, 2010 06:03:12 PM +0100 jad <[email-masked]> 
wrote:

>>>>> Specify an interoperable mechanism to monitor, control and configure
>>>>> common functionality of DNS nameservers.
>>>>
>>>> Probably the most common functionality is updating zone files. Is this
>>>> in scope, out of scope, or not determined yet? There is clamoring for
>>>> secure updating that is easier to configure and than SIG0 and its
>>>> friends, and almost no one cares if this is done in the DNS protocol,
>>>> so this WG might or might not be the right place for that.
>>>
>>> Our thinking at the time was that nscp would need some limited
>>> mechanism to create new zones. You need at least an SOA and filename
>>> after all. However, there are many ways that the zone data could be
>>> inserted into the zone. Dynamic updates,. AXFR, checkout from
>>> subversion, database.....
>>>
>>> So I do think that the bulk creation/insertion of zone data is out of
>>> scope. However, configuration of the nameserver so that it knows how to
>>> get that data is in scope.
>>
>> OTOH, why not allow it using the same mechanism that is being used for
>> the rest of the control? That is, don't prevent "Dynamic updates,. AXFR,
>> checkout from subversion, database.....", but specify how to do it the
>> same way as the rest of the control?
>
> Sure, I wouldn't prevent nscp from updating zones. But I don't think nscp
> would be the best way or my first choice. So maybe saying "out of scope"
> is a bit strong.

In fact, I think it very much should be in scope.  Loading generated 
records from a zone file is a non-starter if you're also going to allow 
dynamic updates to that zone, and loading updates via DDNS, while possible 
is extremely annoying.  To make loading generated zone data work well, I 
need to keep metadata alongside each record indicating where it came from, 
so I can distinguish changes made by DDNS clients from situations where the 
zone simply doesn't match the current version of the generated data.  Today 
I do that by keeping a specially-formatted TXT record alongside each "real" 
record, so they can be updated at the same time (as part of the same 
(atomic) DDNS update).  I'd much rather do zone content management outside 
the DNS protocol, with the server not only keeping my record-origin 
metadata but also providing me with information about when a record was 
last updated and by what client, which doesn't appear in the DNS.

IMHO, zone content management certainly should be in scope.

-- Jeff

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 16 Sep 2010 15:01:31 +0200

On Wed, Sep 15, 2010 at 02:57:35PM -0400,
 Jeffrey Hutzelman <[email-masked]> wrote 

> IMHO, zone content management certainly should be in scope.

-1 for a practical reason: we already have several good ways to update
zone content and two are standard and use the DNS (RFC 2136 and
5936).

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 16 Sep 2010 08:35:57 -0700

>zone content and two are standard and use the DNS (RFC 2136 and

Aren't those only applicable when the zone admin is also running a DNS server, brings it up to date, and then tells the DNS admin to synchronize? And aren't there *many* other deployment scenarios for DNS content?

--Paul Hoffman, Director
--VPN Consortium

---

From: Lars-Johan Liman <[email-masked]>
Date: Thu, 16 Sep 2010 21:28:24 +0200

Hi, Paul!

On Wed, Sep 15, 2010 at 02:57:35PM -0400, Jeffrey Hutzelman <[email-masked]> wrote

[email-masked]:
> Aren't those only applicable when the zone admin is also running a DNS
> server, brings it up to date, and then tells the DNS admin to
> synchronize? And aren't there *many* other deployment scenarios for
> DNS content?

This discussion can continue from here to eternity and back - and
probably will. ;-)

I agree with Stéphane that there are already standardized mechanisms to
handle zone content updates. I may well be that they require the zone
admin to run a DNS server, but you _can_ (and that's an obvious future
to me) send dynamic updates from an application that doesn't work as a
DNS server _to_ the master server, so _some_ of your cases can probably
be dealt with, but not all. *)

I agree with you that there may be scenarios where these mechanisms are
suboptimal or even inappropriate, but there is at list _a_ mechanism (or
two) for that, whereas in the case of sending "commands" to the DNS
server, there is none.

So, my proposal is

a) Let's cut out a limited piece of work for ourselves to start with,
   and make sure we get to the other end of it in forseeable time.

b) When we do so, we should focus on things for which we have _no_
   current alternative, as opposed to things for which we have already
   at least one alternative, imperfect as it may be.

I.e., leave out updating zone content for now - at least zone content
for which the receiving end is authoritative.

				Cheers,
				  /Liman

*) One obvious case that _cannot_ be dealt with using dynamic updates is
"remove this record from the cache". There are most certainly more.

#----------------------------------------------------------------------
# Lars-Johan Liman, M.Sc.   ! E-mail/SIP/Jabber: [email-masked]
# Senior Systems Specialist ! Tel: +46 8 - 562 860 12
# Autonomica AB, Stockholm  ! http://www.autonomica.se/
#----------------------------------------------------------------------

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 16 Sep 2010 14:19:45 -0700

>This discussion can continue from here to eternity and back - and

Given that it already has, and eternity is ahead of us, yes.

>be dealt with, but not all. *)

I was not aware of those applications. Can you point to some examples?

>for which the receiving end is authoritative.

That works for me, although it should probably be written into the charter.

--Paul Hoffman, Director
--VPN Consortium

---

From: Lars-Johan Liman <[email-masked]>
Date: Fri, 17 Sep 2010 00:01:07 +0200

> I was not aware of those applications. Can you point to some examples?

Well, "nsupdate" is the most obvious one. "dhclient" and "dhcpd" are two
more.

> That works for me, although it should probably be written into the charter.

It should, definitely.

				Cheers,
				  /Liman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 16 Sep 2010 15:25:34 -0700

>Well, "nsupdate" is the most obvious one. "dhclient" and "dhcpd" are two

Wow, my memory for programs I don't like is bad. Good call on all of them.

> > That works for me, although it should probably be written into the charter.

If others agree that we want to possibly do this, but only after we have done the "new" work first, I'll write up proposed words. What do folks think?

--Paul Hoffman, Director
--VPN Consortium

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 17 Sep 2010 01:15:13 +0200

> If others agree that we want to possibly do this, but only after we have done the "new" work first, I'll write up proposed words. What do folks think?

I agree that we should focus on new work first as proposed in previous
mails. My understanding of this group is that we basically want start
with protocol to add/remove/modify zone configuration remotely.

Ondrej
-- 
Ondřej Surý <[email-masked]>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 17 Sep 2010 18:06:38 -0400

--On Friday, September 17, 2010 01:15:13 AM +0200 Ondřej Surý 
<[email-masked]> wrote:

>> If others agree that we want to possibly do this, but only after we have
>> done the "new" work first, I'll write up proposed words. What do folks
>> think?
>

I don't see managing zone content as necessarily wanting to be a separate 
protocol from adding zones and setting policy for them.  Let's not paint 
ourselves into a corner.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 17 Sep 2010 15:15:25 -0700

At 6:06 PM -0400 9/17/10, Jeffrey Hutzelman wrote:
>--On Friday, September 17, 2010 01:15:13 AM +0200 OndÞej Sur˜ <[email-masked]> wrote:
>
>I don't see managing zone content as necessarily wanting to be a separate protocol from adding zones and setting policy for them.  Let's not paint ourselves into a corner.

I don't see us saying "we'll do that after we have settled on a protocol and specified other management actions first" as "paint ourselves into a corner". It's delaying stuff that can be a distraction.

--Paul Hoffman, Director
--VPN Consortium

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 17 Sep 2010 18:27:10 -0400

--On Friday, September 17, 2010 03:15:25 PM -0700 Paul Hoffman 
<[email-masked]> wrote:

>>>> If others agree that we want to possibly do this, but only after we
>>>> have done the "new" work first, I'll write up proposed words. What do
>>>> folks think?
>>>
>> I don't see managing zone content as necessarily wanting to be a
>> separate protocol from adding zones and setting policy for them.  Let's
>> not paint ourselves into a corner.
>
> I don't see us saying "we'll do that after we have settled on a protocol
> and specified other management actions first" as "paint ourselves into a
> corner". It's delaying stuff that can be a distraction.

I'm fine with not working on that right now, and even with expressing that 
in the charter.  But I don't want to be having a discussion six months from 
now about whether a proposed protocol is flexible enough to support zone 
content management and have someone make the argument "it doesn't have to 
be; that's out of scope".

As I see it, zone content management should be in scope for the 
to-be-developed protocol, and needs to be one of the things we consider as 
we design that protocol, even if actually defining how it works is not one 
of the first things we work on.

-- Jeff

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 20 Sep 2010 19:25:52 +0200

On Sat, Sep 18, 2010 at 00:27, Jeffrey Hutzelman <[email-masked]> wrote:
>>>>>> > That works for me, although it should probably be written into the
>>>>>>>
>>>>>>> charter.
>>>>>>
>>>>>> It should, definitely.
>>>>>

Well, you should probably explain why do you think we need
yet-another-protocol for managing zone contents.

There were voices against including it with reasoning (let's focus on
things with no alternative), so if you state that this should be
inside the charter, you should probably provide some arguments why
*XFR method is not sufficient and what will be the improvement against
AXFR/IXFR (+bunch of other out-of-band file transfer methods).

Ondrej

---

From: Tony Finch <[email-masked]>
Date: Mon, 20 Sep 2010 18:54:03 +0100

> AXFR/IXFR (+bunch of other out-of-band file transfer methods).

Dynamic DNS updates are the normal way for managing zone contents
on the master. *XFR are for copying from the master to the slaves.

I thought this group would be standardizing rndc.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 20 Sep 2010 14:24:30 -0400

>of the first things we work on.

Have you read RFCs 1995, 1996 and 5936 for inter-authority server 
coordination of zone content and RFCs 2136 and 3007 for altering the 
content?

Certainly the specified mechanism(s) have their limitations, but 
that's not what I think is needed to be discussed now.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Spouses, like Internet protocols, lack necessary troubleshooting tools. Sigh.

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 20 Sep 2010 14:07:37 -0700

>>>>> On Mon, 20 Sep 2010 19:25:52 +0200, Ondřej Surý <[email-masked]> said:

OS> Well, you should probably explain why do you think we need
OS> yet-another-protocol for managing zone contents.

FYI, as a point of historical reference, the discussion in the dcoma
group went something like this:

1) we already have protocols for transferring zone data
2) we don't have any way, however, to create "initial zones".  IE, the
   missing piece is the ability to send an SOA record to bootstrap the
   nameserver into saying "add this new zone to your authoritative list"
3) we agreed that although existing solutions worked just fine for
   updating zone date once the server was configured to serve that zone,
   we didn't want to "restrict the future".
4) having said that, there was no one in the rooms/list (of many people)
   that thought a new protocol should be used for transferring zone data
   because the existing ones were likely sufficient.

However, one point of netconf is the ability to do a complete
dump/restore of config data and you wouldn't want to exclude the zone
data from that dump/restore set.

IMHO, for a long term solution the results must include the ability to
manage zone data.  It doesn't necessarily need to be in the first
version of the resulting management framework.  Though you could leave
it out of version 1.0, it's a very very important piece to solve "in the
long-term, big-picture"
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Tony Finch <[email-masked]>
Date: Mon, 20 Sep 2010 23:27:13 +0100

On 20 Sep 2010, at 22:07, Wes Hardaker <[email-masked]> wrote:
> 
> However, one point of netconf is the ability to do a complete dump/restore of config data and you wouldn't want to exclude the zone data from that dump/restore set.

DNSSEC makes zone dump and restore harder, because you may have to re-sign the zone if the dump is old. However the existing protocols already handle online signing of dynamic updates, so very little programming is required to AXFR a zone to make a dump, then restore it with a series of incremental updates. I expect that sites needing a more efficient DR plan will have more sophisticated ways to provision their master servers.

Tony.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 20 Sep 2010 15:43:10 -0700

>the requirements of interoperable management of nameservers.

Proposed addition to #2:

Although updating of zone information is potentially an interesting use for such a protocol, it is already possible to do with other standards and thus will not be considered as a design goal until after the other types of control are specified. However, the new protocol needs to be able to handle the addition of an empty zone and the removal of a zone as part of the initial protocol.

--Paul Hoffman, Director
--VPN Consortium

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 20 Sep 2010 18:50:04 -0400

--On Monday, September 20, 2010 02:24:30 PM -0400 Edward Lewis 
<[email-masked]> wrote:

>> to-be-developed protocol, and needs to be one of the things we consider
>> as we design that protocol, even if actually defining how it works is
>> not one of the first things we work on.
>

No, I've never read any DNS-related RFC's, and I don't understand a thing 
about how the system works.  I certainly have never operated a nameserver, 
let alone operated a moderately complex system of servers supporting 
several dozen zones and over 25K names for over a decade.  And I've never, 
ever written a line of DNS-related code.

I think it should be quite clear that while zone transfers and IXFR (and 
the associated notification mechanisms) are effective for distributing zone 
data to slaves, they are not a management mechanism.  Since we're here to 
talk about management, and the immediate question is whether and to what 
extent management of zone content should be in scope, I fail to see how the 
existance of zone distribution mechanisms, incremental or otherwise, is 
relevant.

Certainly DDNS is useful for one-off updates.  It works well for updates 
from DHCP servers, or from clients/end-users.  It even works well for 
management, if your operation is simple enough that you can simply declare 
that the nameserver is the ultimate source of authority and all updates are 
done by administrators manually issuing DDNS updates.  Unfortunately, for 
_automatic_ management, such as keeping up to date with an external source 
that is the true authority while simultaneously accepting some kinds of 
update dynamically from users, DDNS is woefully inadequate.  I covered some 
of this in my first message on the topic, which apparently people didn't 
bother to read before telling me I was an idiot or that I needed to justify 
my argument:

> To make loading generated zone data work well, I need to keep metadata
> alongside each record indicating where it came from, so I can distinguish
> changes made by DDNS clients from situations where the zone simply
> doesn't match the current version of the generated data.  Today I do that
> by keeping a specially-formatted TXT record alongside each "real" record,
> so they can be updated at the same time (as part of the same (atomic)
> DDNS update).  I'd much rather do zone content management outside the DNS
> protocol, with the server not only keeping my record-origin metadata but
> also providing me with information about when a record was last updated
> and by what client, which doesn't appear in the DNS.

Let me make my position crystal-clear, if I can:

I'm not arguing that support for managing zoen content needs to happen now. 
I _am_ arguing that it needs to be able to happen in the future.  If I see 
work proceeding in a direction that would make it difficult or impossible 
to add record-level management operations, I will object.  If I see a 
proposed charter that is designed to forestall such objections now and 
forever by ruling record-level management out of scope, I will object to 
_that_.

> Certainly the specified mechanism(s) have their limitations, but that's
> not what I think is needed to be discussed now.

On the contrary, what we're discussing now is the scope of the proposed 
working group.  If there's an argument to be made that certain work should 
be out of scope because it's adequately addressed by existing protocols, 
then the limitations of such protocols are certainly relevant to the 
discussion.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Carnegie Mellon University - Pittsburgh, PA