> 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?
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.
> I claim it can be useful to specify this information, but acknowledge
> 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.
> > ah, meat. for multiple roots, the iab has (thankfully) recognized that
> > the dns just doesn't work that way.
>
> 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.
> I believe the IAB has only recognized that the former, the namespace,
> 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,
> I don't see how the DNS URI further the multiple namespace root cause.
without the hostport, it can't. let's please just take it out and move on.
> 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.
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.
> 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.
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
> "hostport" field if it decreased correctness for them.
by that statement you tell me that you work with different people than i do.