解释和转换区域文件数据

Interpreting and converting zone file data

我有一个用于单个 TLD 的区域。我正在尝试处理文件数据并将其转换为 JSON 以供使用此数据的其他服务使用。这是我拥有的文件的前五行:

com.    900     in      soa     a.gtld-servers.net.     nstld.verisign-grs.com. 1612915221      1800    900     604800    86400
0-------------------------------------------------------------0.com.    172800  in      ns      ns1.domainit.com.
0-------------------------------------------------------------0.com.    172800  in      ns      ns2.domainit.com.
0-------------------------------------------------------------5.com.    172800  in      ns      fns.frogsmart.net.
0-------------------------------------------------------------5.com.    172800  in      ns      sns.frogsmart.net.
0-------------------------------------------------------------5.com.    172800  in      ns      tns.frogsmart.net.

现在我不确定如何解释这个文件的数据。我在多个地方查看了参考和示例区域文件,但它与这种格式不一样。可以找到参考文献之一 here。我只需要一些关于如何解释每一行的指示。我的理解如下:

  1. 第一个值是域名
  2. 下一个值是一个数字,如果我将第一行用作 header 似乎是 900(不确定是什么)
  3. 下一个值是in(不知道这是什么)
  4. 下一个值是 soa,即 ns(我认为这意味着域的授权开始与名称服务器有关)
  5. 最后,名称服务器,如果我将第一行用作 header 似乎 a.gtld-servers.net(我认为这是主要的 SOA 地址)

现在是其他属性(我认为第一行表示 10 个属性),但这些属性不存在于我试图处理的文件中。到目前为止我能想到的就是这些,如果能提供一些帮助,我们将不胜感激。

首先警告:区域文件可能很大,尤其是 .com 一个并将其转换为 JSON,特别是如果您打算在使用之前在内存中完全构建对象,您可能会遇到麻烦.

所以您应该首先问自己是否真的需要所有数据(例如,如下所示,您将如何处理 SOA 内容?)以及 JSON 是否是最充分的表示,特别是如果不是以流式传输的方式。

DNS 数据在 RFC 1034+1035 中有解释。 更具体地说,RFC1035 中的 §3.3.13:

3.3.13. SOA RDATA format

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/                     MNAME                     /
/                                               /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/                     RNAME                     /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    SERIAL                     |
|                                               |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    REFRESH                    |
|                                               |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                     RETRY                     |
|                                               |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    EXPIRE                     |
|                                               |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    MINIMUM                    |
|                                               |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:

MNAME The of the name server that was the original or primary source of data for this zone.

RNAME A which specifies the mailbox of the person responsible for this zone.

SERIAL The unsigned 32 bit version number of the original copy of the zone. Zone transfers preserve this value. This value wraps and should be compared using sequence space arithmetic.

REFRESH A 32 bit time interval before the zone should be refreshed.

RETRY A 32 bit time interval that should elapse before a failed refresh should be retried.

EXPIRE A 32 bit time value that specifies the upper limit on the time interval that can elapse before the zone is no longer authoritative.

但请注意语义在后来的 RFC 中已经改变,MINIMUM 现在称为 NEGATIVE TTL。

另外 IN(大小写不重要)表示 INternet 但所有记录都会有,将其视为过去围绕 类 进行的 DNS 实验的遗留物,但从未奏效。