SIP中的DNS过程

1.SIP中的DNS过程

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+D2U”, X+D2T”, XX+D2S”, 其中XXX表示服务名称，可以是”SIP”或”SIPS”，D2U表示使用UDP协议，D2T表示使用TCP协议，D2S表示使用SCTP协议；

5、  根据RFC3261的传输准则判断是否需要使用某种强制协议，如果需要使用强制协议，则使用该强制协议，否则对于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  service      regexp     replacement

IN NAPTR  50    50   "s"   "SIPS+D2T"   ""    _sips._tcp.example.com.

IN NAPTR  90    50   "s"   "SIP+D2T"    ""    _sip._tcp.example.com

IN NAPTR  100   50   "s"   "SIP+D2U"    ""    _sip._udp.example.com.

NAPTR返回了多条记录，根据order和pref的取值选择了第一条记录，flag为s表示下一步进行SRV查询，service为SIPS+D2T表示使用TCP作为传输层协议，同时使用sips方式传输消息，replacement表示使用_sips._tcp.example.com进行获取目标网元的地址信息。

然后对域名_sips._tcp.example.com进行SRV查询，查询的结果为：

Priority   Weight  Port     Target

IN  SRV   0        1     5060    server1.example.com

IN  SRV   0        2     5060    server2.example.com

SRV返回了两条记录，根据priority和weight选择其中一条，假设选择的是第一条，那么意味这目标端口为5060，Target包含了目标网元的域名server1.example.com。

最后对域名server1.example.com进行A或AAAA查询，得到目标网元的IP地址：

IN AAAA 5F05:2000:80AD:5800:0058:0800:2023:1D71

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过程(RFC3261, RFC3263)，一般为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网络中路由。

RFC2916讲述了将TEL URI转换为SIP URI的方法，即通过NAPTR查询来获得这种转换，具体步骤为：

1、  将TEL号码按照E.164格式表达成全号码（包括国家码）；

2、  去除首部”+”之外的所有其他非数字字符；

3、  去除首部的”+”；

4、  在数字字符之间加上”.”号；

5、  将数字字符串顺序反转；

6、  在字符串后面加上后缀”e164.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.e164.arpa”；

最后对域名” 4.3.2.1.6.7.9.8.6.4.e164.arpa”进行NAPTR查询，得到如下记录：

order  pref  flags  service           regexp             replacement

 IN NAPTR  100   10   "u"  "sip+E2U"     "!^.*$!sip:info@tele2.se!"     .

 IN NAPTR  102   10   "u"  "mailto+E2U"  "!^.*$!mailto:info@tele2.se!"   .

NAPTR返回了两条记录，order和prefer表达记录的使用偏好，flags为”u”，表示regexp域给出了替代规则，根据该规则和原来的域名可以得出一个满足absoluteURI的URI(RFC2396)。Service给出记录对应的协议和服务，”sip”表示转换出的URI用于SIP协议，”mailto”表示转换出的URI用于mail协议，”E2U”表示e.164 to URI服务。

本例是IMS中的TEL到SIP转换，所有使用第一条记录，得到最终的SIP URI，即sip:info@tele2.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的存储格式为6gemini3tuc4noao3edu0。查询类型描述查询哪个方面的问题，最常见的查询类型是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，就将邮件发送到relay1.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  service           regexp             replacement

 IN NAPTR  100   10   "u"  "sip+E2U"     "!^.*$!sip:info@tele2.se!"     .

l         order, 给出处理的顺序，按照oder从小到大的顺序对记录搜索，搜索到匹配的记录后，就停止搜索order值更大的记录；

l         preference, 给出在同一个order下各记录的偏好（或权重），值越小偏好越高，pref和order的不同之处在于，order具有唯一性，用户只可以处理某一个order值，而pref表达的是偏好，用户可以对多个不同pref进行综合考虑；

l         flags, 为[A-Z0-9]中的一个字符，表达映射关系及记录本身的含义，目前有”U”,”S”,”A”和”P”四个标志，其中”U”,”S”和”A”是终结标志，即下一步不需要再进行NAPTR查询，”A”表示下一步进行A，AAAA或者A6查询，”U”表示下一步不需要DNS查询，本次输出的是满足RFC2396要求的absoluteURI，”S”表示下一步进行SRV查询，”P”表示由用户根据service定义自己的规则，所以既可以是终结标志，也可以是非终结标志，如果flags为空(即什么字符也没有)，表示用户需要根据本次输出，再进行一次NAPTR查询；

l         service, 给出新目标(即映射后的新域名或URI)上的服务，以及和该服务交互所使用的协议，其形式为[protocol]*(“+” service)，如果flags中的标志为终结标志时，protocol就必须填写；

l         regexp, 给出根据原域名生成新域名或URI的规则；

l         replacement, 包含一个域名，根据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   Weight  Port     Target

IN  SRV   0        1     5060    icscf1.example.com

IN  SRV   0        2     5060    icscf2.example.com

这样就可以得到example.com域中支持TCP方式的两个SIP服务器。下面对SRV记录中的几个域解释一下：

l         priority, 给出处理的顺序，按照priority从小到大的顺序对记录搜索，搜索到匹配的记录后，就停止搜索priority值更大的记录，对于拥有相同priority的记录将通过weight再次选择；

l         weight, 对于拥有相同priority的多条记录，weight给出了选择某条记录的几率，值越大，被选中的概率就越大，合理的取值范围为0-65535；

l         port, 目标机器提供对应服务的端口；

l         target, 目标机器的域名；

下面再用一个例子来介绍一下怎样通过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文档

RFC3263, Session Initial Protocol: Locating SIP Servers, 讲述SIP传输层的相关细节；

RFC2916, E.164 number and DNS, 讲述如何通过NAPTR将E.164转换为URI的方法；

RFC1034, DOMAIN NAMES – Concepts and Facilities, 讲述DNS中的基本概念；

RFC1035, DOMAIN NAMES – Implementation and Specification, 讲述DNS实现的相关问题；

RFC2915, The Naming Authority Pointer (NAPTR) DNS Resource Record，讲述名称权威指针的原理、细节及使用方法；

RFC2782, A DNS RR for specifying the location of services, 讲述SRV的原理、细节及使用方法；

转载于:https://www.cnblogs.com/MMLoveMeMM/articles/3866362.html