[rssac-caucus] possible new work item
Hi all, I have a suggestion for a new work item for RSSAC. If RSSAC thinks this work would be of value, and there are people willing to work on it, I'd be happy to (co-) lead a work party. A rough sketch of a charter follows. Comments would be most welcome! Thanks, Joe Back in the dim mists of time, individual root servers had names chosen by the organisation that operated them. Some/all of these names are recorded for posterity in the canonical root hints file, e.g. A was originally NS.INTERNIC.NET, B was originally NS1.ISI.EDU, F was originally NS.ISC.ORG, etc. ftp://rs.internic.net/domain/named.cache The naming scheme was subsequently changed to <letter>.ROOT-SERVERS.NET, with the intent that the response to the priming query (using label compression for the ROOT-SERVERS.NET domain) would be smaller, and would allow an additional four root servers to be specified without causing the priming response to grow beyond the specified non-EDNS(0) message size limit using UDP transport. I have seen this cleverness attributed to Bill Manning in the past. ROOT-SERVERS.NET was delegated from the NET zone to all root servers. The domain exists in the NET registry, defended by a platoon of registry locks, and the zone itself is (if I recall correctly) maintained and distributed by Verisign to root server operators as part of the root zone maintainer function, with changes following a similar process to that used for the root zone, including interactions between the three root zone partners. In the opinions of some (but not all) people, the existence of the ROOT-SERVERS.NET zone is a historical mistake, and it would have been better to name the root servers in a way that avoided the necessity for a separate zone, e.g. bare single-label names (A, B, C, ...) or multi-label names with no delegation (A.ROOT-SERVERS, B.ROOT-SERVERS) provisioned directly in the root zone. The presence of a label like ROOT-SERVERS might in effect constitute a reserved TLD label, with corresponding impact on ICANN policy for root zone management, the technical direction and remit of the IETF/IAB, and the intersection of the two. So, there are dragons^Wpolitical considerations, although I think RSSAC should constrain itself to technical commentary and leave any dragon baiting to others. SAC53 has a thing or two to say about "dotless domains" like A, B, C, etc which could no doubt provide a useful citation. A client that sends a priming query with EDNS0.DO=1 (which, I gather, is how most priming queries are observed to arrive today) does not currently receive a response with signatures in the additional section of the response, because the ROOT-SERVERS.NET zone is not signed. The lack of signatures in the ROOT-SERVERS.NET zone is either a feature or a bug, depending on your perspective; if it was to be signed, the question of key management would arise. If signatures were present, there might be some operational impact caused by the increased size of the priming response. Rather than the naming scheme for root servers remaining a collection of partially-remembered anecdotes plus occasional yet regular memes on mailing lists about what a mistake the current naming scheme was, I think it would be good if RSSAC could produce a document that: 1. Provides a citeable history on how root nameservers were originally named and how they are named today, recording the reasons for the change; 2. Considers the risks and benefits of a new naming scheme that avoids the zone cut, including impact on root zone partners' processes, on operational issues like priming response sizes and backed-in assumptions elsewhere about root server names and on security issues relating to DNSSEC validation; 3. Considers the risks associated with any transition from the current naming scheme to a different one; 4. Makes recommendations as to whether a change from the current scheme should be made and, if the recommendation is to make a change, makes further recommendations that might frame the way a transition is planned and managed operationally. A recommendation that there be no change is an equally reasonable outcome; either way the document should include high-quality justification and reasoning. All recommendations made would be actionable by ICANN (rather than recommendations actionable by the other two partners or anybody else with skin in the game), since that is the scope of our role.
Sounds like a workable item to me. I’ve put together a brief document on the history of the root servers, naming structures and historical operator selection criteria. Target for publication is a journal with a tentative publication date in August. That might be your task one. manning bmanning@karoshi.com PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 19May2015Tuesday, at 9:16, Joe Abley <jabley@hopcount.ca> wrote:
Hi all,
I have a suggestion for a new work item for RSSAC. If RSSAC thinks this work would be of value, and there are people willing to work on it, I'd be happy to (co-) lead a work party.
A rough sketch of a charter follows.
Comments would be most welcome!
Thanks,
Joe
Back in the dim mists of time, individual root servers had names chosen by the organisation that operated them. Some/all of these names are recorded for posterity in the canonical root hints file, e.g. A was originally NS.INTERNIC.NET, B was originally NS1.ISI.EDU, F was originally NS.ISC.ORG, etc.
ftp://rs.internic.net/domain/named.cache
The naming scheme was subsequently changed to <letter>.ROOT-SERVERS.NET, with the intent that the response to the priming query (using label compression for the ROOT-SERVERS.NET domain) would be smaller, and would allow an additional four root servers to be specified without causing the priming response to grow beyond the specified non-EDNS(0) message size limit using UDP transport. I have seen this cleverness attributed to Bill Manning in the past.
ROOT-SERVERS.NET was delegated from the NET zone to all root servers. The domain exists in the NET registry, defended by a platoon of registry locks, and the zone itself is (if I recall correctly) maintained and distributed by Verisign to root server operators as part of the root zone maintainer function, with changes following a similar process to that used for the root zone, including interactions between the three root zone partners.
In the opinions of some (but not all) people, the existence of the ROOT-SERVERS.NET zone is a historical mistake, and it would have been better to name the root servers in a way that avoided the necessity for a separate zone, e.g. bare single-label names (A, B, C, ...) or multi-label names with no delegation (A.ROOT-SERVERS, B.ROOT-SERVERS) provisioned directly in the root zone.
The presence of a label like ROOT-SERVERS might in effect constitute a reserved TLD label, with corresponding impact on ICANN policy for root zone management, the technical direction and remit of the IETF/IAB, and the intersection of the two. So, there are dragons^Wpolitical considerations, although I think RSSAC should constrain itself to technical commentary and leave any dragon baiting to others.
SAC53 has a thing or two to say about "dotless domains" like A, B, C, etc which could no doubt provide a useful citation. A client that sends a priming query with EDNS0.DO=1 (which, I gather, is how most priming queries are observed to arrive today) does not currently receive a response with signatures in the additional section of the response, because the ROOT-SERVERS.NET zone is not signed. The lack of signatures in the ROOT-SERVERS.NET zone is either a feature or a bug, depending on your perspective; if it was to be signed, the question of key management would arise. If signatures were present, there might be some operational impact caused by the increased size of the priming response.
Rather than the naming scheme for root servers remaining a collection of partially-remembered anecdotes plus occasional yet regular memes on mailing lists about what a mistake the current naming scheme was, I think it would be good if RSSAC could produce a document that:
1. Provides a citeable history on how root nameservers were originally named and how they are named today, recording the reasons for the change;
2. Considers the risks and benefits of a new naming scheme that avoids the zone cut, including impact on root zone partners' processes, on operational issues like priming response sizes and backed-in assumptions elsewhere about root server names and on security issues relating to DNSSEC validation;
3. Considers the risks associated with any transition from the current naming scheme to a different one;
4. Makes recommendations as to whether a change from the current scheme should be made and, if the recommendation is to make a change, makes further recommendations that might frame the way a transition is planned and managed operationally. A recommendation that there be no change is an equally reasonable outcome; either way the document should include high-quality justification and reasoning.
All recommendations made would be actionable by ICANN (rather than recommendations actionable by the other two partners or anybody else with skin in the game), since that is the scope of our role. _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
[ Top-post ] Gulp. What, someone gave you a worm can opener for your birthday?! Yah, this sounds fun / interesting. If a work party if formed I'd like to participate.... W On Tue, May 19, 2015 at 12:16 PM, Joe Abley <jabley@hopcount.ca> wrote:
Hi all,
I have a suggestion for a new work item for RSSAC. If RSSAC thinks this work would be of value, and there are people willing to work on it, I'd be happy to (co-) lead a work party.
A rough sketch of a charter follows.
Comments would be most welcome!
Thanks,
Joe
Back in the dim mists of time, individual root servers had names chosen by the organisation that operated them. Some/all of these names are recorded for posterity in the canonical root hints file, e.g. A was originally NS.INTERNIC.NET, B was originally NS1.ISI.EDU, F was originally NS.ISC.ORG, etc.
ftp://rs.internic.net/domain/named.cache
The naming scheme was subsequently changed to <letter>.ROOT-SERVERS.NET, with the intent that the response to the priming query (using label compression for the ROOT-SERVERS.NET domain) would be smaller, and would allow an additional four root servers to be specified without causing the priming response to grow beyond the specified non-EDNS(0) message size limit using UDP transport. I have seen this cleverness attributed to Bill Manning in the past.
ROOT-SERVERS.NET was delegated from the NET zone to all root servers. The domain exists in the NET registry, defended by a platoon of registry locks, and the zone itself is (if I recall correctly) maintained and distributed by Verisign to root server operators as part of the root zone maintainer function, with changes following a similar process to that used for the root zone, including interactions between the three root zone partners.
In the opinions of some (but not all) people, the existence of the ROOT-SERVERS.NET zone is a historical mistake, and it would have been better to name the root servers in a way that avoided the necessity for a separate zone, e.g. bare single-label names (A, B, C, ...) or multi-label names with no delegation (A.ROOT-SERVERS, B.ROOT-SERVERS) provisioned directly in the root zone.
The presence of a label like ROOT-SERVERS might in effect constitute a reserved TLD label, with corresponding impact on ICANN policy for root zone management, the technical direction and remit of the IETF/IAB, and the intersection of the two. So, there are dragons^Wpolitical considerations, although I think RSSAC should constrain itself to technical commentary and leave any dragon baiting to others.
SAC53 has a thing or two to say about "dotless domains" like A, B, C, etc which could no doubt provide a useful citation. A client that sends a priming query with EDNS0.DO=1 (which, I gather, is how most priming queries are observed to arrive today) does not currently receive a response with signatures in the additional section of the response, because the ROOT-SERVERS.NET zone is not signed. The lack of signatures in the ROOT-SERVERS.NET zone is either a feature or a bug, depending on your perspective; if it was to be signed, the question of key management would arise. If signatures were present, there might be some operational impact caused by the increased size of the priming response.
Rather than the naming scheme for root servers remaining a collection of partially-remembered anecdotes plus occasional yet regular memes on mailing lists about what a mistake the current naming scheme was, I think it would be good if RSSAC could produce a document that:
1. Provides a citeable history on how root nameservers were originally named and how they are named today, recording the reasons for the change;
2. Considers the risks and benefits of a new naming scheme that avoids the zone cut, including impact on root zone partners' processes, on operational issues like priming response sizes and backed-in assumptions elsewhere about root server names and on security issues relating to DNSSEC validation;
3. Considers the risks associated with any transition from the current naming scheme to a different one;
4. Makes recommendations as to whether a change from the current scheme should be made and, if the recommendation is to make a change, makes further recommendations that might frame the way a transition is planned and managed operationally. A recommendation that there be no change is an equally reasonable outcome; either way the document should include high-quality justification and reasoning.
All recommendations made would be actionable by ICANN (rather than recommendations actionable by the other two partners or anybody else with skin in the game), since that is the scope of our role. _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
-- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
Warren! On 21 May 2015, at 10:47, Warren Kumari wrote:
[ Top-post ]
[ Bottom-post ]
Gulp. What, someone gave you a worm can opener for your birthday?!
Well, closer to an attempt to illustrate that not everything relating to the root server system is shipped in a cylinder with soft-bodied invertebrates on the label. I think it's better for people to form the opinion "it is how it is for easy-to-find reasons, and because changing it is a bad idea" than for them to stock up on tinfoil, if that's what we decide is the right conclusion. And if we decide there are positive benefits in making a change, why wouldn't we recommend that change?
Yah, this sounds fun / interesting. If a work party if formed I'd like to participate....
Hooray! That sounds like two thumbs up. Question for Management: I don't know what the process is here; are we letting this conversation run its course and expecting some direction from the exec in due course? Or are we self-organising within the caucus, and expecting the exec to consider the final output? Or something else? Joe
Hi, Joe, You just came up with an interesting topic. This issue seems valuable to me, too. I would like to work on this with you. Declan Ma ZDNS Ltd.
在 2015年5月20日,上午12:16,Joe Abley <jabley@hopcount.ca> 写道:
Hi all,
I have a suggestion for a new work item for RSSAC. If RSSAC thinks this work would be of value, and there are people willing to work on it, I'd be happy to (co-) lead a work party.
A rough sketch of a charter follows.
Comments would be most welcome!
Thanks,
Joe
Back in the dim mists of time, individual root servers had names chosen by the organisation that operated them. Some/all of these names are recorded for posterity in the canonical root hints file, e.g. A was originally NS.INTERNIC.NET, B was originally NS1.ISI.EDU, F was originally NS.ISC.ORG, etc.
ftp://rs.internic.net/domain/named.cache
The naming scheme was subsequently changed to <letter>.ROOT-SERVERS.NET, with the intent that the response to the priming query (using label compression for the ROOT-SERVERS.NET domain) would be smaller, and would allow an additional four root servers to be specified without causing the priming response to grow beyond the specified non-EDNS(0) message size limit using UDP transport. I have seen this cleverness attributed to Bill Manning in the past.
ROOT-SERVERS.NET was delegated from the NET zone to all root servers. The domain exists in the NET registry, defended by a platoon of registry locks, and the zone itself is (if I recall correctly) maintained and distributed by Verisign to root server operators as part of the root zone maintainer function, with changes following a similar process to that used for the root zone, including interactions between the three root zone partners.
In the opinions of some (but not all) people, the existence of the ROOT-SERVERS.NET zone is a historical mistake, and it would have been better to name the root servers in a way that avoided the necessity for a separate zone, e.g. bare single-label names (A, B, C, ...) or multi-label names with no delegation (A.ROOT-SERVERS, B.ROOT-SERVERS) provisioned directly in the root zone.
The presence of a label like ROOT-SERVERS might in effect constitute a reserved TLD label, with corresponding impact on ICANN policy for root zone management, the technical direction and remit of the IETF/IAB, and the intersection of the two. So, there are dragons^Wpolitical considerations, although I think RSSAC should constrain itself to technical commentary and leave any dragon baiting to others.
SAC53 has a thing or two to say about "dotless domains" like A, B, C, etc which could no doubt provide a useful citation. A client that sends a priming query with EDNS0.DO=1 (which, I gather, is how most priming queries are observed to arrive today) does not currently receive a response with signatures in the additional section of the response, because the ROOT-SERVERS.NET zone is not signed. The lack of signatures in the ROOT-SERVERS.NET zone is either a feature or a bug, depending on your perspective; if it was to be signed, the question of key management would arise. If signatures were present, there might be some operational impact caused by the increased size of the priming response.
Rather than the naming scheme for root servers remaining a collection of partially-remembered anecdotes plus occasional yet regular memes on mailing lists about what a mistake the current naming scheme was, I think it would be good if RSSAC could produce a document that:
1. Provides a citeable history on how root nameservers were originally named and how they are named today, recording the reasons for the change;
2. Considers the risks and benefits of a new naming scheme that avoids the zone cut, including impact on root zone partners' processes, on operational issues like priming response sizes and backed-in assumptions elsewhere about root server names and on security issues relating to DNSSEC validation;
3. Considers the risks associated with any transition from the current naming scheme to a different one;
4. Makes recommendations as to whether a change from the current scheme should be made and, if the recommendation is to make a change, makes further recommendations that might frame the way a transition is planned and managed operationally. A recommendation that there be no change is an equally reasonable outcome; either way the document should include high-quality justification and reasoning.
All recommendations made would be actionable by ICANN (rather than recommendations actionable by the other two partners or anybody else with skin in the game), since that is the scope of our role. _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
Hi, I also support Joe's idea..., good topic to work with. Alejandro, El 5/21/2015 a las 10:47 PM, Declan Ma escribió:
Hi, Joe,
You just came up with an interesting topic.
This issue seems valuable to me, too.
I would like to work on this with you.
Declan Ma
ZDNS Ltd.
在 2015年5月20日,上午12:16,Joe Abley <jabley@hopcount.ca> 写道:
Hi all,
I have a suggestion for a new work item for RSSAC. If RSSAC thinks this work would be of value, and there are people willing to work on it, I'd be happy to (co-) lead a work party.
A rough sketch of a charter follows.
Comments would be most welcome!
Thanks,
Joe
Back in the dim mists of time, individual root servers had names chosen by the organisation that operated them. Some/all of these names are recorded for posterity in the canonical root hints file, e.g. A was originally NS.INTERNIC.NET, B was originally NS1.ISI.EDU, F was originally NS.ISC.ORG, etc.
ftp://rs.internic.net/domain/named.cache
The naming scheme was subsequently changed to <letter>.ROOT-SERVERS.NET, with the intent that the response to the priming query (using label compression for the ROOT-SERVERS.NET domain) would be smaller, and would allow an additional four root servers to be specified without causing the priming response to grow beyond the specified non-EDNS(0) message size limit using UDP transport. I have seen this cleverness attributed to Bill Manning in the past.
ROOT-SERVERS.NET was delegated from the NET zone to all root servers. The domain exists in the NET registry, defended by a platoon of registry locks, and the zone itself is (if I recall correctly) maintained and distributed by Verisign to root server operators as part of the root zone maintainer function, with changes following a similar process to that used for the root zone, including interactions between the three root zone partners.
In the opinions of some (but not all) people, the existence of the ROOT-SERVERS.NET zone is a historical mistake, and it would have been better to name the root servers in a way that avoided the necessity for a separate zone, e.g. bare single-label names (A, B, C, ...) or multi-label names with no delegation (A.ROOT-SERVERS, B.ROOT-SERVERS) provisioned directly in the root zone.
The presence of a label like ROOT-SERVERS might in effect constitute a reserved TLD label, with corresponding impact on ICANN policy for root zone management, the technical direction and remit of the IETF/IAB, and the intersection of the two. So, there are dragons^Wpolitical considerations, although I think RSSAC should constrain itself to technical commentary and leave any dragon baiting to others.
SAC53 has a thing or two to say about "dotless domains" like A, B, C, etc which could no doubt provide a useful citation. A client that sends a priming query with EDNS0.DO=1 (which, I gather, is how most priming queries are observed to arrive today) does not currently receive a response with signatures in the additional section of the response, because the ROOT-SERVERS.NET zone is not signed. The lack of signatures in the ROOT-SERVERS.NET zone is either a feature or a bug, depending on your perspective; if it was to be signed, the question of key management would arise. If signatures were present, there might be some operational impact caused by the increased size of the priming response.
Rather than the naming scheme for root servers remaining a collection of partially-remembered anecdotes plus occasional yet regular memes on mailing lists about what a mistake the current naming scheme was, I think it would be good if RSSAC could produce a document that:
1. Provides a citeable history on how root nameservers were originally named and how they are named today, recording the reasons for the change;
2. Considers the risks and benefits of a new naming scheme that avoids the zone cut, including impact on root zone partners' processes, on operational issues like priming response sizes and backed-in assumptions elsewhere about root server names and on security issues relating to DNSSEC validation;
3. Considers the risks associated with any transition from the current naming scheme to a different one;
4. Makes recommendations as to whether a change from the current scheme should be made and, if the recommendation is to make a change, makes further recommendations that might frame the way a transition is planned and managed operationally. A recommendation that there be no change is an equally reasonable outcome; either way the document should include high-quality justification and reasoning.
All recommendations made would be actionable by ICANN (rather than recommendations actionable by the other two partners or anybody else with skin in the game), since that is the scope of our role. _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
I would support the development of this as I think it would be important work for the community (documenting the why's and how's of how we got here is always a good thing for informing the way forward). On Fri, 22 May 2015, Alejandro Acosta wrote:
Hi, I also support Joe's idea..., good topic to work with.
Alejandro,
El 5/21/2015 a las 10:47 PM, Declan Ma escribi?:
Hi, Joe,
You just came up with an interesting topic.
This issue seems valuable to me, too.
I would like to work on this with you.
Declan Ma
ZDNS Ltd.
? 2015?5?20????12:16?Joe Abley <jabley@hopcount.ca> ???
Hi all,
I have a suggestion for a new work item for RSSAC. If RSSAC thinks this work would be of value, and there are people willing to work on it, I'd be happy to (co-) lead a work party.
A rough sketch of a charter follows.
Comments would be most welcome!
Thanks,
Joe
Back in the dim mists of time, individual root servers had names chosen by the organisation that operated them. Some/all of these names are recorded for posterity in the canonical root hints file, e.g. A was originally NS.INTERNIC.NET, B was originally NS1.ISI.EDU, F was originally NS.ISC.ORG, etc.
ftp://rs.internic.net/domain/named.cache
The naming scheme was subsequently changed to <letter>.ROOT-SERVERS.NET, with the intent that the response to the priming query (using label compression for the ROOT-SERVERS.NET domain) would be smaller, and would allow an additional four root servers to be specified without causing the priming response to grow beyond the specified non-EDNS(0) message size limit using UDP transport. I have seen this cleverness attributed to Bill Manning in the past.
ROOT-SERVERS.NET was delegated from the NET zone to all root servers. The domain exists in the NET registry, defended by a platoon of registry locks, and the zone itself is (if I recall correctly) maintained and distributed by Verisign to root server operators as part of the root zone maintainer function, with changes following a similar process to that used for the root zone, including interactions between the three root zone partners.
In the opinions of some (but not all) people, the existence of the ROOT-SERVERS.NET zone is a historical mistake, and it would have been better to name the root servers in a way that avoided the necessity for a separate zone, e.g. bare single-label names (A, B, C, ...) or multi-label names with no delegation (A.ROOT-SERVERS, B.ROOT-SERVERS) provisioned directly in the root zone.
The presence of a label like ROOT-SERVERS might in effect constitute a reserved TLD label, with corresponding impact on ICANN policy for root zone management, the technical direction and remit of the IETF/IAB, and the intersection of the two. So, there are dragons^Wpolitical considerations, although I think RSSAC should constrain itself to technical commentary and leave any dragon baiting to others.
SAC53 has a thing or two to say about "dotless domains" like A, B, C, etc which could no doubt provide a useful citation. A client that sends a priming query with EDNS0.DO=1 (which, I gather, is how most priming queries are observed to arrive today) does not currently receive a response with signatures in the additional section of the response, because the ROOT-SERVERS.NET zone is not signed. The lack of signatures in the ROOT-SERVERS.NET zone is either a feature or a bug, depending on your perspective; if it was to be signed, the question of key management would arise. If signatures were present, there might be some operational impact caused by the increased size of the priming response.
Rather than the naming scheme for root servers remaining a collection of partially-remembered anecdotes plus occasional yet regular memes on mailing lists about what a mistake the current naming scheme was, I think it would be good if RSSAC could produce a document that:
1. Provides a citeable history on how root nameservers were originally named and how they are named today, recording the reasons for the change;
2. Considers the risks and benefits of a new naming scheme that avoids the zone cut, including impact on root zone partners' processes, on operational issues like priming response sizes and backed-in assumptions elsewhere about root server names and on security issues relating to DNSSEC validation;
3. Considers the risks associated with any transition from the current naming scheme to a different one;
4. Makes recommendations as to whether a change from the current scheme should be made and, if the recommendation is to make a change, makes further recommendations that might frame the way a transition is planned and managed operationally. A recommendation that there be no change is an equally reasonable outcome; either way the document should include high-quality justification and reasoning.
All recommendations made would be actionable by ICANN (rather than recommendations actionable by the other two partners or anybody else with skin in the game), since that is the scope of our role. _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
Dear Joe I think this work do make sense and should be fun I'd like to join the team if the work party formed. Regards Wesley WANG, ZDNS -----邮件原件----- 发件人: rssac-caucus-bounces@icann.org [mailto:rssac-caucus-bounces@icann.org] 代表 Joe Abley 发送时间: 2015年5月20日 0:16 收件人: rssac-caucus@icann.org 主题: [rssac-caucus] possible new work item Hi all, I have a suggestion for a new work item for RSSAC. If RSSAC thinks this work would be of value, and there are people willing to work on it, I'd be happy to (co-) lead a work party. A rough sketch of a charter follows. Comments would be most welcome! Thanks, Joe Back in the dim mists of time, individual root servers had names chosen by the organisation that operated them. Some/all of these names are recorded for posterity in the canonical root hints file, e.g. A was originally NS.INTERNIC.NET, B was originally NS1.ISI.EDU, F was originally NS.ISC.ORG, etc. ftp://rs.internic.net/domain/named.cache The naming scheme was subsequently changed to <letter>.ROOT-SERVERS.NET, with the intent that the response to the priming query (using label compression for the ROOT-SERVERS.NET domain) would be smaller, and would allow an additional four root servers to be specified without causing the priming response to grow beyond the specified non-EDNS(0) message size limit using UDP transport. I have seen this cleverness attributed to Bill Manning in the past. ROOT-SERVERS.NET was delegated from the NET zone to all root servers. The domain exists in the NET registry, defended by a platoon of registry locks, and the zone itself is (if I recall correctly) maintained and distributed by Verisign to root server operators as part of the root zone maintainer function, with changes following a similar process to that used for the root zone, including interactions between the three root zone partners. In the opinions of some (but not all) people, the existence of the ROOT-SERVERS.NET zone is a historical mistake, and it would have been better to name the root servers in a way that avoided the necessity for a separate zone, e.g. bare single-label names (A, B, C, ...) or multi-label names with no delegation (A.ROOT-SERVERS, B.ROOT-SERVERS) provisioned directly in the root zone. The presence of a label like ROOT-SERVERS might in effect constitute a reserved TLD label, with corresponding impact on ICANN policy for root zone management, the technical direction and remit of the IETF/IAB, and the intersection of the two. So, there are dragons^Wpolitical considerations, although I think RSSAC should constrain itself to technical commentary and leave any dragon baiting to others. SAC53 has a thing or two to say about "dotless domains" like A, B, C, etc which could no doubt provide a useful citation. A client that sends a priming query with EDNS0.DO=1 (which, I gather, is how most priming queries are observed to arrive today) does not currently receive a response with signatures in the additional section of the response, because the ROOT-SERVERS.NET zone is not signed. The lack of signatures in the ROOT-SERVERS.NET zone is either a feature or a bug, depending on your perspective; if it was to be signed, the question of key management would arise. If signatures were present, there might be some operational impact caused by the increased size of the priming response. Rather than the naming scheme for root servers remaining a collection of partially-remembered anecdotes plus occasional yet regular memes on mailing lists about what a mistake the current naming scheme was, I think it would be good if RSSAC could produce a document that: 1. Provides a citeable history on how root nameservers were originally named and how they are named today, recording the reasons for the change; 2. Considers the risks and benefits of a new naming scheme that avoids the zone cut, including impact on root zone partners' processes, on operational issues like priming response sizes and backed-in assumptions elsewhere about root server names and on security issues relating to DNSSEC validation; 3. Considers the risks associated with any transition from the current naming scheme to a different one; 4. Makes recommendations as to whether a change from the current scheme should be made and, if the recommendation is to make a change, makes further recommendations that might frame the way a transition is planned and managed operationally. A recommendation that there be no change is an equally reasonable outcome; either way the document should include high-quality justification and reasoning. All recommendations made would be actionable by ICANN (rather than recommendations actionable by the other two partners or anybody else with skin in the game), since that is the scope of our role. _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
Hi Joe, it's an interesting work item. Similarly,you may notice Paul, Kato and I initiate Yeti DNS project (http://yeti-dns.org/) which is dedicated to the scientific and study on Root system. I think it is good place to do some experiment and study on your proposed Item in Yeti testbed. Personally, I'm happy to join and discuss how to create the work party. Cheers, Davey On Wed, May 20, 2015 at 12:16 AM, Joe Abley <jabley@hopcount.ca> wrote:
Hi all,
I have a suggestion for a new work item for RSSAC. If RSSAC thinks this work would be of value, and there are people willing to work on it, I'd be happy to (co-) lead a work party.
A rough sketch of a charter follows.
Comments would be most welcome!
Thanks,
Joe
Back in the dim mists of time, individual root servers had names chosen by the organisation that operated them. Some/all of these names are recorded for posterity in the canonical root hints file, e.g. A was originally NS.INTERNIC.NET, B was originally NS1.ISI.EDU, F was originally NS.ISC.ORG, etc.
ftp://rs.internic.net/domain/named.cache
The naming scheme was subsequently changed to <letter>.ROOT-SERVERS.NET, with the intent that the response to the priming query (using label compression for the ROOT-SERVERS.NET domain) would be smaller, and would allow an additional four root servers to be specified without causing the priming response to grow beyond the specified non-EDNS(0) message size limit using UDP transport. I have seen this cleverness attributed to Bill Manning in the past.
ROOT-SERVERS.NET was delegated from the NET zone to all root servers. The domain exists in the NET registry, defended by a platoon of registry locks, and the zone itself is (if I recall correctly) maintained and distributed by Verisign to root server operators as part of the root zone maintainer function, with changes following a similar process to that used for the root zone, including interactions between the three root zone partners.
In the opinions of some (but not all) people, the existence of the ROOT-SERVERS.NET zone is a historical mistake, and it would have been better to name the root servers in a way that avoided the necessity for a separate zone, e.g. bare single-label names (A, B, C, ...) or multi-label names with no delegation (A.ROOT-SERVERS, B.ROOT-SERVERS) provisioned directly in the root zone.
The presence of a label like ROOT-SERVERS might in effect constitute a reserved TLD label, with corresponding impact on ICANN policy for root zone management, the technical direction and remit of the IETF/IAB, and the intersection of the two. So, there are dragons^Wpolitical considerations, although I think RSSAC should constrain itself to technical commentary and leave any dragon baiting to others.
SAC53 has a thing or two to say about "dotless domains" like A, B, C, etc which could no doubt provide a useful citation. A client that sends a priming query with EDNS0.DO=1 (which, I gather, is how most priming queries are observed to arrive today) does not currently receive a response with signatures in the additional section of the response, because the ROOT-SERVERS.NET zone is not signed. The lack of signatures in the ROOT-SERVERS.NET zone is either a feature or a bug, depending on your perspective; if it was to be signed, the question of key management would arise. If signatures were present, there might be some operational impact caused by the increased size of the priming response.
Rather than the naming scheme for root servers remaining a collection of partially-remembered anecdotes plus occasional yet regular memes on mailing lists about what a mistake the current naming scheme was, I think it would be good if RSSAC could produce a document that:
1. Provides a citeable history on how root nameservers were originally named and how they are named today, recording the reasons for the change;
2. Considers the risks and benefits of a new naming scheme that avoids the zone cut, including impact on root zone partners' processes, on operational issues like priming response sizes and backed-in assumptions elsewhere about root server names and on security issues relating to DNSSEC validation;
3. Considers the risks associated with any transition from the current naming scheme to a different one;
4. Makes recommendations as to whether a change from the current scheme should be made and, if the recommendation is to make a change, makes further recommendations that might frame the way a transition is planned and managed operationally. A recommendation that there be no change is an equally reasonable outcome; either way the document should include high-quality justification and reasoning.
All recommendations made would be actionable by ICANN (rather than recommendations actionable by the other two partners or anybody else with skin in the game), since that is the scope of our role. _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
tl;dr: Yes, I like it, and volunteer to participate. Brian On Tue, May 19, 2015 at 9:16 AM, Joe Abley <jabley@hopcount.ca> wrote:
Hi all,
I have a suggestion for a new work item for RSSAC. If RSSAC thinks this work would be of value, and there are people willing to work on it, I'd be happy to (co-) lead a work party.
A rough sketch of a charter follows.
Comments would be most welcome!
Thanks,
Joe
Back in the dim mists of time, individual root servers had names chosen by the organisation that operated them. Some/all of these names are recorded for posterity in the canonical root hints file, e.g. A was originally NS.INTERNIC.NET, B was originally NS1.ISI.EDU, F was originally NS.ISC.ORG, etc.
ftp://rs.internic.net/domain/named.cache
The naming scheme was subsequently changed to <letter>.ROOT-SERVERS.NET, with the intent that the response to the priming query (using label compression for the ROOT-SERVERS.NET domain) would be smaller, and would allow an additional four root servers to be specified without causing the priming response to grow beyond the specified non-EDNS(0) message size limit using UDP transport. I have seen this cleverness attributed to Bill Manning in the past.
ROOT-SERVERS.NET was delegated from the NET zone to all root servers. The domain exists in the NET registry, defended by a platoon of registry locks, and the zone itself is (if I recall correctly) maintained and distributed by Verisign to root server operators as part of the root zone maintainer function, with changes following a similar process to that used for the root zone, including interactions between the three root zone partners.
In the opinions of some (but not all) people, the existence of the ROOT-SERVERS.NET zone is a historical mistake, and it would have been better to name the root servers in a way that avoided the necessity for a separate zone, e.g. bare single-label names (A, B, C, ...) or multi-label names with no delegation (A.ROOT-SERVERS, B.ROOT-SERVERS) provisioned directly in the root zone.
The presence of a label like ROOT-SERVERS might in effect constitute a reserved TLD label, with corresponding impact on ICANN policy for root zone management, the technical direction and remit of the IETF/IAB, and the intersection of the two. So, there are dragons^Wpolitical considerations, although I think RSSAC should constrain itself to technical commentary and leave any dragon baiting to others.
SAC53 has a thing or two to say about "dotless domains" like A, B, C, etc which could no doubt provide a useful citation. A client that sends a priming query with EDNS0.DO=1 (which, I gather, is how most priming queries are observed to arrive today) does not currently receive a response with signatures in the additional section of the response, because the ROOT-SERVERS.NET zone is not signed. The lack of signatures in the ROOT-SERVERS.NET zone is either a feature or a bug, depending on your perspective; if it was to be signed, the question of key management would arise. If signatures were present, there might be some operational impact caused by the increased size of the priming response.
Rather than the naming scheme for root servers remaining a collection of partially-remembered anecdotes plus occasional yet regular memes on mailing lists about what a mistake the current naming scheme was, I think it would be good if RSSAC could produce a document that:
1. Provides a citeable history on how root nameservers were originally named and how they are named today, recording the reasons for the change;
2. Considers the risks and benefits of a new naming scheme that avoids the zone cut, including impact on root zone partners' processes, on operational issues like priming response sizes and backed-in assumptions elsewhere about root server names and on security issues relating to DNSSEC validation;
3. Considers the risks associated with any transition from the current naming scheme to a different one;
4. Makes recommendations as to whether a change from the current scheme should be made and, if the recommendation is to make a change, makes further recommendations that might frame the way a transition is planned and managed operationally. A recommendation that there be no change is an equally reasonable outcome; either way the document should include high-quality justification and reasoning.
All recommendations made would be actionable by ICANN (rather than recommendations actionable by the other two partners or anybody else with skin in the game), since that is the scope of our role. _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
I am also interested in contributing to this work. BR, Daniel On Tue, May 19, 2015 at 12:16 PM, Joe Abley <jabley@hopcount.ca> wrote:
Hi all,
I have a suggestion for a new work item for RSSAC. If RSSAC thinks this work would be of value, and there are people willing to work on it, I'd be happy to (co-) lead a work party.
A rough sketch of a charter follows.
Comments would be most welcome!
Thanks,
Joe
Back in the dim mists of time, individual root servers had names chosen by the organisation that operated them. Some/all of these names are recorded for posterity in the canonical root hints file, e.g. A was originally NS.INTERNIC.NET, B was originally NS1.ISI.EDU, F was originally NS.ISC.ORG, etc.
ftp://rs.internic.net/domain/named.cache
The naming scheme was subsequently changed to <letter>.ROOT-SERVERS.NET, with the intent that the response to the priming query (using label compression for the ROOT-SERVERS.NET domain) would be smaller, and would allow an additional four root servers to be specified without causing the priming response to grow beyond the specified non-EDNS(0) message size limit using UDP transport. I have seen this cleverness attributed to Bill Manning in the past.
ROOT-SERVERS.NET was delegated from the NET zone to all root servers. The domain exists in the NET registry, defended by a platoon of registry locks, and the zone itself is (if I recall correctly) maintained and distributed by Verisign to root server operators as part of the root zone maintainer function, with changes following a similar process to that used for the root zone, including interactions between the three root zone partners.
In the opinions of some (but not all) people, the existence of the ROOT-SERVERS.NET zone is a historical mistake, and it would have been better to name the root servers in a way that avoided the necessity for a separate zone, e.g. bare single-label names (A, B, C, ...) or multi-label names with no delegation (A.ROOT-SERVERS, B.ROOT-SERVERS) provisioned directly in the root zone.
The presence of a label like ROOT-SERVERS might in effect constitute a reserved TLD label, with corresponding impact on ICANN policy for root zone management, the technical direction and remit of the IETF/IAB, and the intersection of the two. So, there are dragons^Wpolitical considerations, although I think RSSAC should constrain itself to technical commentary and leave any dragon baiting to others.
SAC53 has a thing or two to say about "dotless domains" like A, B, C, etc which could no doubt provide a useful citation. A client that sends a priming query with EDNS0.DO=1 (which, I gather, is how most priming queries are observed to arrive today) does not currently receive a response with signatures in the additional section of the response, because the ROOT-SERVERS.NET zone is not signed. The lack of signatures in the ROOT-SERVERS.NET zone is either a feature or a bug, depending on your perspective; if it was to be signed, the question of key management would arise. If signatures were present, there might be some operational impact caused by the increased size of the priming response.
Rather than the naming scheme for root servers remaining a collection of partially-remembered anecdotes plus occasional yet regular memes on mailing lists about what a mistake the current naming scheme was, I think it would be good if RSSAC could produce a document that:
1. Provides a citeable history on how root nameservers were originally named and how they are named today, recording the reasons for the change;
2. Considers the risks and benefits of a new naming scheme that avoids the zone cut, including impact on root zone partners' processes, on operational issues like priming response sizes and backed-in assumptions elsewhere about root server names and on security issues relating to DNSSEC validation;
3. Considers the risks associated with any transition from the current naming scheme to a different one;
4. Makes recommendations as to whether a change from the current scheme should be made and, if the recommendation is to make a change, makes further recommendations that might frame the way a transition is planned and managed operationally. A recommendation that there be no change is an equally reasonable outcome; either way the document should include high-quality justification and reasoning.
All recommendations made would be actionable by ICANN (rather than recommendations actionable by the other two partners or anybody else with skin in the game), since that is the scope of our role. _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
-- Daniel Migault Ericsson 8400 boulevard Decarie Montreal, QC H4P 2N2 Canada Phone: +1 514-452-2160
On 19/05/2015 17:16, "Joe Abley" <jabley@hopcount.ca> wrote:
Hi all,
I have a suggestion for a new work item for RSSAC. If RSSAC thinks this work would be of value, and there are people willing to work on it, I'd be happy to (co-) lead a work party.
A rough sketch of a charter follows.
Comments would be most welcome! Late to the party but i also think this is worth while and would be happy to help
i'll be happy to review work that talks about renaming root name server names to be in-zone data for the root zone. my preference (as stated in hong kong last december) is to strip off the .NET on the names we have, thus creating an effective TLD (without its own delegation point) "ROOT-SERVERS." i can join one call to explain why i hold that view.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015-05-28 02:16, Paul Vixie wrote:
i'll be happy to review work that talks about renaming root name server names to be in-zone data for the root zone. my preference (as stated in hong kong last december) is to strip off the .NET on the names we have, thus creating an effective TLD (without its own delegation point) "ROOT-SERVERS." i can join one call to explain why i hold that view.
I absolutely agree that's the correct way forward (in-zone and signed). As for the name of the sub-domain, I don't really care. I'd be happy to work with everyone else, either as a full-on group member or as a "consultant" like Paul offers himself. - -- Robert Martin-Legene Internet Infrastructure Specialist Packet Clearing House -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJVdZRYAAoJEM82zYyXDYSw8coQALY//8GbeZandQsB0K5NGsPT E2rx2q8wnqI90UPhku60ZEO+5Pg7o9n43kQ6kfgDks5dZ3BO5YaaWMFSbh3CxjnC O7hwAlYkJ7zgrELIpUosDcchTt0ukY+5Sx+cEfKqY8GNOF4Ok/v6+/oDtVIW16hL qxziqrWu3xpVCqJSr9Cr312Cs1Cu/oYfc89hQw5H15WVgR6/Pl/2LpnclxpSpNnD 1en+OkiQeR73WVEBQGeHOSSwpcPpIldcGBkutG8CVcgpcHMY0ALInKhHhMxwRv1n pZtL2SrEr2tzP/rT8p3Wf9UMbSD6XRyM39h+w/M3tz28IqmQWbvzKSp6viU4ihcX aue82UPi/uSkix0hyMOEeJCi2cxxYy7sb1E/Ecanau/tnLEpxnB/Ehxf+QarJ61G zs/EMxACij2P2xKI+vJ7vfWWPIjqMDvfbX6MuVJX4PEVsVEW6mY/Nn0ogfm+Y4Y+ Q/tyr+8iTco7peifDGMLqXfz0+MhK6LirLY3iAXQX+zi2NUElHseGDT7nkCFFIRE SgegH9kq8zWMOo9a9sxFDqH4tHr62uMUWLPH7e1v44NUL3qmlZsko9ZXzNp83MKZ TVKUClsf5yAmIeP8AR4Gw434b1Vq+BQWNhPxGNC+2TldBzvVFIM3iZYlHQYbGIFt AubEtZjqwjXe3TgYEIh9 =R1H9 -----END PGP SIGNATURE-----
Dear Joe, Thank you for putting forth this possible new work item. Sounds very intriguing and has generated interest. This will be a discussion item at an upcoming RSSAC meeting. We will be in touch after the RSSAC weighs in on this. Thank you again. Regards, - Tripti, RSSAC Co-Chair -----Original Message----- From: rssac-caucus-bounces@icann.org [mailto:rssac-caucus-bounces@icann.org] On Behalf Of Joe Abley Sent: Tuesday, May 19, 2015 12:16 PM To: rssac-caucus@icann.org Subject: [rssac-caucus] possible new work item Hi all, I have a suggestion for a new work item for RSSAC. If RSSAC thinks this work would be of value, and there are people willing to work on it, I'd be happy to (co-) lead a work party. A rough sketch of a charter follows. Comments would be most welcome! Thanks, Joe Back in the dim mists of time, individual root servers had names chosen by the organisation that operated them. Some/all of these names are recorded for posterity in the canonical root hints file, e.g. A was originally NS.INTERNIC.NET, B was originally NS1.ISI.EDU, F was originally NS.ISC.ORG, etc. ftp://rs.internic.net/domain/named.cache The naming scheme was subsequently changed to <letter>.ROOT-SERVERS.NET, with the intent that the response to the priming query (using label compression for the ROOT-SERVERS.NET domain) would be smaller, and would allow an additional four root servers to be specified without causing the priming response to grow beyond the specified non-EDNS(0) message size limit using UDP transport. I have seen this cleverness attributed to Bill Manning in the past. ROOT-SERVERS.NET was delegated from the NET zone to all root servers. The domain exists in the NET registry, defended by a platoon of registry locks, and the zone itself is (if I recall correctly) maintained and distributed by Verisign to root server operators as part of the root zone maintainer function, with changes following a similar process to that used for the root zone, including interactions between the three root zone partners. In the opinions of some (but not all) people, the existence of the ROOT-SERVERS.NET zone is a historical mistake, and it would have been better to name the root servers in a way that avoided the necessity for a separate zone, e.g. bare single-label names (A, B, C, ...) or multi-label names with no delegation (A.ROOT-SERVERS, B.ROOT-SERVERS) provisioned directly in the root zone. The presence of a label like ROOT-SERVERS might in effect constitute a reserved TLD label, with corresponding impact on ICANN policy for root zone management, the technical direction and remit of the IETF/IAB, and the intersection of the two. So, there are dragons^Wpolitical considerations, although I think RSSAC should constrain itself to technical commentary and leave any dragon baiting to others. SAC53 has a thing or two to say about "dotless domains" like A, B, C, etc which could no doubt provide a useful citation. A client that sends a priming query with EDNS0.DO=1 (which, I gather, is how most priming queries are observed to arrive today) does not currently receive a response with signatures in the additional section of the response, because the ROOT-SERVERS.NET zone is not signed. The lack of signatures in the ROOT-SERVERS.NET zone is either a feature or a bug, depending on your perspective; if it was to be signed, the question of key management would arise. If signatures were present, there might be some operational impact caused by the increased size of the priming response. Rather than the naming scheme for root servers remaining a collection of partially-remembered anecdotes plus occasional yet regular memes on mailing lists about what a mistake the current naming scheme was, I think it would be good if RSSAC could produce a document that: 1. Provides a citeable history on how root nameservers were originally named and how they are named today, recording the reasons for the change; 2. Considers the risks and benefits of a new naming scheme that avoids the zone cut, including impact on root zone partners' processes, on operational issues like priming response sizes and backed-in assumptions elsewhere about root server names and on security issues relating to DNSSEC validation; 3. Considers the risks associated with any transition from the current naming scheme to a different one; 4. Makes recommendations as to whether a change from the current scheme should be made and, if the recommendation is to make a change, makes further recommendations that might frame the way a transition is planned and managed operationally. A recommendation that there be no change is an equally reasonable outcome; either way the document should include high-quality justification and reasoning. All recommendations made would be actionable by ICANN (rather than recommendations actionable by the other two partners or anybody else with skin in the game), since that is the scope of our role. _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
On May 28, 2015, at 19:28, Tripti Sinha <tsinha@umd.edu> wrote:
Thank you for putting forth this possible new work item. Sounds very intriguing and has generated interest. This will be a discussion item at an upcoming RSSAC meeting. We will be in touch after the RSSAC weighs in on this.
Thanks, Tripti! Joe
Joe, Fine idea there! Count me in as part of the work party, should it be formed (and I hope it does!) - Jim
On May 19, 2015, at 12:16 PM, Joe Abley <jabley@hopcount.ca> wrote:
Hi all,
I have a suggestion for a new work item for RSSAC. If RSSAC thinks this work would be of value, and there are people willing to work on it, I'd be happy to (co-) lead a work party.
A rough sketch of a charter follows.
Comments would be most welcome!
Thanks,
Joe
Back in the dim mists of time, individual root servers had names chosen by the organisation that operated them. Some/all of these names are recorded for posterity in the canonical root hints file, e.g. A was originally NS.INTERNIC.NET, B was originally NS1.ISI.EDU, F was originally NS.ISC.ORG, etc.
ftp://rs.internic.net/domain/named.cache
The naming scheme was subsequently changed to <letter>.ROOT-SERVERS.NET, with the intent that the response to the priming query (using label compression for the ROOT-SERVERS.NET domain) would be smaller, and would allow an additional four root servers to be specified without causing the priming response to grow beyond the specified non-EDNS(0) message size limit using UDP transport. I have seen this cleverness attributed to Bill Manning in the past.
ROOT-SERVERS.NET was delegated from the NET zone to all root servers. The domain exists in the NET registry, defended by a platoon of registry locks, and the zone itself is (if I recall correctly) maintained and distributed by Verisign to root server operators as part of the root zone maintainer function, with changes following a similar process to that used for the root zone, including interactions between the three root zone partners.
In the opinions of some (but not all) people, the existence of the ROOT-SERVERS.NET zone is a historical mistake, and it would have been better to name the root servers in a way that avoided the necessity for a separate zone, e.g. bare single-label names (A, B, C, ...) or multi-label names with no delegation (A.ROOT-SERVERS, B.ROOT-SERVERS) provisioned directly in the root zone.
The presence of a label like ROOT-SERVERS might in effect constitute a reserved TLD label, with corresponding impact on ICANN policy for root zone management, the technical direction and remit of the IETF/IAB, and the intersection of the two. So, there are dragons^Wpolitical considerations, although I think RSSAC should constrain itself to technical commentary and leave any dragon baiting to others.
SAC53 has a thing or two to say about "dotless domains" like A, B, C, etc which could no doubt provide a useful citation. A client that sends a priming query with EDNS0.DO=1 (which, I gather, is how most priming queries are observed to arrive today) does not currently receive a response with signatures in the additional section of the response, because the ROOT-SERVERS.NET zone is not signed. The lack of signatures in the ROOT-SERVERS.NET zone is either a feature or a bug, depending on your perspective; if it was to be signed, the question of key management would arise. If signatures were present, there might be some operational impact caused by the increased size of the priming response.
Rather than the naming scheme for root servers remaining a collection of partially-remembered anecdotes plus occasional yet regular memes on mailing lists about what a mistake the current naming scheme was, I think it would be good if RSSAC could produce a document that:
1. Provides a citeable history on how root nameservers were originally named and how they are named today, recording the reasons for the change;
2. Considers the risks and benefits of a new naming scheme that avoids the zone cut, including impact on root zone partners' processes, on operational issues like priming response sizes and backed-in assumptions elsewhere about root server names and on security issues relating to DNSSEC validation;
3. Considers the risks associated with any transition from the current naming scheme to a different one;
4. Makes recommendations as to whether a change from the current scheme should be made and, if the recommendation is to make a change, makes further recommendations that might frame the way a transition is planned and managed operationally. A recommendation that there be no change is an equally reasonable outcome; either way the document should include high-quality justification and reasoning.
All recommendations made would be actionable by ICANN (rather than recommendations actionable by the other two partners or anybody else with skin in the game), since that is the scope of our role. _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
I like the idea. My technical knowledge is far away from the people that has already raise their hands to help, so I do not think that I could add any real value to the document. However count on me to review it and make suggestions. Regards as On Thu, 28 May 2015 at 15:07 Jim Martin <jrmii@isc.org> wrote:
Joe, Fine idea there! Count me in as part of the work party, should it be formed (and I hope it does!)
- Jim
On May 19, 2015, at 12:16 PM, Joe Abley <jabley@hopcount.ca> wrote:
Hi all,
I have a suggestion for a new work item for RSSAC. If RSSAC thinks this work would be of value, and there are people willing to work on it, I'd be happy to (co-) lead a work party.
A rough sketch of a charter follows.
Comments would be most welcome!
Thanks,
Joe
Back in the dim mists of time, individual root servers had names chosen by the organisation that operated them. Some/all of these names are recorded for posterity in the canonical root hints file, e.g. A was originally NS.INTERNIC.NET, B was originally NS1.ISI.EDU, F was originally NS.ISC.ORG, etc.
ftp://rs.internic.net/domain/named.cache
The naming scheme was subsequently changed to <letter>.ROOT-SERVERS.NET, with the intent that the response to the priming query (using label compression for the ROOT-SERVERS.NET domain) would be smaller, and would allow an additional four root servers to be specified without causing the priming response to grow beyond the specified non-EDNS(0) message size limit using UDP transport. I have seen this cleverness attributed to Bill Manning in the past.
ROOT-SERVERS.NET was delegated from the NET zone to all root servers. The domain exists in the NET registry, defended by a platoon of registry locks, and the zone itself is (if I recall correctly) maintained and distributed by Verisign to root server operators as part of the root zone maintainer function, with changes following a similar process to that used for the root zone, including interactions between the three root zone partners.
In the opinions of some (but not all) people, the existence of the ROOT-SERVERS.NET zone is a historical mistake, and it would have been better to name the root servers in a way that avoided the necessity for a separate zone, e.g. bare single-label names (A, B, C, ...) or multi-label names with no delegation (A.ROOT-SERVERS, B.ROOT-SERVERS) provisioned directly in the root zone.
The presence of a label like ROOT-SERVERS might in effect constitute a reserved TLD label, with corresponding impact on ICANN policy for root zone management, the technical direction and remit of the IETF/IAB, and the intersection of the two. So, there are dragons^Wpolitical considerations, although I think RSSAC should constrain itself to technical commentary and leave any dragon baiting to others.
SAC53 has a thing or two to say about "dotless domains" like A, B, C, etc which could no doubt provide a useful citation. A client that sends a priming query with EDNS0.DO=1 (which, I gather, is how most priming queries are observed to arrive today) does not currently receive a response with signatures in the additional section of the response, because the ROOT-SERVERS.NET zone is not signed. The lack of signatures in the ROOT-SERVERS.NET zone is either a feature or a bug, depending on your perspective; if it was to be signed, the question of key management would arise. If signatures were present, there might be some operational impact caused by the increased size of the priming response.
Rather than the naming scheme for root servers remaining a collection of partially-remembered anecdotes plus occasional yet regular memes on mailing lists about what a mistake the current naming scheme was, I think it would be good if RSSAC could produce a document that:
1. Provides a citeable history on how root nameservers were originally named and how they are named today, recording the reasons for the change;
2. Considers the risks and benefits of a new naming scheme that avoids the zone cut, including impact on root zone partners' processes, on operational issues like priming response sizes and backed-in assumptions elsewhere about root server names and on security issues relating to DNSSEC validation;
3. Considers the risks associated with any transition from the current naming scheme to a different one;
4. Makes recommendations as to whether a change from the current scheme should be made and, if the recommendation is to make a change, makes further recommendations that might frame the way a transition is planned and managed operationally. A recommendation that there be no change is an equally reasonable outcome; either way the document should include high-quality justification and reasoning.
All recommendations made would be actionable by ICANN (rather than recommendations actionable by the other two partners or anybody else with skin in the game), since that is the scope of our role. _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
Hi Joe-san, The work item sounds interesting. I'd like to join the work party as well. Sorry for coming late. Shinta Sato <shinta@jprs.co.jp> Japan Registry Services Co., Ltd. On Tue, 19 May 2015 12:16:23 -0400 "Joe Abley" <jabley@hopcount.ca> wrote:
Hi all,
I have a suggestion for a new work item for RSSAC. If RSSAC thinks this work would be of value, and there are people willing to work on it, I'd be happy to (co-) lead a work party.
A rough sketch of a charter follows.
Comments would be most welcome!
Thanks,
Joe
Back in the dim mists of time, individual root servers had names chosen by the organisation that operated them. Some/all of these names are recorded for posterity in the canonical root hints file, e.g. A was originally NS.INTERNIC.NET, B was originally NS1.ISI.EDU, F was originally NS.ISC.ORG, etc.
ftp://rs.internic.net/domain/named.cache
The naming scheme was subsequently changed to <letter>.ROOT-SERVERS.NET, with the intent that the response to the priming query (using label compression for the ROOT-SERVERS.NET domain) would be smaller, and would allow an additional four root servers to be specified without causing the priming response to grow beyond the specified non-EDNS(0) message size limit using UDP transport. I have seen this cleverness attributed to Bill Manning in the past.
ROOT-SERVERS.NET was delegated from the NET zone to all root servers. The domain exists in the NET registry, defended by a platoon of registry locks, and the zone itself is (if I recall correctly) maintained and distributed by Verisign to root server operators as part of the root zone maintainer function, with changes following a similar process to that used for the root zone, including interactions between the three root zone partners.
In the opinions of some (but not all) people, the existence of the ROOT-SERVERS.NET zone is a historical mistake, and it would have been better to name the root servers in a way that avoided the necessity for a separate zone, e.g. bare single-label names (A, B, C, ...) or multi-label names with no delegation (A.ROOT-SERVERS, B.ROOT-SERVERS) provisioned directly in the root zone.
The presence of a label like ROOT-SERVERS might in effect constitute a reserved TLD label, with corresponding impact on ICANN policy for root zone management, the technical direction and remit of the IETF/IAB, and the intersection of the two. So, there are dragons^Wpolitical considerations, although I think RSSAC should constrain itself to technical commentary and leave any dragon baiting to others.
SAC53 has a thing or two to say about "dotless domains" like A, B, C, etc which could no doubt provide a useful citation. A client that sends a priming query with EDNS0.DO=1 (which, I gather, is how most priming queries are observed to arrive today) does not currently receive a response with signatures in the additional section of the response, because the ROOT-SERVERS.NET zone is not signed. The lack of signatures in the ROOT-SERVERS.NET zone is either a feature or a bug, depending on your perspective; if it was to be signed, the question of key management would arise. If signatures were present, there might be some operational impact caused by the increased size of the priming response.
Rather than the naming scheme for root servers remaining a collection of partially-remembered anecdotes plus occasional yet regular memes on mailing lists about what a mistake the current naming scheme was, I think it would be good if RSSAC could produce a document that:
1. Provides a citeable history on how root nameservers were originally named and how they are named today, recording the reasons for the change;
2. Considers the risks and benefits of a new naming scheme that avoids the zone cut, including impact on root zone partners' processes, on operational issues like priming response sizes and backed-in assumptions elsewhere about root server names and on security issues relating to DNSSEC validation;
3. Considers the risks associated with any transition from the current naming scheme to a different one;
4. Makes recommendations as to whether a change from the current scheme should be made and, if the recommendation is to make a change, makes further recommendations that might frame the way a transition is planned and managed operationally. A recommendation that there be no change is an equally reasonable outcome; either way the document should include high-quality justification and reasoning.
All recommendations made would be actionable by ICANN (rather than recommendations actionable by the other two partners or anybody else with skin in the game), since that is the scope of our role. _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
participants (17)
-
Alejandro Acosta -
Arturo Servin -
Brian Dickson -
Daniel Migault -
Davey Song -
Declan Ma -
Jim Martin -
Joe Abley -
John Bond -
manning -
Paul Vixie -
Robert Martin-Legene -
Shinta Sato -
Tripti Sinha -
Warren Kumari -
wfms@ottix.net -
王伟