[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: let's talk about RFC2136bis
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 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/>