IDN Deployment Test国际化域名测试计划表

青年近卫军

IDN Deployment Test
Test Setup
Lars-Johan Liman
Autonomica AB
Contents
1 Background 2
2 System Setup 2
2.1 Root Name Servers ?root . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Top Level Domain Name Server ?TLD . . . . . . . . . . . . . . 4
2.3 Iterative Mode Resolver ?IMR . . . . . . . . . . . . . . . . . . . 4
3 The Test Procedure 5
3.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4 Report 6
A IDN test strings 7
$Id: idn-setup.tex,v 1.4 2006/11/21 15:36:38 liman Exp $
1 Background
ICANN is responsible for the management of the name space in the highest level
of the domain name system. ICANN wants to deploy a new type of top level
domains in the public DNS system ?domain names that contain encoded versions
of names expressed with other characters than those in the English alphabet, so
called 攊nternationalized domain names?(IDNs).
ICANN has requested that two external parties test what the technical impact,
on the DNS client side, of deploying such IDNs as top level domains in the public
root would be. The tests are to be carried out in a closed lab environment, and expected
to cover various implementations of server and client software, to a degree
that makes ICANN comfortable when making the decision whether to add these
IDN TLDs to the public DNS or not.
Autonomica has been contracted to undertake such testing, and this is a description
of the system that will be used for these tests.
2 System Setup
The tests will be carried out in Autonomica抯 test facilities in Stockholm. The test
system will consist of the following blocks
1. Two root name servers (root).
2. Top level domain authoritative server (TLD).
3. iterative mode resolver (IMR).
4. Query generator (client).
5. Connecting network.
Only the qualitative performance of the root name servers and the iterative
mode resolvers will be evaluated in this test, according to the demarcations in the
contract.
2.1 Root Name Servers ?root
The root name servers will run on a Unix platform. Two major DNS server implentations
will be tested, known to be used by root server operators. They are
2
ROOT
1
ROOT
2 TLD
FSR FSR FSR FSR FSR FSR
CLIENT
= Services evaluated in the test
Figure 1: Service topology for the test
3
1. ISC BIND
2. NLNet Labs nsd
The reason for testing only these two, and only recent versions, is that the
root name servers are few and operated by groups that have DNS as their main
focus. Upgrading the root name servers to capable code is less overwhelming
than upgrading the iterative mode resolvers. We will try to mimick the existing
root name servers to the best of our abilities. Two servers will be operated to
ensure that the IMR software doesn抰 have problems based on the fact that only a
single server is reachable.
The root servers will contain a copy of the active root zone on the Internet,
augmented with the IDN test domains supplied by ICANN, see Appendix A.
2.2 Top Level Domain Name Server ?TLD
The Top Level Domain Name Server is not part of the test as such. It is involved
only because the normal run of a DNS query (when there is no cached data to
rely on) is to go to the root and follow the referral to the TLD. If the TLD server
isn抰 in place, this top step cannot be completed, and the client will not return
a complete answer. To make easy use of existing tools, and to make the testing
smooth, the TLD will be set up with top level domain zones for each of the test
domains provided by ICANN.
These zones will contain a few DNS records that can be queried for, for which
the query process will complete, so that it can be studied in whole. All zones will
be stored on one and the same server, as this server r坥le will not be evaluated.
2.3 Iterative Mode Resolver ?IMR
The r坥le of the Iterative Mode Resolver is the most important one to test. The
number of IMRs on the Internet is vast, and it is not easy to have them all upgraded.
It is therefore important to understand what impact the addition of IDN
top level domains may have on these servers.
The test system will have several IMRs which will all be configured to start
with empty caches, and they will then be queried by the client for a number of
existing IDN TLDs (as provided by ICANN) to test the exptected sucessful query
process, and a number of non-existing ones (as invented by Autonomica staff) to
verify that the IMRs handle the unsucessful queries gracefully.
The number of implementations of IMR software i vast. There is no reasonable
way one can test all versions of all software on all platforms. To make this at
all feasible, we have to limit ourselves to the most common platforms, which are
4
various versions of ISC BIND, and various versions of Microsoft DNS servers.
Apple Macintosh uses BIND, and most, if not all, Unix vendors ship BIND as
their primary DNS server. There is a plethora of alternative server platforms, but
they are counted in far smaller numbers than those above above.
Since we are looking for possibly broken software, we have chosen not to
test the most recent versions of the software, but the most ancient versions of the
most common minor versions of BIND, and the basic installations ?without any
service packs ?of the Windows 2000 Server, and the Windows 2003 Server in
the belief that the service packs improve the software, and we really want to test
攚orst case?
Windows Vista server is not yet released, and Microsoft is undoubtedly aware
of the IDN concept, so in case there are any minor problems, they can be fixed
before the release.
Thus, the versions of software that will be tested are:
1. ISC BIND version 8.2 (hopefully)1
2. ISC BIND version 8.3
3. ISC BIND version 8.4
4. ISC BIND version 9.0
5. ISC BIND version 9.1
6. ISC BIND version 9.2
7. ISC BIND version 9.3
8. Microsoft DNS Server as shipped in Windows 2000 Server
9. Microsoft DNS Server as shipped in Windows 2003 Server
3 The Test Procedure
3.1 Installation
The first step will be to install operating systems on a number of machines, followed
by installation of the DNS software for each machine. Standard installations,
using default alternatives as far as possible, will be used.
1This software is so old that there are problems to make it work on the more recent versions of
operating systems available today. We hope to succeed in our efforts to make it work.
5
Step two is to configure the root name servers with the root zone and the IDN
delegation data.
The authoritative server will have the most complicated configuration, due to
the fact that it will carry all the zones of the IDN test.
Setting up the IMRs is rather trivial, since they typically only need an 攅mpty?
configuration, with the one minor tweak that the root name server addresses have
to be changed to the ones used in the testbed.
The final step is to set up the client. It will have a list of queries, which it
will sent to each IMR. No nameserver software is neede on this machine. The
software needed will be a DNS query generator, which will be a script that uses
the commonly available tool 攄ig? which gives very good diagnostics containing
every part of the received DSN answers.
3.2 Queries
As mentioned the list of domain names to query for will contain names for existing
terminal nodes in the delegated TLDs, to ensure that the entire process of
following the referral from the root to the TLD, and actually aqcuiring the final
data, works as intended. To be able to identify possible failures in the process,
the list will also contain queries for non-exising terminal nodes (to follow ther
referral, but be unable to acquire the final data) and queries for non-existing IDN
top level domain names in the root (to fail at an early stage).
The results will be checked for any signals of bad process or bad data. Response
times will noted in the process, to look for unexpected tardiness.
The tests will be run several times, using different values on the TTL (Time
To Live) values to investigate how the IMRs behave when records time out and
are cleared from the cache.
4 Report
The results will be compiled in a report delivered to the IDN project at ICANN.
It is our goal to make the output from the test runs available on the Internet.
6
APPENDICES
A IDN test strings
The list of TLD test strings to be used in the test, as provided by ICANN, is:
xn--18-7g4a9f
hippo18potamus
xn--18-xf0jl42g
xn--18-h31ew85n
xn--flod18hst-12a
xn--18-xsdrfd6ex1e
xn--18-dtd1bdi0h3ask
xn--18-28gg3ad5hl2fzb
xn--18-hmf0e1bza7dh8ioagd6n
xn--18-rjdbcud0neb9a8ce1ezef
xn--1818-63dcpd5be6bfqcecfadfad3dl
xn--1818-1goc0bacbac7eg2kh6ci9cj9bk4yla7ablb
xn--181818-qxecc5edd8aee8aebebecadeadead0fkkill5ymam
xn--flod18hstflod18hstflod18hstflod18hstflod18hstflod18-1iejjjj
hippo18potamushippo18potamushippo18potamushippo18potamus18hippo



文件来自ICANN
http://www.icann.org/topics/idn/idn-setup-v1-4.pdf

原计划文件在附件
7

海狸

光速沙发。。。

青年近卫军

IDN Deployment Test
Test Setup


Lars-Johan Liman
Autonomica AB


Contents

1 Background 2

2 System Setup 2

2.1 RootNameServers–root...................... 2


2.2 TopLevelDomainNameServer–TLD . . . . . . . . . . . . . . 4

2.3 IterativeModeResolver–IMR................... 4


3 The Test Procedure 5

3.1 Installation ............................. 5


3.2 Queries ............................... 6


4 Report 6

A IDN test strings 7

$Id: idn-setup.tex,v 1.4 2006/11/21 15:36:38 liman Exp $



1 Background

ICANN is responsible for the management of the name space in the highest level
of the domain name system. ICANN wants to deploy a new type of top level
domains in the public DNS system – domain names that contain encoded versions
of names expressed with other characters than those in the English alphabet, so
called ”internationalized domain names” (IDNs).

ICANN has requested that two external parties test what the technical impact,
on the DNS client side, of deploying such IDNs as top level domains in the public
root would be. The tests are to be carried out in a closed lab environment, and expected to cover various implementations of server and client software, to a degree
that makes ICANN comfortable when making the decision whether to add these
IDN TLDs to the public DNS or not.

Autonomica has been contracted to undertake such testing, and this is a description of the system that will be used for these tests.

2 System Setup

The tests will be carried out in Autonomica’s test facilities in Stockholm. The test
system will consist of the following blocks

1. Two root name servers (root).
2. Top level domain authoritative server (TLD).
3. iterative mode resolver (IMR).
4. Query generator (client).
5. Connecting network.
Only the qualitative performance of the root name servers and the iterative
mode resolvers will be evaluated in this test, according to the demarcations in the
contract.

2.1 Root Name Servers – root
The root name servers will run on a Unix platform. Two major DNS server implentations will be tested, known to be used by root server operators. They are

2



ROOT1ROOT2TLDFSRFSRFSRFSRFSRFSRCLIENT= Services evaluated in the test
Figure 1: Service topology for the test

3



1. ISC BIND
2. NLNet Labs nsd
The reason for testing only these two, and only recent versions, is that the
root name servers are few and operated by groups that have DNS as their main
focus. Upgrading the root name servers to capable code is less overwhelming
than upgrading the iterative mode resolvers. We will try to mimick the existing
root name servers to the best of our abilities. Two servers will be operated to
ensure that the IMR software doesn’t have problems based on the fact that only a
single server is reachable.

The root servers will contain a copy of the active root zone on the Internet,
augmented with the IDN test domains supplied by ICANN, see Appendix A.

2.2 Top Level Domain Name Server – TLD
The Top Level Domain Name Server is not part of the test as such. It is involved
only because the normal run of a DNS query (when there is no cached data to
rely on) is to go to the root and follow the referral to the TLD. If the TLD server
isn’t in place, this top step cannot be completed, and the client will not return
a complete answer. To make easy use of existing tools, and to make the testing
smooth, the TLD will be set up with top level domain zones for each of the test
domains provided by ICANN.

These zones will contain a few DNS records that can be queried for, for which
the query process will complete, so that it can be studied in whole. All zones will
be stored on one and the same server, as this server r.

ole will not be evaluated.

2.3 Iterative Mode Resolver – IMR
The r.

ole of the Iterative Mode Resolver is the most important one to test. The
number of IMRs on the Internet is vast, and it is not easy to have them all upgraded. It is therefore important to understand what impact the addition of IDN
top level domains may have on these servers.

The test system will have several IMRs which will all be configured to start
with empty caches, and they will then be queried by the client for a number of
existing IDN TLDs (as provided by ICANN) to test the exptected sucessful query
process, and a number of non-existing ones (as invented by Autonomica staff) to
verify that the IMRs handle the unsucessful queries gracefully.

The number of implementations of IMR software i vast. There is no reasonable way one can test all versions of all software on all platforms. To make this at
all feasible, we have to limit ourselves to the most common platforms, which are

4



various versions of ISC BIND, and various versions of Microsoft DNS servers.
Apple Macintosh uses BIND, and most, if not all, Unix vendors ship BIND as
their primary DNS server. There is a plethora of alternative server platforms, but
they are counted in far smaller numbers than those above above.

Since we are looking for possibly broken software, we have chosen not to
test the most recent versions of the software, but the most ancient versions of the
most common minor versions of BIND, and the basic installations – without any
service packs – of the Windows 2000 Server, and the Windows 2003 Server in
the belief that the service packs improve the software, and we really want to test
”worst case”.

Windows Vista server is not yet released, and Microsoft is undoubtedly aware
of the IDN concept, so in case there are any minor problems, they can be fixed
before the release.

Thus, the versions of software that will be tested are:

1. ISC BIND version 8.2 (hopefully)1
2. ISC BIND version 8.3
3. ISC BIND version 8.4
4. ISC BIND version 9.0
5. ISC BIND version 9.1
6. ISC BIND version 9.2
7. ISC BIND version 9.3
8. Microsoft DNS Server as shipped in Windows 2000 Server
9. Microsoft DNS Server as shipped in Windows 2003 Server
3 The Test Procedure

3.1 Installation
The first step will be to install operating systems on a number of machines, followed by installation of the DNS software for each machine. Standard installations, using default alternatives as far as possible, will be used.

1This software is so old that there are problems to make it work on the more recent versions of
operating systems available today. We hope to succeed in our efforts to make it work.

5


Step two is to configure the root name servers with the root zone and the IDN
delegation data.

The authoritative server will have the most complicated configuration, due to
the fact that it will carry all the zones of the IDN test.

Setting up the IMRs is rather trivial, since they typically only need an ”empty”
configuration, with the one minor tweak that the root name server addresses have
to be changed to the ones used in the testbed.

The final step is to set up the client. It will have a list of queries, which it
will sent to each IMR. No nameserver software is neede on this machine. The
software needed will be a DNS query generator, which will be a script that uses
the commonly available tool ”dig”, which gives very good diagnostics containing
every part of the received DSN answers.

3.2 Queries
As mentioned the list of domain names to query for will contain names for existing terminal nodes in the delegated TLDs, to ensure that the entire process of
following the referral from the root to the TLD, and actually aqcuiring the final
data, works as intended. To be able to identify possible failures in the process,
the list will also contain queries for non-exising terminal nodes (to follow ther
referral, but be unable to acquire the final data) and queries for non-existing IDN
top level domain names in the root (to fail at an early stage).

The results will be checked for any signals of bad process or bad data. Response times will noted in the process, to look for unexpected tardiness.

The tests will be run several times, using different values on the TTL (Time
To Live) values to investigate how the IMRs behave when records time out and
are cleared from the cache.

4 Report

The results will be compiled in a report delivered to the IDN project at ICANN.
It is our goal to make the output from the test runs available on the Internet.

6



APPENDICES

A IDN test strings

The list of TLD test strings to be used in the test, as provided by ICANN, is:

xn--18-7g4a9f
hippo18potamus
xn--18-xf0jl42g
xn--18-h31ew85n
xn--flod18hst-12a
xn--18-xsdrfd6ex1e
xn--18-dtd1bdi0h3ask
xn--18-28gg3ad5hl2fzb
xn--18-hmf0e1bza7dh8ioagd6n
xn--18-rjdbcud0neb9a8ce1ezef
xn--1818-63dcpd5be6bfqcecfadfad3dl
xn--1818-1goc0bacbac7eg2kh6ci9cj9bk4yla7ablb
xn--181818-qxecc5edd8aee8aebebecadeadead0fkkill5ymam
xn--flod18hstflod18hstflod18hstflod18hstflod18hstflod18-1iejjjj
hippo18potamushippo18potamushippo18potamushippo18potamus18hippo


7




ca191s

IDN Deployment测试
测试安装
守护神-JohanLiman
Autonomica AB
内容
1背景2
2系统安装2
2.1根名字服务器?根. . . . . . . . . . . . . . . . . . . . . . 2
2.2顶部水平域名服务器?TLD . . . . . . . . . . . . . . 4
2.3重复的方式决心?IMR . . . . . . . . . . . . . . . . . . . 4
3测试程序5
3.1安装. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2质问. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4报告6
IDN测试字符串7
$Id: idn-setup.tex,v 1.4 2006/11/21 15:36:38 liman Exp $
1背景
ICANN是有责任的为了名字空间的经营在高度水平
的域名系统. ICANN想要到展开顶部水平的新的类型
域在公众DNS系统?域名那包含编码版本
有名的急速的有其他的特性比. 那些在英文的字母表, 因而
喊声斒构?驶?蛎?(IDNs).
ICANN请求那二外部的合适的测试什么技术的碰撞,
在DNS客户边, 的展开这样的IDNs同样地顶部水平域在公众
根would是.测试是到是完成在封闭的实验室环境, 和期待
到服务器的盖子不同的执行和客户软件, 非常
那制造ICANN舒适的就在那个时候制造判定是否到增加. 这些
IDN TLDs到公众DNS或不.
Autonomica是收缩了的到承担这样的测试, 和这是描写
系统那将的是使用为了. 这些测试.
2系统安装
测试将是完成在Autonomica抯测试容易在斯德哥尔摩.测试
系统将组成下列各项木块
1.二根名字服务器(根).
2.顶部水平领土权威的服务器(TLD).
3.重复的方式决心(IMR).
4.质问发电机(客户).
5.连接网络.
根名字服务器的唯一的性质上的履行和重复的
方式resolvers将是评价在这测试, 依照划分在
合同.
2.1根名字服务器?根
根名字服务器将抢购Unix平台.二主修课DNS服务器implentations
将是测试, 知名的到是使用在根服务器操作员.他们是
2
根
1
根
2 TLD
FSR FSR FSR FSR FSR FSR
客户
= 服务评价在测试
外形1: 服务拓扑为了测试
3
1. ISC绑
2. NLNet实验室nsd
理由测试唯一的. 这些二, 和唯一的最近的版本, 是那
根名字服务器是很少的和操作在组那有DNS同样地他们的主要部分
焦点.升级根名字服务器到有能力的代码是较少压倒性的
比升级重复的方式resolvers.我们将设法mimick现有的
根名字服务器到我们的能力.二服务器将的最好的是操作到
保证那IMR软件doesn抰有问题立基于在事实那唯一的
单一的服务器是可达成的.
根服务器将包含一份活动的根地域在因特网,
增音的有IDN测试域补给在ICANN, 看附录A.
2.2顶部水平域名服务器?TLD
顶部水平域名服务器是测试的不部分同样地.它是棘手的
唯一的ad. 因为的正规运行DNS质问(就在那个时候那儿有没有缓冲数据到
依赖) 是外卖到根和跟随提名到TLD.如果TLD服务器
内码抰适当位置, 这顶部脚步不能是完成, 和客户将不回来
完成答案.到制造容易的使用现有的工具的, 和到制造测试
平滑的, TLD将是建立有顶部水平领土地域为了测试的各自的
域倘若在ICANN.
. 这些地域将包含少许DNS记录那能是质问为了, 为了哪个
质问过程将完成, 所以它能是故意的在全部.全部的地域将
是贮藏在同一个服务器, 同样地这服务器r圤LE将不是评价.
2.3重复的方式决心?IMR
r堉馗吹姆绞骄鲂牡腛LE是最多的重要的一个到测试.
的数IMRs在因特网是大量的, 和它是不容易的到有他们全部的升级.
它是因此重要的到懂的什么碰撞加IDN
顶部水平域可能穿着. 这些服务器.
测试系统将有几个IMRs哪个将全部的是配置到开始
有空的缓冲, 和他们将然后是质问在客户为了许多的
现有的IDN TLDs (同样地倘若在ICANN) 到测试exptected sucessful质问
过程, 和许多的非-现有的一个(同样地发明在Autonomica全体人员) 到
检验那IMRs句柄unsucessful质问温文地.
执行的的数IMR软件我大量的.那儿有没有合理的
路一个能全部的软件的测试全部的版本在全部的平台.到制造这在
全部的可行的, 我们有到界限我们自己到最多的共同的平台, 哪个是
4
的不同的版本ISC绑, 和微软公司的不同的版本DNS服务器.
苹果Apple微机使用绑, 和最多的, 如果不全部的, Unix卖主船绑同样地
他们的第一位的DNS服务器.那儿有二中择一服务器平台的过剩, 但是
他们是.计算在内远的小的民数记比. 那些上面的上面的.
自从我们是样子为了可能地坏掉的软件, 我们有选择不到
软件的测试最多的最近的版本, 但是的最多的远古的版本
的最多的共同的未成年人版本绑, 和基本安装?没有任何的
服务包?窗口的2000服务器, 和窗口2003服务器在
信任那服务包改善软件, 和我们真正地想要到测试
斪罨档氖?
窗口展望服务器是不仍释放, 和微软公司是无庸置疑地注意到
的IDN观念, 因而万一在那里是任何的未成年人问题, 他们能是固定的
在前释放.
因而, 软件那将的版本是测试是:
1. ISC绑版本8.2 (有希望地)1
2. ISC绑版本8.3
3. ISC绑版本8.4
4. ISC绑版本9.0
5. ISC绑版本9.1
6. ISC绑版本9.2
7. ISC绑版本9.3
8.微软公司DNS服务器同样地船在窗口2000服务器
9.微软公司DNS服务器同样地船在窗口2003服务器
3测试程序
3.1安装
首先脚步将是到安装操作系统在许多的机器, 跟随
在的安装DNS软件为了各自的机器.标准安装,
用默认二中择一远到可能的, 将是使用.
1This软件是因而年老的那在那里是问题到达到目标继续工作的更多的最近的版本
操作系统可用到的今天.我们希望到成功在我们的努力到达到目标工作.
5
脚步二是到配置根名字服务器有根地域和IDN
代表团数据.
权威的服务器将有最多的复杂的配置, 由于
的事实那它将进位全部的地域IDN测试.
设置向上IMRs是宁愿琐细的, 自从他们代表性地唯一的需要斂盏?
配置, 有一个未成年人扭那根名字服务器地址有
到是改变到一个使用在testbed.
结局脚步是到建立客户.它将有一列质问, 哪个它
将送到各自的IMR.没有nameserver软件是neede在这机器.
软件需要将是DNS质问发电机, 哪个将是脚本那使用
一般可用到的工具斁? 哪个弹性很好诊断学包含
已收到的每一的部分DSN答案.
3.2质问
同样地提及的列表域名到质问为了将包含名字为了现有的
终点站节点在代表TLDs, 到保证的那全部的过程
下列各项提名从根到TLD, 和实际上aqcuiring结局
数据, 工作同样地有意的.到是能的到识别可能的失败在过程,
列表将也包含质问为了非-exising终点站节点(到跟随
提名, 但是是无资格的到获得结局数据) 和质问为了非-现有的IDN
顶部水平域名在根(到失败在早的舞台).
结果将是选中的为了劣质的过程的任何的信号或劣质的数据.回答
时期将著名的在过程, 到寻找意外的缓慢.
测试将是运行几个时期, 用不同的价值在TTL (时间
到活的) 价值到调查如何IMRs举动就在那个时候记录时间到和
是清除的从缓冲.
4报告
结果将是编译在报告转交IDN项目在ICANN.
它是我们的目的到制造输出从测试运行可用到的在因特网.
6
APPENDICES
IDN测试字符串
的列表TLD测试字符串到是使用在测试, 同样地倘若在ICANN, 是:
xn--18-7g4a9f
hippo18potamus
xn--18-xf0jl42g
xn--18-h31ew85n
xn--flod18hst-12a
xn--18-xsdrfd6ex1e
xn--18-dtd1bdi0h3ask
xn--18-28gg3ad5hl2fzb
xn--18-hmf0e1bza7dh8ioagd6n
xn--18-rjdbcud0neb9a8ce1ezef
xn--1818-63dcpd5be6bfqcecfadfad3dl
xn--1818-1goc0bacbac7eg2kh6ci9cj9bk4yla7ablb
xn--181818-qxecc5edd8aee8aebebecadeadead0fkkill5ymam
xn--flod18hstflod18hstflod18hstflod18hstflod18hstflod18-1iejjjj
hippo18potamushippo18potamushippo18potamushippo18potamus18hippo

cnidner

看了，版主还是说说测试对中文域名意味着什么吧。翻译看起来吃力。

青年近卫军

测试后,如果可行,经过调整和解决相关问题后,中文.com将成为国际标准,那样就可以加入根DNS.到时我们可以不用装插件,在IE6这种不支持IDN的浏览器直接访问中文.com

liling918

好消息啊

cnidner

在ie7下不是可以访问中文.com吗？它测试不测试有什么用？

青年近卫军

IE7是支持,但IE6不支持.成为标准的产品的魅力是无可比拟的.
成为国际标准的中文.com在中国推广时就没有那么多的阻力.
看看2000年,中文.com禁止在中国大陆推广的,搜索下新闻就知道了.

青年近卫军

能根解析的话,就能脱离特殊软件才能访问的束缚了.