Hi Ted,
I think this is a really helpful question, so I'll attempt to answer it
constructively….
I'm also going to suggest a reframing though, because (to start at the end of
your note), I think a lot of the fireworks have occurred because we're talking
about two different sets of issues here: the specifics of the draft and the
special-use names registry (operational and implementation implications of the
request and the draft itself) and some broader, systemic issues of architecture
and even (shudder!) policy. Each can be volatile on its own, so mixing them is
guaranteed to be :)
The draft itself is obviously a serious attempt at justifying the reservation
requested under RFC 6761, and I commend the authors for doing that. I hope they
don't take the concerns being raised as unfriendly to their participation here.
("DNS glitterati" I'm not, but I've run a few nameservers and participated in
DNS protocol discussions from time to time….)
In order to your points….
On Dec 10, 2013, at 12:26 PM, Ted Lemon <[email protected]> wrote:
> Can I just point out here that the only real technical points that have been
> raised in this discussion thus far, at least that I can recall, are that:
>
> (1) defining sTLDs produces a small (relatively) amount of useless traffic at
> the root
This is a specific operational issue. I think David Conrad nailed it; my own
experience of root name server operation makes it difficult to see this as a
problem, with a couple of caveats:
* scalability comes into play at some point; I'd be fairly nervous
about a special-use names registry that was significantly bigger than the
"real" DNS root, for example! (see to your question 3 below). Six names is
nowhere near a concern from that perspective.
* The amount of leakage is going to be larger or smaller, and more or
less predictable, depending on the clarity of the instructions to implementors
on how to avoid it for the protocols using the reserved names. In turn this has
scalability implications for how widely used a given name/protocol becomes as
well as how many there are. I'm not familiar with those protocols in detail, so
I don't know the answer to this question. But if having a reserved name
associated with the protocol is expected to support expanded use, it's worth
looking at how to make use of the reserved name as simple and foolproof as
possible.
> (2) defining sTLDs may have trademark implications that the IETF is not
> competent to address
This is an architectural and policy issue, and isn't inherent in any specific
special-use name but comes up as soon as we've admitted that one of the
desirable properties of DNS-like namespaces is that they promote the use of
names that have some significance to humans.
Names are controversial. Scope of names doesn’t always travel with them; one of
the problems with using things that look like DNS names is that in certain
policy realms, people think of DNS names as global, particularly DNS names that
look like TLDs. Not all of the controversies about what names are OK in the DNS
root are likely to come along with RFC 6761 names, but some will, and the RFC
6761 assertion that such names are “protocol” and therefore strictly
“technical” does not end the argument that will ensue.
After some years of experience with DNS protocol and namespace issues,
including a front-row seat to the controversies ICANN has been involved in, I
understand completely that no one— not ICANN, not vendors like my current
employer, not even the IETF— can tell people what to do or what to name things
inside their own networks. I understand that there’s no way to force people to
use the special use names registry, and no way that reserving or refusing to
reserve a name can be relied upon to change anybody’s behavior in the real
world, so complaining that an RFC 6761 name reservation encourages or blesses
behavior someone doesn’t like is going to be dubious at best. But I’m not the
person you need to be concerned about here.
I’m also not arguing that these issues can’t be overcome. I *am* arguing that
there’s more to handling them than asserting "these names are for ‘technical'
use and only look like DNS names, so none of the issues around ‘real' TLDs
apply.” Some don’t (e.g. registry policy, DNSSEC). Some do (“you can’t have
$foo in the DNS because it would collide with a reserved name.” “But it’s
incredibly valuable as a DNS name and I have the right to use it!”— see the
name collision problem we’ve already got, with the accompanying problem of
proving something *isn’t* already in use.)
In terms of scalability, it's worth noting that whatever problems we might be
"borrowing" from ICANN-space become more likely roughly in proportion to how
many names we're talking about and how widely used/visible they're going to be.
> (3) supporting sTLDs in stub resolvers requires changes to stub resolvers
This appears to be the case and is another operations/implementation issue. The
expectation appears to be that the stub the application uses will know that a
given protocol requires/expects not only that certain names aren't really DNS
names, but what special handling to apply instead (five of the six discussed in
the draft are supposed to get NXDOMAIN, the sixth appears to require something
more complex).
This expectation is more realistic for an application-specific stub than for a
system-specific one. Which architecture it makes more sense to expect an
implementor to be trying to build is a judgment for people who know lots more
about application behavior than I do.
Part of the answer here also goes to scalability. A system-based or
general-purpose stub is going to get harder to write, configure, and debug as
the list of special names gets longer and the list of special behaviors that
have to be coded into it expands. Overall, the complexity of administering
namespaces and resolving names grows with the number of special names. Since
DNS resolvers and DNS-like namespaces can be pretty complex already, it's again
a question of how many of these things do we want or need? in addition to the
utility of any given one.
I suspect there are lots of protocols people are working on now, or will work
on in the future, where "Hey, a special-use DNS-like name would help here,
let's get one….or several…." will sound like a good idea. Having lots of them
may not be such a good idea regardless of the merits of any one in particular.
How useful is useful enough, then? 6761 provides some guidance on this, but
leaves lots of room for judgment, which is why we're having this conversation.
> (4) it would be nice to have stable specifications for the proposed sTLDs
I'd go further than "it would be nice," because I happen to think for the
reasons above that it shouldn't be too easy to get a special-use name and it
shouldn't be too difficult for the implementor to tell how they should be
treated when they do appear-- "it's not a DNS name, so don't worry about it"
won't cut it.
Having not reviewed the underlying protocol specifications associated with this
draft, I'm not comfortable judging whether they are strong enough.
>
> I assume that there is some reason for the strong negative reaction some DNS
> glitterati have expressed towards this proposal, but whatever that reason is
> has not yet been expressed. If you have an inkling of what that reason
> might be, and it is not simply a strong feeling based on history, a feeling
> of dislike for one of the proposed name resolution protocols, or a concern
> about how someone might react to the IESG taking action on this, I would
> greatly appreciate it if you could express that reason.
My reasons:
* I'm not convinced the current draft is clear enough on the
operational specifics of how an implementor should treat the requested names,
or how the overall DNS system will manifest leakage or other mishandling of
these names. This is operational and probably fixable.
* I'm not convinced we've thought through how to manage
"technical"/infrastructure DNS-like names in a world where those have policy
implications we may not like but can't reasonably ignore. This is a matter of
architecture and policy and can really only be resolved by discussion and
judgment.
Hope this helps,
Suzanne_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
