query-source and listened interfaces
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 ___ 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
query-source and listened interfaces
Hi Xinyu, What matters is the kernel routing table for the addresses of the remote servers. The query source address can specified by config, but the kernel will choose which interface to use. Maybe you can put each interface into their own routing table? How to do this is OS dependent, though. Patrick ___ 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: query-source and listened interfaces
No. If you want to do that then you will need to run 3 instances. > On 8 Jul 2021, at 17:08, 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 > ___ > 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@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: query-source and listened interfaces
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: pemen...@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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: query-source and listened interfaces
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 于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: pemen...@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@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > ___ 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: query-source and listened interfaces
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 于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: pemen...@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@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users >> -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: query-source and listened interfaces
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 于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 于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: pemen...@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@lists.isc.org > >> https://lists.isc.org/mailman/listinfo/bind-users > >> > -- > Petr Menšík > Software Engineer > Red Hat, http://www.redhat.com/ > email: pemen...@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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: query-source and listened interfaces
[ Classification Level: GENERAL BUSINESS ] I've done the match-destinations/query-source thing before, but in addition to that, it should theoretically be possible to also use a shared cache between the views, via attach-cache. I've never played with that directive myself, however. - Kevin On Mon, Jul 12, 2021 at 5:32 AM Petr Menšík wrote: > 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: pemen...@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@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > ___ 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: query-source and listened interfaces
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 mailto:pemen...@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 mailto:pemen...@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. > >>
