Re: [Mip6] Re: RFC2136 and IP address ownership

[Paul Vixie <paul@vix.com>]

# > i think i got your meaning the second time here.  basically you're saying
# > that the "self" ACL, with whatever tricks needed to work with RFC 2317, is
# > still nec'y because otherwise we'll have to protect individual DNS names
# > with unique keys per host, which won't scale.
# 
# 	For RFC 2317 style zones I suspect they will need to know the prefix
# 	and range by some out of band mechanism and how the non prefix bits
# 	map into the owner-name.

i'd rather do it by looking at the dns data itself.  that is, following the
CNAME chain if any, starting from a qname computed based on the transport
and ip/ip6 address.  what "self" should mean is that if they want to update
what the cnames point to, that should be allowed.  unfortunately this would
require perfect trust in the ancestor zones, and would be totally irrational.

# 	Off the top of my head this would be how I would implement it for
# 	BIND.
# 
# 	e.g.
# 	allow-update {
# 	    self 1.2.3.128 1.2.3.200 "${4}.128-200.3.2.1.in-addr.arpa";
# 	};

gaaaaaaaaaak.

# 	And the general case for the non RFC 2317 style reverse zone.
# 
# 	allow-update {
# 	    self 0.0.0.0 255.255.255.255 "${4}.${3}.${2}.${1}.in-addr.arpa";
# 	};

well, first, i don't think permissions can be given out of band unless we
update RFC 2136 to outlaw update forwarding.  (which BIND doesn't support,
but i suspect other implementations do support, and some people depend on.)

this yields a general sense that a thing that looked like $GENERATE would
be the right thing.  except that it has to be an RR, probably an ACL RR at
the apex.  (ACL RRs have been proposed several times over the years, and an
early version of similar technology was in older versions of BIND.)

if i'm right that it should be in-band, then it *is* an interoperability
concern and it *must*be* done by IETF rather than by each implementor ad-hoc.

and second, BIND's ACL syntax should remain generalized.  "self" is something
that a zone (either in band or out of band) has to define, and which ACL's
can then depend on.  so "self" would be a zone-level directive (or in-band
zone data, if update forwarding has to be able to work), and then "self"
would be a macro that was available inside the allow-update directive.  but
this is namedroppers; i'd rather discuss on bind-workers or bind-forum the
specific BINDisms needed to make something like "self" work inside BIND.  on
namedroppers we should only discuss implementation-independent issues.

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