先记录到这儿，空了仔细研究一下。

————

iodine - http://code.kryo.se/iodine

***********************************

This is a piece of software that lets you tunnel IPv4 data through a DNS
server. This can be usable in different situations where internet access is
firewalled, but DNS queries are allowed.

QUICKSTART:

Try it out within your own LAN! Follow these simple steps:
- On your server, run: ./iodined -f 10.0.0.1 test.com
  (If you already use the 10.0.0.0 network, use another internal net like
  172.16.0.0)
- Enter a password
- On the client, run: ./iodine -f -r 192.168.0.1 test.com
  (Replace 192.168.0.1 with your server's ip address)
- Enter the same password
- Now the client has the tunnel ip 10.0.0.2 and the server has 10.0.0.1
- Try pinging each other through the tunnel
- Done! 
To actually use it through a relaying nameserver, see below.

HOW TO USE:

Note: server and client are required to speak the exact same protocol. In most
cases, this means running the same iodine version. Unfortunately, implementing
backward and forward protocol compatibility is usually not feasible.

Server side:
To use this tunnel, you need control over a real domain (like mydomain.com),
and a server with a public IP address to run iodined on. If this server
already runs a DNS program, change its listening port and then use iodined's
-b option to let iodined forward the DNS requests. (Note that this procedure
is not advised in production environments, because iodined's DNS forwarding
is not completely transparent.)

Then, delegate a subdomain (say, t1.mydomain.com) to the iodined server.
If you use BIND for your domain, add two lines like these to the zone file:

t1		IN	NS	t1ns.mydomain.com.		; note the dot!
t1ns		IN	A	10.15.213.99

The "NS" line is all that's needed to route queries for the "t1" subdomain
to the "t1ns" server. We use a short name for the subdomain, to keep as much
space as possible available for the data traffic. At the end of the "NS" line
is the name of your iodined server. This can be any name, pointing anywhere,
but in this case it's easily kept in the same zone file. It must be a name
(not an IP address), and that name itself must have an A record (not a CNAME).

If your iodined server has a dynamic IP, use a dynamic dns provider. Simply
point the "NS" line to it, and leave the "A" line out:

t1		IN	NS	myname.mydyndnsprovider.com.	; note the dot!

Then reload or restart your nameserver program. Now any DNS queries for
domains ending in t1.mydomain.com will be sent to your iodined server.

Finally start iodined on your server. The first argument is the IP address
inside the tunnel, which can be from any range that you don't use yet (for
example 192.168.99.1), and the second argument is the assigned domain (in this
case t1.mydomain.com). Using the -f option will keep iodined running in the
foreground, which helps when testing. iodined will open a virtual interface
("tun device"), and will also start listening for DNS queries on UDP port 53.
Either enter a password on the commandline (-P pass) or after the server has
started. Now everything is ready for the client.

If there is a chance you'll be using an iodine tunnel from unexpected
environments, start iodined with a -c option.

Resulting commandline in this example situation:
./iodined -f -c -P secretpassword 192.168.99.1 t1.mydomain.com

Client side:
All the setup is done, just start iodine. It takes one or two arguments, the
first is the local relaying DNS server (optional) and the second is the domain
you used (t1.mydomain.com). If you don't specify the first argument, the
system's current DNS setting will be consulted.

If DNS queries are allowed to any computer, you can directly give the iodined
server's address as first argument (in the example: t1ns.mydomain.com or
10.15.213.99). In that case, it may also happen that _any_ traffic is allowed
to the DNS port (53 UDP) of any computer. Iodine will detect this, and switch
to raw UDP tunneling if possible. To force DNS tunneling in any case, use the
-r option (especially useful when testing within your own network).

The client's tunnel interface will get an IP close to the server's (in this
case 192.168.99.2 or .3 etc.) and a suitable MTU. Enter the same password as
on the server either as commandline option or after the client has started.
Using the -f option will keep the iodine client running in the foreground.

Resulting commandline in this example situation:
./iodine -f -P secretpassword t1.mydomain.com
(add -r to force DNS tunneling even if raw UDP tunneling would be possible)

From either side, you should now be able to ping the IP address on the other
end of the tunnel. In this case, ping 192.168.99.1 from the iodine client, and
192.168.99.2 or .3 etc. from the iodine server.

MISC. INFO:

Routing:
It is possible to route all traffic through the DNS tunnel. To do this, first
add a host route to the nameserver used by iodine over the wired/wireless
interface with the default gateway as gateway. Then replace the default
gateway with the iodined server's IP address inside the DNS tunnel, and
configure the server to do NAT.

However, note that the tunneled data traffic is not encrypted at all, and can
be read and changed by external parties relatively easily. For maximum
security, run a VPN through the DNS tunnel (=double tunneling), or use secure
shell (SSH) access, possibly with port forwarding. The latter can also be used
for web browsing, when you run a web proxy (for example Privoxy) on your
server.

Testing:
The iodined server replies to NS requests sent for subdomains of the tunnel
domain. If your iodined subdomain is t1.mydomain.com, send a NS request for
foo123.t1.mydomain.com to see if the delegation works. dig is a good tool
for this:
dig -t NS foo123.t1.mydomain.com

Also, the iodined server will answer requests starting with 'z' for any of the
supported request types, for example:
dig -t TXT z456.t1.mydomain.com
dig -t SRV z456.t1.mydomain.com
dig -t CNAME z456.t1.mydomain.com
The reply should look like garbled text in all these cases.

Operational info:
The DNS-response fragment size is normally autoprobed to get maximum bandwidth.
To force a specific value (and speed things up), use the -m option.

The DNS hostnames are normally used up to their maximum length, 255 characters.
Some DNS relays have been found that answer full-length queries rather
unreliably, giving widely varying (and mostly very bad) results of the
fragment size autoprobe on repeated tries. In these cases, use the -M switch
to reduce the DNS hostname length to for example 200 characters, which makes
these DNS relays much more stable. This is also useful on some "de-optimizing"
DNS relays that stuff the response with two full copies of the query, leaving
very little space for downstream data (also not capable of EDNS0). The -M
switch can trade some upstream bandwidth for downstream bandwidth. Note that
the minimum -M value is about 100, since the protocol can split packets (1200
bytes max) in only 16 fragments, requiring at least 75 real data bytes per
fragment.

The upstream data is sent gzipped encoded with Base32; or Base64 if the relay
server supports mixed case and '+' in domain names; or Base64u if '_' is
supported instead; or Base128 if high-byte-value characters are supported.
This upstream encoding is autodetected. The DNS protocol allows one query per
packet, and one query can be max 256 chars. Each domain name part can be max
63 chars. So your domain name and subdomain should be as short as possible to
allow maximum upstream throughput.

Several DNS request types are supported, with the NULL type expected to provide
the largest downstream bandwidth. Other available types are TXT, SRV, MX,
CNAME and A (returning CNAME), in decreasing bandwidth order. Normally the
"best" request type is autodetected and used. However, DNS relays may impose
limits on for example NULL and TXT, making SRV or MX actually the best choice.
This is not autodetected, but can be forced using the -T option. It is
advisable to try various alternatives especially when the autodetected request
type provides a downstream fragment size of less than 200 bytes.

Note that SRV, MX and A (returning CNAME) queries may/will cause additional
lookups by "smart" caching nameservers to get an actual IP address, which may
either slow down or fail completely.

DNS responses for non-NULL queries can be encoded with the same set of codecs
as upstream data. This is normally also autodetected, but no fully exhaustive
tests are done, so some problems may not be noticed when selecting more
advanced codecs. In that case, you'll see failures/corruption in the fragment
size autoprobe. In particular, several DNS relays have been found that change
replies returning hostnames (SRV, MX, CNAME, A) to lowercase only when that
hostname exceeds ca. 180 characters. In these and similar cases, use the -O
option to try other downstream codecs; Base32 should always work.

Normal operation now is for the server to _not_ answer a DNS request until
the next DNS request has come in, a.k.a. being "lazy". This way, the server
will always have a DNS request handy when new downstream data has to be sent.
This greatly improves (interactive) performance and latency, and allows to
slow down the quiescent ping requests to 4 second intervals by default, and
possibly much slower. In fact, the main purpose of the pings now is to force
a reply to the previous ping, and prevent DNS server timeouts (usually at
least 5-10 seconds per RFC1035). Some DNS servers are more impatient and will
give SERVFAIL errors (timeouts) in periods without tunneled data traffic. All
data should still get through in these cases, but iodine will reduce the ping
interval to 1 second anyway (-I1) to reduce the number of error messages. This
may not help for very impatient DNS relays like dnsadvantage.com (ultradns),
which time out in 1 second or even less. Yet data will still get trough, and
you can ignore the SERVFAIL errors.

If you are running on a local network without any DNS server in-between, try
-I 50 (iodine and iodined close the connection after 60 seconds of silence).
The only time you'll notice a slowdown, is when DNS reply packets go missing;
the iodined server then has to wait for a new ping to re-send the data. You can
speed this up by generating some upstream traffic (keypress, ping). If this
happens often, check your network for bottlenecks and/or run with -I1.

The delayed answering in lazy mode will cause some "carrier grade" commercial
DNS relays to repeatedly re-send the same DNS query to the iodined server.
If the DNS relay is actually implemented as a pool of parallel servers,
duplicate requests may even arrive from multiple sources. This effect will
only be visible in the network traffic at the iodined server, and will not
affect the client's connection. Iodined will notice these duplicates, and send
the same answer (when its time has come) to both the original query and the
latest duplicate. After that, the full answer is cached for a short while.
Delayed duplicates that arrive at the server even later, get a reply that the
iodine client will ignore (if it ever arrives there).

If you have problems, try inspecting the traffic with network monitoring tools
like tcpdump or ethereal/wireshark, and make sure that the relaying DNS server
has not cached the response. A cached error message could mean that you
started the client before the server. The -D (and -DD) option on the server
can also show received and sent queries.

TIPS & TRICKS:

If your port 53 is taken on a specific interface by an application that does
not use it, use -p on iodined to specify an alternate port (like -p 5353) and
use for instance iptables (on Linux) to forward the traffic:
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 53 -j DNAT --to :5353
(Sent in by Tom Schouten)

Iodined will reject data from clients that have not been active (data/pings)
for more than 60 seconds. Similarly, iodine will exit when no downstream
data has been received for 60 seconds. In case of a long network outage or
similar, just restart iodine (re-login), possibly multiple times until you get
your old IP address back. Once that's done, just wait a while, and you'll
eventually see the tunneled TCP traffic continue to flow from where it left
off before the outage.

With the introduction of the downstream packet queue in the server, its memory
usage has increased with several megabytes in the default configuration.
For use in low-memory environments (e.g. running on your DSL router), you can
decrease USERS and undefine OUTPACKETQ_LEN in user.h without any ill conse-
quence, assuming at most one client will be connected at any time. A small
DNSCACHE_LEN is still advised, preferably 2 or higher, however you can also
undefine it to save a few more kilobytes.

PERFORMANCE:

This section tabulates some performance measurements. To view properly, use
a fixed-width font like Courier.

Measurements were done in protocol 00000502 in lazy mode; upstream encoding
always Base128; iodine -M255; iodined -m1130. Network conditions were not
extremely favorable; results are not benchmarks but a realistic indication of
real-world performance that can be expected in similar situations.

Upstream/downstream throughput was measured by scp'ing a file previously
read from /dev/urandom (i.e. incompressible), and measuring size with
"ls -l ; sleep 30 ; ls -l" on a separate non-tunneled connection. Given the
large scp block size of 16 kB, this gives a resolution of 4.3 kbit/s, which
explains why some values are exactly equal.
Ping round-trip times measured with "ping -c100", presented are average rtt
and mean deviation (indicating spread around the average), in milliseconds.

Situation 1:
Laptop  ->   Wifi AP   ->  Home server  ->  DSL provider  ->  Datacenter
 iodine    DNS "relay"        bind9           DNS cache        iodined

                        downstr.  upstream downstr.  ping-up       ping-down
                        fragsize   kbit/s   kbit/s  avg +/-mdev   avg +/-mdev
------------------------------------------------------------------------------

iodine -> Wifi AP :53
  -Tnull (= -Oraw)           982    43.6    131.0   28.0    4.6   26.8    3.4

iodine -> Home server :53
  -Tnull (= -Oraw)          1174    48.0    305.8   26.6    5.0   26.9    8.4

iodine -> DSL provider :53
  -Tnull (= -Oraw)          1174    56.7    367.0   20.6    3.1   21.2    4.4
  -Ttxt -Obase32             730    56.7    174.7*
  -Ttxt -Obase64             874    56.7    174.7
  -Ttxt -Obase128           1018    56.7    174.7
  -Ttxt -Oraw               1162    56.7    358.2
  -Tsrv -Obase128            910    56.7    174.7
  -Tcname -Obase32           151    56.7     43.6
  -Tcname -Obase128          212    56.7     52.4

iodine -> DSL provider :53
  wired (no Wifi) -Tnull    1174    74.2    585.4   20.2    5.6   19.6    3.4

 [174.7* : these all have 2frag/packet]

Situation 2:
Laptop  ->  Wifi+vpn / wired  ->  Home server
 iodine                            iodined

                        downstr.  upstream downstr.  ping-up       ping-down
                        fragsize   kbit/s   kbit/s  avg +/-mdev   avg +/-mdev
------------------------------------------------------------------------------

wifi + openvpn  -Tnull      1186   166.0   1022.3    6.3    1.3    6.6    1.6

wired  -Tnull               1186   677.2   2464.1    1.3    0.2    1.3    0.1

Performance is strongly coupled to low ping times, as iodine requires
confirmation for every data fragment before moving on to the next. Allowing
multiple fragments in-flight like TCP could possibly increase performance,
but it would likely cause serious overload for the intermediary DNS servers.
The current protocol scales performance with DNS responsivity, since the
DNS servers are on average handling at most one DNS request per client.

PORTABILITY:

iodine has been tested on Linux (arm, ia64, x86, AMD64 and SPARC64), FreeBSD
(ia64, x86), OpenBSD (x86), NetBSD (x86), MacOS X (ppc and x86, with
http://tuntaposx.sourceforge.net/). and Windows (with OpenVPN TAP32 driver, see
win32 readme file).  It should be easy to port to other unix-like systems that
has TUN/TAP tunneling support. Let us know if you get it to run on other
platforms. 

THE NAME:

The name iodine was chosen since it starts with IOD (IP Over DNS) and since
iodine has atomic number 53, which happens to be the DNS port number.

THANKS:

- To kuxien for FreeBSD and OS X testing
- To poplix for code audit

AUTHORS & LICENSE:

Copyright (c) 2006-2009 Bjorn Andersson <flex@kryo.se>, Erik Ekman <yarrick@kryo.se>
Also major contributions by Anne Bezemer.

Permission to use, copy, modify, and distribute this software for any purpose
with or without fee is hereby granted, provided that the above copyright notice
and this permission notice appear in all copies.

THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH
REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT,
INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR
OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
PERFORMANCE OF THIS SOFTWARE.

MD5 implementation by L. Peter Deutsch (license and source in src/md5.[ch])
Copyright (C) 1999, 2000, 2002 Aladdin Enterprises.  All rights reserved.

在VirtualBox网站上发现可以使用PHPＶｉｒｔｕａｌＢｏｘ来达到WEB访问的目的。

多方便的。

PhpVirtualBox的下载地址：http://code.google.com/p/phpvirtualbox/

VirtualBox的下载地址：https://www.virtualbox.org/wiki/Downloads

    洛杉矶和旧金山集中了美国一大半华人，这里的圣诞节和新年当然也有浓浓中国文化味道，就看那些每天晚上灯火辉煌的华人餐厅就知道这“味道”有多强。你很难在美国看到俄国餐厅，也不会看到规模如此大的犹太人街道，即使是那些越南人把所有商铺加起来也比不上另一群越南人—我们的越南华侨社区。在这里久了好像并没有真正活在美国，而是在另一个独特的“中国”。那些洗脚哥哥和餐馆侍应妹妹们即使不会英语也活的和别人没什么两样。至少表面上看就是如此。

    唐人街的热闹过节气氛让美国人十分好奇，这两年美国的商铺不是门可罗雀便是关门大吉，怎唯独中国人社区依然歌舞平生？当然，这和那些推着大包小包下飞机的中国移民有关系，这些人中有投资移民，也有企业移民，也有留学生，还有更多的是各地来的亲属移民们，他们心里都想着一件事，那就是如何在美国安顿下来。为了好好立足，把原来家里的细软都带来了，有房子的也卖了，把房款收入在美国另买一套；没房子的也卖了，还了银行贷款剩下的带过来权当半年内找不到工作的生活费，中国房地产如此就变成了移民们的取款机。当然，这还是无法安慰新移民的忐忑的心，他们把小算盘打得滴答响，不论到哪里都把人民币和美元比价一番，这个比中国贵，那个比中国便宜，久而久之，美国人硬生生地总结了六十条“中国人脸谱”，可正是这些中国人借钱给了他们高消费。

1. 熟人见面打招呼时不问好, 而是问"吃了吗?"（中国过去六十年有一半多是饥饿记忆，关心吃饱比关心啥都感人实惠）

2. 喜欢吃鸡爪。（中国人体型好，鸡爪子不油腻，少脂肪，不像美国汉堡把人都吃撑肥胖症了）

3. 吃鱼时会吸鱼头和鱼鳍。（和鱼亲吻，最好的享受美食方法，顺便把骨头咬啃干净，减少污染，两全齐美，只是让那小猫没多少油水了）。

4. 车子后视镜上会吊中国摆设。（那是中国人自我标榜的方式，说明我们永远是龙传人”。

5. 喜欢唱卡拉OK。（中国人最讲求唱歌的自由民主，谁的嗓门大谁才有种有面子）

6. 房子铺的是瓷砖。(难道你不知道China就是瓷砖的意思？)

7. 厨房覆盖着一层厚厚的油脂。（那才叫着‘肥水不流外人田’，洗完了不还得炒菜冒油烟？干脆等过年才洗，一次搞定）。

8. 炉子上面有铝箔。（防患于未然，把锡纸掀开就不用每次过节时擦洗了）

9. 遥控器外面包着塑料。（这叫着讲究卫生，表面脏，里面干净；行为不端，思想正确，中国特色）

10. 从没吻过你父母。（问问他们愿意被我吻吗？怎能强人所难？何况对父母）

11. 从没抱过你父母。（只听说父母抱孩子，没听说孩子抱父母的）

12. 小学五年级开始就戴眼鏡了。（如今托儿所就开始用电脑了，三岁就开始多了眼镜这个‘人造器官’）

13. 睡醒后头发会起来。（你的头发睡着才竖起来？）

14. 会为一些不可置疑的事情辩论。（这叫实践是检验真理的标准，吵架是检验真理的过程）。

15. 喜欢用折价券。（我父母用布票和肉票，我用折价卷有何不对？）

16. 为了最便宜的汽油费不惜开着车子到处找。（算过没有,我们等汽油差点用完才加，装满一桶便能省两美元，而美国佬见那里便宜就在那里加，哪怕只加四分之一桶也停一次车，每次只能节省五毛钱，傻不傻？）

17. 每天总是到了晚上才洗澡。（中国男人睡前流汗，美国男人睡醒流汗，没错吧。）

18. 旅店房间里的非免费食品都绝不吃。（防范恐怖分子下毒，他们知道只有美国白人才会吃非免费食物。我们买一小杯可乐，但可以添加N次，全家人喝饱，老美只会买大杯，喝不完倒掉，受穷活该）

19. 男人不如女人会打球（男人是当官用的，女人是陪打球用的）

20. 別人为他倒茶时, 他表示感谢的方式是用手指敲一下桌子。（美国人点点头，中国人点点手指，美国人脖子粗，中国人手指细，中国人更节省力气）。

21. 表示感叹时经常说 "哎"(第二声)"呀"(第四声)"和"哇"(第四声)"。 （美国人只发出两声，五个字母“MY GOD”）

22. 开车或坐在副驾驶位乘车时 , 不喜欢系安全带, 因為系安全带让他感觉不舒服和麻烦。（中国人最爱自由自在，只有老美才喜欢让根带子摸自己胸前）

23. 喜欢拉斯维加斯、老虎机和二十一点。（不赌怎叫中国人，我们天生是赌场的肥料，因为太希望赢钱了，钱见我们就吓得飞跑）

24. 厨房桌子上总是有一条湿乎乎的抹布。（这就是家庭主妇的面子工程，抹布不湿怎显出勤劳？）

25. 就餐时习惯把骨头和其他咬碎吐在桌子上。（最后可以清点一下谁的渣子多就知道谁吃得最多，容易记账，不像老美不吃骨头只吃肉）

26. 电冰箱时常会存着很久以前放进去的食物。（我们有三十年饥饿记忆，饥饿感是我们的生物本能，造成我们永远要‘备战备荒’）。

27. 厨房里有洗碗机, 但后来沒用过它。（洗碗机用电，用手洗不耗电；洗碗机耗费洗洁剂比手洗多一倍）。

28. 把洗碗机当碗橱。（美国人把碗当成艺术品摆在橱柜里，我们把艺术品当成碗摆在橱柜里）

29. 特別喜欢用热水瓶, 而且每个热水瓶里面永远裝满热水。（热水是消毒过的，我们祖国的水不消毒不能喝，到了美国我们的胃只适应喝热水了）

30. 虽然有餐厅, 但却总是喜欢在厨房用餐。（我们喜欢吃火锅，边烤边啃，在餐厅怎如锅台上方便？）

看到这里，读者难道还不明白中国人为何在此次经济大萧条中能够独善其身？美国人应当改改心态了。

unixservice.com.ghitr.com   --->unixservice.com
openisp.net.ghitr.com   ---> openisp.net

如果你觉得访问慢了，可以访问源地址：

http://openisp.net/openisp/unxsVZ/wiki/GettingStartedBind

Introduction

This page will guide through the process of setting up a new zone, configuring your nameserver set and putting your BIND server in production using unxsBind. We assume you have read and implemented the instructions described at the Installing unxsBind with yum for CentOS 5 page. If not, that should be your starting point before reading this document.

Securing your install

1. Login into your iDNS.cgi backend at https://yourserverip:9333/cgi-bin/iDNS.cgi (Root/wsxedc)

1. Once there, you must change the Root user password. For doing so, click on the Main tab:

1. Click on the tAuthorize link, you should see the screen below:
2. There you’ll find the Root tAuthorize record loaded.
3. Press [Modify]

1. Update the cPasswd field with the password you want to use.
2. Press [Confirm Modify]
3. You’ll be logged out of the application.
4. Re-login with your new credentials.

Creating a zone

1. Login into your iDNS.cgi backend at https://yourserverip:9333/cgi-bin/iDNS.cgi using the Root username and the password you used.

1. Click on the tZone tab. You’ll see the screen shown below

1. Press the [New] button at the top navigation bar. You should only change the cZone field value with the new zone name. The TTLs set for the sample zone should work for this simple test.
2. Once you changed the cZone field value, to smart.com in our example; press the [Confirm New] button at the left panel.
3. Then, if you click on the tJob tab you’ll see two job entries, one for the master and the other for the slave of the preconfigured nameserver set.

1. After the job queue gets processed for the master server (this should take one minute or so, until the cron job gets executed) you should be able to query your nameserver for the SOA of the created zone:

   [root@localhost ~]# dig @localhost soa smart.com
   
   ; <<>> DiG 9.3.4-P1 <<>> @localhost soa smart.com
   ; (1 server found)
   ;; global options:  printcmd
   ;; Got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57687
   ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
   
   ;; QUESTION SECTION:
   ;smart.com.                     IN      SOA
   
   ;; ANSWER SECTION:
   smart.com.              86400   IN      SOA     ns1.yourdomain.com. hostmaster.yourdomain.com. 2009051900 28800 7200 604800 86400
   
   ;; AUTHORITY SECTION:
   smart.com.              86400   IN      NS      ns2.yourdomain.com.
   smart.com.              86400   IN      NS      ns1.yourdomain.com.
   
   ;; ADDITIONAL SECTION:
   ns1.yourdomain.com.     86400   IN      A       192.0.0.1
   ns2.yourdomain.com.     86400   IN      A       192.168.0.2
   
   ;; Query time: 42 msec
   ;; SERVER: 127.0.0.1#53(127.0.0.1)
   ;; WHEN: Tue May 19 09:28:02 2009
   ;; MSG SIZE  rcvd: 153

Adding RRs to a zone

1. Provided you have gone through the section above, for starting click on the tZone tab.
2. Enter smart at the cSearch box at the left panel (Highlighted with green below) and press <Enter>
3. You should see the tZone record for the smart.com zone

1. Then press the [Add Resource Record] button at the left panel (Highlighted with blue above.)
2. You’ll the the tResource tab, with the fields opened for writing. Complete them as the image below shows:

1. To add the new RR press the [Confirm New] button at the left panel.
2. Wait a minute and test the new RR with dig:

   [root@localhost ~]# dig @localhost www.smart.com
   
   ; <<>> DiG 9.3.4-P1 <<>> @localhost www.smart.com
   ; (1 server found)
   ;; global options:  printcmd
   ;; Got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23724
   ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
   
   ;; QUESTION SECTION:
   ;www.smart.com.                 IN      A
   
   ;; ANSWER SECTION:
   www.smart.com.          86400   IN      A       192.168.0.45
   
   ;; AUTHORITY SECTION:
   smart.com.              86400   IN      NS      ns1.yourdomain.com.
   smart.com.              86400   IN      NS      ns2.yourdomain.com.
   
   ;; ADDITIONAL SECTION:
   ns1.yourdomain.com.     86400   IN      A       192.0.0.1
   ns2.yourdomain.com.     86400   IN      A       192.168.0.2
   
   ;; Query time: 11 msec
   ;; SERVER: 127.0.0.1#53(127.0.0.1)
   ;; WHEN: Tue May 19 10:13:24 2009
   ;; MSG SIZE  rcvd: 126

Configuring your NS Set

Now that you have learned how to create a zone and RRs, let’s move to the final step of this ‘Getting Started’ guide. This section will show you how to configure a NS Set. But first, a little of theory.

What are NS Sets?

Basically, a NS set is a group of nameservers, being those masters or slaves. The server function doesn’t matter as regards this grouping. unxsBind has various tables that organize this system.

tServer ----  tNS ---- tNSType
                   |
               tNSSet

Let’s explain this. The tServer table keeps track of the server records. A server in this context, is the physical hardware (e.g. OpenVZ hardware node) which runs the nameserver identified by the tNS record. At the same time, this nameserver record belongs to a group, which is indicated by a tNSSet record. Moreover, the type of nameserver (master, hidden master or slave) is set by a tNSType record associated with the tNS record.

All these tables are hidden in the tab menu, but you can access them from the ‘Main’ tab, by clicking on the respective link, as the image below shows:

Editing tServer data

If you look at the tServer records which come with the unxsBind sample data, you’ll see two servers:

Assuming you’ll have a master and a slave server, you need to modify these records according with your setup. Modify the greenday.yourdomain.com to match your master server hardware hostname. For doing so:

1. Click on the greenday.yourdomain.com link at the left panel navigation list.
2. Press the [Modify] button at the top navigation bar.
3. Edit the value of the cLabel field.
4. Press the [Confirm Modify] button at the left panel.

Now, repeat the above process for the blink182.yourdomain.com server. Remember that this one should match your slave server hardware hostname.

Editing tNSSet data

unxsBind comes with three NS Sets preconfigured. Probably you will use only one for your initial setup, so we will leave the other NS set untouched in this tutorial. The NS set we are going to modify is the ‘ns1-2.yourdomain.com’ set.

For modifying it:

1. Press on the ‘ns1-2.yourdomain.com’ link at the left panel
2. Press the [Modify] button at the top navigation bar.
3. Edit the value of the cLabel field. Enter a sensible name, like ns1-2.yourcompany.com.
4. Specify the IP address of your master server in the cMasterIPs field. If using multiple master servers, put a semicolon (;) between the IP addresses. If using only a single master, append the semi-colon to the IP address.
5. Press the [Confirm Modify] button at the left panel.

Editing tNS data

These three NS sets that come preconfigured, have their members setup at the tNS table, in this tutorial we will deal with ns1 and ns2 .yourdomain.com, master and slave respectively

We have to modify the ns1.yourdomain.com record to match your master server hostname. For doing so:

1. Click on the ns1.yourdomain.com link at the left panel
2. Press the [Modify] button at the top navigation bar.
3. Edit the value of the cLabel field to match your master server hostname.
4. Press the [Confirm Modify] button at the left panel.

Then repeat for ns2.yourdomain.com

Putting the server into production

Now that you’ve reached this point, you should change the BIND listening IP address to other than 127.0.0.1. For doing so, edit the /usr/local/idns/named.conf file. The section we are interested in is the ‘options’ section. The unxsBind rpm will install a named.conf with the following ‘options’ section:

options {
        directory "/usr/local/idns/named.d";
        listen-on { 127.0.0.1; 127.0.0.1; };
        version "No version information available";
        query-source address 127.0.0.1 port 53;
        pid-file "/usr/local/idns/named.pid";

        //tHit susbsystem required
        zone-statistics yes;

        //multi master configuration
        //if all your servers are masters (recommended)
        //this still allows secondary only zones i.e. external masters
        notify no;

        //master.zones will turn off recursion based on view
        //if any view needs recursion it must be "yes" here.
        recursion yes;
};

You have to change the

        listen-on { 127.0.0.1; 127.0.0.1; };

line to:

        listen-on { 192.168.238.133; 127.0.0.1; };

Provided that 192.168.238.133 is the IP address of the interface your master server will bind connections to. Once that’s done run:

# rndc reconfig

You should see that now your BIND server also listens at the IP address specified above:

[root@localhost ~]# netstat -tnl
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State
tcp        0      0 0.0.0.0:3306                0.0.0.0:*                   LISTEN
tcp        0      0 192.168.238.133:53          0.0.0.0:*                   LISTEN
tcp        0      0 127.0.0.1:53                0.0.0.0:*                   LISTEN
tcp        0      0 127.0.0.1:953               0.0.0.0:*                   LISTEN
tcp        0      0 :::80                       :::*                        LISTEN
tcp        0      0 :::9333                     :::*                        LISTEN
tcp        0      0 :::22                       :::*                        LISTEN
tcp        0      0 :::443                      :::*                        LISTEN

Building the slave server

(soon)

从CSDN开始。到多玩、人人、猫扑。

我想在这几个网站上没有注册的网民是很少的了。

    鉴于网络的不安全性。还是建议大家将各个网站的用户名和密码都分开设置吧！   太恐怖了。如果全部网站的用户名和密码都是统一的。那岂不是一个网站的密码被盗。全部密码都裸奔了。。。

现在的各类在线破解MD5加密算法的网站比比皆是！  拿到一个MD5值不在像几年前难以破解了。

更莫说想CSDN这类明文报错的网站了。

看到此贴的用户们。建议你们立即修改你的密码吧！！

You can easily prevent the kernel module from loading by updating the following two files:

/etc/modprobe.conf - Kernel driver configuration file.
/etc/sysconfig/network - RHEL / CentOS networking configuration file. 

/etc/modprobe.conf

Edit /etc/modprobe.conf, enter:

# vi /etc/modprobe.conf 

Append the following line:

install ipv6 /bin/true

Save and close the file.

/etc/sysconfig/network

Edit /etc/sysconfig/network, enter:

# vi /etc/sysconfig/network 

Update / add as follows:

  NETWORKING_IPV6=no
IPV6INIT=no  

Save and close the file. Restart networking service

# service network restart
# rmmod ipv6 

Alternatively, simple reboot the box:

# reboot 

Verify IPv6 is disabled, enter:

# lsmod | grep ipv6
# /sbin/ifconfig

卸载掉RHEL6自带的YUM包。

    使用下列命令检查YUM的依赖关系。

rpm -qR yum

得到的依赖关系有：

[root@bogon doc]# rpm -qR yum-3.2.27-14.el6.noarch
/usr/bin/python
config(yum) = 3.2.27-14.el6
pygpgme
python >= 2.4
python(abi) = 2.6
python-iniparse
python-sqlite
python-urlgrabber >= 3.9.0-8
rpm >= 0:4.4.2
rpm-python
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
yum-metadata-parser >= 1.1.0
rpmlib(PayloadIsXz) <= 5.2-1
[root@bogon doc]# rpm -qR yum
/usr/bin/python
config(yum) = 3.2.27-14.el6
pygpgme
python >= 2.4
python(abi) = 2.6
python-iniparse
python-sqlite
python-urlgrabber >= 3.9.0-8
rpm >= 0:4.4.2
rpm-python
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
yum-metadata-parser >= 1.1.0
rpmlib(PayloadIsXz) <= 5.2-1

使用YUM来卸载掉自己。

命令是：

yum erase yum

运行结果是：

[root@bogon doc]# yum erase yum
Loaded plugins: rhnplugin
This system is not registered with RHN.
RHN support will be disabled.
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package yum.noarch 0:3.2.27-14.el6 set to be erased
--> Processing Dependency: yum >= 3.2.19-15 for package: yum-rhn-plugin-0.9.1-5.el6.noarch
--> Processing Dependency: yum >= 3.2.25-10 for package: yum-utils-1.1.26-11.el6.noarch
--> Running transaction check
---> Package yum-rhn-plugin.noarch 0:0.9.1-5.el6 set to be erased
--> Processing Dependency: yum-rhn-plugin >= 0.5.3-30 for package: rhn-check-1.0.0-38.el6.noarch
---> Package yum-utils.noarch 0:1.1.26-11.el6 set to be erased
--> Processing Dependency: yum-utils for package: abrt-addon-ccpp-1.1.13-4.el6.i686
--> Running transaction check
---> Package abrt-addon-ccpp.i686 0:1.1.13-4.el6 set to be erased
--> Processing Dependency: abrt-addon-ccpp for package: abrt-cli-1.1.13-4.el6.i686
---> Package rhn-check.noarch 0:1.0.0-38.el6 set to be erased
--> Processing Dependency: rhn-check >= 0.0.8 for package: rhnsd-4.9.3-2.el6.i686
--> Running transaction check
---> Package abrt-cli.i686 0:1.1.13-4.el6 set to be erased
---> Package rhnsd.i686 0:4.9.3-2.el6 set to be erased
--> Processing Dependency: rhnsd for package: rhn-setup-1.0.0-38.el6.noarch
--> Running transaction check
---> Package rhn-setup.noarch 0:1.0.0-38.el6 set to be erased
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================================
 Package       Arch   Version       Repository                                             Size
================================================================================================
Removing:
 yum           noarch 3.2.27-14.el6 @anaconda-RedHatEnterpriseLinux-201009221732.i386/6.0 3.8 M
Removing for dependencies:
 abrt-addon-ccpp
               i686   1.1.13-4.el6  @anaconda-RedHatEnterpriseLinux-201009221732.i386/6.0  49 k
 abrt-cli      i686   1.1.13-4.el6  @anaconda-RedHatEnterpriseLinux-201009221732.i386/6.0  63 k
 rhn-check     noarch 1.0.0-38.el6  @anaconda-RedHatEnterpriseLinux-201009221732.i386/6.0  38 k
 rhn-setup     noarch 1.0.0-38.el6  @anaconda-RedHatEnterpriseLinux-201009221732.i386/6.0 190 k
 rhnsd         i686   4.9.3-2.el6   @anaconda-RedHatEnterpriseLinux-201009221732.i386/6.0  89 k
 yum-rhn-plugin
               noarch 0.9.1-5.el6   @anaconda-RedHatEnterpriseLinux-201009221732.i386/6.0 174 k
 yum-utils     noarch 1.1.26-11.el6 @anaconda-RedHatEnterpriseLinux-201009221732.i386/6.0 239 k

Transaction Summary
================================================================================================
Remove        8 Package(s)
Reinstall     0 Package(s)
Downgrade     0 Package(s)

Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Erasing        : abrt-cli-1.1.13-4.el6.i686                                                                                                            1/8
  Erasing        : rhn-check-1.0.0-38.el6.noarch                                                                                                         2/8
  Erasing        : yum-rhn-plugin-0.9.1-5.el6.noarch                                                                                                     3/8
  Erasing        : rhn-setup-1.0.0-38.el6.noarch                                                                                                         4/8
  Erasing        : rhnsd-4.9.3-2.el6.i686                                                                                                                5/8
  Erasing        : abrt-addon-ccpp-1.1.13-4.el6.i686                                                                                                     6/8
  Erasing        : yum-utils-1.1.26-11.el6.noarch                                                                                                        7/8
  Erasing        : yum-3.2.27-14.el6.noarch                                                                                                              8/8 

Removed:
  yum.noarch 0:3.2.27-14.el6                                                                                                                                 

Dependency Removed:
  abrt-addon-ccpp.i686 0:1.1.13-4.el6     abrt-cli.i686 0:1.1.13-4.el6            rhn-check.noarch 0:1.0.0-38.el6      rhn-setup.noarch 0:1.0.0-38.el6
  rhnsd.i686 0:4.9.3-2.el6                yum-rhn-plugin.noarch 0:0.9.1-5.el6     yum-utils.noarch 0:1.1.26-11.el6    

Complete!

重新安装Centos的YUM包。

然后重新安装Centos6.0的YUM包。

安装YUM需要的RPM包有：

yum-3.2.27-14.el6.centos.noarch.rpm
yum-plugin-fastestmirror-1.1.26-11.el6.noarch.rpm

这两个RPM包的下载地址为：

http://mirrors.163.com/centos/6.0/os/i386/Packages/yum-3.2.27-14.el6.centos.noarch.rpm

http://mirrors.163.com/centos/6.0/os/i386/Packages/yum-plugin-fastestmirror-1.1.26-11.el6.noarch.rpm

建议将2个RPM包下载到一个单独的文件夹。下载完成后，安装这2个RPM包。

安装命令：

省时间的方式是：

rpm -ivh *.rpm

NB的方式是：

rpm -ivh yum-3.2.27-14.el6.centos.noarch.rpm  yum-plugin-fastestmirror-1.1.26-11.el6.noarch.rpm

小问题：

    如果直接安装Centos的YUM包，并修改YUM源后会发现不能够正常的Yum install文件，并提示下列错误：

http://mirrors.163.com/centos/%24releasever/os/i386/repodata/repomd.xml: [Errno 14] HTTP Error 404 : http://mirrors.163.com/centos/%24releasever/os/i386/repodata/repomd.xml 
Trying other mirror.
Error: Cannot retrieve repository metadata (repomd.xml) for repository: base. Please verify its path and try again

这是因为没有修改RHEL的发行版本造成的。如果要修正这个问题则需要执行下列命令：

rpm -e --nodeps redhat-release-server-6Server-6.0.0.37.el6.i686 redhat-indexhtml-6-1.el6.noarch

然后下载Centos的release和indexhtml包，安装即可。

wget http://mirrors.163.com/centos/6.0/os/i386/Packages/centos-indexhtml-6-1.el6.centos.noarch.rpm
wget http://mirrors.163.com/centos/6.0/os/i386/Packages/centos-release-6-0.el6.centos.5.i686.rpm

安装这2个包即可。

yum clean all

到这儿跟换RHEL的YUM源到Centos的操作已经完成了。

下载地址：

I386版：

ed2k://|file|%5B%E3%80%8A%E7%BA%A2%E5%B8%BDLinux6.0.%E6%9C%8D%E5%8A%A1%E5%99%A8%E7%89%88%E3%80%8B%28Red.Hat.Enterprise.Linux.Server.6.0%29%E5%AE%98%E6%96%B9%E5%A4%9A%E5%9B%BD%E8%AF%AD%E8%A8%80%E7%89%88%2C%E9%80%82%E7%94%A8x86%E5%92%8Cx64%E5%B9%B3%E5%8F%B0%5B%E5%85%89%E7%9B%98%E9%95%9C%E5%83%8F%5D%5D.rhel-server-6.0-i386-dvd.iso|2931056640|503184dff4dd37542eee6e57f4a85341|h=azsa3gqbngp23ujbqeyc3ghd4wwtdley|/

X86_64版：

ed2k://|file|%5B%E3%80%8A%E7%BA%A2%E5%B8%BDLinux6.0.%E6%9C%8D%E5%8A%A1%E5%99%A8%E7%89%88%E3%80%8B%28Red.Hat.Enterprise.Linux.Server.6.0%29%E5%AE%98%E6%96%B9%E5%A4%9A%E5%9B%BD%E8%AF%AD%E8%A8%80%E7%89%88%2C%E9%80%82%E7%94%A8x86%E5%92%8Cx64%E5%B9%B3%E5%8F%B0%5B%E5%85%89%E7%9B%98%E9%95%9C%E5%83%8F%5D%5B2010%E5%B9%B411%E6%9C%8812%E6%97%A5%E6%9B%B4%E6%96%B0x64%E7%89%88%E6%9C%AC%5D%5D.rhel-server-6.0-x86_64-dvd.iso|3431618560|c9834d41931eaea393da9f19d08c1a6b|h=wpd3ow4ujlc3k5miv2wym5z6gzr73c4k|/

MD5值：

file: rhel-server-6.0-i386-dvd.iso
 size: 2,795 MB
 md5: 291d234c93442405972689b4b41c14bc
 sha256: 3b637b7120c855eb775a35a3d281232525eed223c6a1ea8a35b20fd17af5fba4

file: rhel-server-6.0-x86_64-dvd.iso
 size: 3,273 MB
 md5: f7141396c6a19399d63e8c195354317d
 sha256: a6fef01cb4d790975a11479018785bfe4e04b9bdeaea8be24c8a4055f98d127e

相关截图：

下载连接：

[DNS.and.BIND.on.IPv6(第1版)].(DNS.and.BIND.on.IPv6).Cricket.Liu.文字版.pdf

中文名: DNS and BIND on IPv6 (第1版)

原名: DNS and BIND on IPv6, 1st edition

作者: Cricket Liu

图书分类: 软件

资源格式: PDF

版本: 英文文字版/更新EPUB版本

出版社: O’Reilly

书号: 978-1449305192

发行时间: 2011年05月27日

地区: 美国

语言: 英文

简介:

内容介绍：

If you’re preparing to roll out IPv6 on your network, this concise book provides the essentials you need to support this protocol with DNS. You’ll learn how DNS was extended to accommodate IPv6 addresses, and how you can configure a BIND name server to run on the network. This book also features methods for troubleshooting problems with IPv6 forward- and reverse-mapping, techniques for helping islands of IPv6 clients communicate with IPv4 resources, and many other topics.

作者介绍：

Cricket Liu

Cricket Liu graduated from the University of California, Berkeley, that great bastion of free speech, unencumbered Unix, and cheap pizza. He joined Hewlett-Packard after graduation and worked for HP for nine years.

Cricket began managing the hp.com zone after the Loma Prieta earthquake forcibly transferred the zone’s management from HP Labs to HP’s Corporate Offices (by cracking a sprinkler main and flooding a Labs computer room). Cricket was hostmaster@hp.com for over three years, and then joined HP’s Professional Services Organization to co-found HP’s Internet Consulting Program.

Cricket left HP in 1997 to form Acme Byte & Wire, a DNS consulting and training company, with his friend Matt Larson. Network Solutions acquired Acme in June 2000, and later the same day merged with VeriSign. Cricket worked for a year as Director of DNS Product Management for VeriSign Global Registry Services.

Cricket joined Infoblox, a company that develops DNS and DHCP appliances, in March, 2003. He is currently their Vice President of Architecture.

Cricket, his wife, Paige, their son, Walt, and daughter, Greta, live in California with their two Siberian Huskies, Annie and Dakota.

内容截图：

目录:

Chapter 1 DNS and IPv6

Chapter 2 BIND on IPv6

Chapter 3 Resolver Configuration

Chapter 4 DNS64

Chapter 5 Troubleshooting