At work, we use a private TLD (I did not decide, don't hit me, not my
fault, I don't speak for my employer, etc), and a validating Unbound
resolver was able to use it with forward-zone.
Now that the root is signed and validated, I get a SERVFAIL, probably
because the root says NXDOMAIN.
Is there any way to tell Unbound to bypass the validation through the
root for a given domain?
it still fails even when you have installed the SEP key
for this domain?
--bill
Hi Stephane,
At work, we use a private TLD (I did not decide, don't hit me, not my
fault, I don't speak for my employer, etc), and a validating Unbound
resolver was able to use it with forward-zone.Now that the root is signed and validated, I get a SERVFAIL, probably
because the root says NXDOMAIN.Is there any way to tell Unbound to bypass the validation through the
root for a given domain?
Yes, I thought this sort of deployment could be an issue. The option:
domain-insecure: "mytld"
tells unbound that this is a non-DNSSEC domain. You can have multiple
such statements in unbound.conf. (joined with trust-anchor statements,
the longest-match name applies).
Best regards,
Wouter
a message of 16 lines which said:
it still fails even when you have installed the SEP key for
this domain?
This domain is not signed.
I had a similar problem.
Unbound knows a configuration option "domain-insecure" to work around it:
# Ignore chain of trust. Domain is treated as insecure.
# domain-insecure: "example.com"
Now, if only BIND supported the same.
Hauke.
a message of 36 lines which said:
Yes, I thought this sort of deployment could be an issue. The option:
domain-insecure: "mytld"
tells unbound that this is a non-DNSSEC domain.
Works for me. Thanks.
Wouldn't it be better to configure a key and forward statement in unbound
for that TLD (just like you would do for a non-tld) so that you can
actually run your TLD with dnssec instead of leaving it insecure?
That is using s stub-zone: with stub-prime:no and stub-addr: ?
Paul