基于HIP的DNS扩展设计

目录TOC\o"1-3"\h\u21750目录 第1章绪论1.1研究背景与意义在传统的Internet协议体系结构中，传输层和网络层是紧密地耦合在一起的，IP地址既要标识主机位置，又要标识主机身份，在传输层使用传输层标识符与网络层紧密绑定，网络层使用IP地址，网络层IP地址扮演双重角色，双重功能意味着当IP地址变化时，路由会发生改变，终端主机的标志也会发生变化，这使得IP地址在主机移动和多宿主情况下不能像在固定主机环境那样提供完美的服务。如果主机移动时IP地址改变时，通信双方无法发送或接收数据并且造成通信的中断，因此，基于TCP/IP的网络结构面临着不同网络互连、多宿主、防火墙穿越等问题，这些问题是在基础的TCP/IP协议上加入移动功能而无法解决的，Internet所要解决的另一个重要问题是安全性问题。在设计Internet体系结构时,用户是可信赖的群体,因而他们相互之间不需要认证，而随着Internet用户群体的不断增加,用户之间已不存在当初的信任关系,主机的IP地址可以频繁更换，IP地址将不再是主机的对外标识，通过传统的防火墙，IDS系统也难以实现对主机的身份认证和对用户行为的控制，因此迫切需要一个有效的认证机制来保障用户之间的可信任性。1.2研究现状主机移动和多宿主引发了新的安全问题，主要有两种：地址盗用和地址洪泛。地址盗用是一个恶意节点声明自己“拥有”一个其他主机正在使用的地址，通过这种假象对拥有该地址的节点进行中间人攻击或拒绝服务攻击。地址洪泛是一个恶意节点欺骗大量的无辜节点现在有一个可用的或者是更好的目标IP地址，致使大量的数据流对目标地址进行洪泛。有很多研究人员对主机移动、多宿主及安全问题进行了广泛而深入的研究，也给出了不少解决的方案，但都没有能够很好也解决这些问题。HIP协议是一个能够同时解决主机移动、多宿主及安全的方案。主机标识协议采用了主机身份与位置信息分离的设计思想，通过增加主机标识主机标识协议,通过增加主机标识命名空间,对地址二义性进行了解耦合,用主机标识表示主机身份信息,地址表示主机位置信息。HIP协议可以很好的解决当前互联网面临的诸多问题,如移动性、多家乡、路由可扩展和安全等。协议定义了一系列控制报文来完成安全关联的建立,更新及关闭等协议操作,协议的正常运行依赖于通信实体对控制报文的正确处理。当网络不稳定或两端主机同时发生移动或同时地址切换的情况下,将会导致控制报文的丢失,造成通信的中断。1.3本文结构安排本说明书的结构组织如下：第1章绪论。介绍了HIP协议给互联网带来的巨大影响和国内外研究和发展现状。第2章HIP协议综述。本章介绍了主机标识协议的基本交换过程，并详细介绍了DNS扩展设计的方案及原理。第3章DNS。主要介绍了基于模块划分的消息序列图，以及各个模块的状态转移图。第4章主机移动性的详细设计。主要介绍了HIP和DNS报文的消息格式，并据此建立数据区。画出程序流程图。第5章第6章总结与展望。总结此次毕业设计的成果，并对未来工作进行了展望。第2章HIP综述2.1主机标识协议2.1.1HIP基本原理HIP是对于基于互联网的一种多寻址和移动性解决方案。同时它也是一种安全协议，标识终端点或主机身份，完成身份鉴别和产生对等点之间的安全连接。HIP在网络结构当中引入了介于网络和传输层之间一层新的协议层,，完成主机标识与网络地址相互之间的映射。在互联网名字空间中加入了由主机标识组成的新的名字空间——主机身份命名空间。这使得地址既作为主机身份又作为定位器的双重身份得到分离,使之仅作为定位器使用。主机识别命名空间要求带有栈的任何设备都具有一个主机标识符。这个标识符是一个被分配给主机的名称,在统计学上应该是全球唯一的，这就允许主机能够被唯一地识别,而不论其地址是什么。在这种情况下,主机标识符就成了公钥,因此能够被用来验证数据包的身份。协议绑定护传输层协议的方式与现在所使用的方式不同。主机标识协议中引进了主机标识符HI和主机标识标签HIT。每个主机可以有多个HI，但由于不同的加密算法所拥有的密钥长度不一样，因而在实际使用时不太方便。HIT是128位定长的、对主机标识符的某种哈希变换.它有自校验、低冲突率的特性，实现和控制的代价较小。又因为与IPv6地址长度一样，在应用程序中使用方便。图2.1引入主标符后的网络协议结构2.1.2HIP基本交换过程图2.2HIP基本交换过程通信发起方发送一个Il报文给主机L(响应方)。Il中包含通信双方的主机标识标签(HITI，HITR)。主机L接收到I1报文后，发送一个R1报文给发起方。R1中包含响应方的密钥交换算法的DH半会话密钥和公钥、一个待解答的迷题(puzzle)以及响应方的签名。主机R收到R1报文后首先验证签名是否来自主机L，若签名来自主机L则进行谜题解答；若发起方在规定时间内找到了符合谜题要求的整数J，则向主机L发送含有谜题解答的I2报文，I2报文同样包含通信双方的HIT、发起方给出的谜题解答、作为公钥的主机标识符以及发起放的签名；若发起方在规定时间内未寻找到符合规定的谜题解答整数，则终止谜题解答，并重新发送基本交换触发报文再次建立HIP基本交换或终止安全连接的建立过程。发起方接收到R1报文后，通过响应方的公钥检验Rl报文是否来自响应方。同时，发起方产生自己的DH半会话密钥，结合响应方的半会话密钥计算出DH会话密钥,后由该会话密钥产生SA的安全参数索引。另外，发起方还需要计算R1报文中的迷题，得到答案。上述信息加上发起方的签名后作为I2报文发送给响应方。响应方得到I2报文后，查看答案是否正确。如果答案正确，响应方解开发起方的会话密钥，计算DH会话密钥和创建HIPSASPI，上述信息加上响应方的签名后作为R2报文发送给发起方。在HIP基本交换建立完成后通信双方不区分发起方和响应方，并以ESP封装的数据包进行基本通信。如果答案不正确,则响应方拒绝和发起方通信。2.1.3HIP基本交换状态转移图图2.3HIP状态转移图当主机R处于UNASSOCIATED状态时，主机和通信节点属于无连接状态。若主机收到I1报文，则向主机L发送回应报文R1；若主机L收到R1报文，则向主机R发送I2报文作为回应，若在规定时间内解出谜题并发送I2报文则主机L状态转移至I2-SENT状态，若未在规定时间内解答出谜题，则重新发送I1报文或者断开基本交换连接；当主机L处于I1-SENT状态时，主机L正在发送I1报文。若收到I1报文，则发送R1，但状态仍保持在I1-SENT状态；若主机L收到R1报文，则向主机R发送I2报文作为回应，并将状态转移至I2-SENT；若主机R收到I2报文，则向主机L发送R2报文作为回应，并将状态转移至R2-SENT；若主机L收到R2报文，则丢弃。当主机L处于I2-SENT状态时，主机L正在发送带有谜题解答的I2报文。若主机R收到I1报文，则发送R1报文，状态不进行转移。当主机R处于R2-SENT状态时，主机R正在发送R2报文。若主机R收到I1、I2报文则回复相对应的报文给主机L，处于R2-SENT状态；若主机L收到R1,在R2-SENT状态时，谜题已失效，丢弃报文并保持状态不变。当主机处于ESTABLISHED状态时，主机与通信主机间已完成四次握手，属于已连接状态。若主机R收到I1、I2报文同样发送相应的回应报文。当主机处于REKEYING状态时，通信节点已进行移动请求位置更新。若收到I1、I2报文，处理成功则发送相对应的报文。2.2DNS扩展方案与设计原理2.2.1DNS扩展原理在该体系结构中。互联网被分成多个区域网络，每个区域网络都由RVS负责管理该区域网络中节点的HIT及其IP地址之间的映射关系。另外，DNS管理节点的域名、HIT以及对应RVS的IP地址之间的映射关系，DNS不直接保存节点的II地址。图2.4基于HIP的DNS扩展设计网络结构区域网络中的路由器发送路由器通告消息，该消息中包含管理该区域网络的RVS的HIT及IP地址。这种路由器通告消息可以通过修改ICMPv6(第六版互联网控制报文协议)的路由器通告消息来实现。节点第一次进入网络时，它使用HIP位置注册机制在所属区域网络的RVS中注册自己的HIT和IP地址。因此，RVS保存了节点的HIT及其IP地址之间的映射关系。在该注册过程中，节点也保存了RVS的HIT和IP地址。当节点发生移动时，它从新子网的AR中获得管理该子网的RVS的HIT和IP地址。此时，MN把新获得的RVS的HIT和自己原来保存的RVS的HIT进行比较：如果新AR路由器通告消息中的RVS的HIT与MN原来保存的RVS的HIT相同。则表明该MN在同一个区域网络的不同子网之间移动，此时，MN根据路由器通告消息获得新IP地址，使用HIP位置更新机制在RVS和通信节点(CN)中进行位置更新。如果新获得的RVS的HIT与原来保存的不同，则表明该MN移动到一个新的区域网络中，此时，MN根据AR所发送的路由器通告消息，获得新的IP地址以及管理该新区域网络的RVS的HIT和IP地址。并且进行如下操作：MN使用HIP位置注册机制，在新区域网络的RVS中注册自己的HIT和IP。新区域网络的RVS获得MN的HIT和地址后，使用HIP位置更新机制，在DNS中更新MN的HIT及其对应RVS的IP地址二者之间的映射关系。进行位置更新后，DNS保存的是MN的HIT与新RVS的IP地址之间的映射关系。MN使用HIP位置更新机制，在CN中进行位置更新。MN给原区域网络中的RVS发送带有DEL参数的UPDATE报文，通告该RVS删除其保存的该MN的HIT和IP地址。2.2.2DNS扩展方案当HIP节点想要与响应者发起HIP交换时，首先进行DNS查询。根据查询类型，这些查询的发布顺序可能会变化。编程接口（API）通常通常会先查询HIPRR，在响应者FQDN中，而那些在API中使用IP地址的用户可能会通常首先查询A和/或AAAARR，在下文中，我们假设发起者首先查询HIP响应方FQDN的RR。如果对HIP类型的查询以DNS回答响应了RCODE=3（名称错误），则响应者的信息不存在DNS中，并且不应进一步查询。如果查询HIP记录返回的DNS答案为RCODE=0（无错误）并且答案部分为空，表示没有HIP可在“响应者”名称处获得该信息。它将在A处发送更多有关A和AAAA类型的查询响应者的FQDN。图2.5静态主机的网络拓扑图查询＃1：QNAME=，QTYPE=HIP：它返回RCODE=0的DNS数据包和一个或多个HIPRR，其中答案中响应者的HIT和HI（例如HIT-R和HI-R）部分，但没有RVS。查询＃2：QNAME=，QTYPE=A：查询＃3：QNAME=，QTYPE=AAAA：它将返回RCODE=0的DNS数据包，分别返回1或包含响应者IP地址的更多A或AAAARR（例如IP-R）的回答部分。HIP协议中引入一个新的基础设施:汇聚服务器，汇聚服务器是一个包转发器,用于移动主机移动到新的网络位置后通过汇聚服务器能够继续发送和接收数据包而不中断通信。汇聚服务器完成数据包的转发工作，而所有请求数据包转发的主机都叫汇聚客户机。为了完成数据包的转发，首先在DNS服务器上增加一条资源记录，存储汇聚服务器信息以供汇聚客户机查询；其次，汇聚客户机在汇聚服务器上注册自己的HI及IP地址等信息。主机要发送数据包时，先从DNS服务器查询汇聚服务器的HI及IP地址，并将第一个数据包发送到汇聚服务器，再由汇聚服务器将此数据包转发给目标地址，后续的数据包不再通过汇聚服务器转发而是通信双方直接进行通信，除非通信双方中有一方地址发生变化。图2.6主机移动时网络拓扑图HIP节点频繁更改其IP地址时，传播更改的自然DNS延迟可能会阻止它在DNS中发布其新IP地址。为了解决这个问题，HIP体系结构引入了RVS。一个HIP主机使用RVS作为集合点以保持可达性，在移动时使用可能的HIP发起程序。这样的HIP节点将在HIPRR中在DNS中发布其RVS域名，而保持其RVS与当前IP地址集保持最新。移动HIP节点会将一个或多个IP地址（IP-R），HI（HI-R），HIT（HIT-R）以及其RVS服务器的域名（例如HIPRR资源记录中的）存储在DNS中。在DNS中移动HIP节点也需要将其IP地址的任何更改通知其RVS。愿意与这样的移动节点通信的发起者将通常发出以下查询：查询＃1：QNAME=，QTYPE=HIP它返回RCODE=0的DNS数据包和一个或多个HIPRR，其中HIT，HI和RVS域名（例如，HIT-R，HI-R和答案部分中的“响应者”（）。查询＃2：QNAME=，QTYPE=A查询＃3：QNAME=，QTYPE=AAAA它们分别返回RCODE=0和一个或多个的DNS数据包包含响应者RVSIP地址的A或AAAARR（例如IP-RVS）的答案部分。第3章DNS扩展概要设计3.1基于模块划分的消息序列图 图3.1基于模块划分的消息序列图从消息序列图可以看出，两台主机进行通信时，需要知道对方的IP地址以及HIT，在主机移动情况下需要知道对方的RVS注册地址及HIT。移动主机R首先在RVS汇聚服务器上注册自己的HI和IP等信息，RVS保存了节点的HIT及其IP地址之间的映射关系，同时RVS使用HIP位置更新机制，向DNS发送UPDATE更新报文，在DNS中更新移动主机R的HIT及其对应的RVSIP地址和映射关系。主机L进行通信时，需要进行DNS查询，进行域名到HIT和IP的解析，查询格式如下：QNAME-,QTYPE=HIP。若DNS返回结果含有主机R的HIT，RVS的IP，那么主机L首先给RVS发送I1报文，该报文包含主机L和主机R的HIT以及RVS的IP，当RVS收到I1后，在I1中加一个FROMI参数，其中包含了主机L的IP地址，主机R收到I1报文后，给主机L发送R1，其中含有VIARVS参数，表示I1经过RVS转发。之后，主机L、R之间直接发送I2、R2报文即可。若DNS返回结果含有主机R的IP、HIT及RVS的IP，那么主机L、R之间直接发起HIP基本交换，建立连接。3.2各模块状态转移图3.2.1UPDATE模块状态转移图图3.2UPDATE模块状态转移图如图，UPDATE模块一个三个状态。空闲状态IDLE发送一条UPDATE（LOCATOR，SEQ）消息向DNS请求位置更新，进入等待UPDATE（SEQ,ACK,ECHO-REQ）状态，若等待失败则返回IDLE状态；若收到UPDATE(SEQ,ACK,ECHO-REQ）消息，发送UPDATE(ACK,ECHO-RES)消息，若等待失败直接返回IDLE状态，完成位置更新并进入IDLE空闲状态。空闲状态收到一条UPDATE（LOCATOR,SEQ）请求位置更新消息，发送UPDATE（SEQ,ACK,ECHO-REQ）回送请求消息并进入等待UPDATE（SEQ,ACK,ECHO-RES）状态。等待失败返回IDLE状态；若收到UPDATE（SEQ,ACK,ECHO-RES）消息，则完成位置更新并进入IDLE空闲状态。3.2.2DNS模块状态转移图图3.3DNS模块状态转移图如图，DNS模块一共有五个状态。空闲状态IDLE接收INFO,进入等待查询WAIT_QUERY状态，等待查询WAIT_QUERY状态发送QTYPE、QNAME进行DNS域名查询，进入等待返回WAIT_UDP（RCODE）状态，等待返回WAIT_UDP（RCODE）状态等待DNS返回消息。若收到RCODE=3，表示DNS中没有节点相关记录，查询失败。若收到CODE=0，并且无其他内容，说明该DNS中暂时没有储存与该节点有关的IP、HIT、RVS的IP，此时主机则应该向DNS发送多次域名解析，请求DNS返回。若收到RCODE=0和主机的HIT和RVS的IP，源节点向RVS发I1，RVS收到I1后，添加一个FROM参数，转发给目的节点，说明该报文来自主机R，发送I1后进入I1-SENT（RVS）状态。主机L收到I1报文后，给源节点发R1，该R1包含VIARVS参数，该参数包含RVS的IP，说明R1经过RVS的转发。若收到RCODE=0,主机的HIT，IP和RVS的IP，则向主机L发送I1并进入I1-SENT状态，然后主机之间直接发起HIP基本交换，建立起双方的通信连接，不需要经过RVS。3.2.3HIP模块状态转移图图3.4HIP模块状态转移图如图，HIP模块一共四种状态。空闲状态IDLE发送一条I1(HIT-RVS,HIT_I)请求注册RVS，进入等待R1(REG_INFO)状态，若没有收到R1，则失败并返回空闲状态，若收到R1，则发送I2（REG_REQ）请求位置注册，并进入等待R2（REG_RES）状态，若没有收到R2，则失败并返回空闲状态，若收到R2则注册成功并返回空闲状态。若在空闲状态收到一条I1(HIT_RVS,HIT_I）消息，发送一条R1（REG_INFO）并进入等待I2（REG_REQ）状态，若没有收到I2消息，则失败并返回空闲状态，若收到I2消息，则发送一条R2（REG_RES）通知完成注册并进入空闲状态，若发送失败则直接进入空闲状态。第4章详细设计4.1数据区定义4.1.1HIP消息格式：图4.1HIP消息格式HIP消息格式由三部分组成：UDP封装头部、HIP头部以及相应报文所需要的HIP参数。HIP总体数据结构：struct_HIP{StructUDPHEADudphead;StructHIPHEADI1_HEAD;StructR1_COUNTERr1_counter;/*类型129*/StructLOCATORlocator;/*类型193*/StructPUZZLEpuzzle;/*类型257*/StructSOLUTION solution;/*类型321*/StructSEQ seq;/*类型385*/StructACK ack;/*类型449*/StructDIFFIE_HELLMANdiffie_hellman;/*类型513*/StructREG_INFO reg_info;/*类型930*/StructREG_REQUESTreg_request;/*类型932*/StructREG_RESPONSE reg_response;/*类型934*/StructREG_FAILED reg_failed;/*类型936*/StructHIP_MAChip_mac;/*类型61505*/StructHIP_SIGNATUREhip_signature;/*类型61697*/_u8mudule_sta;/*状态*/};4.1.2UDP头部格式UDP封装头部：图4.2UDP头部格式源端口：占16位。目的端口：占16位。头部长度：16位，为整个数据包的长度，包括MAC头+ip头+UDP头+校验位。校验和：占16位。UDP头部数据结构：StructUDPHEAD{_u16I_port;/*源端口*/_u16R_port;/*目标端口*/_u16length;/*长度*/_u16checksum;/*控制域*/};4.1.3HIP头部格式HIP头部格式：图4.3HIP头部格式下一头部：占8位，表明紧跟在HIP后面的下一个首部的类型。长度：占8位，是存储HIP头部和HIP参数的长度。类型：占8位，表明HIP报文的具体类型。版本和保留域：各占4位。保留域为将来使用，发送者初始化为0；本设计使用的版本为1。括IP头部的源地址和目的地址。控制域：占16位。涉及报文结构和主机容量。源地址/目的地址：占128位。用校验和：占16位。包来存储发送方和接收方的HIT。HIP头部数据结构：struct_hiphdr{_u8next_hdr;/*载荷*/_u8hdr_length;/*头部长度*/_u8pack_type;/*报文类型*/_u8ver_res;/*版本和保留域*/_u16controls;/*控制信息*/_u16checksum;/*校验和*/_u8hit_sender[32];/*发送者的hit*/_u8hit_receiver[32];/*接收者的hit*/};4.1.4SEQ参数格式SEQ参数： 图4.4SEQ参数格式类型：占16位，SEQ的类型为385。长度：占16位。更新ID：占32位，是网络字节顺序中的无符号数字，在移至ESTABLISHED状态时由主机初始化为零。更新ID在单个HIP关联中具有范围，而不是跨多个关联或多个主机。更新ID增加在主机发送的每个新UPDATE之前一个;由主机发起的第一个UPDATE数据包的更新ID为0。SEQ数据结构:Structseq{_u16type;/*类型*/_u16length;/*长度*/_u32update_id;/*更新ID*/};4.1.5ACK参数格式ACK参数：图4.5ACK参数格式类型：占16位，ACK的类型为449。长度：占16位，以字节为单位。不包括类型和长度字段。对等更新ID：占32位，表示用32位序列数来回应更新ID的确认。ACK数据结构：structack{_u16type;/*类型*/_u16length;/*长度*/_u32peer_update_id;/*对等更新ID*/};4.1.6LOCATOR参数格式LOCATOR参数：图4.6LOCATOR参数格式类型：占16位，LOCATOR的参数类型为193。长度：占16位，以八位字节为单位的长度。流量类型：占8位。定位器类型：占8位，定义定位器字段的语义。定位器长度：占8位，定义定位器字段的长度。单位为四字节。保留域：发送时为零，接收时忽略。P：首选定位器，占1位。定位器生存时间：定位器的生命周期。定位器：其语义和编码由定位器类型字段表示。定位器数据结构：Structlacator_set{_u16type;/*类型*/_u16length;/*长度*/_u8traffic_type;/*流量类型*/_u8lacator_type;/*定位器类型*/_u8lacator_length;/*定位器长度*/_u8res;/*保留域*/_u32lacator_lifetime;/*定位器生存时间*/_u32lacator;/*首选定位器*/};4.1.7ECHO-REQ参数格式ECHO-REQ参数：图4.7ECHO-REQ参数格式类型：占16位，类型为63661。长度：占16位，表示八位字节中不透明数据的长度。不透明数据：占32位。Echo_Request数据结构:StructEcho_Request{_u16type;/*类型*/_u16length;/*长度*/_u32opaque_date;/*透明数据*/}4.1.8ECHO-RES参数格式图4.8ECHO-RES参数类型：占16位，类型为63425。长度：占16位，表示八位字节中不透明数据的长度。不透明数据：占32位，从触发此响应的ECHO_REQUEST_UNSIGNED参数中未经修改复制。Echo_Response数据结构:Struct_Echo_Response{_u16type;/*类型*/_u16length;/*长度*/_u32opaque_date;/*透明数据*/};4.2其他HIP参数数据结构定义：4.2.1题解数据结构：structSOLUTION{_u16type;/*类型*/_u16length;/*长度*/_u8k;/*随机数K*/_u8res;/*保留域*/_u16opaque;/*透明数据*/_u32I;/*随机数I*/_u32J;/*随机数J*/};4.2.2hip_mac数据结构：structHIP_MAC{_u16type;/*类型*/_u16length;/*长度*/_u8hmac[20];/*hmac*/};4.2.3R1_COUNTER参数的数据结构:structR1_COUNTER{_u16type;/*类型*/_u16length;/*长度*/_u32res;/*保留域*/_u64R1_Gen_COUNTER;/*序列号*/};4.2.4密题puzzle参数的数据结构：structPUZZLE{_u16type;/*类型*/_u16length;/*长度*/_u8k;/*随机数K*/_u8lifetime;/*生存周期*/_u16opaque;/*不透明数据*/_64I;/*随机数I*/};4.2.5Diffiiehellman密钥的数据结构：structDIFFIE_HELLMAN{_u16type;/*类型*/_u16length;/*长度*/_u8group_id;/*组ID*/_u16public_value_length;/*公共值的长度*/_u8public_value;/*变量长度*/};4.2.6Hip_Signature数据结构：structHip_Signature{_u16type;/*类型*/_u16length;/*长度*/_u16sig_alg;/*签名算法*/_u16signature;/*签名*/};4.2.7TLV数据结构：structTLV_HEAD{intlength;/*tlv消息总长度，即消息头和消息体总长度*/shortversion;/*消息版本号*/shortcommandID;/*命令类型*/intseqence;/*消息序列号，从1开始递增*/charchecknum[16];/*消息校验*/};4.3DNS报文及HIP资源记录4.3.1经过UDP、IP头部封装后DNS报文图4.9封装后DNS报文4.3.2DNS报文整体结构DNS报文格式分为DNS查询和响应的报文格式。这个报文由12字节长的首部和4个长度可变的字段组成。报文中问题字段是由客户填入的，由服务器返回问题的回答、授权和附加信息字段。报文格式如下：图4.10报文格式4.3.3DNS报文头部结构Header段是必须存在的，它定义了报文是请求还是应答，也定义了其他段是否需要存在，以及是标准查询还是其他。头部字段格式如下：图4.10头部字段格式ID16bit标识字段，客户通过标识字段来确定DNS响应是否与查询请求匹配。QR1bit操作类型：0：查询报文1：响应报文OPCODE4bit查询类型：0：标准查询1：反向查询2：服务器状态查询3～15：保留未用反向查询是客户端请求服务器根据回答生成导致此回答的问题，这个查询类型的使用并不多。AA1bit若置位，则表示该域名解析服务器是授权回答该域的。TC1bit若置位，则表示报文被截断。使用UDP传输时，应答的总长度超过512字节时，只返回报文的前512个字节内容。RD1bit客户端希望域名解析服务器采取的解析方式：0：表示希望域名解析服务器采取迭代解析1：表示希望域名解析服务器采取递归解析RA1bit域名解析服务器采取的解析方式：0：表示域名解析服务器采取迭代解析1：表示域名解析服务器采取递归解析Z3bit全部置0，保留未用。RCODE4bit响应类型：0：无差错1：查询格式错2：服务器失效3：域名不存在4：查询没有被执行5：查询被拒绝6-15:保留未用QDCOUNT16bit无符号16位整数表示报文请求段中的问题记录数ANCOUNT16bit无符号16位整数表示报文回答段中的回答记录数NSCOUNT16bit无符号16位整数表示报文授权段中的授权记录数ARCOUNT16bit无符号16位整数表示报文附加段中的附加记录数图4.11头部字段含义4.3.4QUESTION字段消息格式大多数查询中，Question段包含着问题(question)，比如，指定问什么。这个段包含QDCOUNT(usually1)个问题，每个问题为下面的格式：Question字段的格式:图4.12QUESTION字段格式字段长度描述QNAME变长域名被编码为一些labels序列，每个labels包含一个字节表示后续字符串长度，以及这个字符串，以0长度和空字符串来表示域名结束。注意这个字段可能为奇数字节，不需要进行边界填充对齐。QTYPE2个字节表示查询类型，.取值可以为任何可用的类型值，以及通配码来表示所有的资源记录。QCLASS2个字节表示查询的协议类，比如，IN代表Internet。图4.13QUESTION字段含义4.3.5DNS资源记录图4.14DNS资源记录应答，授权，附加段都共用相同的格式：多个资源记录，资源记录的个数由报文头段中对应的几个数值确定，每个资源记录格式如下：字段长度描述NAME不定长资源记录包含的域名TYPE2个字节表示资源记录的类型，指出RDATA数据的含义CLASS2个字节表示RDATA的类TTL4字节无符号整数，表示资源记录可以缓存的时间。0代表只能被传输，但是不能被缓存RDLENGTH2个字节无符号整数，表示RDATA的长度。RDATA不定长字符串，表示记录，格式跟TYPE和CLASS有关。比如，TYPE是A，CLASS是IN，那么RDATA就是一个4个字节的ARPA网络地址图4.15资源记录格式4.3.6扩展DNS在新的DNS资源记录中不需要严格保存节点域名及其IP地址之间的实时映射关系,但是需要保存节点的域名及其对应RVS的II)地址之间的映射关系。图4.16扩展后DNS记录扩展后NDS，由于HIP协议的引入，可以在资源记录中保存主机的HIT和其对应的RVS之间的映射关系。应用程序在对基本的域名解析的同时，也产生了对HI和HIT解析的需要。在增添了HIP协议的新的协议栈中，域名不再和IP地址进行绑定，而是和主机的HIT进行绑定，通信连接的建立和数据的传输，就不仅仅只需要通过域名解析出IP地址，还需要通过域名解析出进行身份验证的HI和HIT。 与此同时，对于HIP协议的RVS机制，它在实现主机的移动性的功能上，也需要由扩展的DNS系统进行支持。由扩展的DNS系统存储移动主机HIT和对应的RVS服务器地址，再由RVS服务器对移动主机进行注册和管理，有效地实现了主机的移动性。 对现有的DNS系统进行扩展，增加两类DNS资源记录:HIPHI，用于存储主机标识和经过格式化的主机标识标签；HIPRVS，用于存储HIP集中服务器的信息。通过这两种资源记录的存储和使用，DNS服务器可以提供以下管理功能:1.分配并管理网络实名FQDN，实现实名查找和寻址;2.实现FQDN到HI的查询;3.实现FQDN到IP地址的查询;4.实现HI到IP地址的查询和认证;5.对HIP集中服务器进行管理和授权。HIP集中服务器可以接替DNS服务器，完成HI的地址动态追踪功能，减轻DNS服务器的工作压力，为IPv6主机的移动性提供更大支持。4.4DNS报文数据结构Header段数据结构：StructDNS_header{_u16id;/*标识字段*/intqr;/*操作类型*/intopcode;/*查询类型*/intaa;/*表示授权*/inttc;/*报文截断*/Intrd;/*客户端希望的解析方式*/Intra；/*服务器解析方式*/Intz；/*全部置0，保留未用*/Intrcode;/*响应类型*/_u16qdcount;/*问题记录数*/_u16ANCOUNT;/*回答记录数*/_u16NSCOUNT;/*授权记录数*/_u16ARCOUNT;/*附加记录数*/}；QUESTION段数据结构：StructQuestion{Charqname[50];/*查询的域名*/_u16qtype;/*查询类型*/_u16qclass;/*查询的协议类*/}；资源记录段数据结构：Structdns_rr{Char[50];_u16type;_u16class;_u32ttl;_u16rdlength;Dns_rdata_hiprdata;};HIP资源记录数据结构：Structdns_rdata_hip{dns_rdatacommon_tcommon;Isc_mem_t*mctx;Isc_uint8_thit_length;Isc_uint8_tpk_algorithm;Isc_uint16_tpk_length;Unsignedchar*hit;Unsignedchar*pk;dns_name_trvs_name[MAX_NUM_RVS];};hitlength表示HIT的长度，它是一字节为单位，是一个八比特的无符号整数;pkalgorithm用于确定非对称密钥算法，规定了公钥加密算法和潜在的公钥字段的格式，它也是一个八特的无符号整型，目前所定义的值主要为:DSA密钥和RSA密钥，本系统中是用的DSA密钥算法;以及pkl