<div dir="ltr"><div dir="ltr">I have looked into Bind's negative trust anchor implementation. Seems like in Bind, this option cannot be specified to more than 1 week. After 1 week the negative trust will be removed.<div><br></div><div><a href="https://ftp.isc.org/isc/bind/9.11.0a1/doc/arm/man.rndc.html">https://ftp.isc.org/isc/bind/9.11.0a1/doc/arm/man.rndc.html</a><br></div><div><dt style="color:rgb(0,0,0);font-family:"Times New Roman";font-size:medium"><span class="gmail-term"><strong class="gmail-userinput"><code>nta [<span class="gmail-optional">( -d | -f | -r | -l <em class="gmail-replaceable"><code>duration</code></em>)</span>] <em class="gmail-replaceable"><code>domain</code></em> [<span class="gmail-optional"><em class="gmail-replaceable"><code>view</code></em></span>]</code></strong></span></dt><dd style="color:rgb(0,0,0);font-family:"Times New Roman";font-size:medium"><p>Sets a DNSSEC negative trust anchor (NTA) for <code class="gmail-option">domain</code>, with a lifetime of <code class="gmail-option">duration</code>. The default lifetime is configured in <code class="gmail-filename">named.conf</code> via the <code class="gmail-option">nta-lifetime</code> option, and defaults to one hour. The lifetime cannot exceed one week.</p><p>A negative trust anchor selectively disables DNSSEC validation for zones that are known to be failing because of misconfiguration rather than an attack. When data to be validated is at or below an active NTA (and above any other configured trust anchors), <span class="gmail-command"><strong>named</strong></span> will abort the DNSSEC validation process and treat the data as insecure rather than bogus. This continues until the NTA's lifetime is elapsed.</p><p>NTAs persist across restarts of the <span class="gmail-command"><strong>named</strong></span> server. The NTAs for a view are saved in a file called <code class="gmail-filename"><em class="gmail-replaceable"><code>name</code></em>.nta</code>, where <em class="gmail-replaceable"><code>name</code></em> is the name of the view, or if it contains characters that are incompatible with use as a file name, a cryptographic hash generated from the name of the view.</p><p>An existing NTA can be removed by using the <code class="gmail-option">-remove</code> option.</p><p>An NTA's lifetime can be specified with the <code class="gmail-option">-lifetime</code> option. TTL-style suffixes can be used to specify the lifetime in seconds, minutes, or hours. If the specified NTA already exists, its lifetime will be updated to the new value. Setting <code class="gmail-option">lifetime</code> to zero is equivalent to <code class="gmail-option">-remove</code>.</p><p>If <code class="gmail-option">-dump</code> is used, any other arguments are ignored, and a list of existing NTAs is printed (note that this may include NTAs that are expired but have not yet been cleaned up).</p><p>Normally, <span class="gmail-command"><strong>named</strong></span> will periodically test to see whether data below an NTA can now be validated (see the <code class="gmail-option">nta-recheck</code> option in the Administrator Reference Manual for details). If data can be validated, then the NTA is regarded as no longer necessary, and will be allowed to expire early. The <code class="gmail-option">-force</code> overrides this behavior and forces an NTA to persist for its entire lifetime, regardless of whether data could be validated if the NTA were not present.</p><p>All of these options can be shortened, i.e., to <code class="gmail-option">-l</code>, <code class="gmail-option">-r</code>, <code class="gmail-option">-d</code>, and <code class="gmail-option">-f</code>.</p></dd></div><div>Is there a "correct" way of implementing this "trust" between the servers? DNSSEC keys sharing or something?</div><div><br></div><div>Thanks.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 18, 2019 at 4:35 PM Brian Candler <<a href="mailto:b.candler@pobox.com">b.candler@pobox.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 18/04/2019 09:23, abubin wrote:<br>
> However, due to DNSSEC it is not resolving the zone. It will work if I <br>
> disable DNSSEC in bind.<br>
<br>
You need to create a Negative Trust Anchor in your recursor for the <br>
domain you are forwarding.<br>
<br>
If you were using powerdns recursor, the instructions are here:<br>
<br>
<a href="https://doc.powerdns.com/recursor/settings.html#forward-zones" rel="noreferrer" target="_blank">https://doc.powerdns.com/recursor/settings.html#forward-zones</a><br>
<br>
Since you're using a bind recursor, just google for "bind negative trust <br>
anchor".<br>
<br>
</blockquote></div>