Review of draft-ietf-idnabis-defs

[John C Klensin]

--On Monday, October 26, 2009 07:06 -0700 Bernard Aboba
<bernard_aboba at hotmail.com> wrote:

>...
> I do think that something needs to be said about this, since
> the issue has come up in implementation. For example, based on
> the distinction above, a client handling a dynamic update on
> its own using TKEY would implement the lookup protocol,
> whereas a DHCP server handling a dynamic update on behalf of
> the client might implement the registration protocol.

Bernard, please look at those two actual protocols and see if
you can convince yourself that the answer makes any practical
difference.  They have converged much more than they were early
on.  For all practical purposes, the difference now is that the
registration one does more checking than the lookup one on the
theory that some things don't belong in a zone but that, if the
prohibitions are violated, not much harm will be done if someone
attempts to look them up.

In both of the cases you cite, the zone administrator is giving
the client permission to insert a record or update an existing
one.  If it is an existing one, then presumably the registration
checks have been applied already -- the worst case is that they
are applied again.  If it is an insertion situation, then it
would be better to have the registration checks applied but
whether that is required or not is, in practice, more a matter
of zone policy than whatever the specification has to say.

I've gone back and looked at the text in
draft-ietf-idnabis-protocol about this and it seems pretty clear
to me: 

	(1) If a label (node) is being inserted into a zone,
	then the registration rules apply, whether that label is
	inserted into a zone file that is then installed in toto
	or whether it is going in via dynamic update.
	
	(2) Anything else that actually touches the DNS is a
	lookup situation.

Remember, too, that IDNA basically deals with labels.  Any
special properties of TYPEs or RRSETs are DNS issues with labels
that are funny-looking but conformant to the "recommended
syntax", and out of IDNA's scope.

Oddly, that turns the question around.  If dynamic update models
"update this only if the RRSET and/or Name are present" as
atomically "update only if presence is verified" (and I think I
read it that way), then the registration protocol is appropriate
_except_ that, if the node got there in an appropriate way, the
label has already been put through the registration checks so
that performing the extra registration checks is completely
harmless but also fairly useless.   If the model is "find out if
the node is present and, if so, update it" then lookup is
appropriate for the "finding out" part and anything after deals
only with the DATA of existing records and is not an IDNA issue.


And, if a new node is being put into the zone, then the
registration protocol is unambiguously required.

If you can suggest text that will make this more clear and a
place to put it (almost certainly in Protocol -- it doesn't
belong in Defs), I'm confident that the WG will be receptive.
But, since the Last Call process resulted in removal of a
discussion of DNSSEC and its interactions with IDNA, I'm not
convinced that adding  special comments about another piece of
unrelated DNS protocol is consistent and wise.

    john