看到这篇文章不错。转载在这边。以备后面的工作与学习之用
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 的原理、细节及使用方法；
扫一扫
339
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
