Re: Correlation between NOTIFY-Source and AXFR-Source
On 3/11/23 10:43 AM, Fred Morris wrote: I've found myself in situations in the past where NOTIFY has been fetishized as "real time" "real time" can be a VERY loaded phrase. Some sometimes it's measured in fractions of a second. Other times it's measured in minutes. I've always simply considered it faster than the alternative. In this case, before the secondary would naturally get to it's refresh / retry timer. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- 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: Correlation between NOTIFY-Source and AXFR-Source
I've found myself in situations in the past where NOTIFY has been fetishized as "real time", and nobody ever ever asked which upstream server was being queried as a result. So this has been an eye-opening thread, and if I ever find myself in that situation again it'll give me something else to look at. -- Fred -- 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: Correlation between NOTIFY-Source and AXFR-Source
On 3/11/23 10:37 AM, Paul Stead wrote: Sorry I should have made it clearer that the notifier should only be shuffled to the top of the list if it is a defined primary for said zone. Okay. The try the notifier first /if/ it's a configured primary makes more sense to me. I guess I've not had enough caffeine to connect the conditional. Thank you for the assist. I.e An IP on the notify-from list, but not a configured primary wouldn't be in the list of primaries for that zone so would not be shuffled to the top of the list. ACK -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- 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: Correlation between NOTIFY-Source and AXFR-Source
Sorry I should have made it clearer that the notifier should only be shuffled to the top of the list if it is a defined primary for said zone. I.e An IP on the notify-from list, but not a configured primary wouldn't be in the list of primaries for that zone so would not be shuffled to the top of the list. Anand has done a better job at describing this function in other software than my attempts Paul On Sat, 11 Mar 2023, 17:16 Grant Taylor via bind-users, < bind-users@lists.isc.org> wrote: > Hi Paul, > > Thank you for explaining. > > On 3/10/23 12:21 AM, Paul Stead wrote: > > Imagine that 1.1.1.1 has lost network connectivity recently. A notify > > comes from 2.2.2.2 - if I understand correctly Bind will try 1.1.1.1 > > first, time out and then try 2.2.2.2 - even though we know given the > > situation that 2.2.2.2 has the latest copy of the zone we want. > > I guess what I don't understand is why it's a problem for BIND to follow > the configuration that's on the system where it's running. > > N.B. I am quite certain that I've sent notifications from a system that > wasn't a DNS server before. I don't remember if it was dig or something > else. > > I only see a loose suggestion that BIND can do a zone transfer from the > system that it received notifications from. > > I could see having a hierarchy with multiple public secondaries which > transfer from the hidden private mname as well as multiple public > tertiaries which transfer from the secondaries and configuring the > hidden private mname to send notifications to all servers. > > Perhaps the larger spirit of this thread is if that association can be > made hard or not. > > > > -- > Grant. . . . > unix || die > > -- > 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 > -- 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: Correlation between NOTIFY-Source and AXFR-Source
Hi Paul, Thank you for explaining. On 3/10/23 12:21 AM, Paul Stead wrote: Imagine that 1.1.1.1 has lost network connectivity recently. A notify comes from 2.2.2.2 - if I understand correctly Bind will try 1.1.1.1 first, time out and then try 2.2.2.2 - even though we know given the situation that 2.2.2.2 has the latest copy of the zone we want. I guess what I don't understand is why it's a problem for BIND to follow the configuration that's on the system where it's running. N.B. I am quite certain that I've sent notifications from a system that wasn't a DNS server before. I don't remember if it was dig or something else. I only see a loose suggestion that BIND can do a zone transfer from the system that it received notifications from. I could see having a hierarchy with multiple public secondaries which transfer from the hidden private mname as well as multiple public tertiaries which transfer from the secondaries and configuring the hidden private mname to send notifications to all servers. Perhaps the larger spirit of this thread is if that association can be made hard or not. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- 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
