Subject: Re: concerning draft-josefsson-dns-url-08.txt

From: Paul Vixie <[email-masked]>
Date: Fri, 04 Jul 2003 03:56:19 +0000

sorry to lose momentum on this thread, i got busy with something else briefly:

> > a dns resource lives where its parent NS RRs say it lives -- and not, as
> > you also suggest...
> >
> >> The hostport describes the authority that know the intended DNS
> >> resource.  An authority is useful even for abstract, non-DNS-protocol,
> >> DNS resources.  DNS resources themselves are indexed by (NAME, CLASS,
> >> TYPE), but to distinguish between the answer that entity A
> >> knows/generate, and the answer that entity B knows/generate, an
> >> authority scope like "hostport" is needed.
> >
> > ...in the answers that different entities can generate.
> 
> This view limit the usefulness of the URI, as it cannot be used to
> refer to, e.g., not-yet delegated data.  It can be useful to use DNS
> URIs to denote DNS data in a delegation request, to indicate where the
> new data will be placed, so it can be checked for conformance with
> various rules.

i guess we're in different weeds now.  because of the high abstractness
of your "hostport" definition, there's no guaranty that the dns protocol
will even be used by the uri-handler to resolve the pseudoquery.  so, the
idea of "not-yet-delegated" has no foundation at all.

here's the real issue: there are many companies and political movements who
think that iana's namespace is not the only namespace.  new.net, for
example.  iab takes a very strong "single unique namespace" view, and as
such, the i* organizations (iesg in this case) will probably (and ought to,
in my view) take a very dim view of any attempt to standardize a uri that
permits a "multiple namespace" fiction to be operable.

to me the layering violation of your "hostpart" suggestion is jarring, and
obvious, and is approximately equal to extending "hostpart" in normal http:
(and telnet: and mail: and so on) uri's to allow one to specify not only a
hostname, but also the address of the dns server which ought to be asked
to resolve the A or AAAA query.  "http://new.net:foo.sex/bar/", anyone?  if
you answered "no" then you gotta ask yourself why allow a "hostport" in a
dns: uri if you dislike its tangible equivilent in other parts of the spec.

> > you can't have it both ways.  either you're trying to represent dns data
> > using the <qname,qtype,qclass> tuple, or you're trying to represent
> > the query itself.
> 
> I'm trying, like the document says, to represent dns data using the
> <qname,qtype,qclass> tuple together with the authority/server.  The
> authority was added to be able to denote data that, for some reason,
> is not linked into the global DNS.  The reason could be multiple
> roots, split-view DNS, disconnected operation, efficiency or whatnot.

ah, meat.  for multiple roots, the iab has (thankfully) recognized that
the dns just doesn't work that way.  for split-dns and disconnected
operation, the place to put that kind of policy is in the resolver, not
in every application who calls it.  see
	http://sa.vix.com/~vixie/proxynet.pdf
for an example of how to do this (it's from 1995 but the code still
compiles if anybody still wants it.)  the tradeoff between efficiency
and correctness weighs VERY heavily on the side of correctness, such that
the likelihood of getting the wrong data or no data by using "hostport"
for efficiency is MUCH HIGHER than the likelihood of a performance problem
from not using it.  (for user populations of a global size, as ours is.)

> I could remove the hostport element if the consensus is that doing so
> would improve the usefulness of the URI.  Anyone else with an opinion?
> Remove hostport or keep it?

for my part, i'd like to hear the iab's input, since this goes to the
architecture of the overall internet system.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 04 Jul 2003 07:11:53 +0200

> permits a "multiple namespace" fiction to be operable.

I don't see how this relate to being able to specify the DNS server to
query in a URI to denote DNS data.

Can you describe how the DNS URI with a "hostport" make multiple
namespaces operable?

Having multiple namespaces is not [inter]operable by definition, IMHO.

The DNS URI is not an attempt in this direction.

> dns: uri if you dislike its tangible equivilent in other parts of the spec.

I see no problem here.  A HTTP URI should not contain the DNS server
address to use, since the HTTP specification describe how the server
is found.  Same goes for mailto; RFC 821 and 2821 describe how the
SMTP server for a mail address is found.  Adding the DNS server to use
would expose details that should be hidden in the application.

The situation is different for a DNS URI, since RFC 1024/1025 describe
how you query a specific DNS server (IP) via the DNS protocol.

I claim it can be useful to specify this information, but acknowledge
that removing the hostport would remove this potential confusion.

> the dns just doesn't work that way.

The global DNS namespace and the DNS protocol are not the same thing.

I believe the IAB has only recognized that the former, the namespace,
doesn't work with multiple roots, in RFC 2826.  And like I say above,
I don't see how the DNS URI further the multiple namespace root cause.

That the DNS protocol can handle multiple roots is a technical
property that can be used for good purposes, in which "hostport" can
be useful.  (Of course, it is not only useful for multiple roots.)  Do
you have a reference to where the IAB recognize that the DNS protocol
technically doesn't work with multiple roots?

> for split-dns and disconnected operation, the place to put that kind
> of policy is in the resolver, not in every application who calls it.

DNS URIs can be used to put this kind of policy in the resolver.
Applications are not generally expected to support DNS URIs.

> the tradeoff between efficiency and correctness weighs
> VERY heavily on the side of correctness, such that the likelihood of
> getting the wrong data or no data by using "hostport" for efficiency
> is MUCH HIGHER than the likelihood of a performance problem from not
> using it.  (for user populations of a global size, as ours is.)

Some people still do experiment to improve the efficiency in the DNS.
The DNS URI is not intended to be used widely (see the specification,
and "Intended Usage"), nor will the "hostport" field always be
present; that's why it is optional.  People would avoid using the
"hostport" field if it decreased correctness for them.

> architecture of the overall internet system.

There hasn't been much input on the DNS URI, so I do appreciate when
anyone looks at it.

I guess we simply have different opinions, so I'm not sure splitting
more hairs over various definitions will be productive, although
hopefully this discussion can be informative for others, when they
form their own opinion.

Thanks,
Simon

---

From: Paul Vixie <[email-masked]>
Date: Sat, 05 Jul 2003 21:05:33 +0000

> Can you describe how the DNS URI with a "hostport" make multiple

i did.  any time you add to the tuple needed to identify an rrset, you're
extending the protocol.  <qname,qtype,qclass> is a full specification, and
<qname,qtype,qclass,datasource> is a different, and overfull, specification.

> Having multiple namespaces is not [inter]operable by definition, IMHO.

yes, i know that.  although i saw a header go by indicating that simon higgs
has commented on this thread, so by now you probably have evidence that that
view is not universal outside of the iab (and of course you and i.)

> The DNS URI is not an attempt in this direction.

i knew that.  but it will be abused to support the meaningless fiction of
multiple namespaces, and in fact i cannot think of any other likely use for
it -- the diagnostic capabilities you aluded to earlier in this thread are
not going to be accessed through a uri interface, except that if they are,
you will also need to be able to specify RD, buffer size, and so on.

> that removing the hostport would remove this potential confusion.

while i think we mean "to whom" differently in "useful" above, i think we've
found the beginnings of a basis for agreement.

> The global DNS namespace and the DNS protocol are not the same thing.

and yet you said earlier that the back end protocol used by an invoker of
a dns: uri might not even be dns.  if hostport is present and denotes port
22, will the telnet protocol be used to satisfy the metaquery?  i really
do think that the dns namespace and the dns protocol cannot be usefully
disconnected from each other.

> doesn't work with multiple roots, in RFC 2826.

what rfc 2826 says is that there can only be one root per namespace and
that the public namespace can therefore have only one root.  both of which
are true of course.

without quoting half of rfc's 1034, 1035, 2136, and 2181, let me ask what
a standards-limited caching resolver with no nonstandard extensions added
to support multiple namespaces will do when presented with the following
events:

Receive: query for www.foo.com IN A
Forward: query for www.foo.com (to known nameservers of foo.com)
Receive: response to forwarded query,
		including "foo.com IN NS www.bar.sex"
		      and "www.bar.sex IN A ..."
Forward: response to forwarded query (to client who initiated query)
Cache: www.foo.com IN A ...
       www.bar.sex IN A ...
       foo.com IN NS ...
Receive: query for www.bar.sex (will the answer be NXDOMAIN i wonder?)
Receive: query for mail.foo.com (will the query be forwarded to a .sex server?)

the two questions i add parenthetically at the end have no direct answer
in the dns standards documents.  i believe they can be answered by principle
since we know we're dealing with a distributed coherent reliable autonomous
database, but not everyone finds "coherence" convenient and not everyone
answers these kinds of questions by reference to principle in any case.

you can only find the answers directly from the existing literature if you
assume the existence of only one namespace and only one root.  if you want
to be able to operate in a multiple-namespace world, then you must implement
beyond the standards (which proxynet does) or try to extend the standards
(which has not been attempted unless you count rfc1597 and there only dimly.)

>                                                 And like I say above,

without the hostport, it can't.  let's please just take it out and move on.

> be useful.

but it can't.  if you want to support multiple namespaces, you have a
huge amount of work to do which is outside of, and not specified by, the
dns protocol.  see proxynet, which i gave a url for earlier, to see an
example of the kind of work that has to be done.

> present; that's why it is optional.

if you make implementation of it optional, so that a url specifying it might
have undefined results depending on the whim of the implementor, that'd be
fine.  allow experiments, by all means.

>                                         People would avoid using the

by that statement you tell me that you work with different people than i do.