Hi Eric,
Thanks for your review. Some remarks in line.
On Tue, Sep 15, 2015 at 02:28:56PM -0700, Eric Brunner-Williams wrote:
>
> IMO, nothing is gained, and something may be lost, by suggesting that the
> DNS begins, and ends, with the IANA published zone.
I don't believe the document suggests either that beginning or ending,
and I'd like you to point to the text that does (since I don't
understand the text you quoted but that I elided here as making such a
suggestion). The I-D _does_ rely on the premise that the global DNS
for the Internet relies on the IANA root. I think that it does, and I
note that the IAB some time ago published a document that seems to
agree with me. It may be that on this or that network (potentially
even large ones) people are using alternative roots, special
otherwise-undelegated names (e.g. corp), or whatever. Those parts of
the DNS are not on the Internet, even if those servers are part of
some internet and even if people on the Internet could in principle
use those servers for resolution. The global DNS is the one shared
implicitly by all attached to the Internet, and that's rooted at IANA.
If we reach the point where the IANA root and other DNS systems start
to drift apart, we will no longer have one global name space, but
multiple such name spaces none of which is the name space of the
Internet. That's precisely why this issue is fraught.
> with label processing rules. The text "normal registration and lookup rules
> do not apply" is overly restrictive (see above), and conflates the process
> overhead of "registration" (see provreg, ICANN, "variants", et seq.) and
> "lookup rules" (see IDNA and not a lot else).
I reject your above argument, so I don't think it's overly
restrictive, and since we explicitly separate registration and lookup
(since we name each of them) I don't understand why you think there's
a conflation.
> IMO, nothing is gained, and something may be lost, by suggesting that label
> processing uniquely identifies a zone publisher.
Where does the text suggest that, please?
> While 2826 expressed a technical comment, it did not prevent independent
> re-publication of the data published by the IANA, nor the publication of a
> limited number of additional data records.
No indeed. Where exactly do you think the I-D suggests either of
those things?
> IMO, nothing is gained, and something may be lost, by suggesting that:
> (1) the DNS ("DNS context") is properly restricted to the zone published by
> the IANA,
It's not "properly restricted". But we're limiting the scope of the
"normal" DNS to be anchored in the global DNS. Would it help if we
added these sentences: "It is worth noting that some uses of DNS
happen outside the global DNS. For the purposes of this document,
those uses are no different to any other use of domain names that are
not part of the normal DNS."?
> On the Background (2) text:
>
> The closing sentence of paragraph 1 contains a statement for which no
> support exists. While it is true that DNS is "the primary resolution system
> on the Internet", the same statement was true of HOSTTABLES prior to the
> transition, and HOSTTABLES shared neither the "hierarchical", the
> "distributed" nor the "caching" nature of the DNS.
Yes, and those were three of the reasons discussed in the introduction
of RFC 882 for why DNS was needed. Since people in fact adopted the
DNS and those were the reasons for doing so, we claim there's a
teleological explanation there. If you really think this is
controversial, I don't suppose it'll hurt to remove the sentence, but
since this is a WG document I'd like more than one such objection
(because, quite frankly, your argument here seems at best thin to me).
> The closing paragraph conjectures some design goal (resolution concealment)
> that would "necessarily be defeated" by leakage. This seems overly
> confident.
It's an analytic truth, so I'm pretty confident.
> There is a great deal of text in this section (#2), which revisits the
> presumption incorrectly offered in the intro text.
Since we disagree about that incorrectness, I presume we disagree here
too.
> Incorrect processing of label sequences of a UTF8 implementation resulting
> in settlement costs motivated deployment of another mechanism to prevent
> "leakage".
This seems to be a claim about the motivation of something, but it's
completely obscure to me what that something is; and anyway, I'm not
sure what these settlement costs were or where they are documented.
How is this relevant to the section?
> On the ALT Namespace (3) text:
>
> The authors of 2929, IIRC, chose not to make normative reference to US-ASCII
> when discussing text labels, allowing the possible subsequent signaling to
> special application layer processing by text labels composed of non-ASCII
> characters.
The normativity of US-ASCII there is irrelevant; the main thing is
that 2929 (and its successors, of which there are a few) doesn't constrain
anything to LDH. But so what?
> The choice of a sequence of US-ASCII ALPHA characters to signal special
> application layer processing is ad hoc.
I think it's specified somewhere, but it's certainly arbitrary.
> The US-ASCII ALPHA character sequence NXDOMAIN has signaled non-resolved
> status to human eyeballs since 2308, as an alternate expression for the
> "Name Error" RCODE described in 1035 Section 4.1.1. Were a US-ASCII ALPHA
> character sequence terminating label to be required to signal the label
> sequence is not to be looked up, per 1034 et seq., this sequence would have
> obvious and unambiguous meaning tied to 2308, hence to 1035, a property the
> proposed terminating label lacks.
Are you suggesting (I can't tell) that we replace "alt" with
"nxdomain"? If so, I see two objections. First, as you have already
pointed out, the DNS and the global DNS are not coterminus in scope.
Therefore I can freely imagine someone using the alt tree to publish
application-specific data that _is_ to be looked up in the DNS, just
not in the global DNS. This is actually discussed in section 4.1 of
the draft. So "nxdomain" would be wrong in that case. Moreover,
nxdomain is longer than alt, so it shortens the already-cramped space.
> On the IANA Considerations (4) text:
>
> The text of 4.1 is unnecessary, as label sequences terminated in the label
> composed of a specified sequence of US-ASCII ALPHA characters are, according
> to this document, not "domain names" or "DNS names" or "names" in the
> context of the DNS.
They certainly are domain names, and the text of 4.1 is quite clearly
needed under the rules of RFC 6761.
> On the Security Considerations (5) text:
>
> The text is unnecessarily speculative and the risk statement offered
> unranked compared to other well-known risks which are reflected in other
> "Security Considerations" texts.
Do you have specific changes you want to see?
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
