Problems with interfaces going down

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Problems with interfaces going down

bindusers
Greetings,

I’ve been fighting a two-fold problem with named (bind 9.16.11) running on macOS.

1: If an ethernet interface being listened to drops link, named immediately stops listening to it:

12-Feb-2021 17:33:19.326 no longer listening on 192.168.88.220#53

and

2: when link returns I get 2 tries to reestablish listening:

12-Feb-2021 17:33:39.458 listening on IPv4 interface en1, 192.168.88.220#53
12-Feb-2021 17:33:39.463 creating IPv4 interface en1 failed; interface ignored
12-Feb-2021 17:33:41.946 listening on IPv4 interface en1, 192.168.88.220#53
12-Feb-2021 17:33:41.951 creating IPv4 interface en1 failed; interface ignored

which both fail because named is no longer running as root.

--------------

Where I’m confused is that this ISC KB article:

https://kb.isc.org/docs/aa-00420

seems to imply that the "no longer listening" event is due to a periodic interface scan finding the interface "unavailable".

That doesn’t fit my observations since it happens as soon as link is lost. If some minutes-long periodic scan were needed to detect the interface being down it would take, on average, half of that period to happen. It does not.

Further, I tried what the KB article advised by adding the option:

        interface-interval 0;

That does seem to stop the periodic scan (since my log is no longer filled with errors) but the “no longer listening” event still occurs right when the interface drops.

--------------

Is it not possible to have named drop to a non-root user (via -u) but still recover from (or ride through) a momentary ethernet link loss?

Having the server stop working due to a switch I have no control over burping is very suboptimal.

Thanks for any ideas.

-Mike

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Problems with interfaces going down

Mark Andrews


> On 13 Feb 2021, at 10:33, [hidden email] wrote:
>
> Greetings,
>
> I’ve been fighting a two-fold problem with named (bind 9.16.11) running on macOS.
>
> 1: If an ethernet interface being listened to drops link, named immediately stops listening to it:
>
> 12-Feb-2021 17:33:19.326 no longer listening on 192.168.88.220#53
>
> and
>
> 2: when link returns I get 2 tries to reestablish listening:
>
> 12-Feb-2021 17:33:39.458 listening on IPv4 interface en1, 192.168.88.220#53
> 12-Feb-2021 17:33:39.463 creating IPv4 interface en1 failed; interface ignored
> 12-Feb-2021 17:33:41.946 listening on IPv4 interface en1, 192.168.88.220#53
> 12-Feb-2021 17:33:41.951 creating IPv4 interface en1 failed; interface ignored
>
> which both fail because named is no longer running as root.
>
> --------------
>
> Where I’m confused is that this ISC KB article:
>
> https://kb.isc.org/docs/aa-00420
>
> seems to imply that the "no longer listening" event is due to a periodic interface scan finding the interface "unavailable".
>
> That doesn’t fit my observations since it happens as soon as link is lost. If some minutes-long periodic scan were needed to detect the interface being down it would take, on average, half of that period to happen. It does not.
>
> Further, I tried what the KB article advised by adding the option:
>
> interface-interval 0;
>
> That does seem to stop the periodic scan (since my log is no longer filled with errors) but the “no longer listening” event still occurs right when the interface drops.

``automatic-interface-scan``
   If ``yes`` and supported by the operating system, this automatically rescans
   network interfaces when the interface addresses are added or removed.  The
   default is ``yes``.  This configuration option does not affect the time-based
   ``interface-interval`` option; it is recommended to set the time-based
   ``interface-interval`` to 0 when the operator confirms that automatic
   interface scanning is supported by the operating system.

   The ``automatic-interface-scan`` implementation uses routing sockets for the
   network interface discovery; therefore, the operating system must
   support the routing sockets for this feature to work.

> --------------
>
> Is it not possible to have named drop to a non-root user (via -u) but still recover from (or ride through) a momentary ethernet link loss?

If you allow euid switching then you may as well not run with -u as the whole point of -u is
to be a safeguard in the case where there is a program flaw that allows arbitrary execution
to occur.

> Having the server stop working due to a switch I have no control over burping is very suboptimal.
>
> Thanks for any ideas.
>
> -Mike
>
> _______________________________________________
> 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
> [hidden email]
> 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: [hidden email]

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Problems with interfaces going down

Bind-Users forum mailing list
In reply to this post by bindusers
Would it be possible to use a virtual interface from within bind/named that gets mapped by some privileged facility to a hardware interface? (This is the sort of thing that VMs have to do all the time.) For example, could a brctl bridge help?

Or maybe CAP_NET_BIND_SERVICE would allow the interface to be reactivated (if it's a privileged port issue).

Just brainstorming.

Paul


On Fri, 12 Feb 2021 18:33:21 -0500
[hidden email] wrote:

> Greetings,
>
> I’ve been fighting a two-fold problem with named (bind 9.16.11) running on macOS.
>
> 1: If an ethernet interface being listened to drops link, named immediately stops listening to it:
>
> 12-Feb-2021 17:33:19.326 no longer listening on 192.168.88.220#53
>
> and
>
> 2: when link returns I get 2 tries to reestablish listening:
>
> 12-Feb-2021 17:33:39.458 listening on IPv4 interface en1, 192.168.88.220#53
> 12-Feb-2021 17:33:39.463 creating IPv4 interface en1 failed; interface ignored
> 12-Feb-2021 17:33:41.946 listening on IPv4 interface en1, 192.168.88.220#53
> 12-Feb-2021 17:33:41.951 creating IPv4 interface en1 failed; interface ignored
>
> which both fail because named is no longer running as root.
>
> --------------
>
> Where I’m confused is that this ISC KB article:
>
> https://kb.isc.org/docs/aa-00420
>
> seems to imply that the "no longer listening" event is due to a periodic interface scan finding the interface "unavailable".
>
> That doesn’t fit my observations since it happens as soon as link is lost. If some minutes-long periodic scan were needed to detect the interface being down it would take, on average, half of that period to happen. It does not.
>
> Further, I tried what the KB article advised by adding the option:
>
> interface-interval 0;
>
> That does seem to stop the periodic scan (since my log is no longer filled with errors) but the “no longer listening” event still occurs right when the interface drops.
>
> --------------
>
> Is it not possible to have named drop to a non-root user (via -u) but still recover from (or ride through) a momentary ethernet link loss?
>
> Having the server stop working due to a switch I have no control over burping is very suboptimal.
>
> Thanks for any ideas.
>
>
_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Problems with interfaces going down

Mark Andrews
Linux already uses capabilities so it doesn’t have this issue.

FreeBSD there are sysctl settings to allow specific non-root users to bind to specify addresses.

> On 15 Feb 2021, at 15:26, Paul Kosinski via bind-users <[hidden email]> wrote:
>
> Would it be possible to use a virtual interface from within bind/named that gets mapped by some privileged facility to a hardware interface? (This is the sort of thing that VMs have to do all the time.) For example, could a brctl bridge help?
>
> Or maybe CAP_NET_BIND_SERVICE would allow the interface to be reactivated (if it's a privileged port issue).
>
> Just brainstorming.
>
> Paul
>
>
> On Fri, 12 Feb 2021 18:33:21 -0500
> [hidden email] wrote:
>
>> Greetings,
>>
>> I’ve been fighting a two-fold problem with named (bind 9.16.11) running on macOS.
>>
>> 1: If an ethernet interface being listened to drops link, named immediately stops listening to it:
>>
>> 12-Feb-2021 17:33:19.326 no longer listening on 192.168.88.220#53
>>
>> and
>>
>> 2: when link returns I get 2 tries to reestablish listening:
>>
>> 12-Feb-2021 17:33:39.458 listening on IPv4 interface en1, 192.168.88.220#53
>> 12-Feb-2021 17:33:39.463 creating IPv4 interface en1 failed; interface ignored
>> 12-Feb-2021 17:33:41.946 listening on IPv4 interface en1, 192.168.88.220#53
>> 12-Feb-2021 17:33:41.951 creating IPv4 interface en1 failed; interface ignored
>>
>> which both fail because named is no longer running as root.
>>
>> --------------
>>
>> Where I’m confused is that this ISC KB article:
>>
>> https://kb.isc.org/docs/aa-00420
>>
>> seems to imply that the "no longer listening" event is due to a periodic interface scan finding the interface "unavailable".
>>
>> That doesn’t fit my observations since it happens as soon as link is lost. If some minutes-long periodic scan were needed to detect the interface being down it would take, on average, half of that period to happen. It does not.
>>
>> Further, I tried what the KB article advised by adding the option:
>>
>> interface-interval 0;
>>
>> That does seem to stop the periodic scan (since my log is no longer filled with errors) but the “no longer listening” event still occurs right when the interface drops.
>>
>> --------------
>>
>> Is it not possible to have named drop to a non-root user (via -u) but still recover from (or ride through) a momentary ethernet link loss?
>>
>> Having the server stop working due to a switch I have no control over burping is very suboptimal.
>>
>> Thanks for any ideas.
>>
>>
> _______________________________________________
> 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
> [hidden email]
> 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: [hidden email]

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users