Re: Using nsupdate in scripts
On 3/14/2022 3:11 PM, Philip Prindeville wrote: I was hoping that there's a trivial way to parse the named.conf file and figure out what it listens on for updates using a Bind utility, but I guess not... The utility 'rndc status' will return the full path of the configuration file: rndc status | grep "configuration file:" And the utility 'named-checkconf -px configfile' will print out the configuration in canonical form, from which you could grab anything you like. But if what you want isn't in the configuration file (e.g. passed as a command-line parameter, or compiled in), then named-checkconf isn't going to help. To learn those, I think you'll need to query the operating system for information about the specif process. I'd be looking at pgrep and ps, but there's probably better ways to do it. -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska -- 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: Using nsupdate in scripts
Philip Prindeville wrote: > > I'm operating on a residential ILEC that hasn't deployed IPv6, so > turning off IPv6 isn't "self-harm", it's what cyber security > professionals refer to as "reducing attack surface". Sorry, that was unkind of me, and it's a topic I should not be sarcastic about. It isn't clear to me exactly how configurable or hardcoded your script needs to be. If you know it will always run in a v4-only environment, or in either v4-only or dual-stack environments, you might as well hardcode -4 -l and you'll only need to change it if you have a v6-only deployment. -- Tony Finch(he/they) Cambridge, England Dover, Wight, Portland, Plymouth: Cyclonic 2 to 4 at first except in Plymouth, otherwise northwest 4 to 6, becoming variable 2 to 4 later. In Plymouth, rough or very rough, becoming moderate or rough, elsewhere slight or moderate. Rain at first. Good, occasionally poor at first. -- 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: Using nsupdate in scripts
> On Mar 14, 2022, at 5:11 PM, Philip Prindeville
> wrote:
>
>
>
>> On Mar 14, 2022, at 4:25 PM, Tony Finch wrote:
>>
>> Philip Prindeville wrote:
>>>
>>> But I've noticed that since I added the following to my options { }:
>>>
>>> allow-transfer { none; };
>>> dnssec-validation auto;
>>> listen-on-v6 { none; };
>>>
>>> That I get a *lot* of lines like:
>>>
>>> ; Communication with ::1#53 failed: connection refused
>>
>> "Doctor it hurts when I do this!"
>>
>> When you use `nsupdate -l` you are using a hard-coded configuration, that
>> uses a compiled-in path to the session key and fixed IPv4 and IPv6
>> localhost addresses.
>>
>> If that doesn't fit your setup then you need to adjust the command-line
>> options for `nsupdate`.
>>
>> I think for your purposes it would be best to add an environment variable
>> for the nsupdate options, so that the admin can set the variable to
>> contain different options if bare -l doesn't fit their needs. So if in
>> some fit of self-harm they have turned off IPv6, they can add -4 to the
>> variable, or they can get more creative with the -k option. (Sadly you
>> have to set the server address in the update script, not on the command
>> line.)
>
>
> I'm operating on a residential ILEC that hasn't deployed IPv6, so turning off
> IPv6 isn't "self-harm", it's what cyber security professionals refer to as
> "reducing attack surface".
>
> There's no benefit in my situation to listening on IPv6 sockets, and it only
> provides a potential exploit for hackers.
>
> There's no "admin" in my case, this is startup scripting on an embedded
> device (a firewall router).
>
> I could grep for the explicit string "listen-on-v6 { none; };" but I'd need
> to isolate that in the "options { } " section, make sure it's not commented
> out, handle multi-line and whitespace processing, handle "include"
> processing, etc.
>
> In short, it's non-trivial.
>
> I was hoping that there's a trivial way to parse the named.conf file and
> figure out what it listens on for updates using a Bind utility, but I guess
> not...
>
> -Philip
Actually, the canonicalization and include processing is handled by
"named-checkconf -px" ... though I'm not sure why it generates two spaces
between "listen-on-v6" and "{"...
The rest can be handled by a multiline PerlRE I guess.
--
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: Using nsupdate in scripts
> On Mar 14, 2022, at 4:25 PM, Tony Finch wrote:
>
> Philip Prindeville wrote:
>>
>> But I've noticed that since I added the following to my options { }:
>>
>>allow-transfer { none; };
>>dnssec-validation auto;
>>listen-on-v6 { none; };
>>
>> That I get a *lot* of lines like:
>>
>> ; Communication with ::1#53 failed: connection refused
>
> "Doctor it hurts when I do this!"
>
> When you use `nsupdate -l` you are using a hard-coded configuration, that
> uses a compiled-in path to the session key and fixed IPv4 and IPv6
> localhost addresses.
>
> If that doesn't fit your setup then you need to adjust the command-line
> options for `nsupdate`.
>
> I think for your purposes it would be best to add an environment variable
> for the nsupdate options, so that the admin can set the variable to
> contain different options if bare -l doesn't fit their needs. So if in
> some fit of self-harm they have turned off IPv6, they can add -4 to the
> variable, or they can get more creative with the -k option. (Sadly you
> have to set the server address in the update script, not on the command
> line.)
I'm operating on a residential ILEC that hasn't deployed IPv6, so turning off
IPv6 isn't "self-harm", it's what cyber security professionals refer to as
"reducing attack surface".
There's no benefit in my situation to listening on IPv6 sockets, and it only
provides a potential exploit for hackers.
There's no "admin" in my case, this is startup scripting on an embedded device
(a firewall router).
I could grep for the explicit string "listen-on-v6 { none; };" but I'd need to
isolate that in the "options { } " section, make sure it's not commented out,
handle multi-line and whitespace processing, handle "include" processing, etc.
In short, it's non-trivial.
I was hoping that there's a trivial way to parse the named.conf file and figure
out what it listens on for updates using a Bind utility, but I guess not...
-Philip
--
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: Using nsupdate in scripts
Philip Prindeville wrote:
>
> But I've noticed that since I added the following to my options { }:
>
> allow-transfer { none; };
> dnssec-validation auto;
> listen-on-v6 { none; } ;
>
> That I get a *lot* of lines like:
>
> ; Communication with ::1#53 failed: connection refused
"Doctor it hurts when I do this!"
When you use `nsupdate -l` you are using a hard-coded configuration, that
uses a compiled-in path to the session key and fixed IPv4 and IPv6
localhost addresses.
If that doesn't fit your setup then you need to adjust the command-line
options for `nsupdate`.
I think for your purposes it would be best to add an environment variable
for the nsupdate options, so that the admin can set the variable to
contain different options if bare -l doesn't fit their needs. So if in
some fit of self-harm they have turned off IPv6, they can add -4 to the
variable, or they can get more creative with the -k option. (Sadly you
have to set the server address in the update script, not on the command
line.)
--
Tony Finch(he/they) Cambridge, England
Rockall: West or southwest 7 to severe gale 9, decreasing 4 to 6
later. Very rough, becoming very rough or high. Rain or showers. Good,
occasionally poor.
--
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
Using nsupdate in scripts
Hi all,
I have some scripting that generates zone files for RFC-1918 addresses for the
DHCP static reservations when isc-dhcp starts up on OpenWRT:
https://github.com/openwrt/packages/blob/master/net/isc-dhcp/files/dhcpd.init#L551-L583
I push the single monolithic file over here:
https://github.com/openwrt/packages/blob/master/net/isc-dhcp/files/dhcpd.init#L585
But I've noticed that since I added the following to my options { }:
allow-transfer { none; };
dnssec-validation auto;
listen-on-v6 { none; } ;
That I get a *lot* of lines like:
; Communication with ::1#53 failed: connection refused
(One per RR in the monolithic file, in fact) when I run "nsupdate -l -v
$dyn_file".
If I run "nsupdate -4 -l -v $dyn_file" then all of that goes away. This will
always be a local update.
What's the cleanest/most-scriptable way to detect if I should be passing "-4"
or "-6" explicitly to "nsupdate"?
Where does nsupdate get his configuration to know what port to talk to the name
server on? Does he also use the "options" section from /etc/bind/named.conf?
Thanks,
-Philip
--
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
