tsig

说明

使用 tsig，你可以定义 CoreDNS 的 TSIG 密钥。使用这些密钥，tsig 可以验证传入的 TSIG 请求，并对这些请求签名以作响应。它本身并不会对从 CoreDNS 发出的请求进行签名；由发送这些请求的相应插件使用 tsig 定义的密钥进行签名。

tsig 插件还可以要求对某些查询类型进行签名的传入请求，并拒绝不符合要求的请求。

语法

tsig [ZONE...] {
  secret NAME KEY
  secrets FILE
  require [QTYPE...]
}

• ZONE - tsig 将进行 TSIG 的区域。默认情况下，使用了来自服务器阻止的区域。

• secret NAME KEY - 使用 KEY 为 NAME 指定一个 TSIG 密钥。使用此选项可以多次定义多个密钥。密钥对服务器实例是全局的，而不仅仅是对封闭的 ZONE。

• secrets FILE - 与 secret 相同，但从文件中加载密钥。此文件可以定义任意数量的唯一密钥，每个密钥都采用以下 named.conf 格式

  key "example." {
      secret "X28hl0BOfAL5G0jsmJWSacrwn7YRm2f6U5brnzwWEus=";
  };
  

  每个密钥还可以指定一个 algorithm，例如 algorithm hmac-sha256;，但插件目前忽略此项。

  • require QTYPE… - 必须进行 TSIG 的查询类型。如果没有签名，则将REFUSED指定的类型的请求。require all 将要求对所有类型的请求进行签名。 require none 将不会要求对任何类型的请求进行签名。默认行为是不要求。

示例

要求向 example.zone 发送的传输请求进行 TSIG 签名交易。

example.zone {
  tsig {
    secret example.zone.key. NoTCJU+DMqFWywaPyxSijrDEA/eC3nK0xi3AMEZuPVk=
    require AXFR IXFR
  }
  transfer {
    to *
  }
}

要求对发送至 auth.zone 的所有请求进行 TSIG 签名交易。

auth.zone {
  tsig {
    secret auth.zone.key. NoTCJU+DMqFWywaPyxSijrDEA/eC3nK0xi3AMEZuPVk=
    require all
  }
  forward . 10.1.0.2
}

缺陷

第二级

TSIG 传输尚未针对 secondary 插件实现。secondary 插件不会对其区域传输请求进行签名。

区域传输通知

对于 transfer 插件，CoreDNS 的区域传输通知未进行 TSIG 签名。

转发服务器的特殊注意事项 (RFC 8945 5.5)

https://datatracker.ietf.org/doc/html/rfc8945#section-5.5

CoreDNS 不按如下方式实现此部分...

• RFC 要求

  如果 TSIG 中的名称不是服务器与发起者共享的密钥的名称，则服务器必须原样转发消息，包括 TSIG。

  CoreDNS 的行为：如果请求的区域匹配到< em>tsig 插件区域，那么 TSIG 记录将始终被剥离。但即使tsig 插件未参与，forward 插件也可能会通过压缩改变消息，这会导致在目的地发生验证失败。

• RFC 要求

  如果 TSIG 通过了所有检查，转发服务器必须（如果可能）将自己的 TSIG 包含到目的地或下一个转发服务器。

  CoreDNS 的行为：如果请求的区域匹配到tsig 插件区域，forward 插件将代理请求中的上游而不带 TSIG。

• RFC 要求

  如果目的地没有可用的事务安全，并且该消息是一个查询，并且如果相应的响应设置了 AD 标志（请参见 RFC4035），则转发器必须在将 TSIG 添加到响应并将其结果返回给从中接收查询的系统之前清除 AD 标志。

  CoreDNS 的行为：AD 标志未被清除。