[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
let's talk about RFC2136bis
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 namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>