Subject: [dnsext] Extending UPDATE to add/remove zones

From: Jay Daley <[email-masked]>
Date: Wed, 16 Oct 2013 22:33:03 +1300

From my previous post on my draft for a new DNS opcode - servezones - I think there is reasonable interest in an in-band mechanism that instructs a nameserver to etiher start or stop serving one or more zones.  The area with less certainty is what that mechanism should be, a new Opcode (but it's only a 4 bit space!) or extending UPDATE.

I'm planing to write a draft that shows how UPDATE could be extended to do this and then we can compare that with my servezones draft and see which is preferred.  To do that I'd like some help in determining the algorithm for how the extended UPDATE is processed. 

Here's my starter for 10.

1.  A new EDNS option code is assigned that changes the behaviour of the UPDATE as follows (alternatively this could be signalled with a ZTYPE different from SOA)

2.  The ZONE section specifies the zones to be added/removed.  There can be any number of zones listed here to add or remove.  For each zone, if the CLASS is ANY then the zone is to be removed, whereas if it is ANY then the zone is to be added.  This use of CLASS corresponds to the way that it is used to determine if an rrset should be added or removed in the current UPDATE message.

3.  The pre-requisite section is ignored.

4.  The Update section can only contain Adds and only when zones are to be added.  If any records are specified here then that means that the zones to be added are masters and these records are all added to those zones before serving begin.   None of these records may be fully qualified so as to ensure that they apply to all the zones listed.  One of these records must be a SOA record with an empty name, which will be replaced with the zone name

5.  If there is data in the Additional section then that signifies that the zones to be added are slaves.   The records here must be NS records that specify the masters for the zones to be added.  There can only be records here or in the Update section but not both as zones cannot be both masters and slaves.

Is that it? Anything need changing?

BTW we could extend this just a little bit more:

6.  If there is a DNSKEY record in the Additional section then this specifies a TSIG key that this server should use for pulling the zone.  The name for the DNSKEY record is the name of the key as used by TSIG.  This DNSKEY is not added into the zone.

Jay

-- 
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: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 16 Oct 2013 11:40:35 +0200

>6.  If there is a DNSKEY record in the Additional section then this
specifies a TSIG key that this server should use for pulling the zone.  The
name for the DNSKEY record is the name of the key as used by TSIG.  This
DNSKEY is not added into the zone.

I have a question. What would you do with the other algorithms of TSIG that
only use TSIG as an option and is quite different than original TSIG? Such
as cga-tsig.

Thanks,
Hosnieh

---

From: Jay Daley <[email-masked]>
Date: Wed, 16 Oct 2013 22:51:45 +1300

> only use TSIG as an option and is quite different than original TSIG? Such

I'm not sure how that is relevant - perhaps you could explain?  And to answer your question - I have no idea at all.

Jay

---

From: Andreas Gustafsson <[email-masked]>
Date: Wed, 16 Oct 2013 13:30:32 +0300

A couple of comments, without taking sides for or against the general
idea:

> For each zone, if the CLASS is ANY then the zone is to be removed,
> whereas if it is ANY then the zone is to be added.

Presumably the latter "is ANY" should read "is not ANY".

>  None of these records may be fully qualified so as to ensure that
>  they apply to all the zones listed.

There is no way to encode that in the DNS protocol.  All names are
fully qualified on the wire; relative names are merely a convenience
notation used in master files and other user interfaces.
-- 
Andreas Gustafsson, [email-masked]

---

From: Dave Lawrence <[email-masked]>
Date: Wed, 16 Oct 2013 10:19:03 -0400

> notation used in master files and other user interfaces.

Well sure there is, you declare "in this special type of message, all
of the records in the update section are relative to the zones in the
zone section."  I inferred the original intent was to be able to add a
block of zones all with the same template.

Personally I think that's a bad idea, or at the least underspecified
in the original description -- does this concept apply only to owner
names, or names within rdata as well?

It seems like a premature optimization though, and puts too many eggs
in one basket.  Just using separate messages for each zone with
everything fully-qualified does not seem like onerous overhead to me.

---

From: Bob Halley <[email-masked]>
Date: Wed, 16 Oct 2013 15:08:09 +0000

>block of zones all with the same template.

While it would be possible to interpret FQDNs as rooted at some other root
it's not a good solution because then there's no way for the data in the
update section to refer to something out of the zone.  That's OK for owner
names, but it's not OK for names in rdata, e.g. the target of a CNAME.
Zone templating requires the ability to specify both relative and absolute
names, and relative names are not currently representable in the DNS
protocol.

/Bob

---

From: Derek Atkins <[email-masked]>
Date: Wed, 16 Oct 2013 13:23:56 -0400

Hi,

Jay Daley <[email-masked]> writes:

>>From my previous post on my draft for a new DNS opcode - servezones -
> I think there is reasonable interest in an in-band mechanism that
> instructs a nameserver to etiher start or stop serving one or more
> zones.  The area with less certainty is what that mechanism should be,
> a new Opcode (but it's only a 4 bit space!) or extending UPDATE.
>
> I'm planing to write a draft that shows how UPDATE could be extended
> to do this and then we can compare that with my servezones draft and
> see which is preferred.  To do that I'd like some help in determining
> the algorithm for how the extended UPDATE is processed.
[snip]

I admit I haven't read the whole draft, but my question is how do you
authenticate and, more importantly, authorize the addition or (worse)
deletion of zones?  Imagine an attack vector where someone could get
your domain's DNS servers to stop serving your domain(s)!

I think the security of adding and (more importantly) removing zones
should be carefully documented and discussed.

> Jay

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Alex Bligh <[email-masked]>
Date: Wed, 16 Oct 2013 19:17:50 +0100

> should be carefully documented and discussed.

I'm not sure why this would be different from someone doing an update
to remove the entire content of the zone served. Thus I don't really
see why it should need security any different from the existing
provisions for security.

-- 
Alex Bligh

---

From: Jay Daley <[email-masked]>
Date: Thu, 17 Oct 2013 09:00:20 +1300

Thanks to all those that replied.  I've summarised and responded to the points below:

1.  The restriction on FQDNs is too complex and there's no problem with provisioning multiple zones in multiple packets.

I agree and I'll change it so that only one master can be added per update.  I was indeed thinking about zone templating and that's not a DNS issue. 

2.  Clarify what the ZCLASS needs to be set to.

ZCLASS == ANY means delete,  ZCLASS != ANY means add.

3.  There is a substantial security risk here that needs to be addressed.

I agree.  Both zone transfer and dynamic updates have security added over the top through IP address restriction and/or TSIG and I think the same approach should be taken here of identifying the security issue and recommending over the top security but not requiring any.  It would also be useful to state that implementors must support TSIG for this and must not turn it on by default.

One more question - do we really need an EDNS option code as we could do it all by the ZTYPE + ZCLASS without breaking anything:

	ZTYPE == SOA and ZCLASS != ANY means update an existing zone
	ZTYPE == NS and ZCLASS != ANY means add an existing zone
	ZTYPE == NS and ZCLASS = ANY means delete an existing zone

Any thoughts?

Jay

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Oct 2013 07:47:28 +1100

In message <[email-masked]>, Jay Daley writes
:
> 1.  The restriction on FQDNs is too complex and there's no problem with provi
> sioning multiple zones in multiple packets.
> 
> I agree and I'll change it so that only one master can be added per update.  
> I was indeed thinking about zone templating and that's not a DNS issue. 
> 
> 

If you have example.net/in and example.net/hs which example.net are you
referring to with example.net/any?

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: Thu, 17 Oct 2013 09:50:32 +1300

> referring to with example.net/any?

We've already got that problem:

In UPDATE as it currently exists if you have two different RRs  of the same type and different class in the same zone then which is being referred to with CLASS == ANY ?

Jay

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Oct 2013 08:08:46 +1100

In message <[email-masked]>, Jay Daley writes
:
> >> Thanks to all those that replied.  I've summarised and responded to
> the point
> >> s below:
> >>
> >>
> In UPDATE as it currently exists if you have two different RRs  of the
> same type and different class in the same zone then which is being
> referred to with CLASS == ANY ?

A zone, by definition, only contains records of a single class.  The zone
section specify the class of the zone being operated on.

Zone:  example.net IN SOA
Update: example.net ANY TXT

Says delete all example.net IN TXT records.

---

From: Jay Daley <[email-masked]>
Date: Thu, 17 Oct 2013 10:31:11 +1300

On 17/10/2013, at 10:08 AM, Mark Andrews <[email-masked]> 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?

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

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 16 Oct 2013 23:35:59 +0200

>I'm not sure how that is relevant - perhaps you could explain?  And to
answer your question - I have no idea at all.

Cga-tsig addresses secure authentication during different scenarios such as
FQDN, zone transfer, resolver to client, resolver to authoritative servers,
etc.
It uses cga parameters as a means for this authentication. CGA proves the
address ownership of nodes by finding a binding between the nodes' public
key and its iP address. Cga-tsig adds cga parameters to the otherdata
section of TSIG RDATA. So, it is quite different than TSIG but it will be a
new algorithm in tsig. 
http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-06

- What is the difference between your proposed work with cga-tsig draft and
tsig? What is the overlap between your proposed work and cga-tsig draft?

Thanks,
Best,
Hosnieh

---

From: Jay Daley <[email-masked]>
Date: Thu, 17 Oct 2013 10:43:57 +1300

> tsig? What is the overlap between your proposed work and cga-tsig draft?

No Hosnieh I'm not falling for that.  If you think there is any overlap/conflict/interaction between my proposed work and the cga-tsig draft then please identify it and I will address it.  

To be clear, since it appears to me that you might not have understood, the only idea I am floating around TSIG is that a DNSKEY record is given to a nameserver with the intention that is should use to authenticate (via TSIG) a zone transfer request for a new zone that it is asked to serve as a slave.

Jay

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 17 Oct 2013 00:12:48 +0200

Sorry I forgot to submit it to the list ...

>No Hosnieh I'm not falling for that.  If you think there is any
overlap/conflict/interaction between my proposed work and the cga-tsig draft
then please >identify it and I will address it.  

>To be clear, since it appears to me that you might not have understood, the
only idea I am floating around TSIG is that a DNSKEY record is given to a
>nameserver with the intention that is should use to authenticate (via TSIG)
a zone transfer request for a new zone that it is asked to serve as a slave.

I am attempting to rephrase my question. Correct me if I am wrong... I think
DNSKEY is for DNSSEC and not for TSIG. TSIG uses shared secret and it is
added to DNS configuration file (isn't stored in any record in database) .
dissimilar to a part of DNSSEC it is not public key cryptography. This means
that you cannot add the shared secret in DNSKEY for authentication. Security
problem... TSIG might use TKEY which is different than DNSKEY. 
Secondly, I guess addressing TSIG here does not really make sense as you are
not fully addressing security but you're planning to make the DNS update
more efficient. So, I suggest that you only think about  making the Update
more efficient and let other approaches like other RRs TSIG, cga-tsig secure
your approach. 

Thanks,
Best, 
Hosnieh

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Oct 2013 09:16:39 +1100

In message <[email-masked]>, Jay Daley writes
:
> 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

---

From: Jay Daley <[email-masked]>
Date: Thu, 17 Oct 2013 11:20:14 +1300

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

Great thanks - so overloading class to signify deletion can't be used at the zone level as there is no wriggle room at all.

Jay

---

From: Jay Daley <[email-masked]>
Date: Thu, 17 Oct 2013 11:31:24 +1300

> problem... TSIG might use TKEY which is different than DNSKEY. 

Yes it probably ought to be TKEY since this is what it is specifically designed for and not a DNSKEY but DNSKEY is so much simpler so I was just trying it on ...

> more efficient and let other approaches like other RRs TSIG, cga-tsig secure

You've misunderstood why the TSIG key appears in this message.  I am investigating adding new functionality to UPDATE and part of that new functionality requires the transmission of a TSIG key as data inside the packet, for the receiver to use elsewhere.  This TSIG key is not used in this transaction.

Jay

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Oct 2013 09:33:55 +1100

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

Add zone:
Zone: <zname> <class> NS
Update: <aname> <ttl> <class> SOA .....
	<rest of initial zone>
Additional:
master TXT [port=value] [A=value] [AAAA=value] [key=name[:alg:secret]] [name=name]
key TXT [key=name[:algorithm:secret]]
port TXT [port=value]
allow-transfer TXT <TBD>
allow-query TXT <TBD>
allow-update TXT <TBD>

Delete zone:
Zone: <zname> <class> NS
Update: <aname> <ttl> ANY SOA

The use of type NS in the zone section indicates that this is a whole of zone
operation.
 
Mark

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Oct 2013 18:37:20 -0400

> Yes it probably ought to be TKEY since this is what it is specifically designed for and not a DNSKEY but DNSKEY is so much simpler so I was just trying it on ...

You can use SIG(0) to authenticate DNS updates.   This relies on DNSKEY, and is indeed simple.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Oct 2013 10:27:39 +1100

In message <[email-masked]>, Ted Lemon writes
:
> > Yes it probably ought to be TKEY since this is what it is specifically desi
> gned for and not a DNSKEY but DNSKEY is so much simpler so I was just trying 
> it on ...
> 

No, it relies on KEY but I agree with you that it is simple.
 
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

---

From: Jay Daley <[email-masked]>
Date: Thu, 17 Oct 2013 13:46:21 +1300

> key TXT [key=name[:algorithm:secret]]

I sympathise with just how easy this would be, especially if the labels were prefixed with an underscore to prevent collisions, but I think this is a step too far given the variance in implementations and we should use NSCP instead.

> Update: <aname> <ttl> ANY SOA

That's excellent thank you.

I'll put together a draft.

Jay

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Oct 2013 12:37:40 +1100

In message <[email-masked]>, Jay Daley writes
:
> > master TXT [port=3Dvalue] [A=3Dvalue] [AAAA=3Dvalue] =
> [key=3Dname[:alg:secret]] [name=3Dname]
> > key TXT [key=3Dname[:algorithm:secret]]
> > port TXT [port=3Dvalue]
> > allow-transfer TXT <TBD>
> > allow-query TXT <TBD>
> > allow-update TXT <TBD>
> 
> I sympathise with just how easy this would be, especially if the labels =
> were prefixed with an underscore to prevent collisions, but I think this =
> is a step too far given the variance in implementations and we should =
> use NSCP instead.

Additional records don't get added to the zone.  They supplemental data just
like OPT TSIG SIG are supplemental data.  That said they could be defined
later.
 
> >=20
> > Delete zone:
> > Zone: <zname> <class> NS
> > Update: <zname> <ttl> ANY SOA
>

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 17 Oct 2013 00:17:44 -0400

> The use of type NS in the zone section indicates that this is a whole of zone
Mark  and Jay, 

why not burn RRTYPES for these commands ? 

To add a secondary (easier than primary) 
<name> ADDZONE <class> <master server> <port> <keying> 

To create a zone on primary
 <name> NEWZONE <class>  <zone_source>         (Zone source exampe : file:///var/tmp/newzone/name) 
<name> ALLOW <transfer><port> <query> <update>   (This is like a TXT record but with structure in order and number of fields)  
<name> GRANT <seeting up update rules> 

(ALLOW can also be supplied to secondary)

To Remove a zone 
<zone> DELZONE <class> <empty> 

We can keep going 
<zone> ADDFORWARD <forwarders list> 

<zone> DELFORWARD [empty] 
<zone> TAADD <new TA> 
<zone> TADEL <old TA>    (Avoiding using the name "DELTA")

	Olafur

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Oct 2013 15:38:59 +1100

In message <[email-masked]>, Olafur Gudmundsson 
writes:
> <name> ALLOW <transfer><port> <query> <update>   (This is like a TXT
> record but with structure in order and number of fields)

I don't really care which way we go.  It is the concepts that I
want to nail down first.  We also want the scheme to be extensible.

Class could be used to signal the removal of a field which would
slow the burn rate.

Mark

---

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 17 Oct 2013 10:28:42 +0530

On Wed, Oct 16, 2013 at 10:33:03PM +1300, Jay Daley wrote:
> 5.  If there is data in the Additional section then that signifies
> that the zones to be added are slaves.  The records here must be NS
> records that specify the masters for the zones to be added.  There can
> only be records here or in the Update section but not both as zones
> cannot be both masters and slaves.

Would glue be allowed here?

		Mukund

---

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 17 Oct 2013 10:36:07 +0530

> Would glue be allowed here?

I didn't see Mark's reply earlier, but something like that (to specify
the IP address, port, etc. of the master) would be needed.

		Mukund

---

From: Måns Nilsson <[email-masked]>
Date: Thu, 17 Oct 2013 09:35:50 +0200

> why not burn RRTYPES for these commands ? 

Excellent idea. Nobody is going to request any new RRTYPEs anyway,
since TXT is good enough, so we've got loads of them to burn.

</tangential sarcasm>

I think it might work -- it is not as bad an idea as my sarcasm above might depict it as. 

OTOH, a part of me ponders the phrase "out of scope" and points to
https://github.com/kirei/dper or similar mechanisms.

I have not decided yet. But am a happy user of dper. 

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
TONY RANDALL!  Is YOUR life a PATIO of FUN??

---

From: Jaap Akkerhuis <[email-masked]>
Date: Thu, 17 Oct 2013 09:45:27 +0200

I'm not familiar with dper but I too wonder about the tendency to
turn DNS servers into a provision engine as well.

	jaap

---

From: Jay Daley <[email-masked]>
Date: Thu, 17 Oct 2013 20:47:48 +1300

> why not burn RRTYPES for these commands ? 

Perhaps we should ask the Yadifa people to write up their overloading of RR types for in-band control as a draft to save us reinventing the wheel?

Jay

---

From: Jay Daley <[email-masked]>
Date: Thu, 17 Oct 2013 23:34:06 +1300

> Would glue be allowed here?

I see what you are getting at and I think that rather than NS + glue the records that must be here are either A or AAAA records that are the addresses of the servers to contact to pull the zone from.

Jay

---

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 17 Oct 2013 16:47:11 +0530

On Thu, Oct 17, 2013 at 11:34:06PM +1300, Jay Daley wrote:
> I see what you are getting at and I think that rather than NS + glue
> the records that must be here are either A or AAAA records that are
> the addresses of the servers to contact to pull the zone from.

One more thing:

RFC 1035 calls for durable storage of zone data. This is not a strict
requirement for configured secondaries if you consider that a secondary
can AXFR data from scratch during startup and store it in volatile
memory. There are no updates to zone data made at secondaries -
transfers not being considered as updates to data.

So far, the "catalog" (RFC 1035) is a part of the secondary
implementation's static configuration. The secondary can run without
writing to durable storage.

The case where a secondary crashes, loses its dynamic configuration
should be addressed. Is an admin expected to reconfigure the secondary
on startup each time? Is the secondary expected to save the updated
catalog to durable storage? (The latter may not be agreeable to
everyone, so support for both should be considered.)

		Mukund

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 18 Oct 2013 13:14:38 -0400

While this is discussed in dnsext, but there is a lot of good discussion 
on this, I wonder if we should carve out some time during DNSOP to 
discuss this?

tim

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 18 Oct 2013 13:51:01 -0400

On Fri, Oct 18, 2013 at 01:14:38PM -0400, Tim Wicinski wrote:
> 
> While this is discussed in dnsext, but there is a lot of good
> discussion on this, I wonder if we should carve out some time during
> DNSOP to discuss this?

Well, you certainly couldn't discuss it in the meeting of DNSEXT :)

My personal opinion is that DNS is an application, and that if you
want to make improvements to that application, the right WG to go to
is APPSAWG.  I'm aware that I'm sometimes regarded as an eccentric for
this view.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Jay Daley <[email-masked]>
Date: Tue, 22 Oct 2013 14:50:49 +1300

> everyone, so support for both should be considered.)

I think that is an implementation specific decision that should not be hard-coded in the protocol.  i.e. some may choose to require a dynamic re-configuration while others may store the configuration persistently.

Jay

---

From: Derek Atkins <[email-masked]>
Date: Thu, 17 Oct 2013 11:23:08 -0400

> see why it should need security any different from the existing

Well, if somone can add zones to my server it could be a DoS against my
network provider.  So how do you authorize the addition of new zones?
This is something that's definitely a new feature and isn't effectively
implementable using current UPDATE.

As for deleting zones vs deleting records, you're right that the
authorization required to remove all the records in a zone are
effectively the same as the authZ to remove the zone itself.  I believe,
however, that authZ is usually on a record-by-record basis, generally
providing for individuals to change the A record for their own devices.
At least that's how I think it SHOULD be -- I've never deployed UPDATE.
If that's the case then clearly one could have an AuthZ to remove the
SOA (and thereby the whole zone).

I still think it should be spelled out instead of "left for the reader
to figure out."

-derek

---

From: Mark Andrews <[email-masked]>
Date: Thu, 24 Oct 2013 09:20:23 +1100

> network provider.  So how do you authorize the addition of new zones?

RFC 3007.