Re: [DNSOP] Top level names -- precision re categories and where are are the uncertainties?
Steve Crocker writes: Folks, I`ve been watching the dialog on this list regarding to level names. Attached is my attempt to clarify the state of affairs and identify the loose ends. Both PDF and pptx versions attached, the latter in case someone is moved to edit the slides directly. Either I don't understand the slides or they seem to be inconsistent. As an example, you defines 8 states [1] and 8 definitions (later called Categories: when you give exanples. However the examples doesn't match the definitions: Definition 2: Names that have not been formally recognized but are being used privately or for applications that have not yet become standard Definition 3: Two letter Latin characters that have not yet been assigned by the ISO 3166 maintenance agency but might be in the future. Category 2: xq Category 3: onion Are these mistakes or purposely. (There seem to be more of these cases on the slides). jaap [1] I'm not sure whether this is a proper term. Can one state move to another? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Thoughts on the top level name space
On Jul 6, 2015, at 5:08 PM, Edward Lewis edward.le...@icann.org wrote: On 7/5/15, 7:26, DNSOP on behalf of Steve Crocker dnsop-boun...@ietf.org on behalf of st...@shinkuro.com wrote: 3. (ICANN) Two letter Latin characters that have not yet been assigned by the ISO 3166 maintenance agency but might be in the future. Names in this subset may move to subset 7 to become active ccTLDs. Examples: xq 'pq' is a better example. 'xq' is classified as User Assigned, which means it has been assigned for use by anyone for their own purposes. 'pq' is (using Wikipedia’s term) unassigned. Thanks. I didn’t check the tables before writing. I was pretty sure xq wasn’t already assigned to a specific country or territory, but I didn’t think about a “1918” style designation of two letter codes. Perhaps we need another subset to put these into. It would be a “final” state in the sense that once a two letter code is put into that state, it can’t move to another state. And the purview would be the ISO 3166-1 Maintenance Agency. In recognition of this, though, I'd lump all of the alpha-2 codes ([A-Z][A-Z]) into category 3, and call it informally being at the mercy of the ISO 3166-1 Maintenance Agency.” Hmm… I understand your point, but I think it would feel odd to our audiences. If the ISO 3166-1 Maintenance Agency were to tinker with established codes, e.g. DE, JP, CN, etc., all hell would break loose. 4. (IETF) Names the IETF has formally recognized as reserved for particular non-DNS uses. Names in this subset are effectively permanent. (“Effectively permanent” means they are expected to remain in this subset forever and there is no defined process for changing the status of names in this subset.) Examples: example, local (Left in for the discussion later in this message.) 7. (ICANN) ccTLDs, both Latin and IDN. Names in this subset are expected to last indefinitely. If they are taken out of service they move to subset 8. Examples: jp, uk, na, xn--fzc2c9e2c The quirk I have here is the IDN Fast Track [https://www.icann.org/resources/pages/fast-track-2012-02-25-en] and trying to anticipate what names will be in that. The Latin ccTLD codes I can anticipate from category 3 above. But the IDN ccTLD names aren't distinguishable from other IDN names without consulting the Fast Track and even so, well I'll put this under - I don't understand if a name coming through the Fast Track might also be on a generic TLD track. I think this is a non-problem. Strings beginning with “x n - -“ are in subset 1 until they are moved into either subset 7 (Active ccTLD) or subset 6 (Active gTLD). It doesn’t matter whether they moved into the Active ccTLD subset because of the current FastTrack or some future process. As far as I know, if the Fask Track the only source of IDN ccTLD names? I believe this is true at present. There may be other processes in the future. 8. (ICANN) Previously used TLDs that have been taken out of service. Names in this subset must remain out of service for a very long time, currently estimated at 50 years, to avoid unintended consequences. Examples: cs Perhaps there's an 8-1/2: I've been told that the 11 IDN test TLDs which have been rescinded (NS records removed) are eligible to be reinstated if needed for further testing. I've been told means that I have never seen this in print and thus have no citation to give. Heh. Good point. Well, for other reasons I’ve been thinking we may need three additional subsets, and perhaps the experimental IDN TLDs would fit into one of these. The three are: o The two letter codes reserved by the ISO 3166-1 Maintenance Agency that will never be assigned to countries or territories, i.e. what you said above. This subset would be carved out of subset 3 and be a final state. o Names that have shown up in queries with some frequency but may subside in the future and hence may be available for assignment in the future. They would arrive into this subset from subset 1 (or possibly subset 3), and either return to the subset they came from or progress to subset 5. I would put the test IDNs into this subset. o Names that have been permanently excluded from use by both the IETF and ICANN and hence fall into both subsets 4 and 5. I think there’s value in keeping all of these subsets distinct from each other, it’s necessary to create a new subset for names that both groups have excluded. This would be a final state, arrived at either from subset 4 or subset 5. ISSUES o Should there be some sort of operational penalty for leakage of names in subsets 2, 4, 5 and 8 into the public DNS, e.g. a slow response from DNS servers? For the e.g., no. If just because that delaying an answer opens the time a cache can be poisoned. Others have mentioned this. But there's a wider issue suggested by this specific suggestion. What reaction should name
Re: [DNSOP] Thoughts on the top level name space
Thanks. Minor comments in line below. Steve On Jul 7, 2015, at 5:42 AM, Jaap Akkerhuis j...@nlnetlabs.nl wrote: Not taking a stand on this, but some more remarks on these thoughts. Edward Lewis writes: On 7/5/15, 7:26, DNSOP on behalf of Steve Crocker dnsop-boun...@ietf.org on behalf of st...@shinkuro.com wrote: 3. (ICANN) Two letter Latin characters that have not yet been assigned by the ISO 3166 maintenance agency but might be in the future. Names in this subset may move to subset 7 to become active ccTLDs. Examples: xq 'pq' is a better example. 'xq' is classified as User Assigned, which means it has been assigned for use by anyone for their own purposes. 'pq' is (using Wikipedia's term) unassigned. Indeed. The complete user assigned set is: AA, QM-QZ, XA-XZ and ZZ For the alpha 3-code the complete user assigned set is: AAA-AAZ, QMA-QZZ, XAA-XZZZ and ZZA to ZZZ so one could argue that the delegations for TLD xyz (and maybe xxx) is a actually against the rules in ICANN’s Application Guide Book. It’s my understanding that only the two character codes are included in the relationship between DNS top level names and ISO 3166-1. Three letter codes aren’t included, so there’s no conflict. In recognition of this, though, I'd lump all of the alpha-2 codes ([A-Z][A-Z]) into category 3, and call it informally being at the mercy of the ISO 3166-1 Maintenance Agency. But given that they can be freely used, one could consider them as candidates for non-TLD use in the name space. Hmm… Maybe. Seems like a bad idea, though. 4. (IETF) Names the IETF has formally recognized as reserved for particular non-DNS uses. Names in this subset are effectively permanent. (=E2=80=9CEffectively permanent=E2=80=9D means they are expected to remain in this subset forever and there is no defined process for changing the status of names in this subset.) Examples: example, local (Left in for the discussion later in this message.) 7. (ICANN) ccTLDs, both Latin and IDN. Names in this subset are expected to last indefinitely. If they are taken out of service they move to subset 8. Examples: jp, uk, na, xn--fzc2c9e2c I would recommend to not use UK as an example in this discussion. If I remember correctly, the use as a TLD stems from the time before the iso alpha-2 codes got adopted as TLDs. Well, I know there is controversy over some of the two letter codes, particularly UK, SU and EU, but it seems to me they are in full use and treated as ccTLDs. The quirk I have here is the IDN Fast Track [https://www.icann.org/resources/pages/fast-track-2012-02-25-en] and trying to anticipate what names will be in that. The Latin ccTLD codes I can anticipate from category 3 above. But the IDN ccTLD names aren't distinguishable from other IDN names without consulting the Fast Track and even so, well I'll put this under - I don't understand if a name coming through the Fast Track might also be on a generic TLD track. As far as I know, the Fast-Track IDN process uses the ISO standard to see whether the requested name can be applied as ccTLD. so something like Scandinavia will drop because because there is no ISO code for the corresponding country or (administrative) territory. This comment applies to whether a particular name is permitted to move from one subset to another. I don’t think it’s necessary to include the rules for moving, just what subsets names can be in. As far as I know, if the Fask Track the only source of IDN ccTLD names? 8. (ICANN) Previously used TLDs that have been taken out of service. Names in this subset must remain out of service for a very long time, currently estimated at 50 years, to avoid unintended consequences. Examples: cs CS has been used twice by ISO 3166. It is now in the 50 year cool-off period. Perhaps there's an 8-1/2: I've been told that the 11 IDN test TLDs which have been rescinded (NS records removed) are eligible to be reinstated if needed for further testing. I've been told means that I have never seen this in print and thus have no citation to give. See my reply to Ed Lewis re a possible additional subset for names that have appeared at the root with some frequency but might subside And there are other cases; Official assigned by ISO but not used as TLD (um comes to mind). It seems to me that UM did appear in the root and then was taken out of service. I doubt we’d want to see it assigned to another country or territory in the near future. I’d put it in subset 8 unless it were brought back to life in the service of the same territory it had been used for before. Steve jaap ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Thoughts on the top level name space
Putting the focus on this part of Steve¹s original email for now: On 7/5/15, 7:26 AM, DNSOP on behalf of Steve Crocker dnsop-boun...@ietf.org on behalf of st...@shinkuro.com wrote: o ICANN speaks indistinctly about subset 5. o Does the IETF have a process for moving a name from subset 2 to subset 4? Ideally, I would argue we may not need such a process. Beside experimentation with strings like xx-, subset 2 should be empty or, at least, not ground for consideration to move to subset 4. So, beside grand-fathering a few strings, what is needed is a process that is less ambiguous and simpler to evaluate than RFC6761 to reserve strings in subset 4. Maybe something along the lines of IETF validates the technical merits of the proposal and ICANN validates the suggested name That leads us to the next point: o A process for coordination between the IETF and ICANN regarding subsets 2, 4 and 5 would be helpful. RFC6761 does not say anything about such a coordination process. We have now learned a lot going through this round of 6761 candidates, so it is time to work on 6761bis, with, among other things, this coordination between ICANN and IETF on the agenda. Alain. smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Terry Manderson's No Objection on draft-ietf-dnsop-negative-trust-anchors-10: (with COMMENT)
Terry Manderson has entered the following ballot position for draft-ietf-dnsop-negative-trust-anchors-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-negative-trust-anchors/ -- COMMENT: -- Thank you for a well written document. Many more thanks for using github and making commit comment changes there!! ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
Akira Kato and I submitted draft-fujiwara-dnsop-nsec-aggressiveuse-01.
https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/
* Added reference to DLV {{RFC5074}} and imported some sentences.
* Added Aggressive Negative Caching Flag idea.
* Added detailed algorithms in Appendix.
Please check and comment.
I made a mistake at detailed algorithm part in -01.
I added updated version in this mail and I will update the draft.
NSEC3 validation is difficult for me.
Please check this algorithm.
And where is the pseudo code writing guide ?
~~~
QNAME = the query name;
if (QNAME name entry exists in the cache) {
resolve the query as usual;
// if RRSet (query name and query type) exists in the cache,
// the resolver responds the RRSet from the cache
// Otherwise, the resolver needs to iterate the query.
}
// Find closest enclosing NS RRset in the cache.
// The owner of this NS RRset will be a suffix of the QNAME
//- the longest suffix of any NS RRset in the cache.
SIGNER = closest enclosing NS RRSet of QNAME in the cache;
if (SIGNER zone does not have a special NSEC/NSEC3 data structure) {
Resolve the query as usual;
}
if (SIGNER zone is not signed or not validated) {
Resolve the query as usual;
}
if (SIGNER zone is signed with NSEC) {
// NSEC mode
if (covering NSEC RR of QNAME at SIGNER zone
doesn't exist in the cache) {
Resolve the query as usual.
}
TEST = Find the longest existing domain name of QNAME
from the covering NSEC RR;
if (*.TEST name entry exists in the cache) {
the resolver can generate positive response
or resolve the query as usual;
}
if covering NSEC RR of *.TEST at SIGNER zone exists
in the cache {
the resolver can generate negative response;
}
// Lack of information, need to resolve the query as usual
} else
if (SIGNER zone is signed with NSEC3 and does not use Opt-Out) {
// NSEC3 mode
TEST = SIGNER;
while (TEST != QNAME) {
// if any error happens in this loop, break this loop
UPPER = TEST;
add a label from the QNAME to the start of TEST;
// TEST = label.UPPER
if (TEST name entry exist in the cache) {
continue; // need to check rest of QNAME
}
if (covering NSEC3 of TEST exist in the cache) {
// (non-)terminal name TEST does not exist
if (*.UPPER name entry exist in the cache) {
// TEST does not exist and *.UPPER exist
the resolver can generate positive response;
} else
if (covering NSEC3 of *.UPPER exist in the cache) {
// TEST does not exist and *.UPPER does not exist
the resolver can generate negative response;
}
break; // Lack of information
} else
if (NSEC3 of TEST does not exist in the cache) {
break; // Lack of information
}
// TEST label exist, then need to check rest of QNAME
}
// Lack of information, need to resolve the query as usual
}
Resolve the query as usual
~~~
--
Kazunori Fujiwara, JPRS fujiw...@jprs.co.jp
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Thoughts on the top level name space
Not taking a stand on this, but some more remarks on these thoughts. Edward Lewis writes: On 7/5/15, 7:26, DNSOP on behalf of Steve Crocker dnsop-boun...@ietf.org on behalf of st...@shinkuro.com wrote: 3. (ICANN) Two letter Latin characters that have not yet been assigned by the ISO 3166 maintenance agency but might be in the future. Names in this subset may move to subset 7 to become active ccTLDs. Examples: xq 'pq' is a better example. 'xq' is classified as User Assigned, which means it has been assigned for use by anyone for their own purposes. 'pq' is (using Wikipedia's term) unassigned. Indeed. The complete user assigned set is: AA, QM-QZ, XA-XZ and ZZ For the alpha 3-code the complete user assigned set is: AAA-AAZ, QMA-QZZ, XAA-XZZZ and ZZA to ZZZ so one could argue that the delegations for TLD xyz (and maybe xxx) is a actually against the rules in ICANN's Application Guide Book. In recognition of this, though, I'd lump all of the alpha-2 codes ([A-Z][A-Z]) into category 3, and call it informally being at the mercy of the ISO 3166-1 Maintenance Agency. But given that they can be freely used, one could consider them as candidates for non-TLD use in the name space. 4. (IETF) Names the IETF has formally recognized as reserved for particular non-DNS uses. Names in this subset are effectively permanent. (=E2=80=9CEffectively permanent=E2=80=9D means they are expected to remain in this subset forever and there is no defined process for changing the status of names in this subset.) Examples: example, local (Left in for the discussion later in this message.) 7. (ICANN) ccTLDs, both Latin and IDN. Names in this subset are expected to last indefinitely. If they are taken out of service they move to subset 8. Examples: jp, uk, na, xn--fzc2c9e2c I would recommend to not use UK as an example in this discussion. If I remember correctly, the use as a TLD stems from the time before the iso alpha-2 codes got adopted as TLDs. The quirk I have here is the IDN Fast Track [https://www.icann.org/resources/pages/fast-track-2012-02-25-en] and trying to anticipate what names will be in that. The Latin ccTLD codes I can anticipate from category 3 above. But the IDN ccTLD names aren't distinguishable from other IDN names without consulting the Fast Track and even so, well I'll put this under - I don't understand if a name coming through the Fast Track might also be on a generic TLD track. As far as I know, the Fast-Track IDN process uses the ISO standard to see whether the requested name can be applied as ccTLD. so something like Scandinavia will drop because because there is no ISO code for the corresponding country or (administrative) territory. As far as I know, if the Fask Track the only source of IDN ccTLD names? 8. (ICANN) Previously used TLDs that have been taken out of service. Names in this subset must remain out of service for a very long time, currently estimated at 50 years, to avoid unintended consequences. Examples: cs CS has been used twice by ISO 3166. It is now in the 50 year cool-off period. Perhaps there's an 8-1/2: I've been told that the 11 IDN test TLDs which have been rescinded (NS records removed) are eligible to be reinstated if needed for further testing. I've been told means that I have never seen this in print and thus have no citation to give. And there are other cases; Official assigned by ISO but not used as TLD (um comes to mind). jaap ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Thoughts on the top level name space
Sorry for the empty previous post. My recollection is somewhat different from the AC requesting the revocation. But then the then AC reads this list and can relate himself if he wishes to do so. And I was quite upset at the time because I wanted dibs on IMODI.UM (just for the fun of it, not for squatting, actually with the express proviso until and/or if Janssen or whoever holds the trade mark now, wanted it :-)-O) el On 2015-07-07 11:27, Bill Woodcock wrote: As I'm sure our resident bad-idea-fairy can relate in greater detail, .UM was a delegated ccTLD with SLD subdelegations and at least one user, before the administrative contact requested that the TLD delegation be rescinded or deactivated or whatever you want to call it. Just a little more colorful history of the shub-Internet. -Bill [...] -- Dr. Eberhard W. Lisse \/ Obstetrician Gynaecologist (Saar) e...@lisse.na/ * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Bachbrecht, Namibia ;/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] .KEY - a new example of a non-DNS use
As we've been having this thread around TLDs, I noticed this item in Hacker News this morning of a new overlay network that is designed to use hashes of public keys for addressing: https://github.com/zrm/snow https://news.ycombinator.com/item?id=9843373 http://trustiosity.com/snow/how-it-works.html The developer has decided for name resolution **within the overlay network** to use hash-of-public-key.key. I see this as similar to what the Tor folks do with .onion. I point this out only to show another instance of a developer seeking to use DNS-like names (and even DNS tools)... only outside the scope of the regular DNS system. Dan -- Dan York Senior Content Strategist, Internet Society y...@isoc.orgmailto:y...@isoc.org +1-802-735-1624 Jabber: y...@jabber.isoc.orgmailto:y...@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/http://www.internetsociety.org/deploy360/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Thoughts on the top level name space
As I'm sure our resident bad-idea-fairy can relate in greater detail, .UM was a delegated ccTLD with SLD subdelegations and at least one user, before the administrative contact requested that the TLD delegation be rescinded or deactivated or whatever you want to call it. Just a little more colorful history of the shub-Internet. -Bill On Jul 7, 2015, at 17:44, Jaap Akkerhuis j...@nlnetlabs.nl wrote: Not taking a stand on this, but some more remarks on these thoughts. Edward Lewis writes: On 7/5/15, 7:26, DNSOP on behalf of Steve Crocker dnsop-boun...@ietf.org on behalf of st...@shinkuro.com wrote: 3. (ICANN) Two letter Latin characters that have not yet been assigned by the ISO 3166 maintenance agency but might be in the future. Names in this subset may move to subset 7 to become active ccTLDs. Examples: xq 'pq' is a better example. 'xq' is classified as User Assigned, which means it has been assigned for use by anyone for their own purposes. 'pq' is (using Wikipedia's term) unassigned. Indeed. The complete user assigned set is: AA, QM-QZ, XA-XZ and ZZ For the alpha 3-code the complete user assigned set is: AAA-AAZ, QMA-QZZ, XAA-XZZZ and ZZA to ZZZ so one could argue that the delegations for TLD xyz (and maybe xxx) is a actually against the rules in ICANN's Application Guide Book. In recognition of this, though, I'd lump all of the alpha-2 codes ([A-Z][A-Z]) into category 3, and call it informally being at the mercy of the ISO 3166-1 Maintenance Agency. But given that they can be freely used, one could consider them as candidates for non-TLD use in the name space. 4. (IETF) Names the IETF has formally recognized as reserved for particular non-DNS uses. Names in this subset are effectively permanent. (=E2=80=9CEffectively permanent=E2=80=9D means they are expected to remain in this subset forever and there is no defined process for changing the status of names in this subset.) Examples: example, local (Left in for the discussion later in this message.) 7. (ICANN) ccTLDs, both Latin and IDN. Names in this subset are expected to last indefinitely. If they are taken out of service they move to subset 8. Examples: jp, uk, na, xn--fzc2c9e2c I would recommend to not use UK as an example in this discussion. If I remember correctly, the use as a TLD stems from the time before the iso alpha-2 codes got adopted as TLDs. The quirk I have here is the IDN Fast Track [https://www.icann.org/resources/pages/fast-track-2012-02-25-en] and trying to anticipate what names will be in that. The Latin ccTLD codes I can anticipate from category 3 above. But the IDN ccTLD names aren't distinguishable from other IDN names without consulting the Fast Track and even so, well I'll put this under - I don't understand if a name coming through the Fast Track might also be on a generic TLD track. As far as I know, the Fast-Track IDN process uses the ISO standard to see whether the requested name can be applied as ccTLD. so something like Scandinavia will drop because because there is no ISO code for the corresponding country or (administrative) territory. As far as I know, if the Fask Track the only source of IDN ccTLD names? 8. (ICANN) Previously used TLDs that have been taken out of service. Names in this subset must remain out of service for a very long time, currently estimated at 50 years, to avoid unintended consequences. Examples: cs CS has been used twice by ISO 3166. It is now in the 50 year cool-off period. Perhaps there's an 8-1/2: I've been told that the 11 IDN test TLDs which have been rescinded (NS records removed) are eligible to be reinstated if needed for further testing. I've been told means that I have never seen this in print and thus have no citation to give. And there are other cases; Official assigned by ISO but not used as TLD (um comes to mind). jaap ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Thoughts on the top level name space
-07-07 11:27, Bill Woodcock wrote: As I'm sure our resident bad-idea-fairy can relate in greater detail, .UM was a delegated ccTLD with SLD subdelegations and at least one user, before the administrative contact requested that the TLD delegation be rescinded or deactivated or whatever you want to call it. Just a little more colorful history of the shub-Internet. -Bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
