On Monday 2 December 2013 at 11:17, Ted Lemon wrote:
> RFC 6761 has IETF consensus, and does not propose adding new namespaces under
> .arpa, but rather at the top level. Here's what RFC3172 says on the topic of
> .arpa:
>
> This domain is termed an "infrastructure domain", as its role is to
> support the operating infrastructure of the Internet. In particular,
> the "arpa" domain is not to be used in the same manner (e.g., for
> naming hosts) as other generic Top Level Domains are commonly used.
Perhaps 3172 needs to be updated to reflect current IAB practice, then. It's
not hard to find examples of names under ARPA which contradict the text you
quoted (e.g. see RFC 5855).
> Aside from the purely practical matter that having special domains live under
> .arpa would be more complicated to implement,
This feels like an over-general pronouncement that can't hope to be accurate in
all cases. Why is it more complicated in the general case? More complicated
than what?
> it doesn't make sense. Consider .local—our main example of a special-use
> domain. Would it make sense for .local to be under .arpa? I don't think so.
> .local is specifically not "internet infrastructure." It isn't even DNS. It's
> an escape from the DNS namespace, with different semantics than domain names
> in the DNS.
I think you're sharing personal opinion rather than citing fact ("make sense").
The .local convention happened to be adopted by Apple for use in a DNS-like
protocol, and was documented (and the IN-class top-level label reserved) later.
They could equally well have adopted .local.arpa or .local.apple.com.
I'm not complaining about Apple's innovation here, or their decision to
document it at the IETF. But I don't think it's sufficient to assert that
alternatives would not have made sense without justifying why that is so.
> The other proposed special uses are similar. Putting them under .arpa might
> be _expedient_, because it avoids the whole change control question, but
> that's pretty much the only way I can think of that it makes sense.
It doesn't avoid the whole change control question -- it just reduces the
change control to one with a single, uncontentious decision point (the IAB). By
contrast, the business of identifying reserved strings (and enforcing their
non-delegation for other purposes) in the root zone is fraught with
administrative ambiguity.
Joe
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
