query-source and listened interfaces

[Xinyu Wang]

Should authoritative servers reply different way to each recursive
server IP?

--sometimes, yes. especially the FQDN is using CDN.

How would be served content different? Is there reason, why remote
authoritative server changes replies based on source IP?

--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.

Thanks.

Petr Menšík <pemensik at redhat.com> 于2021年7月12日周一 下午11:17写道：

> Should authoritative servers reply different way to each recursive
> server IP?
>
> I think whatever tweaks needs to be done, they should be done on
> recursive server. Whether using secondary zones or RPZ manipulation, but
> I think it should not make difference to other servers in chain.
>
> How would be served content different? Is there reason, why remote
> authoritative server changes replies based on source IP? Could it be
> moved closer to clients? Would it make sense to create just separate
> instances for separate resolver groups?
>
> It would be more clear is authoritative responded always the same way
> for everyone. Possible changes would be implemented at recursive
> resolver itself. Sharing for example RPZ rules for multiple servers if
> required.
>
> Just my 2 cents.
>
> Petr
>
> On 7/12/21 2:03 PM, Xinyu Wang wrote:
> > Hi Petr,
> >
> > Thanks for your reply.
> > I was doing this because sometimes the recursive DNS has multiple IP
> > addresses, meanwhile ECS is not supported by a recursive BIND.
> >
> > So, let's say the recursive has 2 IPs, and they are in different views on
> > the authoritative DNS of a certain domain.
> >
> > In this case, the 'query source' should be exactly the same as the IP
> which
> > is the original's destination IP , so that the corresponding query could
> > match the right view.
> >
> > Does that make sense?
> >
> > Thanks
> >
> > Petr Menšík <pemensik at redhat.com> 于2021年7月12日周一 下午5:32写道：
> >
> >> Hi Xinyu.
> >>
> >> Why would you need client-facing IP address to appear on authoritative
> >> servers? It should be more or less independent.
> >>
> >> I think it might be possible to use views and match-destination combined
> >> with query-source for each view. But it seems similar to running
> separate
> >> bind instances. I think it would have different cache anyway.
> >>
> >> Can you share why source addresses are important?
> >>
> >> Cheers,
> >>
> >> Petr
> >> On 7/8/21 9:08 AM, Xinyu Wang wrote:
> >>
> >> Hi guys,
> >>
> >> Is it possible to make a recursive BIND send queries to authorities from
> >> the interface which the original query was sent to.
> >>
> >> For instance,
> >> the recursive BIND is listening 3 interfaces, they are 1.1.1.1, 1.1.1.2,
> >> and 1.1.1.3
> >>
> >> when a  recusive query arrived at 1.1.1.1, then BIND use 1.1.1.1 to
> >> complete the recursion process.
> >>
> >> when a  recusive query arrived at 1.1.1.2, then BIND use 1.1.1.2 to
> >> complete the recursion process.
> >>
> >> when a  recusive query arrived at 1.1.1.3, then BIND use 1.1.1.3 to
> >> complete the recursion process.
> >>
> >> Hopefully I made myself clear, and looking  forward to some help.
> >> Thanks
> >>
> >>
> >>
> >> --
> >> Petr Menšík
> >> Software Engineer
> >> Red Hat, http://www.redhat.com/
> >> email: pemensik at redhat.com
> >> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
> >>
> >> _______________________________________________
> >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> >> unsubscribe from this list
> >>
> >> ISC funds the development of this software with paid support
> >> subscriptions. Contact us at https://www.isc.org/contact/ for more
> >> information.
> >>
> >>
> >> bind-users mailing list
> >> bind-users at lists.isc.org
> >> https://lists.isc.org/mailman/listinfo/bind-users
> >>
> --
> Petr Menšík
> Software Engineer
> Red Hat, http://www.redhat.com/
> email: pemensik at redhat.com
> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210713/91af386e/attachment-0001.htm>