BlogJava-Chan Chen Coding...-文章分类-Networkhttp://www.blogjava.net/czihong/category/50892.htmlzh-cnTue, 04 Dec 2012 20:39:52 GMTTue, 04 Dec 2012 20:39:52 GMT60各种远程通信协议分析、比较http://www.blogjava.net/czihong/articles/392411.htmlChan ChenChan ChenTue, 04 Dec 2012 06:06:00 GMThttp://www.blogjava.net/czihong/articles/392411.htmlhttp://www.blogjava.net/czihong/comments/392411.htmlhttp://www.blogjava.net/czihong/articles/392411.html#Feedback0http://www.blogjava.net/czihong/comments/commentRss/392411.htmlhttp://www.blogjava.net/czihong/services/trackbacks/392411.html阅读全文

Chan Chen 2012-12-04 14:06 发表评论
]]>Dos Attackhttp://www.blogjava.net/czihong/articles/379260.htmlChan ChenChan ChenFri, 25 May 2012 18:44:00 GMThttp://www.blogjava.net/czihong/articles/379260.htmlhttp://www.blogjava.net/czihong/comments/379260.htmlhttp://www.blogjava.net/czihong/articles/379260.html#Feedback0http://www.blogjava.net/czihong/comments/commentRss/379260.htmlhttp://www.blogjava.net/czihong/services/trackbacks/379260.html什么是DoS攻击 
那么，DoS到底是什么？接触PC机较早的同志会直接想到微软磁盘操作系统 的DOS--Disk Operation System？哦，不不不，我看盖茨可不像是黑客的老大哟！此DoS非彼DOS也，DoS即Denial Of Service，拒绝服务的缩写。DoS是指故意的攻击网络协议实现的缺陷或直接通过野蛮手段残忍地耗尽被攻击对象的资源，目的是让目标计算机或网络无法提供正常的服务或资源访问，使目标系统服务系统停止响应甚至崩溃，而在此攻击中并不包括侵入目标服务器或目标网络设备。这些服务资源包括网络带宽，文件系统空间容量，开放的进程或者允许的连接。这种攻击会导致资源的匮乏，无论计算机的处理速度多快、内存容量多大、网络带宽的速度多快都无法避免这种攻击带来的后果。要知道任何事物都有一个极限，所以总能找到一个方法使请求的值大于该极限值，因此就会故意导致所提供的服务资源匮乏，表面上好象是服务资源无法满足需求。所以千万不要自认为拥有了足够宽的带宽和足够快的服务器就有了一个不怕DoS攻击的高性能网站，拒绝服务攻击会使所有的资源变得非常渺小。 
其实，我们作个形象的比喻来理解DoS。街头的餐馆是为大众提供餐饮服务，如果一群地痞流氓要DoS餐馆的话，手段会很多，比如霸占着餐桌不结账，堵住餐馆的大门不让路，骚扰餐馆的服务员或厨子不能干活，甚至更恶劣……相应的计算机和网络系统则是为Internet 用户提供互联网资源的，如果有黑客要进行DoS攻击的话，可以想象同样有好多手段！今天最常见的DoS攻击有对计算机网络的带宽攻击和连通性攻击。带宽攻击指以极大的通信量冲击网络，使得所有可用网络资源都被消耗殆尽，最后导致合法的用户请求无法通过。连通性攻击指用大量的连接请求冲击计算机，使得所有可用的操作系统资源都被消耗殆尽，最终计算机无法再处理合法用户的请求。 什么是DDoS 

传统上，攻击者所面临的主要问题是网络带宽，由于较小的网络规模和较慢的网络速度的限制，攻击者无法发出过多的请求。虽然类似"the ping of death"的攻击类型只需要较少量的包就可以摧毁一个没有打过补丁的UNIX系统，但大多数的DoS攻击还是需要相当大的带宽的，而以个人为单位的黑客们很难使用高带宽的资源。为了克服这个缺点，DoS攻击者开发了分布式的攻击。攻击者简单利用工具集合许多的网络带宽来同时对同一个目标发动大量的攻击请求，这就是DDoS攻击。 
DDoS（Distributed Denial Of Service）又把DoS又向前发展了一大步，这种分布式拒绝服务攻击是黑客利用在已经侵入并已控制的不同的高带宽主机（可能是数百，甚至成千上万台）上安装大量的DoS服务程序，它们等待来自中央攻击控制中心的命令，中央攻击控制中心在适时启动全体受控主机的DoS服务进程，让它们对一个特定目标发送尽可能多的网络访问请求，形成一股DoS洪流冲击目标系统，猛烈的DoS攻击同一个网站。在寡不敌众的力量抗衡下，被攻击的目标网站会很快失去反应而不能及时处理正常的访问甚至系统瘫痪崩溃。可见DDoS与DoS的最大区别是人多力量大。DoS是一台机器攻击目标，DDoS是被中央攻击中心控制的很多台机器利用他们的高带宽攻击目标，可更容易地将目标网站攻下。另外，DDoS攻击方式较为自动化，攻击者可以把他的程序安装到网络中的多台机器上，所采用的这种攻击方式很难被攻击对象察觉，直到攻击者发下统一的攻击命令，这些机器才同时发起进攻。可以说DDoS攻击是由黑客集中控制发动的一组DoS攻击的集合，现在这种方式被认为是最有效的攻击形式，并且非常难以抵挡。 
无论是DoS攻击还是DDoS攻击，简单的看，都只是一种破坏网络服务的黑客方式，虽然具体的实现方式千变万化，但都有一个共同点，就是其根本目的是使受害主机或网络无法及时接收并处理外界请求，或无法及时回应外界请求。其具体表现方式有以下几种： 
1．制造大流量无用数据，造成通往被攻击主机的网络拥塞，使被攻击主机无法正常和外界通信。

2．利用被攻击主机提供服务或传输协议上处理重复连接的缺陷，反复高频的发出攻击性的重复服务请求，使被攻击主机无法及时处理其它正常的请求。 
3．利用被攻击主机所提供服务程序或传输协议的本身实现缺陷，反复发送畸形的攻击数据引发系统错误的分配大量系统资源，使主机处于挂起状态甚至死机。 

常见的DoS攻击 

拒绝服务攻击是一种对网络危害巨大的恶意攻击。今天，DoS具有代表性的攻击手段包括Ping of Death、TearDrop、UDP flood 、SYN flood、Land Attack、IP Spoofing DoS等。我们看看它们又是怎么实现的。 

死亡之 ping ( ping of death ) ：ICMP (Internet Control Message Protocol，Internet控制信息协议)在Internet上用于错误处理和传递控制信息。它的功能之一是与主机联系，通过发送一个"回音请求"（echo request）信息包看看主机是否"活着"。最普通的ping程序就是这个功能。而在TCP/IP的RFC文档中对包的最大尺寸都有严格限制规定，许多操作系统的TCP/IP协议栈都规定ICMP 包大小为64KB，且在对包的标题头进行读取之后，要根据该标题头里包含的信息来为有效载荷生成缓冲区。"Ping of Death" 就是故意产生畸形的测试Ping（Packet Internet Groper）包，声称自己的尺寸超过 ICMP 上限，也就是加载的尺寸超过 64KB上限，使未采取保护措施的网络系统出现内存分配错误，导致 TCP/IP 协议栈崩溃，最终接收方荡机。 

泪滴( teardrop ) ：泪滴攻击利用在 TCP/IP 协议栈实现中信任IP 碎片中的包的标题头所包含的信息来实现自己的攻击。IP 分段含有指示该分段所包含的是原包的哪一段的信息，某些 TCP/IP协议栈（例如NT 在service pack 4 以前）在收到含有重叠偏移的伪造分段时将崩溃。 UDP 洪水 (UDP flood) ：如今在Internet上UDP（用户数据包协议）的应用比较广泛，很多提供WWW和Mail等服务设备通常是使用Unix的服务器，它们默认打开一些被黑客恶意利用的UDP服务。如echo服务会显示接收到的每一个数据包，而原本作为测试功能的chargen服务会在收到每一个数据包时随机反馈一些字符。UDP flood假冒攻击就是利用这两个简单的 TCP/IP 服务的漏洞进行恶意攻击，通过伪造与某一主机的 Chargen 服务之间的一次的 UDP 连接，回复地址指向开着Echo 服务的一台主机，通过将Chargen 和 Echo服务互指，来回传送毫无用处且占满带宽的垃圾数据，在两台主机之间生成足够多的无用数据流，这一拒绝服务攻击飞快地导致网络可用带宽耗尽。 SYN 洪水 ( SYN flood ) ：我们知道当用户进行一次标准的TCP（Transmission Control Protocol）连接时，会有一个3次握手过程。首先是请求服务方发送一个SYN（Synchronize Sequence Number）消息，服务方收到SYN后，会向请求方回送一个SYN-ACK表示确认，当请求方收到SYN-ACK后，再次向服务方发送一个ACK消息，这样一次TCP连接建立成功。"SYN Flooding"则专门针对TCP协议栈在两台主机间初始化连接握手的过程进行DoS攻击，其在实现过程中只进行前2个步骤：当服务方收到请求方的SYN-ACK确认消息后，请求方由于采用源地址欺骗等手段使得服务方收不到ACK回应，于是服务方会在一定时间处于等待接收请求方ACK消息的状态。而对于某台服务器来说，可用的TCP连接是有限的，因为他们只有有限的内存缓冲区用于创建连接，如果这一缓冲区充满了虚假连接的初始信息，该服务器就会对接下来的连接停止响应，直至缓冲区里的连接企图超时。如果恶意攻击方快速连续地发送此类连接请求，该服务器可用的TCP连接队列将很快被阻塞，系统可用资源急剧减少，网络可用带宽迅速缩小，长此下去，除了少数幸运用户的请求可以插在大量虚假请求间得到应答外，服务器将无法向用户提供正常的合法服务。 

Land （Land Attack）攻击：在 Land 攻击中，黑客利用一个特别打造的SYN 包--它的原地址和目标地址都被设置成某一个服务器地址进行攻击。此举将导致接受服务器向它自己的地址发送 SYN-ACK 消息，结果这个地址又发回 ACK 消息并创建一个空连接，每一个这样的连接都将保留直到超时，在 Land 攻击下，许多 UNIX将崩溃，NT 变得极其缓慢（大约持续五分钟）。 
IP欺骗DOS攻击：这种攻击利用TCP协议栈的RST位来实现，使用IP欺骗，迫使服务器把合法用户的连接复位，影响合法用户的连接。假设现在有一个合法用户(100.100.100.100)已经同服务器建立了正常的连接，攻击者构造攻击的TCP数据，伪装自己的IP为100.100.100.100，并向服务器发送一个带有RST位的TCP数据段。服务器接收到这样的数据后，认为从100.100.100.100发送的连接有错误，就会清空缓冲区中已建立好的连接。这时，合法用户100.100.100.100再发送合法数据，服务器就已经没有这样的连接了，该用户就被拒绝服务而只能重新开始建立新的连接。 

常见的DDoS攻击 

smurf、Fraggle 攻击、Trinoo、Tribe Flood Network(TFN)、TFN2k以及Stacheldraht是比较常见的DDoS攻击程序，我们再看看它们的原理，其攻击思路基本相近。 Smurf 攻击：Smurf是一种简单但有效的 DDoS 攻击技术，Smurf还是利用ping程序进行源IP假冒的直接广播进行攻击。在Internet上广播信息可以通过一定的手段（通过广播地址或其他机制）发送到整个网络中的机器。当某台机器使用广播地址发送一个ICMP echo请求包时（例如Ping），一些系统会回应一个ICMP echo回应包，这样发送一个包会收到许多的响应包。Smurf攻击就是使用这个原理来进行的，同时它还需要一个假冒的源地址。也就是说Smurf在网络中发送的源地址为要攻击的主机地址，目的地址为广播地址的ICMP echo请求包，使许多的系统同时响应并发送大量的信息给被攻击主机（因为他的地址被攻击者假冒了）。Smurf是用一个伪造的源地址连续ping一个或多个计算机网络，这就导致所有计算机响应的那个主机地址并不是实际发送这个信息包的攻击计算机。这个伪造的源地址，实际上就是攻击的目标，它将被极大数量的响应信息量所淹没。对这个伪造信息包做出响应的计算机网络就成为攻击的不知情的同谋。一个简单的 smurf 攻击最终导致网络阻塞和第三方崩溃，这种攻击方式要比 ping of death 洪水的流量高出一两个数量级。这种使用网络发送一个包而引出大量回应的方式也被叫做Smurf"放大"。 

Fraggle 攻击：Fraggle 攻击对 Smurf 攻击作了简单的修改，使用的是 UDP 应答消息而非 ICMP。 

"trinoo"攻击：trinoo 是复杂的 DDoS 攻击程序，是基于UDP flood的攻击软件。它使用"master"程序对实际实施攻击的任何数量的"代理"程序实现自动控制。当然在攻击之前，侵入者为了安装软件，已经控制了装有master程序的计算机和所有装有代理程序的计算机。攻击者连接到安装了master程序的计算机，启动master程序，然后根据一个IP地址的列表，由master程序负责启动所有的代理程序。接着，代理程序用UDP 信息包冲击网络，向被攻击目标主机的随机端口发出全零的4字节UDP包，在处理这些超出其处理能力垃圾数据包的过程中，被攻击主机的网络性能不断下降，直到不能提供正常服务，乃至崩溃。它对IP地址不做假，因此此攻击方法用得不多。 

"Tribal Flood Network"和 "TFN2K" 攻击：Tribe Flood Network与trinoo一样，使用一个master程序与位于多个网络上的攻击代理进行通讯，利用ICMP给代理服务器下命令，其来源可以做假。TFN可以并行发动数不胜数的DoS攻击，类型多种多样，而且还可建立带有伪装源IP地址的信息包。 可以由TFN发动的攻击包括：SYN flood、UDP flood、ICMP回音请求flood及Smurf（利用多台服务器发出海量数据包，实施DoS攻击）等攻击。TFN的升级版TFN2k进一步对命令数据包加密，更难查询命令内容，命令来源可以做假，还有一个后门控制代理服务器。 

"stacheldraht"攻击：Stacheldraht也是基于TFN和trinoo一样的客户机/服务器模式，其中Master程序与潜在的成千个代理程序进行通讯。在发动攻击时，侵入者与master程序进行连接。Stacheldraht增加了新的功能：攻击者与master程序之间的通讯是加密的，对命令来源做假，而且可以防范一些路由器用RFC2267过滤，若检查出有过滤现象，它将只做假IP地址最后8位，从而让用户无法了解到底是哪几个网段的哪台机器被攻击；同时使用rcp (remote copy，远程复制)技术对代理程序进行自动更新。Stacheldraht 同TFN一样，可以并行发动数不胜数的DoS攻击，类型多种多样，而且还可建立带有伪装源IP地址的信息包。Stacheldraht所发动的攻击包括UDP 冲击、TCP SYN 冲击、ICMP 回音应答冲击。 
如何防止DoS/DdoS攻击 

DoS攻击几乎是从互联网络的诞生以来，就伴随着互联网络的发展而一直存在也不断发展和升级。值得一提的是，要找DoS的工具一点不难，黑客群居的网络社区都有共享黑客软件的传统，并会在一起交流攻击的心得经验，你可以很轻松的从Internet上获得这些工具，像以上提到的这些DoS攻击软件都是可以从网上随意找到的公开软件。所以任何一个上网者都可能构成网络安全的潜在威胁。DoS攻击给飞速发展的互联网络安全带来重大的威胁。然而从某种程度上可以说，DoS攻击永远不会消失而且从技术上目前没有根本的解决办法。 
面对凶多吉少的DoS险滩，我们该如何对付随时出现的黑客攻击呢？让我们首先对造成DoS攻击威胁的技术问题做一下总结。DoS攻击可以说是如下原因造成的： 
1．软件弱点是包含在操作系统或应用程序中与安全相关的系统缺陷，这些缺陷大多是由于错误的程序编制，粗心的源代码审核，无心的副效应或一些不适当的绑定所造成的。由于使用的软件几乎完全依赖于开发商，所以对于由软件引起的漏洞只能依*打补丁，安装hot fixes和Service packs来弥补。当某个应用程序被发现有漏洞存在，开发商会立即发布一个更新的版本来修正这个漏洞。由于开发协议固有的缺陷导致的DoS攻击，可以通过简单的补丁来弥补系统缺陷。 
2．错误配置也会成为系统的安全隐患。这些错误配置通常发生在硬件装置，系统或者应用程序中，大多是由于一些没经验的，无责任员工或者错误的理论所导致的。如果对网络中的路由器，防火墙，交换机以及其他网络连接设备都进行正确的配置会减小这些错误发生的可能性。如果发现了这种漏洞应当请教专业的技术人员来修理这些问题。 
3．重复请求导致过载的拒绝服务攻击。当对资源的重复请求大大超过资源的支付能力时就会造成拒绝服务攻击（例如，对已经满载的Web服务器进行过多的请求使其过载）。 
要避免系统免受DoS攻击，从前两点来看，网络管理员要积极谨慎地维护系统，确保无安全隐患和漏洞；而针对第三点的恶意攻击方式则需要安装防火墙等安全设备过滤DoS攻击，同时强烈建议网络管理员应当定期查看安全设备的日志，及时发现对系统的安全威胁行为。 
3Com公司是一个全面的企业网络解决方案提供商，旨在为企业用户提供"丰富、简单、灵活、可*而高性能价格比"的网络解决方案。Internet支持工具就是其中的主要解决方案之一，包括SuperStack 3 Firewall、Web Cache以及Server Load Balancer。不但作为安全网关设备的3Com SuperStack 3 防火墙在缺省预配置下可探测和防止"拒绝服务"(DoS)以及"分布式拒绝服务"(DDoS)等黑客侵袭，强有力的保护您的网络，使您免遭未经授权访问和其他来自Internet的外部威胁和侵袭；而且3Com SuperStack 3 Server Load Balancer在为多服务器提供硬件线速的4-7层负载均衡的同时，还能保护所有服务器免受"拒绝服务"(DoS)攻击；同样3Com SuperStack 3 Web Cache在为企业提供高效的本地缓存的同时，也能保证自身免受"拒绝服务"(DoS)攻击



Chan Chen 2012-05-26 02:44 发表评论
]]>Gatewayhttp://www.blogjava.net/czihong/articles/378896.htmlChan ChenChan ChenWed, 23 May 2012 00:43:00 GMThttp://www.blogjava.net/czihong/articles/378896.htmlhttp://www.blogjava.net/czihong/comments/378896.htmlhttp://www.blogjava.net/czihong/articles/378896.html#Feedback0http://www.blogjava.net/czihong/comments/commentRss/378896.htmlhttp://www.blogjava.net/czihong/services/trackbacks/378896.html
In computer networking, a gateway is a node (a router) on a TCP/IP network that serves as an access point to another network. A default gateway is the node on the computer network that the network software uses when an IP address does not match any other routes in the routing table.
In home computing configurations, an ISP often provides a physical device which both connects local hardware to the Internet and serves as a gateway. Such devices include DSL modems and cable modems.
In organizational systems a gateway is a node that routes the traffic from a workstation to another network segment. The default gateway commonly connects the internal networks and the outside network (Internet). In such a situation, the gateway node could also act as a proxy server and a firewall. The gateway is also associated with both a router, which uses headers and forwarding tables to determine where packets are sent, and a switch, which provides the actual path for the packet in and out of the gateway.
In other words, a default gateway provides an entry point and an exit point in a network.
Contents

  [hide] 
1 Example1
2 Example2
3 See also
4 External links
[edit]Example1

An office network consists of six hosts and a router is given as:
Hosts addresses:
192.168.4.3
192.168.4.4
192.168.4.5
192.168.4.6
192.168.4.7
192.168.4.8
Router (this side) address:
192.168.4.1
The network has a subnet mask of:
255.255.255.0 (/24 in CIDR notation)
Thus the usable network ranges from addresses 192.168.4.1 to 192.168.4.254. (TCP/IP defines the addresses 192.168.4.0 and 192.168.4.255 for special functions.)
The office's hosts will send packets addressed to IPs within this range directly, by resolving the destination IP address into a MAC address through an ARP sequence (if not already known through the host's ARP cache) and then enveloping the IP packet into a layer 2 (MAC) packet addressed to the destination host.
Packets addressed outside of this range (for this example, a packet addressed to 192.168.12.3) cannot travel directly to the destination. Instead they must be sent to the default gateway for further routing to their ultimate destination. In this example, the default gateway uses the IP address 192.168.4.1, which is resolved into a MAC address with ARP in the usual way. Note that the destination IP address remains 192.168.12.3, but the next-hop physical address is that of the gateway, rather than of the ultimate destination.
[edit]Example2

A network with three routers and three hosts, connected to the Internet through router1.
Hosts and addresses:
PC1 10.1.1.100, default gateway 10.1.1.1
PC2 172.16.1.100, default gateway 172.16.1.1
PC3 192.168.1.100, default gateway 192.168.1.96
Router1:
Interface 1 5.5.5.2 (public IP)
Interface 2 10.1.1.1
Router2:
Interface 1 10.1.1.2
Interface 2 172.16.1.1
Router3:
Interface 1 10.1.1.3
Interface 2 192.168.1.96
Network mask in all networks: 255.255.255.0 (/24 in CIDR notation).
If the routers do not use a Routing Information Protocol to discover which network each router is connected to, then the routing table of each router must be set up.
Router1
Network ID Network mask Gateway Interface (examples; may vary) Cost (decreases the TTL)
0.0.0.0 (default route) 0.0.0.0 Assigned by ISP (e.g. 5.5.5.1) eth0 (Ethernet 1st adapter) 10
10.1.1.0 255.255.255.0 10.1.1.1 eth1 (Ethernet 2nd adapter) 10
172.16.1.0 255.255.255.0 10.1.1.2 eth1 (Ethernet 2nd adapter) 10
192.168.1.0 255.255.255.0 10.1.1.3 eth1 (Ethernet 2nd adapter) 10

Router2
Network ID Network mask Gateway Interface (examples; may vary) Cost (decreases the TTL)
0.0.0.0 (default route) 0.0.0.0 10.1.1.1 eth0 (Ethernet 1st adapter) 10
172.16.1.0 255.255.255.0 172.16.1.1 eth1 (Ethernet 2nd adapter) 10
Router3
Network ID Network mask Gateway Interface (examples; may vary) Cost (decreases the TTL)
0.0.0.0 (default route) 0.0.0.0 10.1.1.1 eth0 (Ethernet 1st adapter) 10
192.168.1.0 255.255.255.0 192.168.1.96 eth1 (Ethernet 2nd adapter) 10
Router2 manages its attached networks and default gateway; router 3 does the same; router 1 manages all routes within the internal networks.
Accessing internal resources If PC2 (172.16.1.100) needs to access PC3 (192.168.1.100), since PC2 has no route to 192.168.1.100 it will send packets for PC3 to its default gateway (router2). Router2 also has no route to PC3, and it will forward the packets to its default gateway (router1). Router1 has a route for this network (192.168.1.0/24) so router1 will forward the packets to router3, which will deliver the packets to PC3; reply packets will follow the same route to PC2.
Accessing external resources If any of the computers try to access a webpage on the Internet, like http://en.wikipedia.org/, the destination will first be resolved to an IP address by using DNS-resolving. The IP-address could be 91.198.174.2. In this example, none of the internal routers know the route to that host, so they will forward the packet through router1's gateway or default route. Every router on the packet's way to the destination will check whether the packet's destination IP-address matches any known network routes. If a router finds a match, it will forward the packet through that route; if not, it will send the packet to its own default gateway. Each router encountered on the way will store the packet ID and where it came from so that it can pass the request back to previous sender. The packet contains source and destination, not all router hops. At last the packet will arrive back to router1, which will check for matching packet ID and route it accordingly through router2 or router3 or directly to PC1 (which was connected in the same network segment as router1).
The packet doesn't return If router1 routing table does not have any route to 192.168.1.0/24, and PC3 tries to access a resource outside its own network, then the outgoing routing will work until the reply is fed back to router1. Since the route is unknown to router1, it will go to router1's default gateway, and never reach router3. In the logs of the resource they will trace the request, but the requestor will never get any information. The packet will die because the TTL-value decrease to less than 1 when it is travelling through the routers or the router will see that it has a private IP and discard it. This could be discovered by using Microsoft Windows utility Pathping, since you only can ping until that router which has no route or wrong route. (Note that some routers will not reply to pinging.)



Chan Chen 2012-05-23 08:43 发表评论
]]>DHCP Overviewhttp://www.blogjava.net/czihong/articles/377752.htmlChan ChenChan ChenWed, 09 May 2012 18:09:00 GMThttp://www.blogjava.net/czihong/articles/377752.htmlhttp://www.blogjava.net/czihong/comments/377752.htmlhttp://www.blogjava.net/czihong/articles/377752.html#Feedback0http://www.blogjava.net/czihong/comments/commentRss/377752.htmlhttp://www.blogjava.net/czihong/services/trackbacks/377752.htmlTechnical overview
Dynamic Host Configuration Protocol automates network-parameter assignment to network devices from one or more DHCP servers. Even in small networks, DHCP is useful because it makes it easy to add new machines to the network.
When a DHCP-configured client (a computer or any other network-aware device) connects to a network, the DHCP client sends a broadcast query requesting necessary information from a DHCP server. The DHCP server manages a pool of IP addresses and information about client configuration parameters such as default gateway, domain name, the name servers, other servers such as time servers, and so forth. On receiving a valid request, the server assigns the computer an IP address, a lease (length of time the allocation is valid), and other IP configuration parameters, such as the subnet mask and the default gateway. The query is typically initiated immediately after booting, and must complete before the client can initiate IP-based communication with other hosts. Upon disconnecting, the IP address is returned to the pool for use by another computer. This way, many other computers can use the same IP address within minutes of each other.
Depending on implementation, the DHCP server may have three methods of allocating IP-addresses:
dynamic allocation: A network administrator assigns a range of IP addresses to DHCP, and each client computer on the LAN is configured to request an IP address from the DHCP server during network initialization. The request-and-grant process uses a lease concept with a controllable time period, allowing the DHCP server to reclaim (and then reallocate) IP addresses that are not renewed.
automatic allocation: The DHCP server permanently assigns a free IP address to a requesting client from the range defined by the administrator. This is like dynamic allocation, but the DHCP server keeps a table of past IP address assignments, so that it can preferentially assign to a client the same IP address that the client previously had.
static allocation: The DHCP server allocates an IP address based on a table with MAC address/IP address pairs, which are manually filled in (perhaps by a network administrator). [Only requesting clients with a MAC address listed in this table will be allocated an IP address]. This feature (which is not supported by all DHCP servers) is variously called Static DHCP Assignment (by DD-WRT), fixed-address (by the dhcpd documentation), Address Reservation (by Netgear), DHCP reservation or Static DHCP (byCisco/Linksys), and IP reservation or MAC/IP binding (by various other router manufacturers).
[edit]Technical details
DHCP uses the same two ports assigned by IANA for BOOTP: destination UDP port 67 for sending data to the server, and UDP port 68 for data to the client. DHCP communications are connectionless in nature.
DHCP operations fall into four basic phases: IP discovery, IP lease offer, IP request, and IP lease acknowledgement. These points are often abbreviated as DORA (Discovery, Offer, Request, Acknowledgement).
DHCP clients and servers on the same subnet communicate via UDP broadcasts, initially. If the client and server are on different subnets, a DHCP Helper or DHCP Relay Agentmay be used. Clients requesting renewal of an existing lease may communicate directly via UDP unicast, since the client already has an established IP address at that point.
[edit]DHCP discovery
The client broadcasts messages on the physical subnet to discover available DHCP servers. Network administrators can configure a local router to forward DHCP packets to a DHCP server from a different subnet. This client-implementation creates a User Datagram Protocol (UDP) packet with the broadcast destination of 255.255.255.255 or the specific subnet broadcast address.
A DHCP client can also request its last-known IP address (in the example below, 192.168.1.100). If the client remains connected to a network for which this IP is valid, the server may grant the request. Otherwise, it depends whether the server is set up as authoritative or not. An authoritative server will deny the request, making the client ask for a new IP address immediately. A non-authoritative server simply ignores the request, leading to an implementation-dependent timeout for the client to give up on the request and ask for a new IP address.
DHCPDISCOVER
UDP Src=0.0.0.0 sPort=68
Dest=255.255.255.255 dPort=67
OP HTYPE HLEN HOPS
0x01 0x01 0x06 0x00
XID
0x3903F326
SECS FLAGS
0x0000 0x0000
CIADDR (Client IP Address)
0x00000000
YIADDR (Your IP Address)
0x00000000
SIADDR (Server IP Address)
0x00000000
GIADDR (Gateway IP Address)
0x00000000
CHADDR (Client Hardware Address)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 octets of 0s, or overflow space for additional options. BOOTP legacy
Magic Cookie
0x63825363
DHCP Options
DHCP option 53: DHCP Discover
DHCP option 50: 192.168.1.100 requested
DHCP option 55: Parameter Request List:
Request Subnet Mask (1), Router (3), Domain Name (15),
Domain Name Server (6)
[edit]DHCP offer
When a DHCP server receives an IP lease request from a client, it reserves an IP address for the client and extends an IP lease offer by sending a DHCPOFFER message to the client. This message contains the client's MAC address, the IP address that the server is offering, the subnet mask, the lease duration, and the IP address of the DHCP server making the offer.
The server determines the configuration based on the client's hardware address as specified in the CHADDR (Client Hardware Address) field. Here the server, 192.168.1.1, specifies the IP address in the YIADDR (Your IP Address) field.
DHCPOFFER
UDP Src=192.168.1.1 sPort=67
Dest=255.255.255.255 dPort=68
OP HTYPE HLEN HOPS
0x02 0x01 0x06 0x00
0x00000000
YIADDR (Your IP Address)
0xC0A80164
SIADDR (Server IP Address)
0xC0A80101
GIADDR (Gateway IP Address)
0x00000000
CHADDR (Client Hardware Address)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 octets of 0s. BOOTP legacy
Magic Cookie
0x63825363
DHCP Options
DHCP option 53: DHCP Offer
DHCP option 1: 255.255.255.0 subnet mask
DHCP option 3: 192.168.1.1 router
DHCP option 51: 86400s (1 day) IP lease time
DHCP option 54: 192.168.1.1 DHCP server
DHCP option 6: DNS servers 9.7.10.15, 9.7.10.16, 9.7.10.18
[edit]DHCP request
In response to the offer Client requests the server. The client replies DHCPRequest, unicast to the server, requesting the offered address. A client can receive DHCP offers from multiple servers, but it will accept only one DHCP offer. Based on the Transaction ID field in the request, servers are informed whose offer the client has accepted. When other DHCP servers receive this message, they withdraw any offers that they might have made to the client and return the offered address to the pool of available addresses. In some cases DHCP request message is broadcast, instead of being unicast to a particular DHCP server, because the DHCP client has still not received an IP address. Also, this way one message can let all other DHCP servers know that another server will be supplying the IP address without missing any of the servers with a series of unicast messages.
Read more: http://wiki.answers.com/Q/What_is_Dora_process_in_DHCP_and_how_it_works#ixzz1ljWKjqeA
DHCPREQUEST
UDP Src=0.0.0.0 sPort=68
Dest=255.255.255.255 dPort=67
OP HTYPE HLEN HOPS
0x01 0x01 0x06 0x00
XID
0x3903F326
SECS FLAGS
0x0000 0x0000
CIADDR (Client IP Address)
0x00000000
YIADDR (Your IP Address)
0x00000000
SIADDR (Server IP Address)
0xC0A80101
GIADDR (Gateway IP Address)
0x00000000
CHADDR (Client Hardware Address)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 octets of 0s. BOOTP legacy
Magic Cookie
0x63825363
DHCP Options
DHCP option 53: DHCP Request
DHCP option 50: 192.168.1.100 requested
DHCP option 54: 192.168.1.1 DHCP server.
[edit]DHCP acknowledgement
When the DHCP server receives the DHCPREQUEST message from the client, the configuration process enters its final phase. The acknowledgement phase involves sending a DHCPACK packet to the client. This packet includes the lease duration and any other configuration information that the client might have requested. At this point, the IP configuration process is completed.
The protocol expects the DHCP client to configure its network interface with the negotiated parameters.
DHCPACK
UDP Src=192.168.1.1 sPort=67
Dest=255.255.255.255 dPort=68
OP HTYPE HLEN HOPS
0x02 0x01 0x06 0x00
XID
0x3903F326
SECS FLAGS
0x0000 0x0000
CIADDR (Client IP Address)
0x00000000
YIADDR (Your IP Address)
0xC0A80164
SIADDR (Server IP Address)
0xC0A80101
GIADDR (Gateway IP Address switched by relay)
0x00000000
CHADDR (Client Hardware Address)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 octets of 0s. BOOTP legacy
Magic Cookie
0x63825363
DHCP Options
DHCP option 53: DHCP ACK
DHCP option 1: 255.255.255.0 subnet mask
DHCP option 3: 192.168.1.1 router
DHCP option 51: 86400s (1 day) IP lease time
DHCP option 54: 192.168.1.1 DHCP server
DHCP option 6: DNS servers 9.7.10.15, 9.7.10.16, 9.7.10.18
After the client obtains an IP address, the client may use the Address Resolution Protocol (ARP) to prevent IP conflicts caused by overlapping address pools of DHCP servers.
[edit]DHCP information
A DHCP client may request more information than the server sent with the original DHCPOFFER. The client may also request repeat data for a particular application. For example, browsers use DHCP Inform to obtain web proxy settings via WPAD. Such queries do not cause the DHCP server to refresh the IP expiry time in its database.
[edit]DHCP releasing
The client sends a request to the DHCP server to release the DHCP information and the client deactivates its IP address. As client devices usually do not know when users may unplug them from the network, the protocol does not mandate the sending of DHCP Release.
[edit]Client configuration parameters in DHCP
A DHCP server can provide optional configuration parameters to the client. RFC 2132 describes the available DHCP options defined by Internet Assigned Numbers Authority(IANA) - DHCP and BOOTP PARAMETERS.
A DHCP client can select, manipulate and overwrite parameters provided by a DHCP server.[3]
[edit]Options
An option exists to identify the vendor and functionality of a DHCP client. The information is a variable-length string of characters or octets which has a meaning specified by the vendor of the DHCP client. One method that a DHCP client can utilize to communicate to the server that it is using a certain type of hardware or firmware is to set a value in its DHCP requests called the Vendor Class Identifier (VCI) (Option 60). This method allows a DHCP server to differentiate between the two kinds of client machines and process the requests from the two types of modems appropriately. Some types of set-top boxes also set the VCI (Option 60) to inform the DHCP server about the hardware type and functionality of the device. The value that this option is set to give the DHCP server a hint about any required extra information that this client needs in a DHCP response.
[edit]DHCP Relaying
In small networks, where only one IP subnet is being managed, DHCP clients communicate directly with DHCP servers. However, DHCP servers can also provide IP addresses for multiple subnets. In this case, a DHCP client that has not yet acquired an IP address cannot communicate directly with the DHCP server using IP routing, because it doesn't have a routable IP address, nor does it know the IP address of a router. In order to allow DHCP clients on subnets not directly served by DHCP servers to communicate with DHCP servers, DHCP relay agents can be installed on these subnets. The DHCP client broadcasts on the local link; the relay agent receives the broadcast and transmits it to one or more DHCP servers using unicast. The relay agent stores its own IP address in the GIADDR field of the DHCP packet. The DHCP server uses the GIADDR to determine the subnet on which the relay agent received the broadcast, and allocates an IP address on that subnet. When the DHCP server replies to the client, it sends the reply to the GIADDR address, again using unicast. The relay agent then retransmits the response on the local network.
[edit]Reliability
The DHCP protocol provides reliability in several ways: periodic renewal, rebinding, and failover. DHCP clients are allocated leases that last for some period of time. Clients begin to attempt to renew their leases once half the lease interval has expired. They do this by sending a unicast DHCPREQUEST message to the DHCP server that granted the original lease. If that server is down or unreachable, it will fail to respond to the DHCPREQUEST. However, the DHCPREQUEST will be repeated by the client from time to time,[specify] so when the DHCP server comes back up or becomes reachable again, the DHCP client will succeed in contacting it, and renew its lease.
If the DHCP server is unreachable for an extended period of time,[specify] the DHCP client will attempt to rebind, by broadcasting its DHCPREQUEST rather than unicasting it. Because it is broadcast, the DHCPREQUEST message will reach all available DHCP servers. If some other DHCP server is able to renew the lease, it will do so at this time.
In order for rebinding to work, when the client successfully contacts a backup DHCP server, that server must have accurate information about the client's binding. Maintaining accurate binding information between two servers is a complicated problem; if both servers are able to update the same lease database, there must be a mechanism to avoid conflicts between updates on the independent servers. A standard for implementing fault-tolerant DHCP servers was developed at the Internet Engineering Task Force.[4][note 1]
If rebinding fails, the lease will eventually expire. When the lease expires, the client must stop using the IP address granted to it in its lease. At that time, it will restart the DHCP process from the beginning by broadcasting a DHCPDISCOVER message. Since its lease has expired, it will accept any IP address offered to it. Once it has a new IP address, presumably from a different DHCP server, it will once again be able to use the network. However, since its IP address has changed, any ongoing connections will be broken.
[edit]Security
The base DHCP protocol does not include any mechanism for authentication.[5] Because of this, it is vulnerable to a variety of attacks. These attacks fall into three main categories:
Unauthorized DHCP servers providing false information to clients.[6]
Unauthorized clients gaining access to resources.[6]
Resource exhaustion attacks from malicious DHCP clients.[6]
Because the client has no way to validate the identity of a DHCP server, unauthorized DHCP servers can be operated on networks, providing incorrect information to DHCP clients. This can serve either as a denial-of-service attack, preventing the client from gaining access to network connectivity[citation needed], or as a man-in-the-middle attack. Because the DHCP server provides the DHCP client with server IP addresses, such as the IP address of one or more DNS servers,[6] an attacker can convince a DHCP client to do its DNS lookups through its own DNS server, and can therefore provide its own answers to DNS queries from the client.[7] This in turn allows the attacker to redirect network traffic through itself, allowing it to eavesdrop on connections between the client and network servers it contacts, or to simply replace those network servers with its own.[7]
Because the DHCP server has no secure mechanism for authenticating the client, clients can gain unauthorized access to IP addresses by presenting credentials, such as client identifiers, that belong to other DHCP clients.[citation needed] This also allows DHCP clients to exhaust the DHCP server's store of IP addresses—by presenting new credentials each time it asks for an address, the client can consume all the available IP addresses on a particular network link, preventing other DHCP clients from getting service.[citation needed]
DHCP does provide some mechanisms for mitigating these problems. The Relay Agent Information Option protocol extension (RFC 3046) allows network operators to attach tags to DHCP messages as these messages arrive on the network operator's trusted network. This tag is then used as an authorization token to control the client's access to network resources. Because the client has no access to the network upstream of the relay agent, the lack of authentication does not prevent the DHCP server operator from relying on the authorization token.[5]
Another extension, Authentication for DHCP Messages (RFC 3118), provides a mechanism for authenticating DHCP messages. Unfortunately RFC 3118 has not seen widespread adoption because of the problems of managing keys for large numbers of DHCP clients.[8]
整个过程： 
1. DHCP请求IP地址的过程 l 发现阶段，即DHCP客户端寻找DHCP服务器的阶段。
客户端以广播方式发送DHCPDISCOVER包，只有DHCP服务器才会响应。
l 提供阶段，即DHCP服务器提供IP地址的阶段。
DHCP服务器接收到客户端的DHCPDISCOVER报文后，从IP地址池中选择一个尚未分配的IP地址分配给客户端，向该客户端发送包含租借的IP地址和其他配置信息
的DHCPOFFER包。 
l 选择阶段，即DHCP客户端选择IP地址的阶段。如果有多台DHCP服务器向该客户端发送DHCPOFFER包，客户端从中随机挑选，然后以广播形式向各DHCP服务
器回应DHCPREQUEST包，宣告使用它挑中的DHCP服务器提供的地址，并正式请求该DHCP服务器分配地址。其它所有发送DHCPOFFER包的DHCP服务器接收
到该数据包后，将释放已经OFFER（预分配）给客户端的IP地址。 如果发送给DHCP客户端的DHCPOFFER包中包含无效的配置参数，客户端会向服务器发送
DHCPCLINE包拒绝接受已经分配的配置信息。
l 确认阶段，即DHCP服务器确认所提供IP地址的阶段。
当DHCP服务器收到DHCP客户端回答的DHCPREQUEST包后，便向客户端发送包含它所提供的IP地址及其他配置信息的DHCPACK确认包。然后，DHCP客户端
将接收并使用IP地址及其他TCP/IP配置参数。 
2. DHCP客户端续租IP地址的过程
l DHCP服务器分配给客户端的动态IP地址通常有一定的租借期限，期满后服务器会收回该IP地址。如果DHCP客户端希望继续使用该地址，需要更新IP租约。
实际使用中，在IP地址租约期限达到一半时，DHCP客户端会自动向DHCP服务器发送DHCPREQUEST包，以完成IP租约的更新。如果此IP地址有效，
则DHCP服务器回应DHCPACK包，通知DHCP客户端已经获得新IP租约。 如果DHCP客户端续租地址时发送的DHCPREQUEST包中的IP地址与DHCP服务器当前
分配给它的IP地址（仍在租期内）不一致，DHCP服务器将发送DHCPNAK消息给DHCP客户端。 
3. DHCP客户端释放IP地址的过程 
l DHCP客户端已从DHCP服务器获得地址，并在租期内正常使用，如果该DHCP客户端不想再使用该地址，则需主动向DHCP服务器发送DHCPRELEASE包，
以释放该地址，同时将其IP地址设为0.0.0.0。
 


Chan Chen 2012-05-10 02:09 发表评论
]]>Bits and Byteshttp://www.blogjava.net/czihong/articles/372255.htmlChan ChenChan ChenTue, 20 Mar 2012 03:01:00 GMThttp://www.blogjava.net/czihong/articles/372255.htmlhttp://www.blogjava.net/czihong/comments/372255.htmlhttp://www.blogjava.net/czihong/articles/372255.html#Feedback0http://www.blogjava.net/czihong/comments/commentRss/372255.htmlhttp://www.blogjava.net/czihong/services/trackbacks/372255.html
Question: What Is the Difference Between Bits and Bytes?
The terms bit and byte are common in computer networking. Both terms refer to digital data transmitted over a network connection. For example, bits and bytes both may represent network addresses or port numbers.
Answer:
A bit is a single numeric value, either '1' or '0', that encodes a single unit of digital information. A byte is a sequence of bits; usually eight bits equal one byte.

For example, in Internet Protocol (IP) networking, IP addresses contain 32 bits or 4 bytes. The bits encode the network address so that it can be shared on the network. The bytes divide the bits into groups.

The IP address 192.168.0.1, for instance, is encoded with the following bits and bytes:

11000000 10101000 00000000 00000001
Bits are grouped into bytes to, generally speaking, increase the efficiency of computer hardware, including network equipment, disks and memory.

Q. "Is there any difference between bps (small 'b') and Bps (capital 'b')?" 

A. The term "bps" specifies network bandwidth in bits per second. The term "Bps" specifies network bandwidth in bytes per second. 



Chan Chen 2012-03-20 11:01 发表评论
]]>Telnet and SSHhttp://www.blogjava.net/czihong/articles/371752.htmlChan ChenChan ChenMon, 12 Mar 2012 09:29:00 GMThttp://www.blogjava.net/czihong/articles/371752.htmlhttp://www.blogjava.net/czihong/comments/371752.htmlhttp://www.blogjava.net/czihong/articles/371752.html#Feedback0http://www.blogjava.net/czihong/comments/commentRss/371752.htmlhttp://www.blogjava.net/czihong/services/trackbacks/371752.html


Telnet is a protocol that allows you to connect to remote computers (called hosts) over a TCP/IP network (such as the Internet). You use software called a telnet client on your computer to make a connection to a telnet server (i.e., the remote host). Once your telnet client establishes a connection to the remote host, your client becomes a virtual terminal, allowing you to communicate with the remote host from your computer. In most cases, you'll need to log into the remote host, which requires that you have an account on that system. Occasionally, you can log in as guest or public without having an account.
Telnet clients are available for all major operating systems.
Command-line telnet clients are built into most versions of Mac OS X, Windows, Unix, and Linux. To use them, go to their respective command lines (i.e., the Terminal application in Mac OS X, the shell in Unix or Linux, or the DOS prompt in Windows), and then enter:
  telnet host
Secure Shell (SSH) is a network protocol for secure data communication, remote shell services or command execution and other secure network services between two networked computers that it connects via a secure channel over an insecure network: a server and a client (running SSH server and SSH client programs, respectively).[1] The protocol specification distinguishes two major versions that are referred to as SSH-1 and SSH-2.
The best-known application of the protocol is for access to shell accounts on Unix-like operating systems. It was designed as a replacement for Telnet and other insecure remote shell protocols such as the Berkeley rsh and rexec protocols, which send information, notably passwords, in plaintext, rendering them susceptible to interception and disclosure using packet analysis.[2] The encryption used by SSH is intended to provide confidentiality and integrity of data over an unsecured network, such as the Internet.


Chan Chen 2012-03-12 17:29 发表评论
]]>How does DNS workhttp://www.blogjava.net/czihong/articles/370335.htmlChan ChenChan ChenMon, 20 Feb 2012 03:47:00 GMThttp://www.blogjava.net/czihong/articles/370335.htmlhttp://www.blogjava.net/czihong/comments/370335.htmlhttp://www.blogjava.net/czihong/articles/370335.html#Feedback0http://www.blogjava.net/czihong/comments/commentRss/370335.htmlhttp://www.blogjava.net/czihong/services/trackbacks/370335.html

Suppose your computer wants to find the IP address of network-surveys.cr.yp.to. It contacts a series of DNS servers around the Internet.

There are several DNS servers with information about network-surveys.cr.yp.to. A central root server (located at Internet HQ in Virginia) has the following data in a file on disk:

     .:198.41.0.4      
     &to:198.6.1.82
The root server's IP address is 198.41.0.4; your computer also has this address in a file on disk. Your computer sends its question to the root server, and receives a response from the root server's data:
     +--------+  network-surveys.cr.yp.to?  +-----------+      
     |  Your  | --------------------------> |198.41.0.4 |      
     |computer|      <---------------       |root server|      
     +--------+       &to:198.6.1.82        +-----------+
The response &to:198.6.1.82 is a delegation. It says ``For information about .to, ask the DNS server at IP address 198.6.1.82.''

The DNS server at 198.6.1.82 (also located somewhere in Virginia) has the following data in a file on disk:

     .to:198.6.1.82      &yp.to:131.193.178.160
Your computer sends its question to that DNS server, and receives a response:
     +--------+  network-surveys.cr.yp.to?  +----------+      
     |  Your  | --------------------------> |198.6.1.82|      
     |computer|  <------------------------  |.to server|      
     +--------+    &yp.to:131.193.178.160   +----------+
The response &yp.to:131.193.178.160 is another delegation. It says ``For information about .yp.to, ask the DNS server at IP address 131.193.178.160.''

The DNS server at 131.193.178.160 (located in my office in Chicago) has the following data in a file on disk:

     .yp.to:131.193.178.160      =network-surveys.cr.yp.to:131.193.178.100
Your computer sends its question to that DNS server, and receives a response:
     +--------+           network-surveys.cr.yp.to?         +---------------+      
     |  Your  | ------------------------------------------> |131.193.178.160|      
     |computer| <------------------------------------------ | .yp.to server |      
     +--------+  =network-surveys.cr.yp.to:131.193.178.100  +---------------+
The response =network-surveys.cr.yp.to:131.193.178.100 finally answers the original question: the IP address of network-surveys.cr.yp.to is 131.193.178.100.

All of this work is handled by a DNS cache running on your computer. Your computer remembers everything that it learned (for a limited amount of time; information changes!) to save time later. As an alternative, your computer can contact an external DNS cache operated by your Internet service provider; the external DNS cache will do all the work and report the answer.

Multiple servers

To protect against computer failure, there are actually several root servers, several .to servers, and two yp.to servers. Each of the root servers has the following information:
    .:198.41.0.4:a      
    .:128.9.0.107:b      
    .:192.33.4.12:c      
    .:128.8.10.90:d      
    .:192.203.230.10:e      
    .:192.5.5.241:f      
    .:192.112.36.4:g      
    .:128.63.2.53:h      
    .:192.36.148.17:i      
    .:192.58.128.30:j      
    .:193.0.14.129:k      
    .:198.32.64.12:l      
    .:202.12.27.33:m      
    &to:128.250.1.21:a      
    &to:193.0.0.193:b      
    &to:196.7.0.139:c      
    &to:206.184.59.10:d      
    &to:198.6.1.82:e      
    &to:206.86.247.253:f      
    &to:148.59.19.11:g
Each of the .to servers has the following information:
    .to:128.250.1.21:a      
    .to:193.0.0.193:b      
    .to:196.7.0.139:c      
    .to:206.184.59.10:d      
    .to:198.6.1.82:e      
    .to:206.86.247.253:f      
    .to:148.59.19.11:g      
    &yp.to:131.193.178.181:a      
    &yp.to:131.193.178.160:b      
    # or, in BIND master zone-file format:      
    # yp.to IN NS a.ns.yp.to      
    # yp.to IN NS b.ns.yp.to      
    # a.ns.yp.to IN A 131.193.178.181      
    # b.ns.yp.to IN A 131.193.178.160
Your computer tries the root servers in a random order. When it receives a response from some root server, it moves to the .to servers, and tries them in a random order. It eventually receives the answer from one of the two yp.to servers.

Reverse lookups

Suppose your computer sees the IP address 208.33.217.122 and wants to know the corresponding computer name.

Your computer asks a series of DNS servers about the name 122.217.33.208.in-addr.arpa. The root servers have the following information:

    &33.208.in-addr.arpa:206.228.179.10:c      
    &33.208.in-addr.arpa:144.228.254.10:b      
    &33.208.in-addr.arpa:144.228.255.10:a
The DNS server at IP address 144.228.254.10 has the following information:
    .33.208.in-addr.arpa:144.228.255.10:a      
    .33.208.in-addr.arpa:206.228.179.10:c      
    .33.208.in-addr.arpa:144.228.254.10:b      
    &217.33.208.in-addr.arpa:209.191.164.20:a      
    &217.33.208.in-addr.arpa:206.253.194.65:b
The DNS server at IP address 209.191.164.20 has the following information:
    .217.33.208.in-addr.arpa:209.191.164.20:a      
    .217.33.208.in-addr.arpa:206.253.194.65:b      
    =mm-outgoing.amazon.com:208.33.217.122
The answer is mm-outgoing.amazon.com.

Looking up the address for a name, and then the computer name for that address, doesn't necessarily produce the original name. Looking up the computer name for an address, and then the address for that name, doesn't necessarily produce the original address.

 

1. Your web browser asks the resolving DNS server what the address of www.domainname.com is. Your computer already knows where the local ISP resolving DNS server is through its network configuration. 
2. The Resolving DNS server does not know the address. So it asks a root server the same question. The 13 root servers have globally well-known IP addresses, and are run by a US-based company called ICANN
3. The root server replies that it does not know, but it gives the address of the server which knows about .com domains. 
4. The resolving DNS server asks the .com server what the address of www.domainname.com is. 
5. The .com server replies that it does not know, but it gives the address of the server which knows about .domainname.com domain. This server is can be a managed server and many companies pay an annual fee (via a domain registar) to maintain this referral for their domain.
6. The resolving DNS server asks the .domainname.com server what the address of www.domainname.com is. 
7. The server answers the query with the IP address of www.domainname.com, and marks the response as “authoratitve”. This is an assertion that the answer is correct and complete. It also adds to its reply that “this data is valid for 24 hours”, so that anyone who is asking can confidently re-use the information for that time without having to issue another query. 
8. The resolving DNS server finally has its answer, and can reply back to the web browser with the IP address. Crucially it marks its answer as “non-authoratitive”, so that the web browser knows it has the information indirectly



Chan Chen 2012-02-20 11:47 发表评论
]]>