query-source and listened interfaces
Petr Menšík
pemensik at redhat.com
Wed Jul 21 21:12:43 UTC 2021
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.
On 7/13/21 8:19 AM, Xinyu Wang wrote:
> 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.
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.
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.
I would prefer using separate caches for networks which need different
results. It would be easier to debug later.
Your design:
+-------+ A +--------+ +---------+
|auth +------+ cache +-----+ client1 |
| | | | +---------+
| +------+ | +---------+
| | B | +-----+ client2 |
+-------+ +--------+ +---------+
My expectation:
+-------+ A +--------+ +---------+
|auth +------+ cache1 +-----+ client1 |
| | +--------+ +---------+
| | +--------+ +---------+
| +------+ cache2 +-----+ client2 |
+-------+ B +--------+ +---------+
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.
>
> Thanks.
>
> Petr Menšík <pemensik at redhat.com <mailto: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 <mailto: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/ <http://www.redhat.com/>
> >> email: pemensik at redhat.com <mailto:pemensik at redhat.com>
> >> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
> >>
> >> _______________________________________________
> >> Please visit https://lists.isc.org/mailman/listinfo/bind-users
> <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/
> <https://www.isc.org/contact/> for more
> >> information.
> >>
> >>
> >> bind-users mailing list
> >> bind-users at lists.isc.org <mailto:bind-users at lists.isc.org>
> >> https://lists.isc.org/mailman/listinfo/bind-users
> <https://lists.isc.org/mailman/listinfo/bind-users>
> >>
> --
> Petr Menšík
> Software Engineer
> Red Hat, http://www.redhat.com/ <http://www.redhat.com/>
> email: pemensik at redhat.com <mailto:pemensik at redhat.com>
> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
>
>
--
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/20210721/8a285164/attachment-0001.htm>
More information about the bind-users
mailing list