[stork-users] Stork agent cannot connect through rndc

Mik J mikydevel at yahoo.fr
Mon Sep 2 15:34:24 UTC 2024


Thank you Slawek for your work and your additional tests.
And also for the explanations.

Have a nice day.




Le lundi 2 septembre 2024 à 11:11:47 UTC+2, Slawek Figiel <slawek at isc.org> a écrit : 





Hello Mik!

I analyzed the problem and I confirm that it exists. Thank you for your 
report and patience.

The problem is Stork doesn't directly read the `named.conf` 
configuration file. Instead of it, we read the `named-checkconf` command 
output. It seems `named-checkconf` resolves the wildcard to the 
`0.0.0.0` address and replaces it in the output configuration.
But Stork expects the asterisk. Any other address is used as-is. 
Unfortunately, the `0.0.0.0` address is not a valid address to send 
requests (it isn't an alias to `localhost`).

I opened https://gitlab.isc.org/isc-projects/stork/-/issues/1495 to 
solve the problem.

Regards,
Slawek Figiel

On 29/08/2024 16:37, Mik J wrote:
> Hello Slawek,
> 
> I think there's a misunderstanding, I'm not asking any help about how to configure bind.
> 
> I'm telling you that Stork doesn't work as it should be.
> 
> Just taking my first example
> inet 127.0.0.1 port 953 allow { "rndc-users"; }; <= works
> inet * port 953 allow { "rndc-users"; }; <= doesn't work
> 
> I totally understand that I could be wrong in life in general.
> But what I see is what I see, I replace 127.0.0.1 by * and I have this message
> ERRO[2024-08-29 16:09:14]            agent.go:311   Failed to forward commands to rndc            Address="0.0.0.0" Port="953" error="exit status 1"
> 
> The documentation is here
> https://bind9.readthedocs.io/en/stable/reference.html
> And it says
> "An ip_address of * (asterisk) is interpreted as the IPv4 wildcard address; connections are accepted on any of the system’s IPv4 addresses."
> 
> On my server these commands work
> # rndc -b 127.0.0.1 -s 127.0.0.1 -p 953 status
> # rndc -b 100.64.1.2 -s 100.64.1.2 -p 953 status
> 
> Conclusion:
> - Bind works as expected
> - Stork doesn't work as expected with *. Did you test it ?
> 
> And once again, I may have missed something but to me there's a problem here.
> 
> Regards
> 
> 
> Le jeudi 29 août 2024 à 13:02:31 UTC+2, Slawek Figiel <slawek at isc.org> a écrit :
> 
> 
> 
> 
> 
> Hello Mik!
> 
> The Stork agent matches the first "inet" clause occurrence in the
> "controls" node. Stork supports the "*" asterisk as an address. In this
> case, the Stork agent will establish a connection to the "localhost"
> (not 127.0.0.1) address.
> 
> The best place for questions about the BIND 9 configuration is the BIND
> 9 mailing list: bind-users at lists.isc.org
> (https://lists.isc.org/mailman/listinfo/bind-users).
> 
> I think the BIND 9 community will explain in detail how the listening on
> the control endpoint works in this application.
> 
> You can also consult the BIND 9 ARM available on:
> https://bind9.readthedocs.io/en/latest/ .
> 
> Regards
> Slawek Figiel
> 
> On 29/08/2024 00:55, Mik J wrote:
>> Hello again Slawek,
>>
>> After a lot of research I started to find what's going wrong. There are two things
>>
>> Like this it's working
>> acl "rndc-users" { 127.0.0.1/32; 100.64.1.0/24; };
>> controls {
>>            inet 127.0.0.1 port 953 allow { "rndc-users"; };
>>
>> a) But like that it's not working (127.0.0.1 is replaced by *)
>> acl "rndc-users" { 127.0.0.1/32; 100.64.1.0/24; };
>> controls {
>>            inet * port 953 allow { "rndc-users"; };
>>
>> So is there a problem with listening on all interfaces ?
>>
>>
>> b) And like that it's not working as well
>> acl "rndc-users" { 127.0.0.1/32; 100.64.1.0/24; };
>> key "rndc-remote" { algorithm hmac-sha256; secret "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"; };
>> controls {
>>            inet 127.0.0.1 port 953 allow { "rndc-users"; } keys {"rndc-remote";};
>> This time keys {"rndc-remote";} is added
>>
>> Regards
>>
>>
>>
>> Le mercredi 28 août 2024 à 15:07:18 UTC+2, Slawek Figiel <slawek at isc.org> a écrit :
>>
>>
>>
>>
>>
>> Mik,
>>
>> you can find the BIND 9 configuration used by the Stork project in the
>> docker/config/agent-bind9 (demo) and tests/system/config/bind (system
>> tests) directories.
>>
>>
>> If you use BIND 9 chroot, you need to use both flags:
>> `named-checkconf -t /var/named -p /etc/named.conf`.
>> Please check if you use the `-t` flag when you start the BIND 9 process
>> and use the same value.
>>
>> Please call the above command as a Stork agent user. It would be best to
>> switch to it using the `sudo su stork-agent-user` command.
>>
>> There may be more files referenced in the named.conf file. Stork agent
>> user must have an access to all of them. Please, check also if the Stork
>> agent user has permissions to execute the `named-checkconf` binary.
>>
>> Regards,
>> Slawek Figiel
>>
>> On 28/08/2024 14:59, Mik J wrote:
>>> Hello Slawek,
>>>
>>> When I do
>>> # named-checkconf -t /var/named/
>>> I don't have any output
>>>
>>> But when I do
>>> # named-checkconf -p /var/named/etc/named.conf
>>> I have an output that corresponds more or less to named.conf
>>>
>>> Could you show me an example of your named.conf configuration (regarding rndc key) and /etc/rndc.key and/or /etc/rndc.conf
>>>
>>> Because both commands work
>>> # rndc -b 127.0.0.1 -s 127.0.0.1 -p 953 -k /etc/rndc.key status
>>> # rndc -b 127.0.0.1 -s 127.0.0.1 -p 953 -c /etc/rndc.conf status
>>>
>>> And the files are world readable (at the moment)
>>> # ls -l /etc/rndc.key
>>> -rw-r--r--  1 root  _bind  100 Aug 28 14:22 /etc/rndc.key
>>> # ls -l /etc/rndc.conf
>>> -rw-r--r--  1 root  wheel  411 Aug 28 14:23 /etc/rndc.conf
>>> # ls -l /var/named/etc/named.conf
>>> -rwxr--r--  1 root  _bind  13534 Aug 16 11:26 /var/named/etc/named.conf
>>>
>>> I really don't understand what could go wrong
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Le mercredi 28 août 2024 à 13:42:48 UTC+2, Slawek Figiel <slawek at isc.org> a écrit :
>>>
>>>
>>>
>>>
>>>
>>> Hello Mik!
>>>
>>> The "named-checkconf" call is constructed in
>>> backend/agent/bind9.go:569-577 :
>>>
>>>          // Prepare named-checkconf arguments.
>>>          args := []string{}
>>>          if rootPrefix != "" {
>>>              args = append(args, "-t", rootPrefix)
>>>          }
>>>          // The config path must be last.
>>>          args = append(args, "-p", bind9ConfPath)
>>>
>>>          out, err := executor.Output(namedCheckconfPath, args...)
>>>
>>> So, we provide the BIND 9 configuration path via "-p" flag and path to
>>> the BIND 9 chroot via the "-t" flag (if applicable).
>>>
>>> Regards,
>>> Slawek Figiel
>>>
>>>
>>> On 28/08/2024 00:26, Mik J wrote:
>>>> Hello Slawek,
>>>>
>>>> I did
>>>> # named-checkconf
>>>> open: /etc/named.conf: file not found
>>>>
>>>> So I made a symbolic link
>>>> # ln -s /var/named/etc/named.conf /etc/named.conf
>>>> And ran again the command
>>>> # named-checkconf
>>>>
>>>> However no improvement.
>>>>
>>>> Which option is used along with named-checkconf because when I run it I don't see anything, it's silent.
>>>>
>>>>
>>>> At the moment I launch the stork agent as root so there shouldn't be file permission problems.
>>>>
>>>> # ls -l /etc/rndc.key
>>>> -rw-r--r--  1 root  _bind  100 May 11 00:29 /etc/rndc.key
>>>> The permissions are not so good but I'll change them
>>>>
>>>> I don't have any file specified in my named.conf except:
>>>> - Log files: for example
>>>> channel queries_errors_file {
>>>>                file "/var/log/query-errors.log" versions 3 size 5m;
>>>>
>>>> - or zone files
>>>> zone "127.in-addr.arpa" {
>>>>            type master;
>>>>            file "/master/reverse/loopback";
>>>>            allow-transfer { localhost; };
>>>> };
>>>>
>>>> I'm not sure my configuration is involved in this issue, maybe that's because I'm using Openbsd 7.5 and it has something specific.
>>>>
>>>> Regards
>>>>
>>>>
>>>>
>>>> Le lundi 26 août 2024 à 11:51:46 UTC+2, Slawek Figiel <slawek at isc.org> a écrit :
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Hello Mik!
>>>>
>>>> Please check if your Stork agent user has rights to read the
>>>> "named.conf" and "rndc.key" files and any other files referenced in
>>>> "named.conf".
>>>>
>>>>> Also I see that the stork agent tries to connect to 127.0.0.1 using
>>>> rndc but I haven't specified the stork agent to use this adress
>>>> (although that's the one I want)
>>>>> But, in general, how is the stork agent supposed to find the DNS
>>>> server adress and port ?
>>>>
>>>> Stork uses "named-checkconf" to read the BIND 9 configuration and
>>>> extracts the RNDC address and port from it.
>>>>
>>>> I'm waiting for your feedback.
>>>> Regards
>>>> Slawek
>>>>
>>>> On 16/08/2024 11:24, Mik J wrote:
>>>>> Stork: 1.18.0
>>>>> OS: Openbsd 7.5
>>>>>
>>>>> Hello,
>>>>>
>>>>> I made my stork agent to be installed on one of my DNS.
>>>>>
>>>>> However I get this message
>>>>> INFO[2024-08-16 11:00:46]            bind9.go:560   Found BIND 9 config file in /var/named/etc/named.conf based on output of `named -V`.
>>>>> ERRO[2024-08-16 11:00:49]            agent.go:311   Failed to forward commands to rndc            Address="127.0.0.1" Port="953" error="exit status 1"
>>>>>
>>>>>
>>>>> If I run the command manually, it works
>>>>> # rndc -b 127.0.0.1 -s 127.0.0.1 -p 953 -k /etc/rndc.key status
>>>>> version: BIND 9.18.28 (Extended Support Version) <id:f77fadb> ()
>>>>> running on localhost: OpenBSD amd64 7.5 GENERIC.MP#82
>>>>> boot time: Fri, 16 Aug 2024 02:07:05 GMT
>>>>> last configured: Fri, 16 Aug 2024 02:07:05 GMT
>>>>> configuration file: /etc/named.conf (/var/named/etc/named.conf)
>>>>> ...
>>>>>
>>>>> How to debug this problem ?
>>>>>
>>>>> - How does stork knows what is the rndc.key, does it read it in named.conf or should it read /etc/rndc.key
>>>>> - If it reads /etc/rndc.key, how does it know where to find this file ?
>>>>>
>>>>>
>>>>> Also I see that the stork agent tries to connect to 127.0.0.1 using rndc but I haven't specified the stork agent to use this adress (although that's the one I want)
>>>>> But, in general, how is the stork agent supposed to find the DNS server adress and port ?
>>>>>
>>>>> Regards
>>
>>>>
>>>>>
>>>>>


More information about the Stork-users mailing list