wkumari / draft-wkumari-dnsop-alt-tld Goto Github PK

From the mailing list, via @peterthomassen

There's a broken sentence in Section 5:

"Care must be taken to ensure that the mapping of thepseudo-TLD into its corresponding non-DNS name resolution system inorder to get whatever security is offered by that system."

--> the "that" clause lacks a verb. (... ensure that the mapping ... [what]?)

At the occasion of fixing that, I'll also note two other suggestions / potential improvements:

• Section 2: "wastes resources": whose? Only the root servers' mentioned in the same sentence? Suggestion: "wastes resources on both the resolver and the root server side."

• Section 5: Amend the last sentence with something like "in particular, the risk of collisions with and subsequent compromise through other naming systems existing now or in the future should be considered". (I know the previous versions has something similar, but this is less strong, and I think it's worthwhile pointing out what people are getting into.)

Currently people generating alternate namespaces are just choosing one. We could ask the IANA to run an informational, first come, first served registry, or simply just mirror the existing behavior.

Remember to add:
Barry Lieba

(I'm keeping this as an open issue for IETF LC comments)

Should .ALT be delegated to (new style) AS112 nameservers?

We do suggest that caching and auth nameservers immediately return NXD for all names in .ALT, but until everyone does that there will be some hitting the root.

• should ALT domain itself be DNSSEC signed? is it appropriate to not sign this space, or is it required to sign this space? why?
• should subdomains of ALT be able to be concretely signed over?
• should subdomains of ALT be able to be repudiated by NSEC3 if the desire is to disclaim them
• what mechanisms in DNSSEC could be used, to do existence, non-existence checks?

The whole question of the applicability of DNSSEC to the space needs to be discussed.

Statement: https://datatracker.ietf.org/liaison/1351/

From Jim Reid on the mailing list:

I still don’t see why a special TLD has to be set aside or needed for these alternate name spaces. What can be done with .alt that couldn’t be equally done in (say) alt.arpa? The ID says nothing on that issue. Or why alternate name spaces that aren’t part of the DNS need to be somehow anchored in the DNS.

I suspect that this document really needs to specify alt is a placeholder and the specific string is strongly not defined, or requested in the document.

I think alt has substantive issues:

• for potential future use ALTernative culture &c in TLD
• clear semantic meaning to other uses eg .ALT USENET domain
• three letter acronyms are immensely valuable

The .notdns is in some sense wiser. So, rather than request a name, (which btw, demands formal request to IAB to request ICANN to reserve) this documents requests a name. Some name.

The Dingledine2004 reference is formatted in a suboptimal way in all three display renderings (text, PDF, and "htmlized") on the datatracker:

1. There is a comma. followed by two space characters, followed by another comma, instead of just one comma.
2. The URL is enclosed in two sets of less than / greater than characters, instead of just one.

Issue one may be a missing feature in the renderer, i.e., an empty field is not omitted.

Issue two may be caused by having added < and > to the target attribute.

I do not have the IETF XML tooling installed, and thus cannot test possible fixes. Therefore just this GitHub issue.

From @wessels:

“Caching Resolvers performing aggressive use of DNSSEC-validated caches ... will not send any queries for names under .alt to the root zone.” This statement is too strong. RFC 8198 says SHOULD, not MUST. Not to mention cache misses.

From the list, from @schanzen

"Developers are wholly responsible for dealing with any collisions"

I think this is an impossible task and as a developer that is addressed
here I have to say that we cannot do that unilaterally for our
implementation/design because collisions occur when others do
something.
Maybe you are talking about "groups" (as used in this paragraph) or the
"alternative name system community" here, which would make more sense?
This paragraph also uses both "groups" and "developers", and the
difference (to me) is not clear.

Maybe simply strike this sentence again?
Instead or in addition maybe a full acknowledment of this issue in the
security considerations, along the lines of

"
This draft does not define a registry or governance model for the .alt
namespace and as such developers/groups as well as users and applications cannot
expect unambiguous mappings from names with a ".alt"-TLD to a specific
alternative name space / name resolution mechanism.
This issue can be mitigated, for example, through the creation and use of a
registry by the alternative name system developer community.
"

From @d3e3e3:

Since it has no keywords in it, Section 1.1 should be deleted.

The very first like of README.md is
Important: Read CONTRIBUTING.md before submitting feedback or contributing but there is no CONTRIBUTING.md file in the repo.

From https://mailarchive.ietf.org/arch/msg/dnsop/tlWuAikoK564tAcYW6YRR27gygc :

A suggestion/nit which I'm fine to see ignored: the text in section 4 (Privacy Considerations) isn't that clear and might be helped via one or a couple of examples e.g. by adding:

"For example, a value such as 'mumblemumble.alt' would be a clear privacy leak."

And for bonus points, one might further add:

"In addition if a name ending in .alt is sufficiently unique, long-lasting and frequently leaks into the global DNS, then regardless of how the value is constructed, that value can act like a web cookie, with all the associated downsides of (re-)identification."