Subject: let's talk about RFC2136bis

From: Paul Vixie <[email-masked]>
Date: Sat, 08 Mar 2003 05:42:48 +0000

the process used by dnssec-editors@ has appeared to be somewhat successful,
so let's see if we can get some agreement on various upgrade issues between
RFC2136 and its inevitable "bis" version.  olafur, if we could have a few
minutes to discuss this in san francisco, it might help to get a new document
out immediately thereafter.

--------

#1 -- scope of changes

i'm hoping that we can do minimal changes, basically just editorial (for
clarity) or because of some kind of error or inconsistency.  there's no
reason to revisit it at a deeper level nor to reconsider the basic approach.
(however, it's stuck at proposed standard until we get some things fixed.)

--------

#2 -- rr comparison

   1.1.1. Two RRs are considered equal if their NAME, CLASS, TYPE, RDLENGTH
   and RDATA fields are equal.  Note that the time-to-live (TTL) field is
   explicitly excluded from the comparison.

does this need to mention the whole uppercase/lowercase issue?  noting that
the RRs are compared in their virtual state not their wire state, there's
no compression issue as with dnssec.  but do we need a sentence to the effect
that "if the rdata contains domain names, then domain name comparison rules
are in effect, for example the MXs of (10 internet.net) and (10 INTERNET.NET)
are to be considered equivilent" ?

--------

#3 -- rr type restrictions

   1.1.5. The following RR types cannot be appended to an RRset.  If the
   following comparison rules are met, then an attempt to add the new RR
   will result in the replacement of the previous RR:

      SOA    compare only NAME, CLASS and TYPE -- it is not possible to
             have more than one SOA per zone, even if any of the data
             fields differ.

      WKS    compare only NAME, CLASS, TYPE, ADDRESS, and PROTOCOL -- only
             one WKS RR is possible for this tuple, even if the services
             masks differ.

      CNAME  compare only NAME, CLASS, and TYPE -- it is not possible to
             have more than one CNAME RR, even if their data fields differ.

do we need to disallow updates of the dnssec types, or cause logical OR'ing
if an NXT is appended, or anything like that?

--------

#4 -- clarification of domain owner naming

   1.2 - Glue RRs

   For the purpose of determining whether a domain name used in the UPDATE
   protocol is contained within a specified zone, a domain name is ``in'' a
   zone if it is owned by that zone's domain name.  See section 7.18 for
   details.

a number of people have said that "owned by" is hard to read.  therefore
perhaps we should expand it to say "at or below the zone apex".  the reason
this is here is that it's possible to add data to a zone which is below a
zone "bottom cut" (see section 7.18, i guess) even though that data will
not be visible to opcode QUERY.  i think "owned by" is the right term but
i am willing to expand it if others think differently.

--------

#5 -- edns size issues

   2.1 - Transport Issues

   An update transaction may be carried in a UDP datagram, if the request
   fits, or in a TCP connection (at the discretion of the requestor).  When
   TCP is used, the message is in the format described in [RFC1035 4.2.2].

it rather seems to me that in an edns world, there's no easy way for an
initiator to learn the buffer size of a responder other than by sending a
QUERY first.  (this wasn't an oversight in edns -- we knew what we were
leaving out but believed, correctly i still feel, that time to market was
more important than an expansive feature set.)  should 2136bis mention
that an edns QUERY could be sent first, to discover the responder's buffer
size, and that a subsequent edns UPDATE can take advantage of that buffer
size?

--------

#6 -- edns request-id field

   2.2 - Message Header
    ...
      ID      A 16-bit identifier assigned by the entity that generates any
              kind of request.  This identifier is copied in the
              corresponding reply and can be used by the requestor to match
              replies to outstanding requests, or by the server to detect
              duplicated requests from some requestor.

allow me to curse myself for not suggesting an edns OPTion for extended
request-id.  i daresay that a 128-bit cryptorandom cookie would be pretty
hard to guess.  this point has nothing to do with 2136bis, i just hope
somebody sees this and writes up an edns OPTion for extended request-id.

--------

#7 -- order of permission checking

   3.3 - Check Requestor's Permissions
   ...
   3.3.2. While the exact processing is implementation defined, if these
   verification activities are to be performed, this is the point in the
   server's processing where such performance should take place, since if a
   REFUSED condition is encountered after an update has been partially
   applied, it will be necessary to undo the partial update and restore the
   zone to its original state before answering the requestor.

this is in the wrong place.  the question is, should it come before 3.2
(before checking prerequisites) or before 3.1 (before checking the zone
section)?  i think i'm ready to argue for "before 3.1" since this is an
instance of local policy and it can examine any other part of the request
that it wants to in order to make its decision.  it should also be run as
early as possible in order to catch a DDoS before having done any work on
behalf of the attacker.

--------

#8 -- clarifying server selection

   4.3. If the requestor has reasonable cause to believe that all of a
   zone's servers will be equally reachable, then it should arrange to try
   the primary master server (as given by the SOA MNAME field if matched by
   some NS NSDNAME) first to avoid unnecessary forwarding inside the slave
   servers.  (Note that the primary master will in some cases not be
   reachable by all requestors, due to firewalls or network partitioning.)

some microsoft-generated updates were/are sent to the SOA MNAME regardless
of whether it is also listed in an NS NSDNAME.  (see www.as112.net for fun.)
additionally, there's someone out there who searches "up the tree" looking
for a receptive zone server if they get back a timeout or error from a more
appropriate (closer enclosing) zone's server.  do we need to clarify the
text to say that once a zone apex has been found, all updates must be done
within that zone, and that searching upward looking for "more receptive"
zone servers for parent or grandparent zones will probably lead to hostility
("and a sense of futility" --t.l.)?

--------

#9 -- forwarding, threat or menace?

   3.1.1. ...  If the server is a zone slave, the request will be
   forwarded toward the primary master.
   ...
   5.2. Multiple UPDATE requests or responses in transit might be
   delivered in any order, due ... to multipath forwarding graphs
   wherein several slave servers all forward to the primary master.
   ...
   6 - Forwarding

   When a zone slave forwards an UPDATE message upward toward the zone's
   primary master server, it must allocate a new ID and prepare to enter
   the role of ``forwarding server,'' which is a requestor with respect to
   the forward server.

update forwarding has been singled out for much ridicule amongst those who
have implemented 2136.  there were valid operational reasons for it...

   6.1. The set of forward servers will be same as the set of servers this
   zone slave would use as the source of AXFR or IXFR data.  So, while the
   original requestor might have used the zone's NS RRset to locate its
   update server, a forwarder always forwards toward its designated zone
   master servers.

...but tcp forwarding, in particular, creates a synchronous "hold state"
condition for the forwarders, and is thus ripe for all manner of DDoS...

   6.2. If the original requestor used TCP, then the TCP connection from
   the requestor is still open and the forwarder must use TCP to forward
   the message.  If the original requestor used UDP, the forwarder may use
   either UDP or TCP to forward the message, at the whim of the
   implementor.

i won't go into it further or make any specific proposals since i'm hoping
that nominum and ultradns will both comment extensively on updates.  it's
possible that the right answer is "remove forwarding from the design" and
just demand that updates be receivable by the server named in the SOA RR.

--------

#10 -- security improvements

   8 - Security Considerations

   8.1. In the absence of [SECUPD] or equivilent technology, the
   protocol described by this document makes it possible for anyone who
   can reach an authoritative name server to alter the contents of any
   zones on that server.  This is a serious increase in vulnerability
   from the current technology.  Therefore it is very strongly
   recommended that the protocols described in this document not be used
   without [SECUPD] or other equivalently strong security measures,
   e.g. IPsec.

i think that we should require TSIG or SIG(0), and disallow ip source
address verification unless TCP is used.

i also think that we should recommend that if TCP is used, an implicit
ip source address access control rule should allow "that host" (the
initiator) to update its own PTR RR (either in in-addr.arpa or ip6.arpa.)

--------

#11 -- misc issues from an unnamed party

> explicity specify the atomicity rule (whole update is atomic)

how much more explicit can we be than:

   3.7 - Atomicity

   During the processing of an UPDATE transaction, the server must ensure
   atomicity with respect to other (concurrent) UPDATE or QUERY
   transactions.  No two transactions can be processed concurrently if
   either depends on the final results of the other; in particular, a QUERY
   should not be able to retrieve RRsets which have been partially modified
   by a concurrent UPDATE, and an UPDATE should not be able to start from
   prerequisites that might not still hold at the completion of some other
   concurrent UPDATE.  Finally, if two UPDATE transactions would modify the
   same names, RRs or RRsets, then such UPDATE transactions must be
   serialized.
	
> clarify if precondtion can appear anywhere in update message or not

no, it pretty much has to be in the third section, as defined in section 2:

   The overall format of an UPDATE message is, following [ibid]:

      +---------------------+
      |        Header       |
      +---------------------+
      |         Zone        | specifies the zone to be updated
      +---------------------+
      |     Prerequisite    | RRs or RRsets which must (not) preexist
      +---------------------+
      |        Update       | RRs or RRsets to be added or deleted
      +---------------------+
      |   Additional Data   | additional data
      +---------------------+

> clarify rules on singleton, delete MUST occur before add

this one bears heavily upon the next:

> clarify the NS rules, zone may be temporarily invalid but must
> be valid at end of update eg
> 	DEL NS * 
> 	ADD ns 1 
> 	ADD ns 2 
> is a valid sequence. 

the intent when 2136 was written was that the zone state had to be correct
at the end of the atomicity period, but could be wildly wrong (SOA missing,
last NS RR deleted, etc) inside the atomicity period.  the order of update
operations was as specified in the update message and created virtual (but
unchecked) state: if you put the delete first, it deletes first, if you put
it last, it deletes last.

before we think about where in the document this should be described, let's
hear from some implementors and users as to what they actually do and what
they actually expect and/or require.

--------

#12 -- issues from another unnamed party

> I stumbled across this doing some background work.  Apparently 2136 is
> sitting at PS.  I had a comment about it in Sept of last year, and a little
> while ago I came across a wording change I'd recommend:
> 
> #    RCODE   Response code - this four bit field is undefined in requests
> ...
> #               Mneumonic   Value   Description
> 
> Mnemonic is misspelled

so noted.

> ...
> #               NXDOMAIN    3       Some name that ought to exist,
> #                                   does not exist.
> 
> I'd change this to "The QNAME sought does not exist"

that doesn't work in the context of an UPDATE operation, where there is no
QNAME, and in fact any "name must exist" or "rrset must exist" or even "rr
must exist" in the prerequisites section can cause an rcode of NXDOMAIN to
be sent back to an UPDATE requestor.

it's apparently going to be necessary for the rcodes to be unique to each
opcode.  at least the definition of each rcode has to vary per opcode, and
maybe we ought to consider reusing the rcode numbers themselves per opcode.

> I'm wondering if the definition of mnemonics are meant to add to the
> standard specifications.  In RFC 1034, the error is an "authoritative
> name error," and the name NXDOMAIN is from one implementation
> (BIND). [This was brought to my attention by Paul, so this is not
> news.]  The issue is whether a DS version of dynamic update should be
> written more cleanly wrt to bias towards an implementation.

see above.

--------

th-th-that's all folks.  what else has anybody got against 2136 that they'd
like to see fixed in 2136bis?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Vixie <[email-masked]>
Date: Mon, 10 Mar 2003 21:43:08 +0000

> >...  what else has anybody got against 2136 that they'd like to see
> >fixed in 2136bis?

> Remove the more-or-less arbitrary restriction on dynamic addition or
> deletion of SOA RRs. The "security improvements" changes you've proposed
> above would seem to moot the security-based objections to this, and the
> only other objections of which I'm aware -- concerns (one might say FUD)
> over how dynamic zone-creation/removal would work in practice -- confuse
> (IMO) implementation issues with protocol ones.

the restriction isn't arbitrary.  at the moment, data needed for a zone
to exist has to be transmitted out of band, since there is no defined
format in any standard protocol for carrying things like zone data source
(file name, sql table name, etc) or if it's a slave server, the list of
axfr targets, or etc.  then there's the problem of the zone section -- an
soa by definition does not go into an existing zone, so the zone section
would have to specify the new zone, which would not exist at the time of
[rfc2136 3.1].

adding soa creation/deletion in 2136bis would not be a case of removing
a restriction (arbitrary or not), it would be a fundamental change to the
data model.  i don't think we should attempt this in a "bis" document since
we're really just trying to fix the things that implementors have found
unclear or misleading or inconsistent or just plain wrong.

i think a zone management protocol is badly needed, but 2136 (or 2136bis)
is not it.

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 10 Mar 2003 17:40:06 -0500

Paul Vixie wrote:

>(file name, sql table name, etc) 
>
Which is an implementation detail, IMO.

>or if it's a slave server, the list of
>axfr targets, or etc.  
>
I'm only considering master servers.

>then there's the problem of the zone section -- an
Agreed. The algorithm would need to be tweaked slightly. Addition of an 
SOA RR would need to be a special case that bypasses (or inverts?) the 
usual "does this zone already exist?" checks. This doesn't seem major to me.

>unclear or misleading or inconsistent or just plain wrong.
I disagree with "fundamental". Nothing really changes as far as the wire 
format is concerned, nor the initial parsing of the request packet, nor 
the response from the server. As mentioned above, a small tweak would 
need to be made to the processing algorithm, and only in the case of an 
SOA add (deletes would still need to check for the existence of the 
zone, as per normal). Perhaps you forgot to mention it, but there would 
also have to be some explicit language to the effect that the NS records 
for the child zone would need to be added in the same update request as 
the SOA "add" (since an SOA without NS records does not make for a legal 
zone).

>i think a zone management protocol is badly needed, but 2136 (or 2136bis)
And I'm not proposing a whole zone management protocol, only the lifting 
of one restriction in Dynamic Update that could be *part* of a zone 
management subsystem. This is not an all-or-nothing scenario. I see 
nothing wrong with part of the zone management subsystem using Dynamic 
Update, and the rest being done out-of-band. It doesn't have to all be 
done with a single protocol.

Perhaps I should mention that my homegrown DNS maintenance system is 
based almost *entirely* on Dynamic Update. About the only part that 
isn't possible to do via Dynamic Update is zone creation and deletion. 
So, while it may seem "natural" to you that SOA addition and deletion 
should remain a special case for Dynamic Update, for me (and potentially 
others evolving in parallel or following my example) Dynamic Update is 
the "rule", and the prohibition against SOA adds or deletes is the 
"exception". And one which appears to have no solid justification, once 
the security issue is resolved.

                                        - Kevin

---

From: <[email-masked]>
Date: Mon, 10 Mar 2003 22:40:36 -0500

---- Original message ----
>Date: Mon, 10 Mar 2003 21:43:08 +0000
>From: Paul Vixie <[email-masked]>  
>Subject: Re: let's talk about RFC2136bis   
>To: [email-masked]
>

If I could comment,

If "zone management" is restricted to the implementation independent tasks of adding or 
dropping of zones, then could we develop a draft that goes something like:

For an add:
Master loads zone and sends a "zone add" directive to the slaves.
Slaves receive the "zone add" and add the zone via a zone tranfer (provided the human 
has decided to trust the master)

For a drop:
Master drops a zone and sends a "zone drop" directive to the slaves.
Slaves receive the "zone drop" and drop the zone.

I realize that there are many other tasks associated with zone management depending on 
the implementatin. The protocol could set part of the packet(s) aside for implementation 
specific data that can be safely ignored by servers that may not understand things like 
views or acl's, for example.

I know this is way over simplified, but, would that be the bulk of it?

Dave...