On 01/06/2015 03:03 AM, David Conrad wrote: > This document confuses the concepts of the domain name namespace > with the DNS implementation of that namespace, making numerous assertions that they must have a particular string within the namespace because their particular application does not (necessarily) require the use of the DNS. This is a false dichotomy: the DNS implementation of the singular hierarchical domain name namespace does not preclude the use of any portion of that namespace outside of the DNS (for example, see nsswitch).
Well, I believe that while you are technically right, an nnswitch plugin hijacking ".com" today to do something very different from DNS resolution is typically not merely bad design, but most likely malware. This is what we mean by usability: we need to satisfy user's expectations, and just grabbing some TLD that ICANN has already allocated is likely to cause usability problems by confusing users. > I'm not sure if this is the right place to raise this, but I'm a bit confused: if DNS servers (caching/authoritative) are expected to respond with NXDOMAIN since "not doing so can put users’ privacy at risk", doesn't this set users of pTLDs up for privacy violations by bad guys running a DNS server? Yes, it does. Correctly configured installations of the P2P name systems must never contact DNS servers about these pTLDs. However, if an *honest* DNS server were to say redirect a user of a '.onion' to an advertisement server, the information leak might be extended to the advertisement server. So this is about limiting the privacy breach, not about avoiding it. Only correct configurations can avoid it. And it is also a bit about possibly reducing the load on the DNS root by officially condoning not asking the root for these TLDs. > - 2. Applicability > > "pTLDs cannot be allocated administratively" > > Perhaps you mean "Names within pTLDs cannot be allocated > administratively"? Yes, except thinking about it 'cannot ... administratively' also has not exactly the right ring to it. I'll change it to: "Names within pTLDs are not allocated by some designated administration" would be more precise. > "pTLDs do not depend on the DNS tree hierarchy for their resolution" > > As above. I see your point about the confusion between DNS-style names and DNS-style resolution. > "However the default hierarchical DNS response to any request to any > pTLD MUST be NXDOMAIN." > > If your applications depend on getting back an NXDOMAIN, you're going > to have a bit of trouble with DNS redirection. More to the point, if > your applications require an NXDOMAIN, it suggests you _ARE_ using > the DNS which implies RFC 6761 does not apply. It also suggests your > applications will be flooding the root with queries for > non-resolvable names which, while all the rage these days, is a bit > anti-social. Not exactly. Legacy GUIs often use DNS (or Socks4a) to interact with the P2P name system. So for the legacy GUI the system looks like DNS. But then at the dns2gns proxy, the NSS or the Socks-proxy, the DNS-formatted, DNS-style requests are processed differently based on the TLD. However, if say the socks proxy is "off", or the NSS is missconfigured, then the requests may unintentionally be leaked to DNS. > 'The word "peer" is used in the meaning of a individual system on the > network. Thus, "local peer" means the localhost.' > > I would've thought "local peer" would mean a system within the same > network topological level, not on the same machine (implied by > localhost). But maybe that's just me. I agree, while uncommon it doesn't have to be localhost. I'll remove the sentence starting with "Thus". > "A pTLD is mentioned in capitals, and within double quotes to mark > the difference with a regular DNS gTLD." > > Presumably you mean "TLD" not "gTLD" as "gTLD" is a specific type of > top-level domain (generic as opposed to country code (ccTLD)). Well, we don't have ccTLDs in the text, and in my view "TLD" includes "gTLD", "ccTLD" and "pTLD". > Hope this helps. Yes, thanks for your constructive feedback. -Christian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
