CN102769529B - Dnssec签名服务器 - Google Patents

Dnssec签名服务器 Download PDF

Info

Publication number
CN102769529B
CN102769529B CN201210208313.7A CN201210208313A CN102769529B CN 102769529 B CN102769529 B CN 102769529B CN 201210208313 A CN201210208313 A CN 201210208313A CN 102769529 B CN102769529 B CN 102769529B
Authority
CN
China
Prior art keywords
signature
data
activation
server
request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201210208313.7A
Other languages
English (en)
Other versions
CN102769529A (zh
Inventor
D·史密斯
J·古尔德
R·莱武
D·德什潘德
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
FLISAEN Co
Original Assignee
FLISAEN Co
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by FLISAEN Co filed Critical FLISAEN Co
Publication of CN102769529A publication Critical patent/CN102769529A/zh
Application granted granted Critical
Publication of CN102769529B publication Critical patent/CN102769529B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

描述了用于执行DNSSEC签名的系统和方法，其中数字签名操作可以由网络可访问签名服务器执行，所述服务器配置为与分离的客户端应用交互。示例的方法可以包括在签名服务器从户端应用接收签名请求以签名第一数据。签名服务器可以为该第一数据确定激活的KSK和/或激活的ZSK。第一数据然后可以由签名服务器发送到数字签名模块，其可以包括，例如，硬件支持模块或者软件签名应用。签名服务器可以从数字签名模块接收该第一数据的经数字签名的版本，并将经签名的第一数据提供给客户端应用。

Description

DNSSEC签名服务器
背景技术
域名系统(DNS)是因特网基础结构的一部分，其将人类可读域名翻译为通过因特网建立TCP/IP通信所需的因特网协议(IP)号码。即，DNS允许用户使用较容易记忆的域名(例如www.en.example.com)而不是数字IP地址(例如“123.4.56.78”)来访问网站和其他资源，数字IP地址是软件使用来与因特网上的计算机进行通信的机器可读地址。每个域名由一系列由点分隔开的字符串(标签)组成。域名中最右端的标签被认为是“顶级域名”(TLD)。熟知的TLD例子是“.com”；“.net”；“.org”等等。每个TLD支持直接在TLD的左侧列出的第二级域，例如“www.example.com”中的“example”。每个第二级域可支持多个直接位于在第二级域的左侧的第三级域，例如“www.en.example.com”中的“en”。还可以存在附加级别域。例如具有附加域级别的域可以是“www.landscape.photos.example.com”。
需要注意单个IP地址，例如分配给单个服务器的一个，可支持多个域名。即，不同域名可解析到相同的服务器，然后服务器可基于请求的域名和/或附加非域信息来确定提供什么内容。这有时被称为虚拟主机(hosting)。
附加非域信息可包括在包括域名的统一资源标识符(“URI”)结构中。例如，“路径”部分是由正斜杠(“/”)分隔开的一系列片段。该信息可以直接包括在域名的右侧，例如“www.example.com/blog/today.htm”中的“blog”，并且可由服务器或其他接收装置用来识别和传送特定内容或运行特定代码。非域信息的其他示例可包括查询和片段，其具体细节为本领域普通技术人员所理解并且不在此详细讨论。该信息的组合可包括在将用户导航到相同页面的其他部分或其他网页的网页超链接中。
因此，从以上提供的各个示例可以看出，并如本领域技术人员所意识到的那样，域，例如第二级域“example.com”，可包括多种具有不同地址和其他识别手段的不同因特网可访问信息。
域名的实际注册由公司执行，被称作域名注册商(registrar)(“注册商”)。注册商向注册局(registry)注册域名。例如，终端用户向注册商提交域名用于注册，并且提供该域名将要解析到的IP地址。注册商与注册局通信以创建注册局数据库记录，注册局数据库记录可用于将域名解析到终端用户提供的IP地址，并指出注册商的身份(通过它域名被注册)。除非在注册局域名注册到期，典型地仅在注册局的域名记录中指定的注册商可以修改或删除有关域名的注册局数据库信息。终端用户可通过遵循特定域转移过程来转换注册商。注册商还可作为主机提供商(hosting provider)，或者终端用户可具有由独立的第三方域主机服务寄存(host)的域。
区域文件是描述被称作DNS区域的DNS的一部分的文本文件。区域文件以资源记录(RR)的形式组织并且包含定义域名和IP地址以及其他资源之间的映射的信息。区域文件的格式由标准定义，每行典型地定义单个资源记录。行以域名开始，但是如果左侧空白，则默认之前定义的域名。域名后面是生存时间(TTL)、类别(其对“因特网”(“internet”)几乎总是是“IN”并且很少被包括在内)、资源记录的类型(A、MX、SOA等等)，其后跟随类型特定数据，例如对于A记录是IPv4地址。通过使用半冒号可包括注释，以及通过使用圆括号可继续行。还存在文件指导(file directive)，其用以美元符号开始的关键字标记。
DNS通过为每个域指定权威(authoritative)名称服务器来分布分配域名并将这些名称映射到IP地址的责任。权威名称服务器被分配来负责它们的特定域，并且继而可为它们的子域分配其他权威名称服务器。该机制通常帮助避免了单个中央注册需要连续不断地被查阅和更新。DNS解析过程允许用户通过反向查找过程被指引到期望的域，从而用户进入期望的域，并且DNS返回合适的IP号码。在DNS解析过程期间，对给定域名的请求从解析器(例如桩解析器(stub resolver))路由至合适的服务器(例如递归解析器)以检索IP地址。为了改进效率、降低通过因特网的DNS业务量以及增加终端用户应用的性能，DNS支持DNS缓存服务器(cache server)，其存储DNS查询结果达由正被考虑的域名记录的生存时间(TTL)所确定的时间段。典型地，这样的缓存DNS服务器，还被称作DNS缓存，还执行必要的递归算法以将以DNS根开始的给定名称解析到所查询域的权威名称服务器。因特网服务提供商(ISP)典型地为他们的客户提供递归和缓存DNS服务器。此外，家庭网络路由器可执行DNS缓存和代理以改进在局域网中的效率。
虽然DNS的分布特性提供在整个系统的效率方面的显著优点，但是它还使系统对系统中各个节点处特定类型的故障和/或攻击易损坏。可能发生的一个特别的问题被称作DNS缓存中毒。DNS缓存中毒发生在当数据被引入到不是发源于权威DNS源的DNS名称服务器的缓存数据库的时候。这可由对名称服务器的故意攻击所导致，或者它可以是一个非故意的结果，例如由于错误配置的DNS缓存或不适当的DNS应用软件设计。因此，DNS缓存中毒可导致(1)解析请求失败，例如当提供了不准确或错误配置的IP地址信息时，或(2)请求用户的解析请求被指向恶意站点，其模仿真正的域并且被用于违法获得诸如账户密码等信息，或分发例如计算机蠕虫或病毒等传送至请求用户的恶意内容。
域名系统安全扩展(DNSSEC)是一套用于保护如IP网络上使用的DNS所提供的特定类型信息的因特网工程任务组(IETF)规范。DNSSEC规定了为DNS准备的区域文件的签名，确保DNS数据的来源鉴别和数据完整性，以及经鉴别的否定存在。一般地，DNSSEC中提供的答复是经过数字签名的，以及通过检查该数字签名，DNS解析器能够检查该信息是否对应于权威DNS服务器上的信息。DNSSEC使用公钥密码用于数字签名和鉴别。DNSKEY记录通过信任链而被鉴别，其中信任链以经核实的用于DNS根区域的公钥集(其是信任的第三方)开始。
为了执行DNSSEC，多个新DNS记录类型被创建或使适于与DNSSEC一起使用，包括RRSIG、DNSKEY、DS、NSEC、NSEC3和NSEC3PARAM。例如，当使用DNSSEC时，对于DNS查询的每个权威答复除请求的记录类型外还将包括RRSIG DNS记录。RRSIG记录是答复DNS资源记录集的数字签名。该数字签名可通过定位DNSKEY记录中发现的正确公钥来核实。在使用信任链的查找过程中，在DNSKEY鉴别中使用DS记录。NSEC和NSEC3记录用于提供对不存在的DNS记录的经鉴别的否定存在响应。
DNSSEC的要求涉及存储在DNSKEY记录和来自其他源的不同密钥的使用，以形成信任锚(trust anchor)。存在例如可用于其它DNSKEY记录签名的密钥签名密钥(KSK)，以及可用于其他记录签名的区域签名密钥(ZSK)。由于ZSK在特定DNS区域的使用和控制之下，它们可以更容易和更经常地被转换。结果是，ZSK一般地可以比KSK更短(在字节长度方面)，同时仍提供可接受的保护级别。
虽然已经开发了用于DNSSEC使用(包括KSK和ZSK的使用)的协议，但在注册商和注册局级别，存在操作DNSSEC使能(enable)域的许多方面，还没有为大规模使用而得到解决和/或优化。例如在短时间段内处理大量签名的能力，限制于基于区域的改变而签名整个区域和使用独立签名系统的惯例。而且，可能的解决方案限定为独立用户，或者有限数量的域等(其可以由特定的DNS提供商管理)。从而，不断需要进一步改进DNSSEC记录所需的签名功能和有关DNSSEC管理的操作的功能性和/或效率。
发明内容
大部分当前的DNSSEC技术包括在受限的区域管理和区域服务应用内(例如由用户、DNS提供商等限制)对DNSSEC数据进行签名。目前，希望采用DNSSEC的用户具有下列基本选项：
1.使用第三方和开源软件连同软件密钥或硬件密钥集的组合建立它们自己的DNSSEC解决方案。
2.使用DNSSEC密钥管理和像 DNS Signer、BlueCat Networks、Xelerance DNSX Secure、Signer以及Infoblox那样的签名工具。这样的工具可提供不同方面的密钥管理和区域签名，但需要安装在客户端位置的硬件。应当注意DNSSEC密钥管理和签名工具需要客户端位置的硬件安装，需要密钥资料的更实践管理，但不支持多于单个用户。
3.使用已经被更新为支持DNSSEC的可控DNS解决方案。可控DNS提供商包括区域管理和区域发布特征。DNSSEC启动允许客户端“打开”用于可控DNS区域的DNSSEC，但需要用户向可控DNS提供商转移或外包他们的DNS主机。
然而，随着DNSSEC被引入大量注册局，例如.com和.net注册局，用于DNSSEC数据的各种签名技术的无效率，特别对于大区域，带来潜在解析问题，包括延迟和解析失败。这样的问题可在电子商务和其他高业务量位置具有显著有害的影响。
本主题可以通过使用网络可访问签名服务器对DNSSEC使能(enable)区域的有效签名方面提供优势，所述网络可访问签名服务器允许远程应用管理签名并且还根据需要对区域数据的部分进行远程签名。根据本发明的方面，与其他那些功能基本上合并进去的技术相比(例如在名称服务器执行签名的技术中，或者特定的区域管理设备执行签名的情况)，使用网络可访问签名服务器可以提供区域管理和区域服务应用从签名机制中的去耦。
通过使用，例如，可扩展的、网络可访问的签名服务器，示例的配置与其他已知的技术相比，还可以减少或者消除手动配置签名服务器的各种功能的需求。网络可访问签名服务器还可以提供对宽范围的DNSSEC应用的支持，无需手动配置，诸如：
1.将资源记录的签名内嵌在高容量的DNSSEC应用中，例如TLD注册局。
2.在具有很多密钥和区域的DNSSEC应用中动态生成密钥、加载密钥、下载密钥并使用密钥签名区域数据。
3.在离线/批量DNSSEC应用中签名整个区域，例如ROOT区域。
在实施例中，用于执行DNSSEC签名的系统和方法可以由签名服务器执行，所述签名服务器配置为与单独的客户端应用进行交互。示例的方法通常包括在签名服务器接收来自客户端应用的签名请求以签名第一数据。签名服务器可以为该第一数据确定合适的签名密钥和/或协议。该第一数据接着由签名服务器发送到数字签名模块，其可以包括，例如，硬件支持模块或者软件签名应用。签名服务器可以从数字签名模块接收第一数据的数字签名版本，并将经签名的第一数据提供给客户端应用。
根据发明的第一方面，DNSSEC签名服务器可以配置为与至少一个DNSSEC客户端应用和数字签名模块交互。DNSSEC签名服务器可以包括，例如，处理器和包括计算机可读代码的存储设备，所述计算机可读代码当由处理器执行时，使得签名服务器充当配置为从至少一个客户端应用接收签名请求以签名第一数据的权威签名服务器。第一数据可以包括，例如，DNS数据。
在实施例中，签名服务器可以为第一数据确定合适的签名密钥，例如，激活KSK和激活ZSK中的至少一个。合适的密钥，诸如激活KSK和激活ZSK中的至少一个可以基于例如包含在签名请求中的TLD标识符确定。在实施例中，签名服务器可以配置成为第一数据确定多于一个的激活签名密钥和/或激活签名算法，并可以基于多于一个的激活签名密钥和/或激活签名算法为第一数据请求多个不同的签名。
在实施例中，签名服务器可以发送第一数据到多个数字签名模块中的一个，并可以从数字签名模块接收第一数据经数字签名的版本。签名服务器还可以配置为向客户端应用提供经签名的第一数据。
在实施例中，签名服务器可以配置为基于包含在签名请求中的服务类型标识符在多个不同的数字签名功能中区别所请求的签名功能，并基于该服务类型标识符将非DNSSEC签名请求路由到非DNSSEC数字签名模块。
根据发明的另一个方面，签名服务器还可以配置为接收(作为相同签名请求的一部分)请求以签名第二数据。该第二数据可以是，例如，DNS或者其他数据。签名服务器可以为第二数据确定合适的签名密钥，例如激活KSK和激活ZSK中的至少一个，该签名密钥不同于用于第一数据的密钥。例如，签名服务器可以为第一数据确定第一密钥集，为第二数据确定第二密钥集。
在实施例中，签名服务器可以将第二数据发送到多个数字签名模块中的一个，并从该数字签名模块接收第二数据经数字签名的版本。签名服务器还可以配置为向客户端应用提供签名的第二数据。
实施例可以包括其中签名服务器配置为接收多个签名请求作为单个请求分组的一部分，并对请求分组进行分析以识别具有彼此不同的激活KSK、激活ZSK和签名协议中的至少一个的不同的签名请求。
在实施例中，数字签名模块可以配置为根据DNSSEC协议对DNS数据的特定部分进行签名，而不是签名整个区域。
在实施例中，签名服务器还可以配置为提供额外的非DNSSEC数字签名功能。
在实施例中，每个数字签名模块可以包括硬件支持模块(HSM)，其在物理上与签名服务器的处理器分离并配置为对由签名服务器提供的数据进行数字签名。
在实施例中，HSM可以包括多个根据别名标识符识别的密钥。签名服务器可以配置为将用于要使用的合适密钥(诸如用于DNS数据的KSK和ZSK中至少一个)的别名标识符传递给数字签名模块，而不传递至少一个KSK和ZSK给数字签名模块。
在实施例中，签名服务器可以配置为定期检查激活密钥(例如激活的KSK或ZSK)的数据库，并基于从数据库接收的信息确定对于给定时间哪个别名标识符是激活的。在实施例中，传递到数字签名模块的别名标识符可以是激活的别名标识符。
在实施例中，签名服务器可以配置为基于至少一个激活KSK和/或激活ZSK识别特定HSM来发送第一数据。
在实施例中，签名服务器可以配置为处理关于不同TLD下的域的请求。
在实施例中，签名服务器可以配置为处理关于由多个注册商管理的至少两个域的请求。
在实施例中，客户端和签名服务器之间的通信可以，例如，通过双向SSL实现。
如此处所讨论的，示例的签名服务器可以支持由众多的不同系统实施的各种DNS操作签名操作，包括，例如，DNSSEC签名功能、其他受控DNS服务、远程签名、根区域签名等等。在实施例中，示例的签名服务器可以配置为支持例如作为单个事务(即工作的极小的、一致的、孤立的和持久的单元)的部分的受影响的DNSSEC记录的签名，所述单个事务各个方面在此处可以称为“内嵌签名”。
本发明的附加特征，优点和实施例根据以下详细的说明，附图和权利要求的考虑已经阐述或显而易见。此外，将要理解本发明的前述概要和以下详细的说明是示例性的并且打算提供进一步解释而没有限制所要求保护的本发明的范围。然而详细说明和具体示例仅指示本发明的优先实施例。在本发明的精神和范围内的各种变更和改变从该详细的说明将对本领域技术人员来说是显而易见的。
附图说明
被包括用以提供本发明进一步理解的附图，被合并进来并且构成本说明书的一部分，其示出了本发明实施例，并且与详细描述一起用于解释本发明的原理。不尝试比可能对本发明的基本理解必要的细节更详细地示出本发明的结构细节以及其可能被实施的不同方式。在图中：
图1描述了根据本发明的方面的一个示例的DNSSEC使能的签名系统的细节。
图2描述了根据本发明的方面的DNSSEC使能的签名系统的进一步的细节。
图3描述了根据本发明的方面的一个示例的签名请求协议。
图4描述了根据本发明的方面的一个示例的签名请求数据协议。
图5描述了根据本发明的方面的另一个示例的签名请求数据协议。
图6描述了根据本发明的方面的一个示例的签名响应协议。
图7描述了根据本发明的方面的一个示例的签名响应数据协议。
图8描述了根据本发明的方面的另一个示例的签名响应数据协议。
图9描述了根据本发明的方面的示例的请求、请求数据、响应和响应数据的关系。
图10描述了根据本发明的方面，一个包括签名服务客户端池管理器的示例的DNSSEC使能的签名系统的进一步的细节。
图11描述了根据本发明的方面可以被支持的用于DNSSEC签名的一个示例的内嵌签名技术的示意性系统布置。
图12描述了可以在本发明的实施例中使用的一个示例的计算机网络结构。
具体实施方式
可以理解的是本发明并不限于在此描述的特殊方法、协议等，这些可改变，正如本领域技术人员将认识到的那样。还需要理解的是在此使用的术语仅用于描述特殊实施例的目的，但不打算限制本发明的范围。还需要注意如在此和在附加权利要求中使用，单数形式“一”、“一个”和“该”也包括复数引用，除非上下文明确做出其他指示。因此，例如提到“服务器”是指一个或多个服务器以及本领域技术人员所知的等价物。
除非定义为其他，在此使用的所有技术术语具有与本发明所属技术领域普通技术人员所普遍理解的相同含义。参考在附图中描述和/或阐明以及在以下描述中详述的非限制实施例和示例而更充分地解释本发明的实施例及其各个特征和优点。应当注意的是图中阐明的特征不必依比例画出，并且如本领域技术人员会意识到的一个实施例的特征可由其他实施例所使用，即使在此没有明确地陈述。公知的部件和处理技术的描述可以被省略使得不会不必要地模糊本发明的实施例。在此使用的示例仅打算促进理解可实施本发明的方式，并且进一步使本领域技术人员能够实施本发明的实施例。从而，在此的示例和实施例不应当解释为限制本发明的范围，其仅由所附权利要求和适用的法律定义。此外，注意在附图的各视图中类似的附图标记涉及相似的部分。
如在此使用的，除非其他限制，注册商可被理解为与域名注册局互动并允许注册者建立和更新域名资源的任何实体或组织。
如在此使用的，除非其他限制，注册者可理解为与注册商互动以建立和更新域名资源的任何个人或组织。
如在此使用的，除非其他限制，DNS主机提供商可理解为代表注册者在其服务器上寄存(host)内容的任何实体或组织，为该内容提供DNS供应(provisioning)和解析能力(例如，分配IP地址并操作能够将域名解析到其管理的那些IP地址的名称服务器)。
本发明的实施例可以提供网络可访问的DNSSEC签名技术以允许大型DNSSEC提供商，诸如注册局，以有效和一致的方式处理来自各个源的大量DNS改变(包括DNSSEC签名数据)。
区域签名概述
如上所述，DNSSEC被设计用来解决缓存中毒及一组其他DNS脆弱性，例如中间人攻击和在权威服务器上的未授权数据变更。其主要目的是提供来源鉴别和DNS数据完整性保护。公钥基础结构(PKI)可被用作公钥分发的方式。DNSSEC提供了DNS数据的核实机制但不是加密机制。它允许可感知安全性的解析器来核实接收到的区域数据由持有私钥的区域管理者签名。
DNSKEY资源记录
区域可以具有一个或多个密钥对，每一对包含私钥和公钥。私钥可安全地保存在域名数据库中并用于区域数据签名。公钥可以存储在数据库中也可以作为DNSKEY资源记录存储在已签名的区域数据中。公钥用于核实区域数据。DNSKEY记录典型地含有下述数据元素：
标志：“区域密钥”和“安全入口点”
协议：固定值为3(用于向后兼容)
算法：公钥的密码算法
公钥：公钥数据
DNSKEY资源记录(“RR”)可以为区域签名密钥(ZSK)或密钥签名密钥(KSK)。密钥签名密钥(KSK)将具有SEP标志集，以使它们能与DNSKEY RR集中的ZSK区分开。密钥签名密钥(KSK)用于对其他DNSKEY资源记录签名，也用于对需要验证的数据建立权限(authority)链。
RRSIG资源记录
RRSIG资源记录拥有资源记录集RR集(具有相同名称、类别和类型的一个或多个DNS记录)的DNSSEC签名。DNSSEC使解析器能够利用存储在DNSKEY记录中的公钥来核实签名。RRSIG记录含有下述数据元素：
覆盖类型：该签名所覆盖的DNS记录类型。
算法：用于创建签名的密码算法。
标签：原始RRSIG记录名称中的多个标签(用于验证通配符)。
初始TTL：覆盖的记录集的TTL值。
签名到期：签名何时到期。
签名起始：签名何时创建。
密钥标记：有助于快速识别可用于验证该签名的DNSKEY记录的短数值。
签名器名称：可用于验证该签名的DNSKEY记录的名称。
签名：密码签名。
DNSKEYRR由激活的KSK和ZSK签名。其他RR集仅由激活的ZSK签名。
NSEC资源记录
NSEC资源记录列出了两个独立的事物：包含权威数据或委托点(delegationpoint)NS RR集的下一个持有者名称(以区域的规范顺序)，和出现在NSEC RR持有者名称中的RR类型集(RFC3845)。区域内的NSEC RR的完整集指出哪些权威RR集存在于区域中并还形成区域中权威持有者名称的链。这些记录作为DNSSEC验证的一部分可由解析器用于核实记录名称和类型的不存在性。
NSEC记录具有下述数据元素：
下一个域名：区域中下一个记录的名称(DNSSEC排序顺序)。
记录类型：为NSEC记录的名称而存在的DNS记录类型。
NSEC3资源记录
NESC3资源记录(RR)为DNS资源记录集提供经鉴别的否定存在。NSEC3RR具有与NSEC RR相同的功能，除了NSEC3使用加密的散列记录名称以防止区域中记录名称的枚举之外。NSEC3记录链接到区域中的下一个记录名称(以散列名称排序的顺序)并列出为了NSEC3记录持有名称的第一标签内由散列值所覆盖的名称而存在的记录类型。这些记录可作为DNSSEC验证的一部分而由解析器用于核实记录名称和类型的不存在性。NSEC3记录含有下述数据元素：
散列算法：所用的密码散列算法。
标志：“Opt-out”(指出委托是否被签名)。
迭代：散列算法被应用了多少次。
加盐(salt)：用于散列计算的加盐值。
下一散列持有者名称：区域中下一个记录的名称(以散列名称排序的顺序)。
记录类型：为了NSEC3记录持有名称的第一标签内由散列值覆盖的名称而存在的记录类型。
图1中示出了一个示例性签名服务器布置的方面。如图1所示，注册局或其他DNSSEC服务提供商可以包括任何数量的签名服务器142、146。例如，多个签名服务器可以包括注册局供应系统。签名服务器142、146可以分别包括硬件支持模块(HSM)144、148和/或软件，其可以具有包括合适的数字签名密钥的实际数字签名功能。签名服务器142、146可以与各种应用、服务和工具110、120和130通信，以及例如交换已签名和未签名的DNS数据。每个CAS110、NCC插件商业服务120和批量/工具130组件将具有与签名服务器(优选地这样的服务器集)的连通性(connectivity)。签名服务器142、146可以将已签名的DNS数据保存到数据库150。在应用、签名服务器、HSM和数据库之间的示例数据流的附加细节在图2中示出。
如图2所示，客户端210可以代表，例如供应系统的前端服务，其可以被配置为识别需要由签名服务器212签名的DNSSEC数据。将被签名的数据可以是，例如，受DNS改变(例如域的增加、更新、删除命令)影响的区域数据的一部分。DNSSEC或者其他将被签名的数据可以基于例如域命令而被分析(parse)或以其他方式识别，并提供给签名服务器212，如链路241所示。客户端210和签名服务器212之间的通信可以例如通过双向SSL隧道。诸如字节、密钥类型(ZSK，KSK)和TLD等的信息可以包含在请求中。签名服务器212可以识别来自传输241的合适的密钥信息和/或HSM，并将未签名的数据传递给合适的HSM214，由链路242示出。这可以包括具有，例如字节、密钥别名和签名算法的签名命令。
在实施例中，签名服务器212还可以接收对其他数据进行签名的请求，作为相同签名请求的一部分。签名服务器212可以为其他数据确定合适的密钥信息。在实施例中，如此处进一步描述的，其他数据的密钥信息可以与包含在相同签名请求中的第一数据的密钥信息不同。
从客户端210向签名服务器212的请求241可以根据签名服务器协议(SSP)进行格式设置。在实施例中，示例的协议可以包括“车箱”(boxcar)格式，其中多个签名请求可以被打包成单个的协议请求，从而优化降低性能的网络往返和带宽利用。另外，SSP可以包括每个服务模块遵循的内建诊断特征，允许客户端确定服务的可用状态和近来的问题。在实施例中，此处描述的协议可以允许，特别是加入到签名服务器的新服务模块所需要的新数据传送分组构成的即时可插性(pluggability)，而不改变传送协议本身。图3示出了一个示例的SSP，在下文中进一步进行描述。
如图3所示，来自客户端的签名服务器请求协议300可以包括如下字段：
分组长度：：＝int(分组的总长度)
协议版本：：＝字节(协议的版本)
服务类型：：＝字节(例如，简单(对于通用签名)；DNSSEC(对于DNSSEC签名)；公钥取回(给定密钥别名，返回公钥))。
事务Id：：＝长(识别请求的唯一id)
标志：：＝int(标志中允许请求传递的字段，(服务-不可知(agnostic)))。
会话Id：：＝长(发送请求的会话Id，可用于审核的目的)。
账户Id：：＝长(发送请求的账户Id，可用于审核的目的)。
记录数目：：＝字节(请求数据的数目(即，包含在整个请求(服务需要对其采取行动)中的分组的数目))
签名请求数据1...n--数据的(一个或多个)分组(服务需要对其采取行动)；通常其包括将要签名的数据。
客户端210可以发送签名请求数据作为其请求300内的有效载荷。在实施例中，签名服务器212可以配置为对不同的服务请求进行识别和采取行动，并基于，例如相关的编解码器对数据有效载荷进行译码。在实施例中，数据可以以各种形式构造，其可以称为“签名请求数据协议”，包括，例如，下文进一步讨论的SimpleSigningRequestData、RRSigSigningRequestData或PublicKeyRetrievalRequestData。
图4示出了简单签名请求签名请求数据协议(Simple Signing Request SigningRequest Data Protocol)的举例。如图4所示，简单签名请求(Simple Signing Request)310可以包括：
长度：：＝int(数据的长度)
算法：：＝串(签名算法)
密钥别名：：＝串(需要用于签名的密钥别名)
请求数据长度：：＝int(请求数据字段的长度)
请求数据：：＝字节(需要被签名服务器签名的数据)
如上面提到的，客户端210、签名服务器212和HSM214可以使用密钥别名来识别特定的密钥。从而，各个组件不需要交换真实密钥，这在基本上不可访问状态下(例如，不能通过网络访问)维持密钥材料安全性方面具有优势，尤其是特定组件(例如HSM214中)维持的密钥。
如图5所示，RRSigSigningRequestData，可以用于以与SimpleSigningRequest类似的方式实现签名请求数据。该RRSigSigningRequestData可以是例如由客户端填充的数据豆(data bean)，保存关于需要被签名的RRSIG记录的信息。如下文进一步讨论的，每一类别的请求可以由签名服务器212返回，作为相应的响应244。应当指出，当签名服务器212接收请求241时，可以用其自身的DNSSEC相关数据或其他数据扩充(augment)该请求数据。
RRSigSigningRequestData320可以包括：
长度：：＝int(数据长度)
RRSIG ID：：＝长度(RRSigSigningRequestData的唯一ID)
域名：：＝串(域的名称)
域Id：：＝长度(域的id)
父域：：＝串(父域)
覆盖类型：：＝int(资源记录类型)
标签数目：：＝int(域名中标签的数目)
初始TTL：：＝长(需要由签名服务器签名的数据)
TTL：：＝长(需要由签名服务器签名的数据)
RR开始时间：：＝长(RRSIG开始时间的纪元时间(epoch time))
RR集字节长度：：＝int(RR集字节的长度)
RR集字节：：＝字节(需要由签名服务器签名的数据)
相应地，考虑到图3中所示的签名服务器请求协议300、图4中所示的SimpleSigningRequestData 310和图5中所示的RRSigSigningRequestData 320的组合，适当配置的签名服务器可以接受具有多个签名请求数据的单个签名请求(例如，通过签名服务器请求协议300)，每个签名请求数据具有潜在的不同签名算法、密钥别名等。如此处进一步讨论的，在RRSigning数据的情况下，合适的算法和/或密钥可以基于例如识别的域和/或与请求相关的TLD。在实施例中，签名服务器可以配置为通过对此处描述的请求和数据分组进行分析来处理关于不同TLD下域的请求，和/或处理关于由多个注册商管理的至少两个域的请求。
签名请求数据协议还可以包括PublicKeyRequestData(未示出)，包括下列字段：
长度：：＝int(数据的长度)
密钥别名：：＝串(用于取回公钥的密钥别名)
签名服务器212可以配置为定期核对用于权威数据的数据库220，以检查在向HSM214发送数据时使用的密钥别名。签名服务器212还可以配置为基于激活的KSK和/或激活的ZSK识别发送数据分组的特定HSM。HSM214可以在初始化时在每个TLD加载多个密钥(有些可以是ZSK，有些可以是KSK)，HSM214可以通过别名、密钥别名知道每个密钥。客户端210可以配置为告知签名服务器212使用了两种密钥中的哪一种(ZSK还是KSK)以及TLD，而签名服务器212可以配置为当与HSM因为签名而进行通信时识别那种密钥的当前密钥别名名称。签名服务器212还可以被强制重新核对数据库220以检查当前的密钥别名。这个命令可以通过JMX管理接口发给例如签名服务器212。相应地，签名服务器212可以理解为“DNSSEC感知”(DNSSEC-aware)。
使签名服务器DNSSEC感知的一个好处是节省了客户将不得不以其他方式传递的数据与几乎每个签名请求进行编组和解组(即使那些数据没有改变)。也就是，客户端210不需要知道没有频繁改变的数据，客户端210也不用与每个请求241一起发送没有频繁改变的数据。更确切地，签名服务器212本身可以知道并缓存那些数据。
签名服务器212还可以配置为也提供通用签名能力。实例包括配置签名服务器用于与可控DNS服务一起使用，该签名服务器具有大量的密钥和区域(成千上万)以生成用于可控DNS服务、根区域签名等的各种签名。在实施例中，客户端可以配置为和动态加载能力一起提供签名参数并上传用于签名的密钥。能够执行多种类型的签名事务的“通用签名”签名服务器可以提供灵活的应用以用于与例如大规模多功能的可控DNS服务一起使用。从而，签名服务器212DNSSEC感知，并能够例如通过运行时间可配置的插件(服务)为了其他签名目的而工作，服务器依赖该插件处理进入请求。根据本发明的方面，签名服务器框架，如图2所示，可以允许各方编写包括不同的参数和密钥的服务模块，其可以与各种品牌的硬件或软件签名器应用进行通信。可以在协议中加入额外的功能以支持新的特征而不妨碍现有的客户端。签名服务器和签名服务器协议的配置可以允许，例如，DNSSEC应用包括其他不同定义的终端用户接口(例如，网页服务、EPP、REST)而不影响基本签名。
实施例可以包括具有服务模块的签名服务器代码库，该服务模块提供签名配置参数的缓存和不缓存组合。服务模块从而可以根据其需要重新使用这些缓存和不缓存特征。缓存可以用于提高具有相对稳定的密钥和签名配置的服务模块的性能，而不缓存可以方便密钥和签名参数的按需加载，用于需要大量仅在签名时激活的离线存储的密钥和参数的情况。此外，当个别服务模块故障或变得不可用(不同协议和密钥时可能会发生)，签名服务器本身可以保持稳健并允许其他模块继续服务请求。这种灵活性可以提供例如目前独立DNSSEC签名应用无法完成的大量选项。
不缓存方式(例如所有适用的密钥都不在HSM或其他签名模块中缓存)的一个特定优点是数字化包装的密钥可以存储在更便宜和更高可用性的存储库中，例如易于跨数据中心复制的数据库等。然后HSM或其他签名模块可以按需取回密钥来签名数据。这种真实密钥的单独存储、按需加载已经被发明人发现，使得整个签名服务(例如此处描述的)能够缩放(scale)更大量的密钥而不会牺牲HSM的性能能力或者使用的数据库的可用性。这已经被发现在极大规模的DNS服务的上下文中尤其有用，例如该极大规模的DNS服务可以由注册局提供，其可能需要为成千上万的区域访问密钥。
在实施例中，HSM或其他签名模块，可以用HSM或其他签名模块的私钥对存储在数据库中的有关密钥进行加密。如此处进一步描述的，每一个密钥是可以由密钥别名识别的，并在取回时可以由HSM或其他签名模块使用私钥进行解密。
返回图2，HSM214可以对，例如在请求242中接收的DNSSEC数据以合适的密钥进行签名，并将签名的数据回传给签名服务器212，如链路243所示。在实施例中，这种签名可以基于，例如，根据包含在请求中的密钥别名等识别适当的密钥和/或协议。或者，HSM或者其他软件签名应用可以具有预先确定的密钥和/或参数以应用于指向它们的签名请求。应当指出，根据本发明的包括分开识别包含在签名请求中的数据分组的方面，分组可以异步处理，从而客户端能够持续处理而不会由于签名响应而发生阻塞。进一步地，单个签名服务器可以接收并作用于请求以同时跨应用和跨区域签名数据。即，单个服务器可以在单个请求分组中接收命令以签名彼此不相关、跨区域和/或应用的数据。
另外，签名服务器212可以配置成为单个数据分组请求并提供多个签名。例如，签名服务器212可以识别不止一个要应用到特定数据的激活的密钥和/或算法，并可以基于该不止一个激活的密钥和/或算法从HSM或其他签名模块请求多个签名。在实施例中，签名服务器212可以配置为请求并报告，例如通过第一算法使用第一密钥对第一数据的签名和通过第二算法使用第二密钥对第一数据的签名。例如，根据用户要求，在密钥翻转(rollover)的上下文和/或为了DNSSEC有效实现算法运作(roll)(例如，SHA-1到SHA-2)，可以应用多个激活的密钥和签名。
HSM 214可以在物理上与签名服务器212的处理器分开，并且可以包括，例如，额外的安全协议以保护存储在HSM 214中的密钥。例如，HSM 214可以配置为仅通过物理加载过程交换特定密钥信息以保护存储在其中的密钥，尤其是那些使用寿命长或具有广泛应用性的密钥，如KSK。在实施例中，HSM可以包括一个或多个密钥和一个或多个识别存储在其中的密钥的别名标识符。
签名服务器212可以将签名的数据，例如DNSSEC或其他数字签名的数据，或者其他数据，诸如事务提交信息，返回给客户端210，如链路244所示。
如上指出，每一类别的请求可以由签名服务器212返回，做为相应的响应244。由签名服务器212返回的响应244可以配置为遵循如图6所示的签名服务器响应协议。
如图6中所示，签名服务器响应协议400可以包括，例如：
分组长度：：＝int(分组的总长度)
协议版本：：＝字节(与在请求中发送的相同)
服务类型：：＝字节(与在请求中发送的相同)
事务Id：：＝长(与在请求中发送的相同)
标志：：＝int(标志中允许传递请求的字段(服务-不可知(agnostic)))
响应代码：：＝字节(处理请求后的响应代码。见下文用于可由签名服务器返回的响应代码。)
响应消息长度：：＝int(用于由服务器返回的响应的详细响应消息的长度。)
响应消息字符：：＝char(响应消息字符)。
记录数目：：＝字节(响应数据的数目(例如包含在服务需要在其上起作用的总请求中的分组的数量)。)
签名响应数据1...n。
表1中示出了示例的签名响应代码：
表1
响应代码 响应描述
0 成功
1 请求失败
2 由于数据库故障，请求失败
3 由于签名引擎故障，请求失败
4 由于不支持的服务请求，请求失败
5 没有找到密钥别名的公钥
签名响应数据可以包括，例如对应于请求SimpleSigningRequestData、RRSigSigningRequestData或者PublicKeyRetrievalRequestData的SimpleSigningResponseData、RRSigSigningResponseData或者PublicKeyRetrievalResponseData。在实施例中，对于在请求中发送的每个请求-数据分组可以有一个响应数据对象。
图7中示出了一个示例的SimpleSigningResponseData410，例如，其由签名服务器212返回，作为对诸如图4中所示的SimpleSigningRequest的响应。如图7所示，SimpleSigningResponseData410的字段可以包括：
长度：：＝int(数据的长度)
签名的数据长度：：＝int(签名的数据字段长度)
签名的数据：：＝字节(需要由签名服务器签名的数据)
图8示出了RRSigSigningResponseData420的一个实例，其可用于由诸如图5所示的RRSIG相关的请求产生的每个响应-数据分组。RRSigSigningResponseData420的字段可以包括：
长度：：＝int(数据的长度)
RRSIG ID：：＝长(RRSigSigningRequestData的唯一ID)
域名：：＝串(域的名称)
域Id：：＝长(域的id)
父域：：＝串(父域)
覆盖类型：：＝int(资源记录类型)
标签数目：：＝int(域名中标签的数目)
初始TTL：：＝长(需要由签名服务器签名的数据)
TTL：：＝长(需要由签名服务器签名的数据)
RR开始时间：：＝长(RRSIG开始时间的纪元时间)
密钥标记：：＝int(用于对该请求进行签名的密钥的密钥标记)
算法Id：：＝int(用于对该请求签名的算法Id)
签名：：＝串(由签名该请求产生的基本64编码签名)
RR结束时间：：＝长(RRSIG结束时间的纪元时间)
签名响应数据还可以包括PublicKeyResponseData(未示出)，其包含如下字段：
长度：：＝int(数据的长度)
密钥别名：：＝串(在请求中发送的密钥别名)
公钥：：＝串(使用密钥别名取回的密钥的基本64编码公钥)
一旦签名的数据返回到客户端210，客户端可以根据需要分发签名的数据，例如到DNS或者其他服务，和/或根据需要发送确认消息。在实施例中，客户端210可以配置为DNSSEC应用，其可以识别并作用于DNS改变等，以及确定需要执行的合适的DNSSEC功能。从而，签名服务器212可以减少许多DNSSEC专用的应用编程和功能。DNSSEC应用，例如客户端210，可以专注于DNSSEC商业逻辑(什么资源记录需要被签名等)而不必关心签名参数的细节，也不会产生集合并传递额外的信息到签名服务器212所导致的处理和网络成本。同样，如上所述，各种请求和响应协议使DNSSEC应用能够将所有相对较小的签名请求(完全没有各种DNSSEC签名参数和密钥信息)组合为单个分组，从而极大减小了网络复杂和开销。最终，客户端210还可以减少任何HSM接口细节。
图9以图示地描述了在客户端和服务器间共享的上述讨论的示例性的请求和响应协议的关系。应当指出，上述的协议和具体内容在本质上仅是举例，不将本发明的范围限制到这种具体的协议。例如，可以实现利用智能签名服务器能力的其他协议，例如，密钥清单加载到签名服务器中，客户端仅需要传递要签名的数据和用于签名服务器自动选择正确的密钥的合适标识符。
根据本发明的另一个方面，如此处所述，可以管理客户端和签名服务器的集群以提高签名系统的负载平衡和响应能力。例如，如图10所示，在实施例中，对于每个签名服务器801-801n，可以有一个SigningServerClient 810的实例来处理对于特定签名服务器的请求。在SigningServerClient 810之上还可以有SigningServiceClientPool 820，其管理SigningServerClient实例。SigningServiceClientPool 820可以连接到任意数量的SigningServerClient，并且可以配置为，例如，以例如循环(round robin)的方式向各种签名服务器加载平衡请求，如果其连接到的签名服务器不工作将SigningServerClient实例移出轮换等。
每个SigningServerClient 810可以配置为维护与签名服务器的套接(socketconnection)池812，如果该服务掉线通知SigningServiceClientPool 820并启动健康检查线程，和/或在签名服务器恢复运作后不断尝试连接签名服务器并通知SigningServiceClientPool 820将该服务放回轮换中。
相应地，整个系统可以适应客户端侧和服务器侧的故障。例如，客户端侧服务维护签名服务器的列表并对已识别的来自那些服务器的“致命”异常/错误响应做出反应。客户端侧可以将那些出现故障的签名服务器从循环轮换中移出，并可以在服务器恢复在线时不断尝试识别。签名服务器可以配置为支持“ping”使得客户端可以检查其健康。
如果客户端侧的签名服务发现其所有的签名服务器都不工作，它可以在接收到对某些东西签名的请求时立即返回异常。客户端可以持续这样做直到至少一个签名服务器变得可用。
来自签名服务器侧的故障情况可以包括一个其附属物(如HSM或密钥数据库)不可用。如果HSM不可用，签名服务器可以报告指示这个的错误响应。签名服务器可以在这种情况下通过，例如，JMX和日志条目进行警示。签名服务器也可以不断尝试检查HSM是否恢复在线。如果密钥数据库对于密钥数据的刷新变得不可用，签名服务器可以配置为拒绝签名数据的请求(例如，因为它承担使用错误密钥签名的风险)。签名服务器可以配置为报告这个错误作为签名响应，并可以不断尝试连接回密钥数据库。
另一个选项是将签名服务器配置为在服务不能正常工作时将客户端连接“掉线”(drop)和/或停止对特定服务的新连接的监听。这种配置，例如，可以有利于使客户端仅将服务请求指引到目前可操作来实现服务的签名服务器，提高了签名服务网络的状态监测，减少了回报给客户端的错误数量，并且提高了客户端的整体效率。这种配置还可以在问题得以解决之前使签名服务器继续其他可操作服务，而对于不工作的服务没有遭遇和/或报告错误的负担。类似的配置可以应用于签名服务器和多个辅助HSM或其他签名模块之间。
根据图1、2和10中描述的布置和上面详细描述的请求和响应协议的方面，客户端(例如客户端210)可以采用技术和客户端实用工具库来提供负载平衡和高的可用特征。例如，无论其正在使用服务器内部的哪个服务模块，客户端实用工具库都可以与签名服务器进行交互。客户端实用工具库可以提供自动重连和快速-失效(fast-fail)(服务不可用的时间)作为其特征集的一部分。客户端实用工具库的负载平衡特征还可以有助于确保在任何时候，无论多少签名服务器可用和不可用，无论多少客户端连接到这些服务器，负载都将自动地相对均匀地分布在激活服务器之间。
在实施例中，用于签名服务器的服务模块外挂(plug)可以包括用于一个或多个TLD(诸如.com，.net，.net，.edu等)的模块。在实施例中，知到用于不同TLD的各种密钥清单和/或协议的单个服务模块可以支持多个TLD。服务模块可以配置为提供，例如，给定签名所应用的以及负责密钥翻转的TLD，根据需要将使用哪个ZSK产生数字签名；哪个硬件或软件签名器应当为该TLD产生签名；当产生签名时使用哪种TLD专用参数，包括加盐、散列算法、签名算法、签名持续时间等。在实施例中，签名服务器可以配置为自动定期地从数据库重新加载这些设置，从而可以在正常操作过程中拾取(pick up)改变，而不必重新启动。
这种方式的一个特别优势是可以提供一种集中式的权威配置，保证每个TLD的一致的签名生成。而且，这意味着用于TLD的注册局应用本身可以不必直接知道这些策略，而是请求签名服务器对数据签名并依赖签名服务器在签名时在每个TLD基础上应用所需的策略和参数。这种方法可以降低注册局作为整体当在正常操作过程中那些数据改变时对于签名配置数据过期的风险，因为，例如，签名服务器比注册局应用实例少得多。而且，到签名服务器的客户端不需要具有额外的与加载TLD专用签名参数相关的配置和应用逻辑(其会增加应用的复杂性并提高误配置的风险，导致数字签名失败)。最后，客户端不必与每个请求一起传送TLD专用签名参数给签名服务器，这意味着降低了网络负载，提高了吞吐量。
更一般来说，根据本发明的方面，签名服务器可以配置为考虑到开发者插入“智能”服务，其中服务基于签名请求的上下文保存关于哪个密钥被激活、将使用哪种算法等等的知识，上下文本身不包括该信息。这尤其是在那些客户端意欲保持尽可能“沉默”(dumb)的上下文中是优选的。这可以用于，例如，实现更小的分组，减少客户端操作过期信息或与密钥状态不同步的可能，并提供了更小的容量和较不脆弱的客户端代码。
如前面提到的，此处所述的签名服务器方法和装置可以发现适用性并兼容于庞大的DNS阵列和其他签名、服务。例如，通过提供网络可访问、可配置的签名服务器，可以容易地支持各种远程签名协议和配置。可以支持的一个这种非限制性示例包括“在线签名”布置，其可用于此处描述的DNSSEC签名功能，细节在图11中示出。如图11所示，请求者1000，诸如例如注册者、注册商或DNS提供商，可以与注册局供应系统1100通信。请求者1000可发送有关已存在或新的域的命令。例如，请求者1000可发送命令以改变注册局管理的DNS数据，例如在注册局管理的TLD(如.com)下的域的DNS数据。注册局供应系统1100可以以各种方式处理来自请求者1000的域命令，包括，例如执行改变命令，如添加，变更，或删除命令，识别DNSSEC数据改变，识别合适的密钥，应用数字签名，将DNS和DNSSEC改变保存在注册局数据库1200等。
由注册局供应系统1100向注册局数据库1200提供的数据可以包含域的DNS信息和已签名DNSSEC数据。在实施例中，示例的签名服务器可以支持，例如，在单个事务中实现DNS改变和DNSSEC改变的方法。
如上所述，DNSSEC签名可以由签名服务器实现，同步地内嵌(inline)有事务。单独的服务可以用于取得注册局数据库中的每个已提交事务并将其逐步应用到DNS服务器。
内嵌有域注册局的域命令的DNSSEC签名可以通过确保例如注册局数据库总是表示在DNS中发布的内容的权威源，在维护最高级的数据完整性方面提供优势。
作为实现DNSSEC内嵌签名的一部分，网络可用和高性能签名服务器集群，例如，图1和2中所示的，可以提供来签名DNSSEC信息。已经发现其即使在最大的TLD的上下文中也有效，并且即使在服务来自需要数字签名的客户端的1000+同时连接时，也会以高级数据完整性维护DNS传播SLA’s，并维护域注册局响应时间SLA’s。
本发明的实施例可包括执行所述方法的系统，以及编码有促使计算机执行所述方法的指令的计算机可读存储介质。例如，如图12所示，像服务器600，610和/或620这样的服务器系统包括至少一个处理器、存储器和电子通信设备(未示出)，其可配置为对例如在此描述的那些通过例如因特网的网络605接收的请求进行接收、识别、响应和/或行动。服务器600，610和/或620中任一个可例如由在此进一步描述的因特网主机提供商、注册商和/或注册局来操作，并且可以与一般由网络设备630代表的任何数量的递归DNS服务器通信。如在此描述的那样，递归服务器630可为主机提供商、注册商和/或注册局操作服务器600，610和620的域缓存DNS相关数据。
请求更新域的DNS数据可通过各种系统(诸如例如计算机611，612)，通过可与(一个或多个)移动设备614、微微小区网络设备615、移动计算机616或任何具有必备功能能力的其他具有网络能力设备进行无线或其他通信的分离的服务器613，例如从注册商、DNS服务提供商或注册者来发起。
在此描述的各种通信、传输和相关功能可例如通过网络605完成，并且诸如服务器600，610和620这样的服务器系统执行的所述处理的结果可以根据已知技术而被显示，存储和/或分配。网络605可包括任何数量的通信组件，包括无线，蜂窝，卫星，光和/或其他类似通信链路。
服务器600，610和620以及计算机611，612可包括任何数量的处理器(未示出)，其耦合到存储设备，包括第一存储器(未示出，典型地是随机存取存储器，或“RAM”)、第二存储器(未示出，典型地是只读存储器，或“ROM”)。这两种存储设备可包括任何合适类型的计算机可读介质，包括非暂时存储介质，诸如闪存驱动，硬盘，软盘，磁带，例如CD-ROM盘的光介质，和/或磁光介质。还可使用海量存储设备(未示出)以存储程序、数据等等，并且典型地是次级存储介质，例如比主存更慢的硬盘。将会意识到在海量存储设备中保留的信息可以在合适的情况下以标准方法合并作为主存的一部分作为虚拟存储器。特定的海量存储设备，诸如CD-ROM，还可单方向地向处理器传递数据。
服务器600，610和620和计算机611，612还可包括接口，其包括一个或多个输入/输出设备，诸如视频监视器，轨迹球，鼠标，键盘，麦克风，触敏显示器，传感器读卡器，磁带或纸带阅读器，写字板，指示笔，声音或手写识别器，或其他已知输入设备，包括其他计算机。服务器600，610和620以及计算机611，612可耦合到计算机或其他使用网络连接的电子通信网络605。网络605可连接各种有线，光，电和其他已知网络以在服务器600，610和620，计算机611，612，独立服务器613，(一个或多个)移动设备614，微微小区网络设备615，(一个或多个)移动计算机616，递归服务器630和任何其他具有类似功能的设备之间交换信息。具有这样的网络连接，可以考虑到服务器600，610和620，和计算机611，612，和其中的处理器可在执行以上描述的方法步骤期间从网络605接收信息，或可向网络605输出信息。以上描述的设备和物质对计算机硬件和软件领域的技术人员所熟知，并且不需要单独或详尽地描述以被本领域技术人员所理解。以上描述硬件元素可以(通常临时)配置为作为执行以上描述操作的一个或多个模块。
此外，本发明的实施例进一步包括计算机可读存储介质，其包括用于执行此处描述的各种计算机可执行操作的程序指令。该介质还可单独地或组合地包括程序指令，数据文件，数据结构，表等等。介质和程序指令可以是那些专门为了本发明的目的设计和构造的，或者它们可以是计算机软件领域技术人员可获得的类型。计算机可读存储介质的示例包括磁介质，诸如闪存驱动，硬盘，软盘，磁带；光介质，诸如CD-ROM盘；磁光介质；和专门配置为存储和执行程序指令的硬件设备，诸如只读存储器设备(ROM)和随机存取存储器(RAM)。程序指令的示例包括机器代码(诸如由编译器创建)以及包括高级代码的文件(其可由计算机使用解释器来执行)。
以上给出的说明书仅是说明性的，并且不意味着是本发明所有可能的实施例，应用或修改的详尽列表。因此，本发明所述的方法和系统的不同修改和改变将对本领域技术人员是显而易见的，没有背离本发明的范围和精神。虽然本发明已经结合具体实施例加以描述，但应当理解所要求保护的本发明不应当过度地限制为这样的具体实施例。

Claims (32)

1.一种DNSSEC签名服务器，配置为与至少一个单独的DNSSEC客户端应用和多个数字签名模块进行交互，该DNSSEC签名服务器包括：
处理器；和
包括计算机可读代码的存储装置，所述计算机可读代码当由处理器执行时使签名服务器作为权威服务器以：
从所述至少一个单独的客户端应用接收签名请求以数字签名包括在所述签名请求中的第一数据；
为所述第一数据确定激活的KSK和激活的ZSK中的至少一个；
将所述第一数据发送到所述多个数字签名模块中的一个以便被数字签名；
从数字签名模块接收所述第一数据的经数字签名的版本；以及
将经签名的第一数据提供给所述单独的客户端应用。
2.根据权利要求1所述的服务器，其中所述签名服务器进一步配置为：
接收作为相同签名请求的部分的请求来签名第二数据；
为所述第二数据确定激活的KSK和激活的ZSK中的至少一个，并且其不同于用于所述第一数据的所述激活的KSK和/或激活的ZSK中的至少一个；
将所述第二数据发送到所述多个数字签名模块中的一个；
从数字签名模块接收所述第二数据的经数字签名的版本；以及
将经签名的第二数据提供给所述单独的客户端应用。
3.根据权利要求1所述的服务器，其中所述第一数据包括DNS数据，以及所述数字签名模块配置为根据DNSSEC协议对DNS数据的特定部分进行签名，而不是对整个区域签名。
4.根据权利要求3所述的服务器，其中所述签名服务器进一步配置为提供额外的非DNSSEC数字签名功能。
5.根据权利要求1所述的服务器，其中所述签名服务器进一步配置为：
接收多个签名请求作为单个请求分组的部分；以及
分析所述请求分组以识别具有彼此不同的激活的KSK. 激活的ZSK和签名协议中的至少一个的不同签名请求。
6.根据权利要求1所述的服务器，其中所述激活的KSK和激活的ZSK中的至少一个基于包括在所述签名请求中的TLD标识符来被确定。
7.根据权利要求6所述的服务器，其中所述签名服务器进一步配置为基于包括在所述签名请求中的服务类型标识符从多个不同的数字签名功能中区分请求的签名功能，并基于所述服务类型标识符将非DNSSEC签名请求路由到非DNSSEC数字签名模块。
8.根据权利要求1所述的服务器，其中每个数字签名模块包括硬件安全模块（HSM），其在物理上与所述签名服务器的处理器分离，并配置为对由所述签名服务器提供的数据进行数字签名。
9.根据权利要求8所述的服务器，其中所述HSM包括多个根据别名标识符识别的多个密钥，以及所述签名服务器进一步配置为将用于DNS数据的KSK和ZSK中的至少一个的别名标识符传递到所述数字签名模块，而不传递所述KSK和ZSK中的至少一个到所述数字签名模块。
10.根据权利要求9所述的服务器，其中所述签名服务器进一步配置为定期检查激活的KSK或ZSK的数据库，以及基于从所述数据库接收的信息确定在给定时间内哪些别名标识符是激活的，以及其中传递到所述数字签名模块的别名标识符是激活的别名标识符。
11.根据权利要求9所述的服务器，其中所述服务器进一步配置为基于所述激活的KSK和/或激活的ZSK中的至少一个识别特定HSM以发送所述第一数据。
12.根据权利要求1所述的服务器，其中所述签名服务器进一步配置为处理关于在不同顶级域下的域的请求。
13.根据权利要求1所述的服务器，其中所述签名进一步配置为处理关于由多个注册商管理的至少两个域的请求。
14.根据权利要求1所述的服务器，其中所述客户端和所述签名服务器之间的通信通过双向SSL来执行。
15.根据权利要求1所述的服务器，其中所述签名进一步配置为：
为所述第一数据确定多于一个的激活的密钥和/或激活的算法；
将用于所述多于一个的激活的密钥和/或激活的算法的标识符发送到所述数字签名模块；
从所述数字签名模块接收所述第一数据的多个经数字签名的版本；以及
将第一数据的所述多个经数字签名的版本提供给所述单独的客户端应用。
16.根据权利要求1所述的服务器，其中所述数字签名模块，响应于接收所述第一数据，从数据库动态地加载用于所述第一数据的所述激活的KSK和激活的ZSK中的所述至少一个。
17.一种由DNSSEC签名服务器对DNS信息进行加密的方法，所述DNSSEC签名服务器配置为与至少一个单独的DNSSEC客户端应用和多个数字签名模块进行交互，所述方法包括：
从所述至少一个单独的客户端应用接收签名请求来数字签名包括在所述签名请求中的第一数据；
确定激活的KSK和激活的ZSK中的至少一个以数字签名所述第一数据；
将所述第一数据发送到所述多个数字签名模块中的一个以便被数字签名；
从所述数字签名模块接收所述第一数据的经数字签名的版本；以及
将经签名的第一数据提供给所述单独的客户端应用。
18.根据权利要求17所述的方法，进一步包括：
接收作为相同签名请求的部分的请求来签名第二数据；
为所述第二数据确定激活的KSK和激活的ZSK中的至少一个，并且其不同于用于所述第一数据的所述激活的KSK和/或激活的ZSK中的至少一个；
将所述第二数据发送到所述多个数字签名模块中的一个；
从数字签名模块接收所述第二数据的经数字签名的版本；以及
将经签名的第二数据提供给所述单独的客户端应用。
19.根据权利要求17所述的方法，其中所述第一数据包括DNS数据，以及所述数字签名模块配置为根据DNSSEC协议对DNS数据的特定部分进行签名，而不是对整个区域签名。
20.根据权利要求19所述的方法，其中所述签名服务器进一步配置为提供额外的非DNSSEC数字签名功能。
21.根据权利要求17所述的方法，其中接收多个签名请求作为单个请求分组的部分，所述方法进一步包括：
分析所述请求分组以识别具有彼此不同的激活的KSK、激活的ZSK和签名协议中的至少一个的不同签名请求。
22.根据权利要求17所述的方法，其中所述激活的KSK和激活的ZSK中的至少一个基于包括在所述签名请求中的TLD标识符来被确定。
23.根据权利要求22所述的方法，进一步包括基于包括在所述签名请求中的服务类型标识符从多个不同的数字签名功能中区分请求的签名功能，并基于所述服务类型标识符将非DNSSEC签名请求路由到非DNSSEC数字签名模块。
24.根据权利要求17所述的方法，其中每个数字签名模块包括硬件安全模块（HSM），其在物理上与所述签名服务器的处理器分离，并配置为对由所述签名服务器提供的数据进行数字签名。
25.根据权利要求24所述的方法，其中所述HSM包括多个根据别名标识符识别的多个密钥，所述方法进一步包括将用于DNS数据的KSK和ZSK中的至少一个的别名标识符传递到所述数字签名模块，而不传递所述KSK和ZSK中的至少一个到所述数字签名模块。
26.根据权利要求25所述的方法，进一步包括定期检查激活的KSK或ZSK的数据库，以及基于从所述数据库接收的信息确定在给定时间内哪些别名标识符是激活的，以及其中传递到所述数字签名模块的别名标识符是激活的别名标识符。
27.根据权利要求25所述的方法，进一步包括基于所述激活的KSK和/或激活的ZSK中的至少一个识别特定HSM以发送所述第一数据。
28.根据权利要求17所述的方法，进一步包括处理关于在不同顶级域下的域的请求。
29.根据权利要求17所述的方法，进一步包括处理关于由多个注册商管理的至少两个域的请求。
30.根据权利要求17所述的方法，其中所述客户端和所述签名服务器之间的通信通过双向SSL来执行。
31.根据权利要求17所述的方法，进一步包括：
为所述第一数据确定多于一个的激活的密钥和/或激活的算法；
将用于所述多于一个的激活的密钥和/或激活的算法的标识符发送到所述数字签名模块；
从所述数字签名模块接收所述第一数据的多个经数字签名的版本；以及
将第一数据的所述多个经数字签名的版本提供给所述单独的客户端应用。
32.根据权利要求17所述的方法，进一步包括响应于接收所述第一数据，在所述数字签名模块处动态地从数据库加载用于所述第一数据的所述激活的KSK和激活的ZSK中的所述至少一个。
CN201210208313.7A 2011-05-02 2012-05-02 Dnssec签名服务器 Active CN102769529B (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/098940 2011-05-02
US13/098,940 US9130917B2 (en) 2011-05-02 2011-05-02 DNSSEC signing server

Publications (2)

Publication Number Publication Date
CN102769529A CN102769529A (zh) 2012-11-07
CN102769529B true CN102769529B (zh) 2017-04-12

Family

ID=46061989

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201210208313.7A Active CN102769529B (zh) 2011-05-02 2012-05-02 Dnssec签名服务器

Country Status (7)

Country Link
US (3) US9130917B2 (zh)
EP (1) EP2521330B1 (zh)
JP (1) JP2012235464A (zh)
CN (1) CN102769529B (zh)
AU (1) AU2012202493B2 (zh)
BR (1) BR102012010346A2 (zh)
CA (1) CA2775693C (zh)

Families Citing this family (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9106695B2 (en) * 2012-03-14 2015-08-11 Daniel Kaminsky Method and system for user authentication using DNSSEC
US9215205B1 (en) * 2012-04-20 2015-12-15 Infoblox Inc. Hardware accelerator for a domain name server cache
US10715377B2 (en) 2012-12-21 2020-07-14 Comcast Cable Communications, Llc Domain name services servers management to share data efficiently
CN104253793A (zh) * 2013-06-27 2014-12-31 政务和公益机构域名注册管理中心 域名系统的安全扩展的密钥签名密钥和区域签名密钥的更新方法
US9380019B2 (en) * 2013-08-26 2016-06-28 Verisign, Inc. Command performance monitoring
US9300623B1 (en) * 2014-02-18 2016-03-29 Sprint Communications Company L.P. Domain name system cache integrity check
CN103746817B (zh) * 2014-02-18 2018-01-09 互联网域名系统北京市工程研究中心有限公司 Dnssec签名方法及其系统
CN114710351A (zh) * 2014-03-26 2022-07-05 大陆-特韦斯股份有限公司 用于在通信过程中改进数据安全性的方法和系统
US9544266B2 (en) * 2014-06-27 2017-01-10 Microsoft Technology Licensing, Llc NSEC3 performance in DNSSEC
US9894050B1 (en) * 2014-08-11 2018-02-13 Google Llc Server based settings for client software with asymmetric signing
US9473516B1 (en) * 2014-09-29 2016-10-18 Amazon Technologies, Inc. Detecting network attacks based on a hash
CN104486087B (zh) * 2014-12-23 2017-12-29 中山大学 一种基于远程硬件安全模块的数字签名方法
US9544278B2 (en) 2015-01-07 2017-01-10 Red Hat, Inc. Using domain name system security extensions in a mixed-mode environment
US9762556B2 (en) * 2015-01-09 2017-09-12 Verisign, Inc. Registering, managing, and communicating with IOT devices using domain name system processes
EP3051469B1 (en) 2015-01-28 2024-05-22 Inexto Sa Method and apparatus for unit and container identification and tracking
CN104618116B (zh) * 2015-01-30 2019-03-08 北京数字认证股份有限公司 一种协同数字签名系统及其方法
PL3051372T3 (pl) * 2015-01-31 2019-10-31 Inexto Sa Zabezpieczona identyfikacja i weryfikacja produktu
JP6526244B2 (ja) * 2015-02-14 2019-06-05 ヴァリメール インコーポレイテッド ドメインネームサービスを介するプライベートキーの安全な委任された配信
US10270742B2 (en) * 2015-03-27 2019-04-23 Arris Enterprises Llc Cryptographic service with output redirection
US10033699B2 (en) 2015-05-08 2018-07-24 Cloudflare, Inc. Transparent DNSSEC-signing proxy
US9954840B2 (en) 2015-05-08 2018-04-24 Cloudflare, Inc. Generating a negative answer to a domain name system query that indicates resource records as existing for the domain name regardless of whether those resource records actually exist for the domain name
US20180205543A1 (en) 2015-08-13 2018-07-19 Inexto Sa Enhanced obfuscation or randomization for secure product identification and verification
CN106470250B (zh) * 2015-08-19 2019-09-10 互联网域名系统北京市工程研究中心有限公司 域名注册方法、装置和系统
EP3341880B1 (en) 2015-08-25 2022-03-30 Inexto Sa Verification with error tolerance for secure product identifiers
US10594494B2 (en) 2015-08-25 2020-03-17 Inexto Sa Multiple authorization modules for secure production and verification
US11025407B2 (en) 2015-12-04 2021-06-01 Verisign, Inc. Hash-based digital signatures for hierarchical internet public key infrastructure
US10178195B2 (en) 2015-12-04 2019-01-08 Cloudflare, Inc. Origin server protection notification
US10153905B2 (en) * 2015-12-04 2018-12-11 Verisign, Inc. Hash-based electronic signatures for data sets such as DNSSEC
US10181954B2 (en) * 2016-03-28 2019-01-15 Digicert, Inc. Cloud-based code signing service—hybrid model to avoid large file uploads
US20180024807A1 (en) * 2016-07-21 2018-01-25 Vision Menu, Inc. System and Method of Document and Signature Management
US10367825B2 (en) * 2016-12-28 2019-07-30 Verisign, Inc. Method and system for parallel validation of domain name system security extension records
US11032127B2 (en) 2017-06-26 2021-06-08 Verisign, Inc. Resilient domain name service (DNS) resolution when an authoritative name server is unavailable
US11394540B1 (en) * 2018-08-30 2022-07-19 United Services Automobile Association (Usaa) Multi autonomous secure domain name systems
US11468435B1 (en) * 2019-01-03 2022-10-11 Blockchain Innovation, Llc Apparatus and methods of air-gapped crypto storage using diodes
CN110071810B (zh) * 2019-04-25 2021-10-01 哈尔滨工业大学 一个基于开源dns软件的自证根实现方法
CN111316303B (zh) 2019-07-02 2023-11-10 创新先进技术有限公司 用于基于区块链的交叉实体认证的系统和方法
CN116910726A (zh) 2019-07-02 2023-10-20 创新先进技术有限公司 用于将去中心化标识映射到真实实体的系统和方法
SG11202003792QA (en) 2019-07-02 2020-05-28 Advanced New Technologies Co Ltd System and method for verifying verifiable claims
CN111095865B (zh) 2019-07-02 2023-08-04 创新先进技术有限公司 用于发布可验证声明的系统和方法
CN111213147B (zh) 2019-07-02 2023-10-13 创新先进技术有限公司 用于基于区块链的交叉实体认证的系统和方法
CN111066020B (zh) 2019-07-02 2023-08-04 创新先进技术有限公司 用于创建去中心化标识的系统和方法
US11562349B2 (en) * 2019-08-20 2023-01-24 Anchor Labs, Inc. Risk mitigation for a cryptoasset custodial system using data points from multiple mobile devices
WO2021158827A1 (en) * 2020-02-04 2021-08-12 Valimail Inc. Spatial broadcasting device authentication
US11575646B2 (en) * 2020-03-12 2023-02-07 Vmware, Inc. Domain name service (DNS) server cache table validation
US11444931B1 (en) * 2020-06-24 2022-09-13 F5, Inc. Managing name server data
US11218326B1 (en) * 2020-07-02 2022-01-04 Afilias Limited System and method for generating current live and test versions of DNS data for rollover
US11297033B2 (en) 2020-07-02 2022-04-05 Afilias Limited System and method for generating current live and test versions of DNS data for HSM changes
US11233767B1 (en) 2020-07-02 2022-01-25 Afilias Limited System and method for publishing DNS records of a domain including either signed or unsigned records
US11405353B2 (en) 2020-07-16 2022-08-02 Afilias Limited System and method for generating concurrently live and test versions of DNS data
CN114079645B (zh) * 2020-08-13 2022-12-30 花瓣云科技有限公司 注册服务的方法及设备
US11870801B2 (en) * 2021-01-27 2024-01-09 Paypal, Inc. Protecting computer system end-points using activators
CN113296812A (zh) * 2021-06-09 2021-08-24 深圳忆联信息系统有限公司 Windows系统升级的批量签名方法、装置及计算机设备
US20220417032A1 (en) * 2021-06-23 2022-12-29 Arris Enterprises Llc Distributed signing system

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101242426A (zh) * 2007-02-06 2008-08-13 华为技术有限公司 建立传输层安全连接的方法、系统及装置
CN101277257A (zh) * 2007-03-26 2008-10-01 华为技术有限公司 一种dns动态更新的方法、装置和系统
CN101336535A (zh) * 2005-12-27 2008-12-31 法国电信公司 管理dnssec请求的服务器和方法

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3617406B2 (ja) * 2000-03-30 2005-02-02 日本電気株式会社 マルチドメインに対応した品質保証型通信サービス提供方式およびサービス提供方法並びにサービス仲介装置
US6845400B2 (en) * 2000-12-28 2005-01-18 Nortel Networks Limited Storing subscriber location indication at DNS, to enable location specific provision of internet content
FR2908540A1 (fr) * 2006-11-15 2008-05-16 France Telecom Deploiement de bases dnssec
CA2586223A1 (en) * 2007-04-19 2007-07-18 Cannotech Experts-Conseils Inc. Opt-in process and nameserver system for ietf dnssec
WO2009070430A2 (en) * 2007-11-08 2009-06-04 Suridx, Inc. Apparatus and methods for providing scalable, dynamic, individualized credential services using mobile telephones
US8429715B2 (en) * 2008-08-08 2013-04-23 Microsoft Corporation Secure resource name resolution using a cache
WO2010145686A1 (en) * 2009-06-15 2010-12-23 Nokia Siemens Networks Oy Gateway certificate creation and validation
US8645701B2 (en) * 2010-07-13 2014-02-04 Verisign, Inc. System and method for zone signing and key management in a DNS system
US8347100B1 (en) * 2010-07-14 2013-01-01 F5 Networks, Inc. Methods for DNSSEC proxying and deployment amelioration and systems thereof
US8549148B2 (en) * 2010-10-15 2013-10-01 Brocade Communications Systems, Inc. Domain name system security extensions (DNSSEC) for global server load balancing
US8711843B2 (en) * 2010-10-29 2014-04-29 Telefonaktiebolaget Lm Ericsson (Publ) Cryptographically generated addresses using backward key chain for secure route optimization in mobile internet protocol
US8953798B2 (en) * 2010-10-29 2015-02-10 Telefonaktiebolaget L M Ericsson (Publ) Enhanced cryptographically generated addresses for secure route optimization in mobile internet protocol
US8498414B2 (en) * 2010-10-29 2013-07-30 Telefonaktiebolaget L M Ericsson (Publ) Secure route optimization in mobile internet protocol using trusted domain name servers
US8910245B2 (en) * 2010-11-05 2014-12-09 Citrix Systems, Inc. Systems and methods for managing domain name system security (DNSSEC)

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101336535A (zh) * 2005-12-27 2008-12-31 法国电信公司 管理dnssec请求的服务器和方法
CN101242426A (zh) * 2007-02-06 2008-08-13 华为技术有限公司 建立传输层安全连接的方法、系统及装置
CN101277257A (zh) * 2007-03-26 2008-10-01 华为技术有限公司 一种dns动态更新的方法、装置和系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
F5 and Infoblox DNS Integrated Architecture：Offering a Complete Scalable, Secure DNS Solution;Nathan Meyer ET AL;《WHITE PAPER BY F5，URL: http://web.archive.org/web/20100326145019/http://www.f5.com/pdf/white-papers/ infoblox-wp.pdf》;20100201;第1-18页 *

Also Published As

Publication number Publication date
US20150372822A1 (en) 2015-12-24
EP2521330B1 (en) 2015-08-12
CA2775693A1 (en) 2012-11-02
CA2775693C (en) 2019-05-07
CN102769529A (zh) 2012-11-07
US10158620B2 (en) 2018-12-18
US20170324724A1 (en) 2017-11-09
AU2012202493B2 (en) 2016-03-17
JP2012235464A (ja) 2012-11-29
US20120284505A1 (en) 2012-11-08
BR102012010346A2 (pt) 2015-08-11
US9130917B2 (en) 2015-09-08
US9749307B2 (en) 2017-08-29
EP2521330A1 (en) 2012-11-07

Similar Documents

Publication Publication Date Title
CN102769529B (zh) Dnssec签名服务器
EP2518970B1 (en) Dnssec inline signing
US11818142B2 (en) Distributed data authentication and validation using blockchain
CN106068639B (zh) 通过dns处理的透明代理认证
CN109983752A (zh) 带有编码dns级信息的网络地址
US20120254386A1 (en) Transfer of DNSSEC Domains
US20030163737A1 (en) Simple secure login with multiple-authentication providers
CN102685074B (zh) 防御网络钓鱼的网络通信系统及方法
US10341286B2 (en) Methods and systems for updating domain name service (DNS) resource records
CN106936945B (zh) 分布式域名解析方法及装置
CN103379116A (zh) Dnssec在线签名
US20220006772A1 (en) System and method for generating current live and test versions of dns data for hsm changes
CN102769621A (zh) 一种面向真实用户身份的主机移动方法
EP3844657B1 (en) Distributed data authentication and validation using blockchain
US11233767B1 (en) System and method for publishing DNS records of a domain including either signed or unsigned records
Jones et al. Layering a Public Key Distribution Service Over Secure DNS:“Everybody Comes to RIKS”
JP2012199607A (ja) Ｄｎｓｓｅｃ代理装置
KR20120124044A (ko) Ｄｎｓｓｅｃ 서명 서버
Melvin Endpoint Identification Using System Logs
KR20120122979A (ko) Ｄｎｓｓｅｃ 인라인 서명

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant