Re: NAPTR RR

[Robert Elz <kre@MUNNARI.OZ.AU>]

    Date:        Mon, 21 Dec 1998 12:46:06 -0500 (EST)
    From:        Leslie Daigle <leslie@Bunyip.Com>
    Message-ID:  <Pine.SUN.3.95.981221124446.7227M-100000@buzz.Bunyip.Com>

  | Could you/DNSIND have a look at 
  |	draft-ietf-urn-naptr-rr-00.txt                

Randy forwarded your message to the DNSIND list (namedroppers@internic.net).

I would encourage other DNSIND WG members to read the draft, and comment.

  | It does have a dependency on the SRV RR work, so apart from a desire
  | to be sure that the above document is robust, the URN work is now keenly
  | interested to know if/when SRV will be put forward as a standards-track RFC.

An update on RFC2052, aimed at PS status, should be in IETF last call soon
now we hope.   We're waiting on some fairly minor updates from its editors.

  | Anyway, comments on the above document/plans for SRV would be appreciated.

The doc has a number of problems.   Some are trivial - there are some
purely editorial things which I won't bother with in a -00 draft (better
to get the substance right, and then clean up the references, grammar, etc).

You need some work on the ABNF as well, "//" is not a comment lead in (';' is),
and
			/ ... /
is not legal ABNF anything, though it may be intuitively obvious.   Fortunately
by using the symbols defined in appendix A of the ABNF doc, I think almost all
your demands for that will simply vanish.   The service_field value is overly
optional, which, while not technically illegal, can complicate parsers.
Just remove the outer [ ], nothing changes, but it is simpler.  repl is
better expressed as "repl = 1*(  dns_str / backref )".   Lastly on
ABNF '<' '>' is the syntax for non ABNF information to be embedded in a rule,
not '(' ')'.

On DNS issues. most importantly ...

   Replacement
          The next NAME to query for NAPTR, SRV, or A records depending
          on the value of the flags field. This MUST be DNS compressed.

MUST is wrong there, it MUST be MUST NOT.    You could allow local compression,
but then you'll be waiting on another DNSIND doc getting to PS status.  Or
you could just say nothing about name compression at all, and rely upon the
standard DNS rules (which will forbid compression until at least EDNS1 is
done, at which time, maybe, your RR might be included in the list of types
for which compression is allowed for conforming implementations, and which will
allow local compression after local compression has been published, and
implemented).    You really ought to say that this is a fully qualified domain
name.

Then, your description of the RR format seems to be confusing what is needed
to describe the master file format, and what is needed to describe the
packet format.   Both are required.   However, you only need to define the
RDATA format - the rest of the RR is standard, and unless you were going to
be using fields in unusual ways, there's no need to mention those at all
(that is, the class, ttl, type, etc).

For the RDATA though, you need to describe how to write it in the master
file, and how to encode it in the DNS packet.   Those two are obviously
related, but not at all the same.    Eg: for the order and preference
fields, the master file format requires (I assume) an integer between 0
and 65535, whereas the packet format is a 16 bit unsigned integer in
network byte order.

Since you get to define both the master file format, and the packet
encoding, I think you're insane to define the regular expression field the
way that you do.   Aside from the fact that you seem to be of the belief that
there is some magic DNS type known as STRING (which there isn't) that you
can simply refer to.   There is (in 1035) a "character-string" which is
fine for an encoding format for the RE, but as your draft makes quite
clear, leads to a master file format which is obnoxious at least.   I would
simply define a format that suits you better for the master file, and have
it encoded in the packet in just the same way a character-string would be.

For the master file, since you have a fairly well defined, and delimited,
format already, all you need do is prohibit the use of white space as flags
and as the delim-char, and you can simply use your subst_expr as the master
file format for the regular expression, without any further encoding at all.
This will eliminate all the problems you have attempting to explain how to
use \ in that field (especially as you show examples supposedly in master file
format, but without the \ -> \\ mapping which you later attempt to explain
is needed).    What's more, this all leads to exactly the same bit
pattern in the DNS packet, for the same regular expression, so it isn't
even incompatible with anyone who has implemented rfc2168.


Next, I think your examples (and those in 2168) which show names built for
SRV record lookups are over done.   The SRV spec already specifies how to
add in the app protocol and transport protocol values, you don't need them
in NAPTR records (you have the app protocol in the service field already,
for the few cases where that app protocol makes sense over multiple transport
protocols, it is probably best to allow the client to choose - that, or to
attempt SRV lookups with all possible transport protocols and see what the
server supports).   In any case, the current SRV draft:
	draft-ietf-dnsind-rfc2052bis-01.txt
specifies underscores to be prepended to the protocol names when used in
SRV records, to lower the chances of name clashes with other users of the
DNS.   So if these fields are to remain, the (current) correct way to
specify what you have as...

  IN NAPTR 100  50  "s"  "z3950+N2L+N2C"     ""    z3950.tcp.gatech.edu

would be

  IN NAPTR 100  50  "s"  "z3950+N2L+N2C"     ""    _z3950._tcp.gatech.edu

and similarly

   z3950.tcp.gatech.edu   IN SRV 0    0      1000 z3950.gatech.edu

would be

   _z3950._tcp.gatech.edu IN SRV 0    0      1000 z3950.gatech.edu

(you should also note that for valid master file format, all those
domain names need trailing dots, or they'll get the default origin
appended).

You have an 'i' flag that requires case insensitive matching - you need to
define exactly what that means, especially in the presence of non ascii
characters.   You also seem to require that %3f type sequences be encoded
that way - but it isn't at all clear whether the matching algorithm is
supposed to treat such sequences as a single character (does "." match it?)
or as 3 characters.

It is implied several times, and perhaps I just didn't read carefully enough,
but I could not find stated anywhere, that only one of the replacement or
regexp field is allowed to be present.   Yet, the fields are not actually
optional in the RDATA, both are required.   It is implied, I believe, that
a reference to the root domain specifies an empty replacement field.  Most
likely a zero length regexp specifies a missing regexp field (this one would
be the one difficulty with not adding any extra syntax to encode the regexp,
but ways around that could be found).    This all needs to be clarified.
Further, you need to say how records with both fields missing, and records
with neither field missing, are to be interpreted.


You say ...

   Once a match is 
   found, the Services field is examined for whether or not this rule 
   advances toward the desired result.

I'm afraid I can't fathom what "advances toward the desired result" actually
means.    My guess you just mean whether a recognisable (useful for the
application) protocol is listed, but perhaps not.


I also suspect that you need to extend your examples to show something a
little more realistic - including regular expression matches that fail.

Eg: the urn:cid:... example that you give works fine if the urn that is
the original text is the one you use as the example.
	urn:cid:199606121851.1@mordred.gatech.edu

But consider what happens if instead it is ...
	urn:cid:199606121851.1@gatech.edu

Or if it is
	urn:cid:199606121851.1@host.dept.gatech.edu

and compare that with
	urn:cid:199606121851.1@host.unimelb.edu.au

and figure out some way to allow the next NAPTR lookup to be gatech.edu
in the first of those cases, and unimelb.edu.au in the second one.   All
this turns out to be quite messy I think - I'm not sure that the basic
method is really amenable to a solution at all.    (I know the examples are
just to show how the basic scheme works, but examples tend to be used as
models by domain admins who don't necessarily know all the possibilities,
and if they're unrealistic, bad things happen).

Another example shows SRV records being looked up for SMTP - I suspect that
will never happen in practice, and that no-one will ever enter _smtp._tcp....
records in zone files - MX is quite sufficient for SMTP, MX is what is
used, what is being specified (even now) in the drums WG for SMTP clients
to use, MX will remain the way SMTP clients locate the applicable server.
The text in the SRV doc that suggests it should be used for everything in the
known universe is being changed to suggest that it be used where an application
protocol demands its use, and only there.   I'd avoid any suggestion in the
examples that SMTP might ever use SRV lookups.

I suspect that here it isn't important, but you need to be aware that there
are no character set restrictions on DNS domain names.   That doesn't mean that
you can't limit the set of names that you want to deal with (most protocols
do in fact, SMTP is an obvious example).  Just be clear in the doc that it
if your protocol imposing the restrictions, not the DNS or anything else.
That is, don't imply that this is being forced upon you, or that you naturally
get the benefit (whichever it is) from some other source.  (RFC952, as modified
by 1123, applies to entries in the HOSTS.TXT file, which is no longer relevant
for anything anyone much cares about).

kre

ps: feel free to forward this message to whatever list is dealing with your
draft.