Re: XPTR Drafts

[Florian Weimer <fw@deneb.enyo.de>]

* Phillip Hallam-Baker:

>    Record BasicPrefixResolve (
>                      String node, String prefix, RecordType  record)
>       1.   Record F1 =  Lookup (prefix + "." + node, record)

Nit: You don't want string concatenation, but domain name
concatenation.

>          If  (F1 <> NIL) Return F1

You should explicitly address error code and no data behavior, instead
of just looking at the data section.  The resolution algorithm should
only proceed if there is an RCODE=0, no data response.  You should
also reference the wildcard-clarify RFC (sorry, forgot its number),
which is said to specify that the query does not return NXDOMAIN when
there is the XPTR record there which is queried below.

>       2.   Record F2 = Lookup (node, PREPTR)
>          If (F2 = NIL) Return NIL

The error code should be passed on to the application.

>       3.   Record F3 = Lookup (prefix + "." + F2.domain)
>          Return F3


>    In such situations the service discovery process MAY specify the use
>    of the Reverse DNS.  The reverse DNS is an area of the DNS space (in-
>    addr.arpa, ipv6.arpa).  A PTR record in the reverse DNS maps an IPv4

I think it's ip6.arpa.  And your proposal might also apply to
e164.arpa in some way, so this whole section should probably be
generalized.

>    Depending on the requirements of the service it MAY be desirable for
>    discovery to process XPTR records in the reverse DNS directly or to
>    first attempt to follow a PTR record to obtain a DNS node where basic
>    prefix resolution is to be performed.

Hmm, hmm.  Is this really necessary?  It's less clear to me what
should happen if the reversed DNS name already has got a NAPTR or SRV
entry.


The document should specifiy that the LHS of XPTR MUST NOT be subject
to label compression.  Name servers SHOULD NOT perform additional
section processing, and resolvers and applications MUST NOT rely on
it.


Apart from that, I like your approach better than the dynamic record
type extension I described some time ago.  It seems to address a
similar set of issues, and the XPTR records are much easier to write
down and maintain manually.

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