Re: Limit actions on control channel?

2021-06-18 Thread Paul Kosinski via bind-users
It ought to be possible to write a front-end to listen on the standard control 
channel and only forward (properly-keyed) 'status' requests to the "real" port 
that BIND listens to. 

>From looking at the RNDC exchange via Wireshark however, you'd have to adapt 
>some of BIND's code that does the encryption / key-signing of RNDC requests. 
>Still, for us users, that might be safer -- and more update resistant -- than 
>modifying BIND itself.


On Thu, 17 Jun 2021 11:48:36 -0800
John Thurston  wrote:

> I see I can define (using the 'controls' statement) a 'read-only' inet 
> channel. I suspect I could define a couple of channels on the same 
> address if I put them on different ports. Is there a way to define a 
> single 'read-write' channel, and then limit certain keys to read-only 
> access on it?
> 
> Here's the scenario:
> 
> I'd like to have a single control channel listening (on port 953, for 
> example). I'd like to say the key named "foo" can do lots of things, but 
> the key named "bar" can only submit a "status" message. This would let 
> our monitoring application ask for "status" without also letting it ask 
> for "reload" or "flushname".
> 
___
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


Limit actions on control channel?

2021-06-17 Thread John Thurston
I see I can define (using the 'controls' statement) a 'read-only' inet 
channel. I suspect I could define a couple of channels on the same 
address if I put them on different ports. Is there a way to define a 
single 'read-write' channel, and then limit certain keys to read-only 
access on it?


Here's the scenario:

I'd like to have a single control channel listening (on port 953, for 
example). I'd like to say the key named "foo" can do lots of things, but 
the key named "bar" can only submit a "status" message. This would let 
our monitoring application ask for "status" without also letting it ask 
for "reload" or "flushname".


--
--
Do things because you should, not just because you can.

John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
___
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