它是否拒绝返回请求的记录，或者是否返回记录，并将域视为不安全？
答案1
如果解析器遇到它不支持的 DNSSEC 算法会发生什么？
DNSSEC 旨在允许验证，只要存在一条验证路径即可。如果解析器能够找到至少一种其支持的算法并检查所有信息（签名等）均正常，则 DNSSEC 验证将正常，未知算法将被忽略。
当然，如果解析器只找到它不支持的算法，甚至找不到它支持的算法，那么 DNSSEC 验证将失败，并SERVFAIL返回。
可能有多个 DNSKEY RR 符合上述条件。在这种情况下，验证器无法预先确定使用哪个 DNSKEY RR 来验证签名，并且必须尝试每个匹配的 DNSKEY RR，直到签名被验证或验证器用尽了要尝试的匹配公钥。
因此，一个好的算法就足够了，解析器不必测试所有算法。这有利于在发布端逐步引入新算法，同时解析器也会不断更新以了解新算法。
另请参阅RFC 8626“DNSSEC 算法实施要求和使用指南”。
它是否拒绝返回请求的记录，或者返回记录，并将域视为不安全？
DNSSEC 通常是二进制的：域具有正确的 DNSSEC 验证或存在错误（因此SERVFAIL）。如果失败，解析器不允许从域中剥离 DNSSEC，并返回记录，就好像域从一开始就没有 DNSSEC 一样。
但是，这只是理论。在实践中，确实存在这样的情况：即使对于已知 DNSSEC 已损坏的域，递归解析器有时也需要继续应答，因为人们认为否则会产生太大的麻烦。参见过去著名的 NASA/Comcast 示例。这就是为什么现在有“负信任锚”或 NTA：这是递归解析器操作员的一种说法，“域 X 的 DNSSEC 已损坏，请忽略那里的信任失败，并像没有 DNSSEC 一样运行”。这应该是一种临时措施，并且显然是每个递归解析器本地的。
看RFC 7646“DNSSEC 负信任锚的定义和使用”（2015 年 9 月）：
本文档定义了负信任锚 (NTA)，可通过禁用指定域的 DNSSEC 验证来缓解 DNSSEC 验证失败。
答案2
据我所知，安全意识验证解析器必须给出错误响应。因此，预期会出现 SERVFAIL 错误响应。
当更新以支持相对较新的 RFC 8914甚至会出现扩展的 DNS 错误详细信息，例如：
Extended DNS Error Code 1 - Unsupported DNSKEY Algorithm
Extended DNS Error Code 2 - Unsupported DS Digest Type