Subject: Re: let's talk about RFC2136bis

From: Edward Lewis <[email-masked]>
Date: Mon, 10 Mar 2003 09:21:44 -0800

At 5:42 +0000 3/8/03, Paul Vixie wrote:
>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.)
>

I agree with that.  Pragmatically, no one is screaming about the 
protocol.  I'll only answer to some issues.

>#3 -- rr type restrictions
>
>do we need to disallow updates of the dnssec types, or cause logical OR'ing
>if an NXT is appended, or anything like that?

I would recommend that the dynamic update server do no action 
whatsoever on an NXT in a request.  A dynamic update client must 
never include an NXT in any section of the request.

As far as KEY RR - the server MAY refuse to accept (act upon) a 
request to add/alter a key that does not meet the key-restrict RFC 
requirements.

As far as SIG SS - the server MAY refuse to accept (act upon) a 
request which contains a explicitly cryptographically invalid 
signature or a signature whose expiration is in the past (according 
to the master server's clock).  Note: nothing requires that the 
public key component of the key generating the SIG RR be available to 
the master server - that's why 'explicitly' is mentioned.

(Details, details...)

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

I think there's a terminology problem in the doc.  I'd try this:

     1.2 - Glue RRs

     For the purpose of determining whether an <owner> name used in the UPDATE
     <request> is contained within a specified zone, an <owner> name is ``in'' a
     zone if <the name is a subdomain of > the zone's domain name.  See section
     7.18 for details.

I put the significant changes in angle brackets.  The point is that 
only only the "owner names" in RR's within the dynamic update request 
are at issue.  The other point is that whether A is a subdomain of B 
is a question that ignores zone cuts.

>#6 -- edns request-id field
>allow me to curse myself

permission granted ;)

>#7 -- order of permission checking
>
>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.

I agree, if for that reason alone.

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

ack

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

Sounds reasonable.  Perhaps this should be tested at a conference though.

>#12 -- issues from another unnamed party
>
>>  ...
>>  #               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.

Okay, but then how about not using NXDOMAIN here.  The problem is 
that in RFC 1034 the authoritative name error has morphed in the 
documents to NXDOMAIN via  the use of NXDOMAIN in BIND code.  Here, 
though, is an RFC defining NXDOMAIN to mean something other than 
'authorative name error.'

I guess that's the rub here...probably needs more hashing out.

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

Yeah.  Two issues arose as a result of a tutorial given last September at RIPE.

In a nutshell:

1) When a zone is frozen (in one implementation: temporarily 
suspending dynamic updates), is it worthwhile sending out an error 
message that says: dynamic update is suspended?  This was discussed 
on namedroppers, I'll have to find the archives when I'm back on net.

2) The error returned when a bad TSIG key is used:

Below is a part of a message to bind-bugs on this.  I don't dispute 
Mark's answer, but it points to something that we might want to 
clarify: that the error is generated in TSIG processing and not the 
dynamic update processing.

>>  I just noticed this:
>>
>>  >Outgoing update query:
>>  >;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  32593
>>  >;; flags: ; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1
>>  >;; ZONE SECTION:
>>  >;dynamic.myzone.example.                IN      SOA
>>  >
>>  >;; UPDATE SECTION:
>>  >a.dynamic.myzone.example. 9000  IN      TXT     "ksjlksjdfjsdklf"
>>  >
>>  >;; TSIG PSEUDOSECTION:
>>  >four.                 0       ANY     TSIG    hmac-md5.sig-alg.reg.int. \
>>  >                10318 37255 300 16 R52twrMFLZfk+jYlYs6qBA== 32593 NOERROR
>>  0
>>  >
>>
>>  My print statement...
>>  >nsupdate : Result code is 65575
>>
>>  >; TSIG error with server: tsig indicates error
>>  >
>>  >Reply from update query:
>>  >;; ->>HEADER<<- opcode: UPDATE, status: NOTAUTH, id:  32593
>>  >;; flags: qr ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
>>  >;; TSIG PSEUDOSECTION:
>>  >four.                 0       ANY     TSIG    hmac-md5.sig-alg.reg.int. \
>>  >                                       10318 37255 300 0  32593 BADKEY 0
>>
>>  NOTAUTH should apply to the "a.dynamic.myzone.example." and not the
>>  tsig name. True, the TSIG name is bad (it was part of a test of bad
>>  updates), but that should mean the error code is REFUSED here.
>>
>
>         The answer looks correct according to RFC 2845.
>
>         Mark

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

--
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: Kevin Darcy <[email-masked]>
Date: Mon, 10 Mar 2003 13:12:43 -0500

Paul Vixie wrote:

>[snip]
>#2 -- rr comparison
>[snip]
>[snip]
>[snip]
>#5 -- edns size issues
>[snip]
>[snip]
>[snip]
>#8 -- clarifying server selection
>
>[snip]
>
>#9 -- forwarding, threat or menace?
>
>[snip]
>
>[snip]
>#11 -- misc issues from an unnamed party
>
>[snip]
>
[snip]

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

                            - Kevin

---

From: [email-masked] (Andreas Gustafsson)
Date: Mon, 10 Mar 2003 16:52:47 -0800 (PST)

Before I comment on the RFC2136 issues you mentioned, I'd like to add
two more...

#13 -- contradiction in section 3.4.2.2

   3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to
   the zone.  In case of duplicate RDATAs (which for SOA RRs is always
   the case, and for WKS RRs is the case if the ADDRESS and PROTOCOL
   fields both match), the Zone RR is replaced by Update RR.  If the
   TYPE is SOA and there is no Zone SOA RR, or the new SOA.SERIAL is
   lower (according to [RFC1982]) than or equal to the current Zone SOA
   RR's SOA.SERIAL, the Update RR is ignored.  In the case of a CNAME
   Update RR and a non-CNAME Zone RRset or vice versa, ignore the CNAME
   Update RR, otherwise replace the CNAME Zone RR with the CNAME Update
   RR.

The last sentence contains a contradiction.  If we have a non-CNAME
Update RR and a CNAME Zone RRset (that's the "vice versa" case), it
says we should "ignore the CNAME Update RR" even though the Update
RR is not a CNAME.

Also, strictly speaking the "otherwise" condition means "either both
the Update RR and Zone RRset are CNAMEs, or neither one is", but the
text following the "otherwise" only applies to the former case.

I propose replacing the last sentence with the following two sentences:

					       In the case of a CNAME
   Update RR and a non-CNAME Zone RRset or vice versa, ignore the 
   Update RR.  In the case of a CNAME Update RR and a CNAME Zone RR,
   replace the CNAME Zone RR with the CNAME Update RR.

#14 -- conflict between section 3.4.2.4 and pseudocode

The text of RFC2136 says:

   3.4.2.4. For any Update RR whose class is NONE, any Zone RR whose
   NAME, TYPE, RDATA and RDLENGTH are equal to the Update RR is deleted,
   unless the NAME is the same as ZNAME and either the TYPE is SOA or
   the TYPE is NS and the matching Zone RR is the only NS remaining in
   the RRset, in which case this Update RR is ignored.

The corresponding pseudocode in section 3.4.2.7 says:

	   elsif (rr.class == NONE)
		if (rr.type == SOA)
		     next [rr]
		if (rr.type == NS && zone_rrset<rr.name, NS> == rr)
		     next [rr]
		zone_rr<rr.name, rr.type, rr.data> = Nil

The text and the pseudocode are in conflict in the case where the last
NS RR of an NS RR set in a place other than the zone apex (i.e., in a
delegation) is being deleted.  The text allows this deletion, but the
pseudocode would cause it to be ignored.  Since the text takes precendence
over the pseudocode, the pseudocode should be changed to say

	   elsif (rr.class == NONE)
		if (rr.type == SOA)
		     next [rr]
		if (rr.type == NS && rr.name == zname &&
		    zone_rrset<rr.name, NS> == rr)
		     next [rr]
		zone_rr<rr.name, rr.type, rr.data> = Nil

-- 
Andreas Gustafsson, [email-masked]