Re: RFC2136 and IP address ownership

[Paul Vixie <paul@vix.com>]

i have long thought that RFC 2136 ought to have recommended that implementors
support a "self" ACL, such that for some zones (likely, those full of PTR's)
could be set up so that the ability to do a three-way TCP handshake using a
given IP (or IP6) address would grant create/delete access to some set of RR
types (PTR, NAPTR, TXT, etc) at the names corresponding to the inverse address
node (so, for 192.5.5.241, that's 241.5.5.192.in-addr.arpa).

RFC 2317 complicates this goal considerably.  without a solution that allows
for pattern matching with arbitrary intermediary zone names, a "self" ACL is
not useful.  if your parent zone delegates using a $GENERATE CNAME, then you
have to have a way to express to your "self" ACL logic which octets/nibbles
of the address are to be built up out of labels that might include _ or - or
/ or \. (literal period) or any of the other things RFC 2317 users might use.

if someone wants to take this on, i'd be grateful and i suspect that the MIP6
WG and other WG's would also be grateful.  microsoft offered GSS-TSIG as their
solution to "too many nodes with update permission to be able to distribute
TSIG keys to all of them", but GSS-TSIG is a big mouthful of code and RTT for
something as trivial and frequent as a mobile-IP device, which could be "thin",
crossing a cell boundary.

i apologize for not encoding what i knew about this problem space as a "NOTE"
or "CAVEAT" in RFC 2136.

on the plus side, a new specification on this topic would not invalidate any
part of RFC 2136.  something is currently missing, but nothing is currently
wrong.

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