<div dir="ltr">Should authoritative servers reply different way to each recursive<br>server IP?<br><div><br></div><div>--sometimes, yes. especially the FQDN is using CDN.</div><div><br></div><div>How would be served content different? Is there reason, why remote<br>authoritative server changes replies based on source IP?<br></div><div><br></div><div>--again, I'll explain this based on CDN cases. There might be tons of cache nodes in a delivery network. The authority chooses the 'best' one by identifying the end-users location. Most of CDN traffic are dispatched by doing this, and the source IP tells the authority where an end-user comes from.</div><div><br></div><div>Thanks. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Petr Menšík <<a href="mailto:pemensik@redhat.com">pemensik@redhat.com</a>> 于2021年7月12日周一 下午11:17写道：<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Should authoritative servers reply different way to each recursive<br>
server IP?<br>
<br>
I think whatever tweaks needs to be done, they should be done on<br>
recursive server. Whether using secondary zones or RPZ manipulation, but<br>
I think it should not make difference to other servers in chain.<br>
<br>
How would be served content different? Is there reason, why remote<br>
authoritative server changes replies based on source IP? Could it be<br>
moved closer to clients? Would it make sense to create just separate<br>
instances for separate resolver groups?<br>
<br>
It would be more clear is authoritative responded always the same way<br>
for everyone. Possible changes would be implemented at recursive<br>
resolver itself. Sharing for example RPZ rules for multiple servers if<br>
required.<br>
<br>
Just my 2 cents.<br>
<br>
Petr<br>
<br>
On 7/12/21 2:03 PM, Xinyu Wang wrote:<br>
> Hi Petr,<br>
><br>
> Thanks for your reply.<br>
> I was doing this because sometimes the recursive DNS has multiple IP<br>
> addresses, meanwhile ECS is not supported by a recursive BIND.<br>
><br>
> So, let's say the recursive has 2 IPs, and they are in different views on<br>
> the authoritative DNS of a certain domain.<br>
><br>
> In this case, the 'query source' should be exactly the same as the IP which<br>
> is the original's destination IP , so that the corresponding query could<br>
> match the right view.<br>
><br>
> Does that make sense?<br>
><br>
> Thanks<br>
><br>
> Petr Menšík <<a href="mailto:pemensik@redhat.com" target="_blank">pemensik@redhat.com</a>> 于2021年7月12日周一 下午5:32写道：<br>
><br>
>> Hi Xinyu.<br>
>><br>
>> Why would you need client-facing IP address to appear on authoritative<br>
>> servers? It should be more or less independent.<br>
>><br>
>> I think it might be possible to use views and match-destination combined<br>
>> with query-source for each view. But it seems similar to running separate<br>
>> bind instances. I think it would have different cache anyway.<br>
>><br>
>> Can you share why source addresses are important?<br>
>><br>
>> Cheers,<br>
>><br>
>> Petr<br>
>> On 7/8/21 9:08 AM, Xinyu Wang wrote:<br>
>><br>
>> Hi guys,<br>
>><br>
>> Is it possible to make a recursive BIND send queries to authorities from<br>
>> the interface which the original query was sent to.<br>
>><br>
>> For instance,<br>
>> the recursive BIND is listening 3 interfaces, they are 1.1.1.1, 1.1.1.2,<br>
>> and 1.1.1.3<br>
>><br>
>> when a  recusive query arrived at 1.1.1.1, then BIND use 1.1.1.1 to<br>
>> complete the recursion process.<br>
>><br>
>> when a  recusive query arrived at 1.1.1.2, then BIND use 1.1.1.2 to<br>
>> complete the recursion process.<br>
>><br>
>> when a  recusive query arrived at 1.1.1.3, then BIND use 1.1.1.3 to<br>
>> complete the recursion process.<br>
>><br>
>> Hopefully I made myself clear, and looking  forward to some help.<br>
>> Thanks<br>
>><br>
>><br>
>><br>
>> --<br>
>> Petr Menšík<br>
>> Software Engineer<br>
>> Red Hat, <a href="http://www.redhat.com/" rel="noreferrer" target="_blank">http://www.redhat.com/</a><br>
>> email: <a href="mailto:pemensik@redhat.com" target="_blank">pemensik@redhat.com</a><br>
>> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB<br>
>><br>
>> _______________________________________________<br>
>> Please 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<br>
>> unsubscribe from this list<br>
>><br>
>> ISC funds the development of this software with paid support<br>
>> subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> for more<br>
>> 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>
>><br>
-- <br>
Petr Menšík<br>
Software Engineer<br>
Red Hat, <a href="http://www.redhat.com/" rel="noreferrer" target="_blank">http://www.redhat.com/</a><br>
email: <a href="mailto:pemensik@redhat.com" target="_blank">pemensik@redhat.com</a><br>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB<br>
<br>
<br>
</blockquote></div>