mlf slf psl_不解析PSL的公共后缀查找

mlf slf psl

During my work at SSE (I was working on the security-first DNS provider deSEC), I was facing the need for quickly looking up the so-called Public Suffix for a given domain name. If the domain name is, say, amazon.co.uk, then the Public Suffix would be co.uk. Such lookups are usually done by loading and parsing the Public Suffix List (PSL) and then matching the last part(s) of the domain name against the list, eventually settling on the longest match.

在SSE工作期间(我正在研究安全第一的DNS提供商deSEC)，我面临着快速查找给定域名的所谓公共后缀的需求。 如果域名是amazon.co.uk ，则后缀为co.uk 通常通过加载和解析公共后缀列表(PSL) ，然后将域名的最后一部分与列表进行匹配，最终找到最长的匹配项，从而完成查找。

As it turns out, this approach requires application awareness of the PSL and comes with significant maintenance overhead — more on that later. Let’s first understand both benefits and quirks of the PSL, and then see why it’s more complicated than it looks at first sight. Employing the DNS as a key-value store will lead an elegant way out of the mess.

事实证明，这种方法需要PSL的应用程序意识，并且会带来大量的维护开销-稍后会介绍更多。 首先让我们了解PSL的优点和怪异之处，然后看看为什么它比乍一看更复杂。 使用DNS作为键值存储将引导您摆脱困境。

PSL背后的想法 (The Idea behind the PSL)

The PSL has a wide range of applications, as there are several (usually security-related) scenarios in which applications or service providers need to make a policy decision based on the public suffix of the domain name at hand. A special case is when the domain name is itself a public suffix. For example, Certificate Authorities most likely would not want to issue a wildcard TLS certificate for the name *.co.uk, although a wildcard certificate for *.t.co (Twitter’s URL shortener service) may be perfectly fine.

PSL具有广泛的应用程序，因为在几种(通常与安全性相关的)方案中，应用程序或服务提供商需要根据手头的域名后缀来制定策略决策。 特殊情况是域名本身是公共后缀。 例如，尽管*.t.co (Twitter的URL缩短服务)的通配符证书可能很好，但是证书颁发机构极有可能不想为*.co.uk颁发通配符TLS证书。

Here are some common applications in which knowledge of a domain name’s public suffix is required:

以下是一些需要了解域名公共后缀的常见应用程序：

• In order to decide how exactly cookie scoping should be restricted across domains, browsers determine public suffixes. Some browsers also highlight a domain’s public suffix in the address bar to aid visual inspection and hamper phishing.

  为了确定跨域限制cookie范围的精确程度， 浏览器确定了公共后缀。 某些浏览器还会在地址栏中突出显示域的公共后缀，以帮助进行外观检查并阻止网络钓鱼。

• Certificate Authorities (CAs) checking for wildcard misissuance should not allow a wildcard certificate for a public suffix name such as *.co.uk.

  检查通配符发行错误的证书颁发机构(CA)不应将通配符证书用于*.co.uk类的公共后缀名称。

• Some CAs such as Let’s Encrypt limit the number of certificates that can be requested for a given domain, including subdomains (within a given interval, such as per week). CAs need to be aware of each domain’s public suffix in order to decide on which part of the domain the limit should be applied. For example, a certificate request for console.cloud.google.com should be counted towards the google.com name (2nd-to-last label) while a certificate request for www.google.co.uk would be counted towards google.co.uk (3rd-to-last label!).

  诸如“加密”之类的某些CA限制了给定域(包括子域)(在给定间隔内，例如每周)内可以请求的证书数量。 CA需要了解每个域的公共后缀，以便决定应在域的哪个部分上应用限制。 例如， console.cloud.google.com的证书申请应计入google.com名称(倒数第二个标签)，而www.google.co.uk的证书申请应计入google.co.uk (倒数第二个标签！)。

• The DMARC email authentication protocol, intended for fighting spam by validating the message origin, is configured via DNS records on the registrable domain (organizational domain in DMARC speak), i.e. the domain name whose direct parent is the domain name’s public suffix. For example, DMARC for the address admin@services.staff.example.org is configured as a DNS record under example.org (to be precise: as a TXT record at _dmarc.example.org). DMARC validators need to know where to look for that record: Should they use _dmarc.staff.example.org or _dmarc.example.org? The PSL answers this question.

  DMARC电子邮件身份验证协议旨在通过验证邮件来源来抵制垃圾邮件，它是通过可注册域 (DMARC所说的组织域 )上的DNS记录配置的，即直接父域是域名的公共后缀的域名。 例如，将地址admin@services.staff.example.org DMARC配置为example.org下的DNS记录(准确地说，是_dmarc.example.org的TXT记录)。 DMARC验证程序需要知道在哪里查找该记录：他们应该使用_dmarc.staff.example.org还是_dmarc.example.org ？ PSL回答了这个问题。

• As a consequence of a little known subtlety in the specification of the DNS, DNS providers too need to be aware of what’s a public suffix.

  由于DNS规范中鲜为人知的微妙结果， DNS提供者也需要知道什么是公共后缀。

I first encountered the need for ad-hoc PSL lookups while working on the deSEC DNS hosting platform, and so I would like to devote a separate section to this last use case. If you are not interested in the intricacies of setting up a DNS platform, you can skip the next section.

在deSEC DNS托管平台上工作时，我首先遇到了临时PSL查找的需求 ，因此我想在此最后一个用例中专门介绍一个部分。 如果您对设置DNS平台的复杂性不感兴趣，则可以跳过下一部分。

深入研究：公共后缀与DNS提供商的相关性 (Deep Dive: The Relevance of Public Suffixes for a DNS Provider)

Here’s why: In DNS, it is possible to store conflicting information on the same name server. For example, one customer could register the zone example.com and create a DNS record for the subdomain www with IP address 1.2.3.4, while another can register the zone www.example.com and create a record there, with IP address 6.6.6.6. Each customer “owns” a part of the global DNS tree, but the two overlap. If this situation occurs, RFC 1034 Sec. 4.3.2 prescribes that the most specific zone (subtree) wins.

原因如下：在DNS中，可以将冲突的信息存储在同一名称服务器上。 例如，一个客户可以注册区域example.com并为IP地址为1.2.3.4的子域www创建DNS记录，而另一位客户可以注册区域www.example.com并在其中创建IP地址为6.6的记录。 6.6。 每个客户“拥有”全局DNS树的一部分，但两者重叠。 如果发生这种情况，请参见RFC 1034 Sec。 4.3.2规定最具体的区域(子树)获胜。

In other words, DNS queries for www.example.com are answered with 6.6.6.6, which might not be what the owner of example.com was expecting. (Such subzone takeovers may include dangerous names such as _acme-challenge.www.example.com, allowing the attacker to obtain a TLS certificate for the parent name. You can find some real world cases in a paper I wrote in 2018.)

换句话说，对www.example.com DNS查询将以6.6.6.6回答，这可能与example.com的所有者所期望的不一样。 (此类分区接管可能包含危险的名称，例如_acme-challenge.www.example.com ，使攻击者可以获取父名称的TLS证书。您可以在我于2018年撰写的一篇论文中找到一些现实情况。)

To avoid this problem, we introduced a check at deSEC to reject zone registrations for domain names if any parent domain name is owned by another user. — Great, we’re safe then, aren’t we?

为避免此问题，我们在deSEC进行了一项检查，如果任何父域名由另一个用户拥有，则拒绝域名的区域注册。 -太好了，那我们就安全了，不是吗？

Unfortunately, no. With this check in place, a malicious (or imprudent) user may register co.uk and, as a consequence, cause all other users to be blocked from registering their legitimate <something>.co.uk names: the security check would interpret such registrations as a hijacking attempt. We find ourselves in a catch-22: it seems that we have no choice but to either allow a malicious user to hijack another customer’s subdomains, or — with the security check in place — to allow them to occupy a large chunk of the DNS tree, such as co.uk!

抱歉不行。 进行此检查后，恶意(或轻率)用户可能会注册co.uk ，并因此导致所有其他用户无法注册其合法的<something>.co.uk名称：安全检查将解释为注册为劫持企图。 我们陷入了困境：似乎我们别无选择，只能要么允许恶意用户劫持另一个客户的子域，要么(通过安全检查)让他们占据DNS树的很大一部分，例如co.uk ！

This is where the PSL comes in: unless you’re a registry and managing a public suffix (such as a top level domain), there is no legitimate use case for any user to register a domain that is a public suffix itself. After all, domain owners purchase a domain name under a public suffix, and then need DNS services for that registrable domain, not for the public suffix. Thus, barring a few very special cases, it is safe to reject registrations of domain names which are public suffixes themselves.

这就是PSL的用处：除非您是注册中心并管理公共后缀(例如顶级域)，否则任何用户都没有合法用例来注册本身就是公共后缀的域。 毕竟，域名所有者在公共后缀下购买域名，然后需要该可注册域的DNS服务， 而不是公共后缀。 因此，除非有一些非常特殊的情况，否则可以安全地拒绝作为公共后缀的域名注册。

By combining the two security checks (rejecting both subzone registration and public suffix registration), safe operation of the DNS service is ensured. But it comes at a price: At deSEC, we need to perform a public suffix lookup for each domain name for which registration is attempted.

通过结合两个安全检查(拒绝分区注册和公共后缀注册)，可以确保DNS服务的安全运行。 但这是有代价的：在deSEC，我们需要为每个尝试注册的域名执行公共后缀查找。

实用并发症 (Practical Complications)

All of the above types of applications, and possibly even more, need to perform lookups in the PSL. The list, ever changing, is now over 200 KB large (there are thousands of public suffixes), and only loosely structured. The usual approach is to distribute the official PSL file in text format along with the application itself, and update it once in a while.

以上所有类型的应用程序，甚至可能还有更多类型的应用程序，都需要在PSL中执行查找。 列表不断变化，现在超过200 KB(有数千个公共后缀)，并且结构松散。 通常的方法是将文本形式的官方PSL文件与应用程序本身一起分发，并不时进行更新。

This poses several problems:

这带来了几个问题：

• Parsing the PSL is not trivial. For example, it supports wildcards as well as exceptions: all direct children of kawasaki.jp are declared as public suffixes with the PSL entry *.kawasaki.jp, but city.kawasaki.jp is exempt (!city.kawasaki.jp).

  解析PSL 并非易事 。 例如，它支持通配符以及例外： kawasaki.jp所有直接子代都被声明为带有PSL条目*.kawasaki.jp公共后缀，而city.kawasaki.jp是免税的( !city.kawasaki.jp )。

• When a given domain name is matched by several entries, only the longest one is the public suffix: the public suffix of some-bucket.s3.amazonaws.com is s3.amazonaws.com (and not com — but both are on the list).

  当给定的域名是由几个条目匹配，只有最长的一个是公共后缀：公共后缀some-bucket.s3.amazonaws.com是s3.amazonaws.com (而不是com -但两者都在名单上)。

• In light of these parsing issues, applications need to transform the PSL text file into a suitable representation in which lookups are efficient (typically a tree structure; a good choice requires some expertise).
  鉴于这些解析问题，应用程序需要将PSL文本文件转换为合适的表示形式，在这种表示形式中查找效率很高(通常是树形结构；一个好的选择需要一些专业知识)。
• Also, a storage solution is required. It’s easiest to simply store the PSL file in the file system, but with the above considerations in mind, it may not be the best solution.
  另外，需要一种存储解决方案。 仅将PSL文件存储在文件系统中是最容易的，但是考虑到以上考虑，它可能不是最佳解决方案。
• Developers have to come up with some sort of update mechanism. Do random updates at deployment time suffice?
  开发人员必须提出某种更新机制。 部署时进行随机更新是否足够？

PSL users have to worry about all of this. While the above problems have been solved several times in various implementations for different browsers, programming languages, etc., there is no one-stop solution so far.

PSL用户必须担心所有这些。 尽管上述问题已经在针对不同浏览器，编程语言等的各种实现中得到了多次解决，但到目前为止还没有一站式解决方案。

That leads to the obvious question: Is there a better, more generic approach?

这就引出了一个显而易见的问题：是否有更好，更通用的方法？

解决方案：将PSL映射到DNS (Solution: Mapping the PSL onto the DNS)

The DNS, being a domain-based key-value store, is well-fit to serve as a directory for domain-related lookups. Both keys and values are rather arbitrary: the constraints are only that the key must be a valid (sub-)domain name, and the value must fit one of the established DNS record types (e.g. A for IP addresses, TXT for strings, or PTR for mapping a key onto another domain name). In recent years, a few interesting DNS-based applications have evolved, such as storage of TLS public keys using TLSA records (DANE).

DNS是基于域的键值存储，非常适合用作与域相关的查找的目录。 密钥和值都相当随意：约束条件是密钥必须是有效的(子)域名，并且该值必须适合已建立的DNS记录类型之一(例如，IP地址为A ，字符串为TXT ，或用于将密钥映射到另一个域名的PTR )。 近年来，一些有趣的基于DNS的应用程序得到了发展，例如使用TLSA记录(DANE)存储TLS公钥 。

The suffixes listed in the PSL qualify as proper DNS names (keys), with the exception of wildcard exception rules (let’s worry about that later). It is thus possible to map the PSL onto the DNS structure itself, forming a tree structure, and then “mount the PSL” as a subtree somewhere in the DNS. We chose to use the domain publicsuffix.zone as our home, and use query.publicsuffix.zone as the PSL mount point.

除通配符例外规则(稍后再担心)之外，PSL中列出的后缀都可以用作正确的DNS名称(键)。 因此可以将PSL映射到DNS结构本身上，形成树结构，然后将其作为子树“挂载PSL”作为DNS中的某个子树。 我们选择使用域publicsuffix.zone作为我们的家，并使用query.publicsuffix.zone作为PSL挂载点。

To represent PSL information, we use PTR records and encode all public suffixes as the values of such records. Keys are set up such that one can simply take any domain name and query a PTR record for that name, with .query.publicsuffix.zone appended. The zone contains crafty CNAME redirects and nifty wildcard configurations, such that the DNS lookup eventually arrives at a PTR record which does indeed point to the public suffix of the domain of interest. To ensure authenticity, we use DNSSEC (as is the case for all deSEC-managed domains).

为了表示PSL信息，我们使用PTR记录并将所有公共后缀编码为此类记录的值。 设置密钥后，可以简单地获取任何域名，并在PTR记录中查询该名称，并附加.query.publicsuffix.zone 。 该区域包含巧妙的CNAME重定向和精巧的通配符配置，因此DNS查找最终到达PTR记录，该记录的确指向所关注域的公共后缀。 为了确保真实性，我们使用DNSSEC(所有deSEC管理的域都是这种情况)。

As an example, let’s figure out the public suffix of www.google.co.uk. Here’s what we have configured under query.publicsuffix.zone:

例如，让我们找出www.google.co.uk的公共后缀。 这是我们在query.publicsuffix.zone下配置的query.publicsuffix.zone ：

• There is a PTR record at co.uk.query.publicsuffix.zone with a value of co.uk. This is the record that the query reply will be expected to contain.

  有一个PTR的记录co.uk .query.publicsuffix.zone具有的价值co.uk 。 这是查询答复将包含的记录。

• We also have configured a CNAME redirect record for all domains under this suffix, pointing one level up in the DNS hierarchy: *.co.uk.query.publicsuffix.zone CNAME co.uk.query.publicsuffix.zone.

  我们还为该后缀下的所有域配置了CNAME重定向记录，在DNS层次结构*.co.uk .query.publicsuffix.zone CNAME co.uk .query.publicsuffix.zone向上一级： *.co.uk .query.publicsuffix.zone CNAME co.uk .query.publicsuffix.zone 。

The lookup then proceeds as follows:

然后，查找过程如下：

1. We ask a PTR query for www.google.co.uk.query.publicsuffix.zone.

   我们要求对PTR查询www.google.co.uk .query.publicsuffix.zone 。

2. The DNS resolution process will encounter the CNAME record at *.co.uk.query.publicsuffix.zone and redirect the question to co.uk.query.publicsuffix.zone.

   DNS解析过程将在*.co.uk .query.publicsuffix.zone遇到CNAME记录，并将问题重定向到co.uk .query.publicsuffix.zone 。

3. The PTR record at co.uk.query.publicsuffix.zone will be returned, yielding the answer co.uk. Voilà! 🎉

   在PTR达到创纪录的co.uk .query.publicsuffix.zone将被退回，得到的答案co.uk 。 瞧！ 🎉

PSL wildcard rules are accommodated effortlessly with this approach: we simply prepend the wildcard label *. to the value of the PTR record. Wildcard exceptions are taken care of by adding explicit records at the domain name representing the exception rule, cutting the corresponding DNS subtree out of the wildcard’s sphere of influence. Consider the following example:

通过这种方法可以毫不费力地适应PSL通配符规则：我们只需在通配符标签前加上*. PTR记录的值。 通配符例外的处理是通过在代表例外规则的域名上添加显式记录，将相应的DNS子树从通配符的影响范围中删除来进行的。 考虑以下示例：

• *.kawasaki.jp is a wildcard public suffix, and city.kawasaki.jp is an exception.

  *.kawasaki.jp是通配符公共后缀， city.kawasaki.jp是一个例外。

• As usual, we define a CNAME record for *.kawasaki.jp.query.publicsuffix.zone (pointing one level up) and a PTR record at kawasaki.jp.query.publicsuffix.zone with value *.kawasaki.jp.

  与往常一样，我们为*.kawasaki.jp .query.publicsuffix.zone定义一个CNAME记录(指向上一级)，并在kawasaki.jp .query.publicsuffix.zone定义一个值为*.kawasaki.jp的PTR记录。

• To take care of the exception, we set an explicit PTR record at city.kawasaki.jp.query.publicsuffix.zone, overriding the wildcard rule with an explicit PTR value of jp.

  为了解决该异常，我们在city.kawasaki.jp .query.publicsuffix.zone设置了一个显式PTR记录，使用显式PTR值jp覆盖了通配符规则。

• Finally, we configure a CNAME record at *.city.kawasaki.jp.query.publicsuffix.zone, pointing one level up.

  最后，我们在*.city.kawasaki.jp .query.publicsuffix.zone配置一个CNAME记录，指向上一级。

值得考虑的事情 (Things Worth Considering)

Generic and platform-independent. The DNS-based PSL lookup solution solves all of the problems mentioned above. Applications only need the ability to perform DNS queries (which should almost always be the case). Parsing of the PSL is not required on the application layer; no decisions on storage or internal representation need to be made. Also, PSL information in the DNS is always up to date: we propagate changes from the official list on a daily basis.

通用且与平台无关。 基于DNS的PSL查找解决方案解决了上述所有问题。 应用程序仅需要具有执行DNS查询的能力(几乎总是如此)。 在应用层不需要解析PSL。 无需决定存储或内部代表。 此外，DNS中的PSL信息始终是最新的：我们每天都会传播来自官方列表的更改。

Library support. For convenience, there is a Python library (psl-dns) that comes with a handy interface to “simply answer your question”, such as psl.is_public_suffix('city.kawasaki.jp') or psl.get_public_suffix('some-bucket.s3.amazonaws.com'). The library provides some extra convenience: For internationalized domain names, it will preserve the Unicode vs. Punycode format choice between question and answer. For those who can’t get enough, it also allows listing all PSL rules pertinent to a domain name using psl.get_rules() (there may be several override rules in certain wildcard configurations).For information on library support for other languages, check out the documentation at publicsuffix.zone. In any case, the use of a library is by no means necessary: if you like to stick to the KISS principle or if your language is not supported, simple DNS lookups will get you there as well.

图书馆支持。 为方便起见，有一个Python库(psl-dns)带有一个方便使用的界面来“简单地回答您的问题”，例如psl.is_public_suffix('city.kawasaki.jp')或psl.get_public_suffix('some-bucket.s3.amazonaws.com') 。 该库提供了一些额外的便利：对于国际化域名，它将保留在问题和答案之间选择Unicode vs. Punycode格式。 对于那些不够用的人，它还允许使用psl.get_rules()列出与域名相关的所有PSL规则(某些通配符配置中可能有多个覆盖规则)。有关其他语言的库支持的信息，请参见在publicsuffix.zone中删除文档。 无论如何，都没有必要使用库：如果您希望坚持使用KISS原则，或者如果不支持您的语言，则简单的DNS查找也可以帮助您。

PTR record support. Some DNS resolvers (especially those run by consumer Internet access providers) do not support PTR queries. The problem can be worked around by using another resolver (such as 8.8.8.8), or by querying the ANY record type instead (which will return all records for the given name, including PTR).When asking for ANY records, you may find that the response will sometimes contain additional TXT records. Those are purely informational and represent PSL rules that cover the domain name, but were overridden by some other rule (again, this can happen in case of wildcard exceptions). Unless you are interested in these no-op rules, you can ignore them completely.

PTR记录支持。 某些DNS解析器(尤其是由消费者Internet访问提供商运行的解析器)不支持PTR查询。 这个问题可以通过其他解析器(如8.8.8.8)来工作围绕，或通过查询ANY记录类型，而不是(这将返回所有记录给定的名称，包括PTR )。当询问ANY记录，你会发现该响应有时会包含其他TXT记录。 这些纯粹是信息性的，代表了覆盖域名的PSL规则，但被其他一些规则所覆盖(同样，通配符例外可能会发生这种情况)。 除非您对这些无操作规则感兴趣，否则可以完全忽略它们。

Edge cases. Domain names are limited to 63 labels (they can contain at most 62 dots). Appending .query.publicsuffix.zone to the name of interest costs 3 labels, so only domains names with up to 60 labels are supported. This will not usually be an issue.Furthermore, the PSL specification allows rules with inline wildcards, such as inline.*.wildcard.test. Such constructs cannot be mapped onto the DNS, as DNS requires wildcards to be in the leftmost position. However, the PSL does not currently contain any actual rules of this kind, and PSL maintainers are planning to drop inline wildcard support entirely. Consequently, this edge case is currently not a practical issue, and it most likely never will be.

边缘情况。 域名限制为63个标签(它们最多可以包含62个点)。 将.query.publicsuffix.zone附加到感兴趣的名称需要花费3个标签，因此仅支持最多包含60个标签的域名。 这通常不会成为问题。此外， PSL规范允许使用带有内联通配符的规则，例如inline.*.wildcard.test 。 此类构造无法映射到DNS，因为DNS要求通配符位于最左侧。 但是，PSL当前不包含任何此类实际规则，并且PSL维护人员计划完全放弃内联通配符支持 。 因此，这种极端情况目前不是实际问题，很可能永远不会。

Privacy. It is clear that when querying a DNS service, the involved DNS service provider(s) will learn about the names queried. It would thus be a bad idea if a browser vendor decided to query our PSL service for cookie policing, as this would expose important aspects of their users’ browsing activities to SSE and deSEC (the operators of publicsuffix.zone) as well as other parties (when using a resolver). In other contexts, such as during certificate issuance checks, the concern is lessened and a DNS query may be acceptable: the subject names of newly issued TLS certificates are publicly logged anyways, and a DNS query leaks the same information. Privacy concerns thus depend on the specific use case and must be evaluated on a case-by-case basis.By all means, we do not operate the service to collect any data (and in fact we do not keep query logs). We are open to providing full copies of the PSL zone to parties who would like to run a private on-site deployment of the service — just get in touch!

隐私。 显然，在查询DNS服务时，所涉及的DNS服务提供商将了解所查询的名称。 因此，这将是一个坏主意，如果浏览器厂商决定来查询我们的PSL服务cookie的监管，因为这样会暴露自己的用户的浏览活动的重要方面SSE和deSEC (的运营商publicsuffix.zone )以及其他各方(使用解析器时)。 在其他情况下(例如，在证书颁发检查期间)，该问题得到了缓解，并且DNS查询可以接受：无论如何， 公开发布的新发布的TLS证书的主题名称始终被公开记录 ，而DNS查询则泄漏相同的信息。 因此，对隐私的关注取决于特定的用例，并且必须根据具体情况进行评估。无论如何，我们不会操作该服务来收集任何数据(实际上，我们不会保留查询日志)。 我们愿意向希望进行私有现场服务部署的各方提供PSL区域的完整副本，请与我们联系！

结论 (Conclusion)

Knowing the public suffix of a given domain name is an important piece of information in several widespread applications. However, keeping an up-to-date copy of the list and parsing it correctly is a challenging task from which many issues arise.

在多个广泛的应用程序中，了解给定域名的公共后缀是重要的​​信息。 但是，保留列表的最新副本并正确解析它是一项具有挑战性的任务，由此产生许多问题。

Looking up public suffixes by utilizing a DNS-based representation of the PSL solves these issues, at the same time demonstrating that there are still novel applications to the DNS. While it may be surprising to some, I would like to make the case that this is a great illustration of how DNS is exactly the right technology to tackle the issue of storing information that is closely related to domain names: decentralized, ubiquitous, and, with DNSSEC, authentic.

通过利用基于DNS的PSL表示来查找公共后缀可以解决这些问题，同时表明对DNS仍有新颖的应用程序。 尽管有些人可能会感到惊讶，但我想说明一下，这很好地说明了DNS是如何正确解决与域名密切相关的信息存储问题的正确技术：去中心化，普遍存在以及与DNSSEC，真实。

This service has been made possible through the continued contribution of SSE to the security-first, free, and open-source DNS hosting service deSEC. It was while working on deSEC that I first became aware of the need for ad-hoc PSL lookups. We are glad to have found a low-maintenance solution for our own needs that at the same time we can provide as a free, public service.

通过SSE对安全第一，免费和开源DNS托管服务deSEC的持续贡献，使得该服务成为可能。 在从事deSEC的工作时，我首先意识到临时PSL查找的必要性。 我们很高兴找到一种低维护的解决方案来满足我们自己的需求，同时我们可以提供免费的公共服务。

翻译自: https://medium.com/sse-blog/public-suffix-lookups-without-parsing-the-psl-22abe9aa7cc4

mlf slf psl