看到这篇文章不错。转载在这边。以备后面的工作与学习之用
1
.SIP
中的
DNS
过程
1.1 .SIP 消息涉及的DNS 过程
SIP 消息涉及到的DNS 过程主要包括两个方面:一方面是如何发送请求消息,发送方需要通过DNS 过程得到传输层协议类型,下一跳的IP 地址和端口等信息;另一方面是如何返回响应 消息,需要决定上一跳的地址和端口,尤其是上一跳网元发生故障时,如何返回响应 消息。
1.1 .SIP 消息涉及的DNS 过程
SIP 消息涉及到的DNS 过程主要包括两个方面:一方面是如何发送请求消息,发送方需要通过DNS 过程得到传输层协议类型,下一跳的IP 地址和端口等信息;另一方面是如何返回响应 消息,需要决定上一跳的地址和端口,尤其是上一跳网元发生故障时,如何返回响应 消息。
1.2
.
如何发送SIP
请求消息
定义一个名为TARGET 的变量,如果URI 定义了maddr 参数,TARGET 取值于该参数,否则取值于URI 的hostport 部分。
第一步是决定使用哪种传输层协议发送请求消息,包括下列步骤 :
1 、如果URI 定义了传输层协议,则使用该传输层协议,否则转步骤2 ;
2 、如果TARGET 包含IP 地址,那么对于SIP URI 使用UDP 协议,SIPS URI 使用TCP 协议,否则转步骤3 ;
3 、如果TARGET 包含了端口,那么对于SIP URI 使用UDP 协议,SIPS URI 使用TCP 协议,否则转步骤4 ;
4 、使用TARGET 中的域名进行NAPTR 查询,如果NAPTR 返回的记录为空转步骤5 ,否则查看返回的记录,记录中的service 域一般取值为”XXX+D 2 U”, X+D 2 T”, XX+D 2 S”, 其中XXX 表示服务 名称,可以是”SIP” 或”SIPS” ,D 2 U 表示使用UDP 协议,D 2 T 表示使用TCP 协议,D 2 S 表示使用SCTP 协议;
5 、根据RFC 3261 的传输准则判断是否需要使用某种强制协议,如果需要使用强制协议,则使用该强制协议,否则对于SIP URI 使用UDP 协议,SIPS URI 使用TCP 协议;
第二步是决定目标的IP 地址和端口,包括下列步骤 :
1 、如果TARGET 包含了IP 地址和端口,则使用该地址和端口,否则转步骤2 ;
2 、如果TARGET 包含了IP 地址,则使用对应传输协议的默认端口,否则转步骤3 ;
3 、如果TARGET 不包含IP 地址,但包含了端口,则使用A 或AAAA 查询,获得域名对应的IP 地址,否则转步骤4 ;
4 、如果在第一大步的第四小步没有进行NAPTR 查询,转步骤5 ,则使用该查询返回的记录中的replacement 域中域名进行SRV 查询,然后转步骤6 ;
5 、在TARGET 包含的域名加上_XXX._YYY. 前缀(其中XXX 表示服务 类型,可以取值sip 或sips ,YYY 表示传输类型,可以取值udp, tcp 或sctp 等),然后使用加了前缀的域名进行SRV 查询,并转步骤6 ;
6 、如果SRV 返回了记录,记录会包含端口和最新域名,然后对最新域名进行A 或AAAA 查询得到IP 地址,如果SRV 没有返回记录转步骤7 ;
7 、直接对TARGET 中的域名使用A 或AAAA 查询得到IP 地址,端口则根据传输协议使用默认端口;
一个发送请求消息例子 ,下一跳消息的SIP URI 为:sip:example.com ,如下是向该网元发送SIP 请求消息的过程:
首先 对域名example.com 进行NAPTR 查询,查询的结果为:
order pref flags serviceregexp replacement
IN NAPTR 50 50 "s" "SIPS+D 2 T""" _sips._tcp.example.com.
IN NAPTR 90 50 "s" "SIP+D 2 T""" _sip._tcp.example.com
IN NAPTR 100 50 "s" "SIP+D 2 U" "" _sip._udp.example.com.
NAPTR 返回了多条记录,根据order 和pref 的取值选择了第一条记录,flag 为s 表示下一步进行SRV 查询,service 为SIPS+D 2 T 表示使用TCP 作为传输层协议,同时使用sips 方式传输消息,replacement 表示使用_sips._tcp.example.com 进行获取目标网元的地址信息。
然后 对域名_sips._tcp.example.com 进行SRV 查询,查询的结果为:
Priority WeightPortTarget
IN SRV 0 1 5060 server 1 .example.com
IN SRV 0 2 5060 server 2 .example.com
SRV 返回了两条记录,根据priority 和weight 选择其中一条,假设选择的是第一条,那么意味这目标端口为5060 ,Target 包含了目标网元的域名server 1 .example.com 。
最后 对域名server 1 .example.com 进行A 或AAAA 查询,得到目标网元的IP 地址:
IN AAAA 5 F 05 : 2000 : 80 AD: 5800 : 0058 : 0800 : 2023 : 1 D 71 1.3 . 如何发送响应 消息
一般情况下,对于可靠的传输层协议,响应 消息在请求消息所在的连接上返回,对于非可靠的传输层协议,响应 消息通过发送请求消息的源IP 地址以及Via 中的端口返回。但是如果UAC 发送完请求消息后就发生了异常,UAS 应当如何返回响应 消息?具体包括如下过程:
1 、如果Top Via 包含了IP 地址和端口,向该地址和端口返回响应 消息;
2 、如果Top Via 包含了IP 地址,没有包含端口,使用传输层协议的默认端口返回响应 消息;
3 、如果Top Via 包含了域名和端口,使用A 或AAAA 查询,获得IP 地址列表,然后试图向列表中的每一个IP 地址发送响应 消息,只到有一个发送成功为止;
4 、如果Top Via 包含了域名,没有包含端口,使用SRV 查询,获得端口和新域名,对新域名的处理和步骤3 类似; 2 .IMS 中的 DNS 过程
IMS 中的DNS 过程也可以分为两类:一类是IMS 中的SIP 实体基于SIP URI 的DNS 查询,例如主叫侧S-CSCF 需要获得被叫网络中的I-CSCF ,其过程采用SIP 定义的DNS 过程;另一类是基于TEL URI 的DNS 查询。
定义一个名为TARGET 的变量,如果URI 定义了maddr 参数,TARGET 取值于该参数,否则取值于URI 的hostport 部分。
第一步是决定使用哪种传输层协议发送请求消息,包括下列步骤 :
1 、如果URI 定义了传输层协议,则使用该传输层协议,否则转步骤2 ;
2 、如果TARGET 包含IP 地址,那么对于SIP URI 使用UDP 协议,SIPS URI 使用TCP 协议,否则转步骤3 ;
3 、如果TARGET 包含了端口,那么对于SIP URI 使用UDP 协议,SIPS URI 使用TCP 协议,否则转步骤4 ;
4 、使用TARGET 中的域名进行NAPTR 查询,如果NAPTR 返回的记录为空转步骤5 ,否则查看返回的记录,记录中的service 域一般取值为”XXX+D 2 U”, X+D 2 T”, XX+D 2 S”, 其中XXX 表示服务 名称,可以是”SIP” 或”SIPS” ,D 2 U 表示使用UDP 协议,D 2 T 表示使用TCP 协议,D 2 S 表示使用SCTP 协议;
5 、根据RFC 3261 的传输准则判断是否需要使用某种强制协议,如果需要使用强制协议,则使用该强制协议,否则对于SIP URI 使用UDP 协议,SIPS URI 使用TCP 协议;
第二步是决定目标的IP 地址和端口,包括下列步骤 :
1 、如果TARGET 包含了IP 地址和端口,则使用该地址和端口,否则转步骤2 ;
2 、如果TARGET 包含了IP 地址,则使用对应传输协议的默认端口,否则转步骤3 ;
3 、如果TARGET 不包含IP 地址,但包含了端口,则使用A 或AAAA 查询,获得域名对应的IP 地址,否则转步骤4 ;
4 、如果在第一大步的第四小步没有进行NAPTR 查询,转步骤5 ,则使用该查询返回的记录中的replacement 域中域名进行SRV 查询,然后转步骤6 ;
5 、在TARGET 包含的域名加上_XXX._YYY. 前缀(其中XXX 表示服务 类型,可以取值sip 或sips ,YYY 表示传输类型,可以取值udp, tcp 或sctp 等),然后使用加了前缀的域名进行SRV 查询,并转步骤6 ;
6 、如果SRV 返回了记录,记录会包含端口和最新域名,然后对最新域名进行A 或AAAA 查询得到IP 地址,如果SRV 没有返回记录转步骤7 ;
7 、直接对TARGET 中的域名使用A 或AAAA 查询得到IP 地址,端口则根据传输协议使用默认端口;
一个发送请求消息例子 ,下一跳消息的SIP URI 为:sip:example.com ,如下是向该网元发送SIP 请求消息的过程:
首先 对域名example.com 进行NAPTR 查询,查询的结果为:
order pref flags serviceregexp replacement
IN NAPTR 50 50 "s" "SIPS+D 2 T""" _sips._tcp.example.com.
IN NAPTR 90 50 "s" "SIP+D 2 T""" _sip._tcp.example.com
IN NAPTR 100 50 "s" "SIP+D 2 U" "" _sip._udp.example.com.
NAPTR 返回了多条记录,根据order 和pref 的取值选择了第一条记录,flag 为s 表示下一步进行SRV 查询,service 为SIPS+D 2 T 表示使用TCP 作为传输层协议,同时使用sips 方式传输消息,replacement 表示使用_sips._tcp.example.com 进行获取目标网元的地址信息。
然后 对域名_sips._tcp.example.com 进行SRV 查询,查询的结果为:
Priority WeightPortTarget
IN SRV 0 1 5060 server 1 .example.com
IN SRV 0 2 5060 server 2 .example.com
SRV 返回了两条记录,根据priority 和weight 选择其中一条,假设选择的是第一条,那么意味这目标端口为5060 ,Target 包含了目标网元的域名server 1 .example.com 。
最后 对域名server 1 .example.com 进行A 或AAAA 查询,得到目标网元的IP 地址:
IN AAAA 5 F 05 : 2000 : 80 AD: 5800 : 0058 : 0800 : 2023 : 1 D 71 1.3 . 如何发送响应 消息
一般情况下,对于可靠的传输层协议,响应 消息在请求消息所在的连接上返回,对于非可靠的传输层协议,响应 消息通过发送请求消息的源IP 地址以及Via 中的端口返回。但是如果UAC 发送完请求消息后就发生了异常,UAS 应当如何返回响应 消息?具体包括如下过程:
1 、如果Top Via 包含了IP 地址和端口,向该地址和端口返回响应 消息;
2 、如果Top Via 包含了IP 地址,没有包含端口,使用传输层协议的默认端口返回响应 消息;
3 、如果Top Via 包含了域名和端口,使用A 或AAAA 查询,获得IP 地址列表,然后试图向列表中的每一个IP 地址发送响应 消息,只到有一个发送成功为止;
4 、如果Top Via 包含了域名,没有包含端口,使用SRV 查询,获得端口和新域名,对新域名的处理和步骤3 类似; 2 .IMS 中的 DNS 过程
IMS 中的DNS 过程也可以分为两类:一类是IMS 中的SIP 实体基于SIP URI 的DNS 查询,例如主叫侧S-CSCF 需要获得被叫网络中的I-CSCF ,其过程采用SIP 定义的DNS 过程;另一类是基于TEL URI 的DNS 查询。
2.1
.
基于SIP URI
的DNS
查询
基于SIP URI 的查询采用SIP 定义的DNS 过程(RFC 3261 , RFC 3263 ) ,一般为NAPTR 查询,SRV 查询,最后是A 或AAAA 查询。整个过程涉及多次DNS 查询,可能造成会话建立时间过长,为此有两种方法可以解决这个问题。第一种方法,DNS 服务器 猜测用户可能会进行的DNS 查询,然后返回所有这些可能的查询,例如用户进行了NAPTR 查询后,DNS 服务器 不仅返回NAPTR 查询的结果,还会返回相关的SRV 以及AAAA 的记录。第二种方法是用户将查询结果缓存一段时间,在这段时间以内,如果再次查询该域名,可以直接使用相关记录。 2.2 . 基于TEL URI 的DNS 查询
IMS 中的tel 号码有两种情况:一种情况是tel 号码对应于IMS 网络中的一个用户;另外一种情况是tel 号码对应于非IMS 网络中的用户,如PSTN 用户、GSM 用户等。后一种情况比较简单,只需要将对应的SIP 消息转发给BGCF 来处理即可。而对于前一种情况则需要将TEL URI 转换成SIP URI ,因为只有SIP URI 才可以在IMS 网络中路由。
RFC 2916 讲述了将TEL URI 转换为SIP URI 的方法,即通过NAPTR 查询来获得这种转换,具体步骤为:
1 、将TEL 号码按照E. 164 格式表达成全号码(包括国家码);
2 、去除首部”+” 之外的所有其他非数字字符;
3 、去除首部的”+” ;
4 、在数字字符之间加上”.” 号;
5 、将数字字符串顺序反转;
6 、在字符串后面加上后缀”e 164 .arpa” ;
7 、将字符串作为域名,进行NAPTR 查询;
8 、根据查询返回的记录得到对应SIP URI ;
下面以一个例子来讲述整个过程 ,假设号码为+ 46 - 8 - 9761234 ,具体转换过程为:
首先去除所有非数字字符,得到” 4689761234 ” ;
其次加上”.” 号,得到” 4.6.8.9.7.6.1.2.3.4 ” ;
再次进行反转,得到” 4.3.2.1.6.7.9.8.6.4 ” ;
再次加上后缀,得到” 4.3.2.1.6.7.9.8.6.4 .e 164 .arpa” ;
最后对域名” 4.3.2.1.6.7.9.8.6.4 .e 164 .arpa” 进行NAPTR 查询,得到如下记录:
order pref flags serviceregexp replacement IN NAPTR 100 10 "u" "sip+E 2 U""!^.*$!sip:info@tele 2 .se!". IN NAPTR 102 10 "u" "mailto+E 2 U" "!^.*$!mailto:info@tele 2 .se!" .
NAPTR 返回了两条记录,order 和prefer 表达记录的使用偏好,flags 为”u” ,表示regexp 域给出了替代规则,根据该规则和原来的域名可以得出一个满足absoluteURI 的URI(RFC 2396 ) 。Service 给出记录对应的协议和服务 ,”sip” 表示转换出的URI 用于SIP 协议,”mailto” 表示转换出的URI 用于mail 协议,”E 2 U” 表示e. 164 to URI 服务 。
本例是IMS 中的TEL 到SIP 转换,所有使用第一条记录,得到最终的SIP URI ,即sip:info@tele 2 .se 。
基于SIP URI 的查询采用SIP 定义的DNS 过程(RFC 3261 , RFC 3263 ) ,一般为NAPTR 查询,SRV 查询,最后是A 或AAAA 查询。整个过程涉及多次DNS 查询,可能造成会话建立时间过长,为此有两种方法可以解决这个问题。第一种方法,DNS 服务器 猜测用户可能会进行的DNS 查询,然后返回所有这些可能的查询,例如用户进行了NAPTR 查询后,DNS 服务器 不仅返回NAPTR 查询的结果,还会返回相关的SRV 以及AAAA 的记录。第二种方法是用户将查询结果缓存一段时间,在这段时间以内,如果再次查询该域名,可以直接使用相关记录。 2.2 . 基于TEL URI 的DNS 查询
IMS 中的tel 号码有两种情况:一种情况是tel 号码对应于IMS 网络中的一个用户;另外一种情况是tel 号码对应于非IMS 网络中的用户,如PSTN 用户、GSM 用户等。后一种情况比较简单,只需要将对应的SIP 消息转发给BGCF 来处理即可。而对于前一种情况则需要将TEL URI 转换成SIP URI ,因为只有SIP URI 才可以在IMS 网络中路由。
RFC 2916 讲述了将TEL URI 转换为SIP URI 的方法,即通过NAPTR 查询来获得这种转换,具体步骤为:
1 、将TEL 号码按照E. 164 格式表达成全号码(包括国家码);
2 、去除首部”+” 之外的所有其他非数字字符;
3 、去除首部的”+” ;
4 、在数字字符之间加上”.” 号;
5 、将数字字符串顺序反转;
6 、在字符串后面加上后缀”e 164 .arpa” ;
7 、将字符串作为域名,进行NAPTR 查询;
8 、根据查询返回的记录得到对应SIP URI ;
下面以一个例子来讲述整个过程 ,假设号码为+ 46 - 8 - 9761234 ,具体转换过程为:
首先去除所有非数字字符,得到” 4689761234 ” ;
其次加上”.” 号,得到” 4.6.8.9.7.6.1.2.3.4 ” ;
再次进行反转,得到” 4.3.2.1.6.7.9.8.6.4 ” ;
再次加上后缀,得到” 4.3.2.1.6.7.9.8.6.4 .e 164 .arpa” ;
最后对域名” 4.3.2.1.6.7.9.8.6.4 .e 164 .arpa” 进行NAPTR 查询,得到如下记录:
order pref flags serviceregexp replacement IN NAPTR 100 10 "u" "sip+E 2 U""!^.*$!sip:info@tele 2 .se!". IN NAPTR 102 10 "u" "mailto+E 2 U" "!^.*$!mailto:info@tele 2 .se!" .
NAPTR 返回了两条记录,order 和prefer 表达记录的使用偏好,flags 为”u” ,表示regexp 域给出了替代规则,根据该规则和原来的域名可以得出一个满足absoluteURI 的URI(RFC 2396 ) 。Service 给出记录对应的协议和服务 ,”sip” 表示转换出的URI 用于SIP 协议,”mailto” 表示转换出的URI 用于mail 协议,”E 2 U” 表示e. 164 to URI 服务 。
本例是IMS 中的TEL 到SIP 转换,所有使用第一条记录,得到最终的SIP URI ,即sip:info@tele 2 .se 。
3
.DNS
的基本概念
3.1 .DNS 的授权
网络信息中心NIC 负责分配顶极域和委派其他指定地区域的授权机构。一个独立管理的DNS 子树称为一个区域,许多二极域将他们的子域划分为更小的区域。当一个系统加入到一个区域中时,该区域的DNS 管理者为该新系统申请一个域名和一个IP 地址,并将他们加入到名字服务器 的数据库中。一个名字服务器 负责一个或多个区域,一个区域的管理者必须为该区域提供一个主名字服务器 和至少一个辅助名字服务器 。每个主名字服务器 都必须知道根名字服务器 的IP 地址,根服务器 必须知道所有二极域中每个授权名字服务器 的名字和IP 地址。常见的顶级域:com 用于商业组织,edu 用于教育机构,org 用于非赢利组织,net 用于计算机网络组织,gov 用于美国政府组织。
下面以一个例子讲述DNS 的查找过程 ,假设Web 浏览器访问“msdn.microsoft.com” 站点,它会通过以下步骤来解析该域名的 IP 地址:
1 、浏览器调用 DNS 客户端(称为解析器),并使用上次查询缓存的信息在本地解析该查询;
2 、如果在本地无法解析查询,客户端就会向已知的 DNS 服务器 询问,如果该 DNS 服务器 曾经在特定的时间段内处理过相同的域名(“msdn.microsoft.com“ )请求,它就会在缓存中检索相应的 IP 地址,并将它返回给客户端;
3 、如果该 DNS 服务器 找不到相应的地址,客户端就会向某个全局根 DNS 服务器 询问,后者返回顶级域权威 DNS 服务器 的指针,在这种情况下,“com” 域权威服务器 的 IP 地址将返回给客户端;
4 、客户端向“com” 服务器 询问“microsoft.com” 服务器 的地址;
5 、客户端将原始查询传到“microsoft.com” 服务器 ,因为“microsoft.com” 服务器 在本地维护“msdn.microsoft.com” 域的权威记录,所以它将最终结果返回给客户端,并完成特定 IP 地址的查询;
注意,可以将 DNS 资源记录缓存到网络上任意数量的 DNS 服务器 中。第 2 步中提到的 DNS 服务器 可能不包含“msdn.microsoft.com” 缓存记录。但是,它可能有“microsoft.com” 的记录,更可能有“com” 域的记录。这可省去客户端获得最终结果所需的一次或几次查询,从而加快了整个搜索过程。 3.2 .DNS 查询报文中的问题部分
查询报文由多个问题部分组成,每个问题代表一个查询,其包括查询名、查询类型和查询类。查询名 是指要查找的名字,它是一个或多个标识符的序列。每个标识符以首字节的计数值来说明随后标识符的字节长度,每个名字以最后字节为0 结束,长度为0 的标识符是根标识符。计数字节的值必须为0 -63 ,因为标识符的最大长度仅为63 。该字段无需以整32 为为 边界,即无需填充字节,例如gemini.tuc.noao.edu 的存储格式为6 gemini 3 tuc 4 noao 3 edu 0 。查询类型 描述查询哪个方面的问题,最常见的查询类型是A 类型(值为1 ),表示期望获得查询名的IP 地址,PTR 查询(值为12 )则请求获得一个IP 地址对应的域名。查询类 一般是1 ,指互联网地址。
3.1 .DNS 的授权
网络信息中心NIC 负责分配顶极域和委派其他指定地区域的授权机构。一个独立管理的DNS 子树称为一个区域,许多二极域将他们的子域划分为更小的区域。当一个系统加入到一个区域中时,该区域的DNS 管理者为该新系统申请一个域名和一个IP 地址,并将他们加入到名字服务器 的数据库中。一个名字服务器 负责一个或多个区域,一个区域的管理者必须为该区域提供一个主名字服务器 和至少一个辅助名字服务器 。每个主名字服务器 都必须知道根名字服务器 的IP 地址,根服务器 必须知道所有二极域中每个授权名字服务器 的名字和IP 地址。常见的顶级域:com 用于商业组织,edu 用于教育机构,org 用于非赢利组织,net 用于计算机网络组织,gov 用于美国政府组织。
下面以一个例子讲述DNS 的查找过程 ,假设Web 浏览器访问“msdn.microsoft.com” 站点,它会通过以下步骤来解析该域名的 IP 地址:
1 、浏览器调用 DNS 客户端(称为解析器),并使用上次查询缓存的信息在本地解析该查询;
2 、如果在本地无法解析查询,客户端就会向已知的 DNS 服务器 询问,如果该 DNS 服务器 曾经在特定的时间段内处理过相同的域名(“msdn.microsoft.com“ )请求,它就会在缓存中检索相应的 IP 地址,并将它返回给客户端;
3 、如果该 DNS 服务器 找不到相应的地址,客户端就会向某个全局根 DNS 服务器 询问,后者返回顶级域权威 DNS 服务器 的指针,在这种情况下,“com” 域权威服务器 的 IP 地址将返回给客户端;
4 、客户端向“com” 服务器 询问“microsoft.com” 服务器 的地址;
5 、客户端将原始查询传到“microsoft.com” 服务器 ,因为“microsoft.com” 服务器 在本地维护“msdn.microsoft.com” 域的权威记录,所以它将最终结果返回给客户端,并完成特定 IP 地址的查询;
注意,可以将 DNS 资源记录缓存到网络上任意数量的 DNS 服务器 中。第 2 步中提到的 DNS 服务器 可能不包含“msdn.microsoft.com” 缓存记录。但是,它可能有“microsoft.com” 的记录,更可能有“com” 域的记录。这可省去客户端获得最终结果所需的一次或几次查询,从而加快了整个搜索过程。 3.2 .DNS 查询报文中的问题部分
查询报文由多个问题部分组成,每个问题代表一个查询,其包括查询名、查询类型和查询类。查询名 是指要查找的名字,它是一个或多个标识符的序列。每个标识符以首字节的计数值来说明随后标识符的字节长度,每个名字以最后字节为0 结束,长度为0 的标识符是根标识符。计数字节的值必须为0 -63 ,因为标识符的最大长度仅为63 。该字段无需以整32 为为 边界,即无需填充字节,例如gemini.tuc.noao.edu 的存储格式为6 gemini 3 tuc 4 noao 3 edu 0 。查询类型 描述查询哪个方面的问题,最常见的查询类型是A 类型(值为1 ),表示期望获得查询名的IP 地址,PTR 查询(值为12 )则请求获得一个IP 地址对应的域名。查询类 一般是1 ,指互联网地址。
3.3
.
资源记录RR
查询结果通过资源记录的方式返回,名字服务器 返回的资源记录可以是回答RR 、授权RR 和附加信息RR 。RR 记录中的类型字段给出该记录所包含的信息:
1 、A ,一个A 记录定义了一个IP 地址;
2 、PTR ,指针记录用于指针查询,IP 地址被看作是noao.edu 域下的一个域名;
3 、CNAME ,表示规范名字,用来表示一个域名,而有规范名字的域名通常叫做别名,某些FTP 服务器 使用它向其他的系统提供一个易于记忆的别名;
4 、HINFO ,表示主机信息,包括说明主机CPU 和操作系统的两个字符串;
5 、MX ,邮件交换记录,例如可以表达如果有邮件要发往use@foo.com ,就将邮件发送到relay 1 .uu.net 这样的信息。
6 、NS ,名字服务器 记录,其说明一个域的授权名字服务器 ,它由域名表示。 3.4 . 使用UDP 还是TCP
DNS 同时支持UDP 和TCP ,端口号都是53 。当查询请求的响应 消息长度超过512 个字节时,UDP 仅返回前512 个字节,这时名字解析器通常使用TCP 重发原来的查询请求。既然DNS 主要使用UDP ,因此好的重传和超时机制就比较重要了。 4 .DNS NAPTR 资源记录
DNS NAPTR 资源记录的功能是能够将原来的域名映射成一个新的域名或者URI(Uniform Resource Identifier) ,并通过flag 域来指定这些新域名或URI 在后继操作中的使用方法。下面通过一个例子来讲述NAPTR 记录各字段的含义:
order pref flags serviceregexp replacement
IN NAPTR 100 10 "u" "sip+E 2 U""!^.*$!sip:info@tele 2 .se!".
lorder , 给出处理的顺序,按照oder 从小到大的顺序对记录搜索,搜索到匹配的记录后,就停止搜索order 值更大的记录;
lpreference , 给出在同一个order 下各记录的偏好(或权重),值越小偏好越高,pref 和order 的不同之处在于,order 具有唯一性,用户只可以处理某一个order 值,而pref 表达的是偏好,用户可以对多个不同pref 进行综合考虑;
lflags , 为[A-Z 0 - 9 ] 中的一个字符,表达映射关系及记录本身的含义,目前有”U”,”S”,”A” 和”P” 四个标志,其中”U”,”S” 和”A” 是终结标志,即下一步不需要再进行NAPTR 查询,”A” 表示下一步进行A ,AAAA 或者A 6 查询,”U” 表示下一步不需要DNS 查询,本次输出的是满足RFC 2396 要求的absoluteURI ,”S” 表示下一步进行SRV 查询,”P” 表示由用户根据service 定义自己的规则,所以既可以是终结标志,也可以是非终结标志,如果flags 为空( 即什么字符也没有) ,表示用户需要根据本次输出,再进行一次NAPTR 查询;
lservice , 给出新目标( 即映射后的新域名或URI) 上的服务 ,以及和该服务 交互所使用的协议,其形式为[protocol]*(“+” service) ,如果flags 中的标志为终结标志时,protocol 就必须填写;
lregexp , 给出根据原域名生成新域名或URI 的规则;
lreplacement, 包含一个域名,根据flags 给出进行下一次NAPTR 、SRV 、A 或者AAAA 查询所需要的域名,一般情况下,regexp 和replacement 两者用其一; 5 .DNS SRV 资源记录
DNS SRV 资源记录用于给出在某域中实现某种服务 和协议的服务器 地址列表。假设我们需要得到example.com 域中支持TCP 协议的SIP 服务器 ,这时就可以对_sip._tcp.example.com 域进行DNS SRV 查询,假设DNS SRV 返回如下记录:
Priority WeightPortTarget
IN SRV 0 1 5060 icscf 1 .example.com
IN SRV 0 2 5060 icscf 2 .example.com
这样就可以得到example.com 域中支持TCP 方式的两个SIP 服务器 。下面对SRV 记录中的几个域解释一下:
lpriority , 给出处理的顺序,按照priority 从小到大的顺序对记录搜索,搜索到匹配的记录后,就停止搜索priority 值更大的记录,对于拥有相同priority 的记录将通过weight 再次选择;
lweight , 对于拥有相同priority 的多条记录,weight 给出了选择某条记录的几率,值越大,被选中的概率就越大,合理的取值范围为0 - 65535 ;
lport , 目标机器提供对应服务 的端口;
ltarget , 目标机器的域名;
下面再用一个例子来介绍一下怎样通过weight 来选择拥有相同priority 的多条记录,假设有四条记录A ,B ,C ,D ,其weight 分别为120 ,70 ,95 ,0 ,其过程如下:
1 . 将weight 为0 的记录排在最前面,其他记录顺序任意,那么现在的顺序可以是DABC ;
2 . 每一个记录取一个加权值,该值等于前面所有记录( 包括自己) 的weight 总和,那么D 为0 ,A 为120 ,B 为190 ,C 为285 ;
3 . 再计算出所有weight 的总和,120 + 70 + 95 + 0 = 285 ,并随机出一个在0 到285 之间( 包括0 和285 ) 的随机数;
4 . 将随机值按照DABC 的顺序和各加权值比较,当出现随机值小于等于加权值时停止比较,该加权值所对应的记录就为本次选中的记录;
通过上述方法可以选出一条可用的记录,如果还需要再选出一条,可以将选出的记录从列表中删去,然后再按步骤2 到步骤4 进行一次即可。
6 . 相关 RFC 文档
RFC 3263 , Session Initial Protocol: Locating SIP Servers, 讲述SIP 传输层的相关细节;
RFC 2916 , E. 164 number and DNS , 讲述如何通过NAPTR 将E. 164 转换为URI 的方法;
RFC 1034 , DOMAIN NAMES – Concepts and Facilities, 讲述DNS 中的基本概念;
RFC 1035 , DOMAIN NAMES – Implementation and Specification, 讲述DNS 实现的相关问题;
RFC 2915 , The Naming Authority Pointer (NAPTR) DNS Resource Record ,讲述名称权威指针的原理、细节及使用方法;
RFC 2782 , A DNS RR for specifying the location of services, 讲述SRV 的原理、细节及使用方法;
查询结果通过资源记录的方式返回,名字服务器 返回的资源记录可以是回答RR 、授权RR 和附加信息RR 。RR 记录中的类型字段给出该记录所包含的信息:
1 、A ,一个A 记录定义了一个IP 地址;
2 、PTR ,指针记录用于指针查询,IP 地址被看作是noao.edu 域下的一个域名;
3 、CNAME ,表示规范名字,用来表示一个域名,而有规范名字的域名通常叫做别名,某些FTP 服务器 使用它向其他的系统提供一个易于记忆的别名;
4 、HINFO ,表示主机信息,包括说明主机CPU 和操作系统的两个字符串;
5 、MX ,邮件交换记录,例如可以表达如果有邮件要发往use@foo.com ,就将邮件发送到relay 1 .uu.net 这样的信息。
6 、NS ,名字服务器 记录,其说明一个域的授权名字服务器 ,它由域名表示。 3.4 . 使用UDP 还是TCP
DNS 同时支持UDP 和TCP ,端口号都是53 。当查询请求的响应 消息长度超过512 个字节时,UDP 仅返回前512 个字节,这时名字解析器通常使用TCP 重发原来的查询请求。既然DNS 主要使用UDP ,因此好的重传和超时机制就比较重要了。 4 .DNS NAPTR 资源记录
DNS NAPTR 资源记录的功能是能够将原来的域名映射成一个新的域名或者URI(Uniform Resource Identifier) ,并通过flag 域来指定这些新域名或URI 在后继操作中的使用方法。下面通过一个例子来讲述NAPTR 记录各字段的含义:
order pref flags serviceregexp replacement
IN NAPTR 100 10 "u" "sip+E 2 U""!^.*$!sip:info@tele 2 .se!".
lorder , 给出处理的顺序,按照oder 从小到大的顺序对记录搜索,搜索到匹配的记录后,就停止搜索order 值更大的记录;
lpreference , 给出在同一个order 下各记录的偏好(或权重),值越小偏好越高,pref 和order 的不同之处在于,order 具有唯一性,用户只可以处理某一个order 值,而pref 表达的是偏好,用户可以对多个不同pref 进行综合考虑;
lflags , 为[A-Z 0 - 9 ] 中的一个字符,表达映射关系及记录本身的含义,目前有”U”,”S”,”A” 和”P” 四个标志,其中”U”,”S” 和”A” 是终结标志,即下一步不需要再进行NAPTR 查询,”A” 表示下一步进行A ,AAAA 或者A 6 查询,”U” 表示下一步不需要DNS 查询,本次输出的是满足RFC 2396 要求的absoluteURI ,”S” 表示下一步进行SRV 查询,”P” 表示由用户根据service 定义自己的规则,所以既可以是终结标志,也可以是非终结标志,如果flags 为空( 即什么字符也没有) ,表示用户需要根据本次输出,再进行一次NAPTR 查询;
lservice , 给出新目标( 即映射后的新域名或URI) 上的服务 ,以及和该服务 交互所使用的协议,其形式为[protocol]*(“+” service) ,如果flags 中的标志为终结标志时,protocol 就必须填写;
lregexp , 给出根据原域名生成新域名或URI 的规则;
lreplacement, 包含一个域名,根据flags 给出进行下一次NAPTR 、SRV 、A 或者AAAA 查询所需要的域名,一般情况下,regexp 和replacement 两者用其一; 5 .DNS SRV 资源记录
DNS SRV 资源记录用于给出在某域中实现某种服务 和协议的服务器 地址列表。假设我们需要得到example.com 域中支持TCP 协议的SIP 服务器 ,这时就可以对_sip._tcp.example.com 域进行DNS SRV 查询,假设DNS SRV 返回如下记录:
Priority WeightPortTarget
IN SRV 0 1 5060 icscf 1 .example.com
IN SRV 0 2 5060 icscf 2 .example.com
这样就可以得到example.com 域中支持TCP 方式的两个SIP 服务器 。下面对SRV 记录中的几个域解释一下:
lpriority , 给出处理的顺序,按照priority 从小到大的顺序对记录搜索,搜索到匹配的记录后,就停止搜索priority 值更大的记录,对于拥有相同priority 的记录将通过weight 再次选择;
lweight , 对于拥有相同priority 的多条记录,weight 给出了选择某条记录的几率,值越大,被选中的概率就越大,合理的取值范围为0 - 65535 ;
lport , 目标机器提供对应服务 的端口;
ltarget , 目标机器的域名;
下面再用一个例子来介绍一下怎样通过weight 来选择拥有相同priority 的多条记录,假设有四条记录A ,B ,C ,D ,其weight 分别为120 ,70 ,95 ,0 ,其过程如下:
1 . 将weight 为0 的记录排在最前面,其他记录顺序任意,那么现在的顺序可以是DABC ;
2 . 每一个记录取一个加权值,该值等于前面所有记录( 包括自己) 的weight 总和,那么D 为0 ,A 为120 ,B 为190 ,C 为285 ;
3 . 再计算出所有weight 的总和,120 + 70 + 95 + 0 = 285 ,并随机出一个在0 到285 之间( 包括0 和285 ) 的随机数;
4 . 将随机值按照DABC 的顺序和各加权值比较,当出现随机值小于等于加权值时停止比较,该加权值所对应的记录就为本次选中的记录;
通过上述方法可以选出一条可用的记录,如果还需要再选出一条,可以将选出的记录从列表中删去,然后再按步骤2 到步骤4 进行一次即可。
6 . 相关 RFC 文档
RFC 3263 , Session Initial Protocol: Locating SIP Servers, 讲述SIP 传输层的相关细节;
RFC 2916 , E. 164 number and DNS , 讲述如何通过NAPTR 将E. 164 转换为URI 的方法;
RFC 1034 , DOMAIN NAMES – Concepts and Facilities, 讲述DNS 中的基本概念;
RFC 1035 , DOMAIN NAMES – Implementation and Specification, 讲述DNS 实现的相关问题;
RFC 2915 , The Naming Authority Pointer (NAPTR) DNS Resource Record ,讲述名称权威指针的原理、细节及使用方法;
RFC 2782 , A DNS RR for specifying the location of services, 讲述SRV 的原理、细节及使用方法;