Subject: [dnsext] A new DNS message - SERVEZONES

From: Jay Daley <[email-masked]>
Date: Tue, 13 Aug 2013 14:48:12 +1200

Not sure where else to take this but I thought you might be interested in it, though possibly more in a "we don't need this you heretic" type of way.  Feedback most welcome, honest.

Jay

A new version of I-D, draft-daley-servezones-00.txt
has been successfully submitted by Jay Daley and posted to the
IETF repository.

Filename:	 draft-daley-servezones
Revision:	 00
Title:		 DNS SERVEZONES message
Creation date:	 2013-08-13
Group:		 Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-daley-servezones-00.txt
Status:          http://datatracker.ietf.org/doc/draft-daley-servezones
Htmlized:        http://tools.ietf.org/html/draft-daley-servezones-00

Abstract:
  This memo describes an addition to the DNS protocol that support the
  remote provisioning of zones on authoritative servers.  This addition
  is complementary to the existing mechanisms for provisioning zone
  data using the DNS protocol.

-- 
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

---

From: Miek Gieben <[email-masked]>
Date: Mon, 12 Aug 2013 20:31:43 -0700

[ Quoting <[email-masked]> in "[dnsext] A new DNS message - SERVEZ..." ]
> Not sure where else to take this but I thought you might be interested in it, though possibly more in a "we don't need this you heretic" type of way.  Feedback most welcome, honest.

somewhat like pdns's supermasters?

http://doc.powerdns.com/html/slave.html#supermaster

grtz Miek

---

From: Jay Daley <[email-masked]>
Date: Tue, 13 Aug 2013 15:40:59 +1200

> http://doc.powerdns.com/html/slave.html#supermaster

Ah yes I'd forgotten about that.  Not quite the same as supermasters is only for provisioning slaves whereas servezones can provision both masters and slaves.  Also, if I remember rightly, supermasters can only add zones and not remove them whereas servezones can do both.

Check out the draft - you'll be surprised at how short and neat it is.

thanks
Jay

---

From: Miek Gieben <[email-masked]>
Date: Mon, 12 Aug 2013 20:58:16 -0700

[ Quoting <[email-masked]> in "Re: [dnsext] A new DNS message - SE..." ]
> Ah yes I'd forgotten about that.  Not quite the same as supermasters is only for provisioning slaves whereas servezones can provision both masters and slaves.  Also, if I remember rightly, supermas…

True, but with a simple hack that could be added too (a SOA with all
0's).

> Check out the draft - you'll be surprised at how short and neat it is.

Yes, I did. What I'm saying is that something like this already exists
and it didn't need to protocol change/addition, there is some elegance
in that.

IMO you should at least mention it [supermasters] and make a case for your proposal?

- Grtz,

 ---
   Miek Gieben

---

From: Mark Andrews <[email-masked]>
Date: Tue, 13 Aug 2013 14:05:57 +1000

This appears to burn a opcode for no good reason.

UPDATE w/ a EDNS option say "NEWZONE" could replace the master side
of this w/o burning a opcode.

NOTIFY w/ type NS could replace the slave side of this w/o burning
a opcode.

The FQDN restrictions.  Do they apply to rdata or not?

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Jay Daley <[email-masked]>
Date: Tue, 13 Aug 2013 16:33:53 +1200

> True, but with a simple hack that could be added too (a SOA with all

It's not as simple as that:

Is that hack for provisioning a master or for removing a zone?  And how would you provision the initial data of a master before it started serving?

> IMO you should at least mention it [supermasters] and make a case for your proposal?

I like the general idea that certain masters have more authority, elegant as you say, but I wouldn't describe servezones as inelegant by comparison since it is simple and straightforward.  However there is much more to supermasters that needs to be done before I need to mention it.  

To be clear if someone did work that idea up into a full proposal that does what servezones does then I would be pleased.

Jay

> 
> - Grtz,
> 
> ---
>   Miek Gieben
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

---

From: Jay Daley <[email-masked]>
Date: Tue, 13 Aug 2013 16:44:16 +1200

> This appears to burn a opcode for no good reason.

We're not exactly burning them when the last one was added 16 years ago in 1997 and one was reclaimed 11 years ago in 2002.

> of this w/o burning a opcode.

So can only one zone be specified or are the RRs in the UPDATE now taken as zones?  And how does it delete zones - with the same overloading of TYPE or CLASS?  And what about the pre-requisites, are they ignored or must they exist before the zone can be deleted?

> NOTIFY w/ type NS could replace the slave side of this w/o burning

Again all this does is generate a list of questions.

I'm not averse to an alternative that hacks the existing protocol but it's not trivial.

> The FQDN restrictions.  Do they apply to rdata or not?

No.

Jay

---

From: Mark Andrews <[email-masked]>
Date: Tue, 13 Aug 2013 15:42:11 +1000

In message <[email-masked]>, Jay Daley writes:
> We're not exactly burning them when the last one was added 16 years ago =
> in 1997 and one was reclaimed 11 years ago in 2002.

It's only a 4 bit space.
 
> So can only one zone be specified or are the RRs in the UPDATE now taken
> as zones?  And how does it delete zones - with the same overloading of
> TYPE or CLASS?

I can think of a couple of ways to do this using notify/update/edns.

> And what about the pre-requisites, are they ignored or
> must they exist before the zone can be deleted?

You apply them as normal to a empty zone if it doesn't already
exist otherwise you apply them to the zone.

> I'm not averse to an alternative that hacks the existing protocol but

Actually it is pretty trivial if all you want to do is tell a server
to start/stop serving a zone.  The hard part is all the metadata that
is associated with serving a zone and making that generic enough to
be useful in a multi-vendor way.

---

From: Jay Daley <[email-masked]>
Date: Tue, 13 Aug 2013 18:02:13 +1200

>> in 1997 and one was reclaimed 11 years ago in 2002.

One every 16 years gives us 192 years until we exhaust even 4 bits.

> ...

> be useful in a multi-vendor way.

If it's trivial then it would be great if you could write it up and we can compare.  I'm not stuck on servezones if there is a better alternative.

Jay

---

From: Phil Regnauld <[email-masked]>
Date: Tue, 13 Aug 2013 11:47:50 +0530

> be useful in a multi-vendor way.

	There were a couple of efforts to address this I believe, including NSCP.

	Cheers,
	Phil

---

From: Jim Reid <[email-masked]>
Date: Tue, 13 Aug 2013 09:11:35 +0100

> This appears to burn a opcode for no good reason.

There are plenty to spare, so burn away.

That said, it would be prudent to define just one opcode covering server "management" in general -- ie start/stop doing something -- and maybe another for provisioning. There be rat-holes...

> NOTIFY w/ type NS could replace the slave side of this w/o burning

Both of these are very bad ideas because they change the behaviour and semantics of an already widely deployed part of the DNS protocol.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 13 Aug 2013 18:31:40 +1000

In message <[email-masked]>, Jim Reid writes:
> That said, it would be prudent to define just one opcode covering server =
> "management" in general -- ie start/stop doing something -- and maybe =
> another for provisioning. There be rat-holes...
> 
> >=20
> Both of these are very bad ideas because they change the behaviour and =
> semantics of an already widely deployed part of the DNS protocol.

How does it break the sematics of UPDATE?

server 1.2.3.4
newzone example.net
update add example.net 3600 SOA ...
update add example.net 3600 NS ...
update add example.net 3600 NS ...
update add example.net 3600 A ...
send

The only difference is you don't get NOTAUTH as a rcode if you tell the
server to create the zone.

It would be about 10 minutes work to add this to named.

---

From: Jay Daley <[email-masked]>
Date: Tue, 13 Aug 2013 20:46:52 +1200

Answering a couple of points:

> That said, it would be prudent to define just one opcode covering server "management" in general -- ie start/stop doing something -- and maybe another for provisioning. There be rat-holes...

I would prefer that DNS server management was a different protocol.  Phil mentioned NSCP, which is an excellent candidate.  Provisioning is an oddity because it didn't exist in DNS originally but was added with UPDATE and having done that I can see the value in finishing the job by adding the provisioning of zones but I can't currently see any value in going further than that.

> How does it break the sematics of UPDATE?

Presumably because people are not looking for the new EDNS code in their existing code and its existence changes the way the data is interpreted, so the behaviour of existing code could vary.

> update add example.net 3600 A ...

How do you delete a zone?  

Jay

---

From: Jim Reid <[email-masked]>
Date: Tue, 13 Aug 2013 10:10:42 +0100

> How does it break the sematics of UPDATE?

Jay's already explained that.

> server to create the zone.

Taking the above strawman example, how would the server at 1.2.3.4 signal to the client that although it speaks UPDATE, it doesn't do this new-fangled "newzone" featurette? For instance because the server doesn't understand this weird UPDATE message or has no code to support that or because it won't/can't allow new zones to be added on the fly, say for policy reasons or file system permissions?

Also, consider backwards compatibility. The installed base won't know to interpret your UPDATE message with extra newzone EDNS secret sauce. They'd just see a regular UPDATE with some EDNS goop that makes no sense to them. Would they (a) reject the request outright (FORMERR? NOTIMP?); (b) try to process the "vanilla" part of that UPDATE message and ignore the EDNS stuff?

Maybe you'd need to burn an error code or two here... :-)

The above are rehotorical questions BTW: there's no need to answer them.

---

From: Jelte Jansen <[email-masked]>
Date: Tue, 13 Aug 2013 11:23:24 +0200

> I would prefer that DNS server management was a different protocol.  Phil mentioned NSCP, which is an excellent candidate.  Provisioning is an oddity because it didn't exist in DNS originally but w…

FYI, in terms of efforts, there's also the approach taken in Yadifa:
https://ripe66.ripe.net/presentations/207-YADIFA-RIEP66-DynamicProvisioning-pres.pdf

IIRC, there were also some other proposals in the style of the old
metazones idea back then (and i recall one floating around based on a
class instead of an opcode).

AFAIK, NSCP hasn't had any action since it got kicked back to dnsop,
lots of people want it, noone wants to work on it, and perhaps it is
also overshooting the goals people have.

BTW, The nscp mailing list wasn't used in the end, but it never did get
cleaned up. So if there is gonna be a bigger effort than 'just' adding
and removing zones, perhaps we can try again.

PS I ran out of initialisms to start my sentences with.

Jelte

---

From: Mark Andrews <[email-masked]>
Date: Tue, 13 Aug 2013 20:35:10 +1000

In message <[email-masked]>, Jim Reid writes:
> Taking the above strawman example, how would the server at 1.2.3.4 signal
> to the client that although it speaks UPDATE, it doesn't do this
> new-fangled "newzone" featurette?

It would return NOTAUTH if it didn't understand the EDNS option and
didn't have the zone.  It had the zone it would "add" the records
which in most cases would be a no-op.  If you add "prereq nxdomain
<zone>" to the above none of the adds would take with a existing
zone.

> For instance because the server doesn't understand this weird UPDATE
> message or has no code to support that or because it won't/can't allow
> new zones to be added on the fly, say for policy reasons or file system
> permissions?

If you don't allow adding new zones you return REFUSED.  Filesystem
problems are no different to not being able to create a journal,
you get SERVFAIL.

> Also, consider backwards compatibility. The installed base won't know to
> interpret your UPDATE message with extra newzone EDNS secret sauce.
> They'd just see a regular UPDATE with some EDNS goop that makes no sense
> to them. Would they (a) reject the request outright (FORMERR? NOTIMP?);
> (b) try to process the "vanilla" part of that UPDATE message and ignore
> the EDNS stuff?
> 

Well the questions are addressable.

---

From: Phil Regnauld <[email-masked]>
Date: Tue, 13 Aug 2013 16:19:38 +0530

> PS I ran out of initialisms to start my sentences with.
	
	ROFL. Maybe it's time I looked at NSCP and draft-regnauld-ns-communication
	(2006!) with new glasses :)

	TTFN,
	Phil

---

From: Joe Abley <[email-masked]>
Date: Tue, 13 Aug 2013 08:38:10 -0400

> also overshooting the goals people have.

There's an implementation that works with multiple nameservers, right?

I don't remember how polished it was, but I remember it being good enough for Sara to be able to do live demos from the stage at RIPE meetings. Even considering Sara's nerves of steel, that suggests it works well enough :-)

  https://dev.sinodun.com/wiki/display/DNSCCM/DNSCCM+Home

Joe

---

From: Jay Daley <[email-masked]>
Date: Wed, 14 Aug 2013 09:01:49 +1200

> https://ripe66.ripe.net/presentations/207-YADIFA-RIEP66-DynamicProvisioning-pres.pdf

Wow.  So this uses DNS UPDATE syntax with a new CLASS to identify itself and a whole set of TYPES have been redefined to be interpreted as provisioning/control instructions.

As a general comment, while the YADIFA implementation is clever I for one don't agree that it is appropriate to add so much provisioning/control into DNS.  Adding/removing zones is an obvious, glaring gap but everything else belongs in an out-of-band protocol like NSCP.  

I say that because we know that DNS server/service providers are continually innovating their feature set.  That's how they differentiate themselves now that DNS servers are commodities.  If all of the provisioning/control is baked into the DNS protocol then it gets very messy when people wish to add proprietary features.  An out-of band protocol with support for extensions, similar to EPP, provides a much better way to support this innovation.

> also overshooting the goals people have.

AFAICT NSCP was just ahead of its time and the depth of features that it has now matches pretty well the depth of features that people are implementing, for example as in YADIFA above.  If anything that just proves how good an idea NSCP was *cough* and what benefits we would all now be accruing had it been agreed as an RFC some years ago.

Jay

---

From: Johan Ihrén <[email-masked]>
Date: Wed, 14 Aug 2013 12:26:13 +0200

>> I would prefer that DNS server management was a different protocol.

Amen to that. I think we're way past the point where we need to discuss whether this is wanted or not (it is), but most of the implementations go for the in-band alternative of overloading the DNS protocol with this type of provisioning information, i.e. traditional mixing of control plane and data plane.

While the DNS protocol does have a bit of bad history in that space (all the SOA parameters specifying slave server refresh and retry behaviour for instance) I think it would be... ummm... unfortunate... to continue down that path just because it is the easiest. 

I'd much rather have a new protocol, be it NSCP or something else.

>> Phil mentioned NSCP, which is an excellent candidate.  Provisioning is an oddity because it didn't exist in DNS originally but was added with UPDATE and having done that I can see the value in finishing the job by adding the provisioning of zones but I can't currently see any value in going further than that.
> 

Shuddder.

> also overshooting the goals people have.

Could be. I've thought a bit about that over the years, and that's probably the best explanation.

Regards,

Johan

---

From: John Dickinson <[email-masked]>
Date: Fri, 16 Aug 2013 12:48:30 +0000

>  https://dev.sinodun.com/wiki/display/DNSCCM/DNSCCM+Home

Yes - we produced an implementation of NSCP a while back which supports BIND 9 and NSD 3 but is now stuck at beta because a) the funding ran out (billable work got in the way) and b) we didn't ever get anyone interested in testing it in anger. We have version 3 of the draft (based on the working implementation) that is 95% done, just stalled at final review as these things tend to do......

Technically the issues we faced with the implementation were:
- We chose to use NETCONF/ Yang which had some limitations. At the time there was only one Open Source implementation of NETCONF (Yuma) which was missing a couple of key features.
-  NETCONF assumes that devices have an API available to dynamically update single elements of the configuration. This didn't play so nicely with nameservers that need to reload the entire config to pick up any change...
- the NETCONF/ Yang model assumes that there is a nice clear base control protocol which every device (nameserver) implements. Then everything else is treated as an optional extension. When you try to implement this for nameservers (even just the the two we implemented) your base model turns out to be tiny since each nameserver does even the most basic things in different enough ways to make a common model tricky. 

I believe there was some work done by BIND10, KNOT and others to try to align their remote control protocols but I don't know the details.

We would be interested in revisiting, updating the code and ID if there is any interest on the dnsop list.

regards
John

---
[email-masked]

http://sinodun.com

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

+44 (0)1491 834957

---

From: Miek Gieben <[email-masked]>
Date: Wed, 21 Aug 2013 16:52:01 -0700

> Ah yes I'd forgotten about that. Not quite the same as supermasters is only
> for provisioning slaves whereas servezones can provision both masters and
> slaves. Also, if I remember rightly, supermasters can only add zones and not
> remove them whereas servezones can do both.

I just rememered how I "solved" this once. Just set a low(er) expiration on
your zone. Who cares if a zone is still running on a server somewhat
longer?

grtz Miek

---

From: Jay Daley <[email-masked]>
Date: Fri, 23 Aug 2013 08:15:12 +1200

> your zone. Who cares if a zone is still running on a server somewhat

I am surprised that you would ask that.  

We regularly get complaints from a registrant that they moved registrar and shifted their website but customers of the old registrar still see their old website.  When the old registrar is one of the largest ISPs in the country, this is a big problem.  I am sure that many other registries get the same complaints.

I would not want to set a low enough expiry to make this a problem as that then introduces a very high dependency on the uptime of the master.  It's unnecessary.

Jay

---

From: Miek Gieben <[email-masked]>
Date: Thu, 22 Aug 2013 20:58:30 +0000

> We regularly get complaints from a registrant that they moved registrar and
> shifted their website but customers of the old registrar still see their old
> website. When the old registrar is one of the largest ISPs in the country,
> this is a big problem. I am sure that many other registries get the same
> complaints.
>
> I would not want to set a low enough expiry to make this a problem as that
> then introduces a very high dependency on the uptime of the master. It's
> unnecessary.

Ok, fair enough. The usecase for when I needed this was different.

grtz Miek