<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I understand CDN might need a change. What I don't understand is
why single recursive cache somewhere in the middle chain should
serve different names to its clients. <br>
</p>
<div class="moz-cite-prefix">On 7/13/21 8:19 AM, Xinyu Wang wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CA+bNcJJDZBup8JTXA8=Y4Q+x4YMZJLB4ZJDca2YgWi26_Pzoiw@mail.gmail.com">
<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>
</blockquote>
<p>Sure, caching is vital. For most CDN usages all records are more
or less equivalent. For any resolver close to authoritative server
it should not matter what view/region it were chosen from. It
should just deliver IP which is close by network topology.<br>
</p>
<p>I do not understand, why should it propagate that differences
even to intermediate caching server. Why should server in the
middle deliver different results to its clients? Almost all normal
resolvers will not behave this way and just ask once, cache it and
deliver the same content to all its clients. No matter what source
they were from. This scenario has to be supported. Configuring all
caches on the way is hard.</p>
<p>I would prefer using separate caches for networks which need
different results. It would be easier to debug later.</p>
<p><font face="monospace">Your design:<br>
+-------+ A +--------+ +---------+<br>
|auth +------+ cache +-----+ client1 |<br>
| | | | +---------+<br>
| +------+ | +---------+<br>
| | B | +-----+ client2 |<br>
+-------+ +--------+ +---------+<br>
</font></p>
<p><font face="monospace">My expectation:<br>
</font><font face="monospace">+-------+ A +--------+
+---------+<br>
|auth +------+ cache1 +-----+ client1 |<br>
| | +--------+ +---------+<br>
| | +--------+ +---------+<br>
| +------+ cache2 +-----+ client2 |<br>
+-------+ B +--------+ +---------+<br>
</font></p>
<p>Why are your clients sharing the same resolver, when it has to
deliver different results based on their source? Is it required?
Should they share common cache except few specific domains? Your
request would still result in more or less my expectation, just it
would be virtual inside of bind. I am just interested why was this
solution chosed. It seems more complicated to me.<br>
</p>
<blockquote type="cite"
cite="mid:CA+bNcJJDZBup8JTXA8=Y4Q+x4YMZJLB4ZJDca2YgWi26_Pzoiw@mail.gmail.com">
<div dir="ltr">
<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" moz-do-not-send="true">pemensik@redhat.com</a>>
于2021年7月12日周一 下午11:17写道：<br>
</div>
<blockquote class="gmail_quote">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" moz-do-not-send="true">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" moz-do-not-send="true">http://www.redhat.com/</a><br>
>> email: <a href="mailto:pemensik@redhat.com"
target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">bind-users@lists.isc.org</a><br>
>> <a
href="https://lists.isc.org/mailman/listinfo/bind-users"
rel="noreferrer" target="_blank" moz-do-not-send="true">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" moz-do-not-send="true">http://www.redhat.com/</a><br>
email: <a href="mailto:pemensik@redhat.com" target="_blank"
moz-do-not-send="true">pemensik@redhat.com</a><br>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB<br>
<br>
<br>
</blockquote>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
Petr Menšík
Software Engineer
Red Hat, <a class="moz-txt-link-freetext" href="http://www.redhat.com/">http://www.redhat.com/</a>
email: <a class="moz-txt-link-abbreviated" href="mailto:pemensik@redhat.com">pemensik@redhat.com</a>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB</pre>
</body>
</html>