<div dir="ltr">Hi John.<div>The reason is step 4c here: <span style="color:rgb(24,24,24);font-family:-apple-system,"system-ui","Segoe UI",Roboto,Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";font-size:13px"><a href="https://datatracker.ietf.org/doc/html/rfc1034#section-5.3.3">https://datatracker.ietf.org/doc/html/rfc1034#section-5.3.3</a></span></div><div><span style="color:rgb(24,24,24);font-family:-apple-system,"system-ui","Segoe UI",Roboto,Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";font-size:13px"><br></span></div><div><span style="color:rgb(24,24,24);font-family:-apple-system,"system-ui","Segoe UI",Roboto,Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";font-size:13px">The A record in the response is for a name that BIND wasn't asked for (otherwise why a CNAME at all?), so in the interests of not just believing random answers that might potentially poison the cache, BIND needs to check for itself, even if the resulting fetch is sent to the same forwarder.</span></div><div><span style="color:rgb(24,24,24);font-family:-apple-system,"system-ui","Segoe UI",Roboto,Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";font-size:13px"><br></span></div><div><span style="color:rgb(24,24,24);font-family:-apple-system,"system-ui","Segoe UI",Roboto,Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";font-size:13px">Your resolver somehow needs to be able to get an answer to the target of the CNAME. Not knowing your setup I can't say *how* it could do this. But possibly by forwarding that name, or a (grand)parent of that domain to another resolver that can get the answer for it?</span></div><div><span style="color:rgb(24,24,24);font-family:-apple-system,"system-ui","Segoe UI",Roboto,Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";font-size:13px"><br></span></div><div><span style="color:rgb(24,24,24);font-family:-apple-system,"system-ui","Segoe UI",Roboto,Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";font-size:13px">Hope that helps.</span></div><div><span style="color:rgb(24,24,24);font-family:-apple-system,"system-ui","Segoe UI",Roboto,Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";font-size:13px">Cheers, Greg</span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 20 Aug 2024 at 21:28, John Thurston <<a href="mailto:john.thurston@alaska.gov">john.thurston@alaska.gov</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"><u></u>
<div>
<p>We are asked to forward queries for <a href="http://foo.example.com" target="_blank">foo.example.com</a> to a set of
private resolvers. So we have something like this in our .conf</p>
<p>
</p><blockquote type="cite"><font face="monospace">zone
"<a href="http://foo.example.com" target="_blank">foo.example.com</a>" {type forward; forward only;<br>
forwarders { 10.1.2.3; 10.1.4.5; };<br>
};</font></blockquote>
<p></p>
<p>And when queried for an A-record for <font face="monospace"><a href="http://bar.foo.example.com" target="_blank">bar.foo.example.com</a></font>
(and the A-record exists), the query is forwarded, the answer is
received, cached, and returned to the customer.<br>
</p>
<p>But in the case where <font face="monospace"><a href="http://bar.foo.example.com" target="_blank">bar.foo.example.com</a></font>
is an alias to a record in some other domain (e.g. foo.baz.local),
the behavior is different.</p>
<p>With a packet capture, I can see the query being forwarded to one
of the targets (with the 'recursion desired' bit set). I can see
the reply coming back with the 'recursion available' bit set, and
the answer containing the CNAME, and the ultimate A-record. The
distant server has performed the requested recursion.<br>
</p>
<p>My recursive server does not, however, return the final A-record
to the customer. It attempts to resolve the intermediate CNAME,
and (since the CNAME is to another private domain of which I have
no knowledge) it fails. An NXDOMAIN is returned to the customer.</p>
<p>I understood the 'type forward' to be a 'hand off'. My server
would set the rd-bit, forward the query on, and accept (and
return) whatever answer was received. If I'm correctly
interpreting what I see, my server will accept whatever answer is
received but only for exactly the zone named in zone-statement.
When the answer contains an alias to some other domain, my server
hands that name back into its own recursing process.</p>
<p>Is there some way to configure BIND so it will simply pass back
to the customer whatever answer is received from the distant
resolver?</p>
<p><br>
</p>
<pre cols="72">--
--
Do things because you should, not just because you can.
John Thurston 907-465-8591
<a href="mailto:John.Thurston@alaska.gov" target="_blank">John.Thurston@alaska.gov</a>
Department of Administration
State of Alaska</pre>
</div>
-- <br>
Visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>
<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote></div>