Feature Request: Redesign zone update access control

[noseshimself]

The current method of defining keys in one place and permitting zone updates by keys from a list, addresses coming from a list of addresses unrelated to keys and permitted patterns without a wildcard meaning "anything" is not the best possible solution (and not working for our use case at all).

1) If you want to restrict keys to source addresses, the address(es) should be assigned to the key, not per domain. In the worst case you have to find all domains modifiable by a certain key (how?) and change them one by one.

2) If you want to be compatible with BIND/nsupdate you have to permit updates without using keys -- which is not permitting adding the source address 0.0.0.0/0 to disable address checks for keys.

3) There is no wildcard meaning "any character including dots" for the ACL pattern which makes it necessary to add the same keys multiple times with different ACL patterns (e.g. for adding "node" together with "_acme-challenge.node"). Annoying.

What is a client on a mobile system supposed to do if it wants to update a zone every time its address is changing? It's simple with BIND (just add the key) but seemingly impossible here. If this can't be solved we will probably have to run a BIND in tandem just for dynamic zone updates.

[ShreyasZare]

Thanks for the feedback. Please let me know the exact use-case you have so that I can understand this issue better.

The current method of defining keys in one place and permitting zone updates by keys from a list, addresses coming from a list of addresses unrelated to keys and permitted patterns without a wildcard meaning "anything" is not the best possible solution (and not working for our use case at all).

The current usage is similar to how it is configured BIND. From my understanding and as per the docs here, BIND too does not have TSIG keys tied to any IP address.

Also there is provision for wildcard already as discussed here.

If you want to restrict keys to source addresses, the address(es) should be assigned to the key, not per domain. In the worst case you have to find all domains modifiable by a certain key (how?) and change them one by one.

I am not sure what is the advantage of having a key restricted to an IP address. This is especially when IP addresses is prone to spoofing as Dynamic Updates also accepts UDP requests.

If you want to be compatible with BIND/nsupdate you have to permit updates without using keys -- which is not permitting adding the source address 0.0.0.0/0 to disable address checks for keys.

If you do not specify any security policy then the access is based only on IP address restrictions if configured. So, its already possible to do that without using keys.

There is no wildcard meaning "any character including dots" for the ACL pattern which makes it necessary to add the same keys multiple times with different ACL patterns (e.g. for adding "node" together with "_acme-challenge.node"). Annoying.

There is wildcard support as discussed here. The wildcards in DNS are not same as used in filesystem or regex. The *.example.com wildcard maps all subdomain names which is exactly how wildcard records in DNS work.

The current UI requires entering the full domain name. This can be updated so that only the subdomain part can be entered. But, the current UI design was chosen explicitly to avoid confusion caused when * is used as the subdomain which can cause the user to think that it applies to the domain as well as the subdomain names. This confusion is avoided when full domain name is required to be entered.

What is a client on a mobile system supposed to do if it wants to update a zone every time its address is changing? It's simple with BIND (just add the key) but seemingly impossible here. If this can't be solved we will probably have to run a BIND in tandem just for dynamic zone updates.

Please elaborate this in detail. TSIG is not linked with client IP address so client's IP address changing frequently is not going to have any effect. How is the setup any different from BIND?

[noseshimself]

Thanks for the feedback. Please let me know the exact use-case you have so that I can understand this issue better.

The current method of defining keys in one place and permitting zone updates by keys from a list, addresses coming from a list of addresses unrelated to keys and permitted patterns without a wildcard meaning "anything" is not the best possible solution (and not working for our use case at all).

The current usage is similar to how it is configured BIND. From my understanding and as per the docs here, BIND too does not have TSIG keys tied to any IP address.

Exactly. But at least for me zone updates are denied if I do not add the source address of the updates to the list of permitted addresses.

Due to limited debugging I can't tell you whether updates are refused because the key did not match. Adding the IP address to the list without a matching key did not work either so I thought it had to be key and IP address. Please correct me if that assumption is wrong.

The incoming keys are 512 bit (sic) HMAC-MD5 -- I wonder if they are working at all (BIND is accepting them).

If you do not specify any security policy then the access is based only on IP address restrictions if configured. So, its already possible to do that without using keys.

!

The *.example.com wildcard maps all subdomain names which is exactly how wildcard records in DNS work.

This is definitely not working for me; x.y.domain.com required me to add ..domain.com

But back to the available algorithms: Are you certain that you are able to accept any possible key length for all algorithms?

From dnssec-keygen:

    -a <algorithm>:
        RSA | RSAMD5 | DSA | RSASHA1 | NSEC3RSASHA1 | NSEC3DSA |
        RSASHA256 | RSASHA512 | ECCGOST |
        ECDSAP256SHA256 | ECDSAP384SHA384 |
        ED25519 | ED448 | DH |
        HMAC-MD5 | HMAC-SHA1 | HMAC-SHA224 | HMAC-SHA256 | 
        HMAC-SHA384 | HMAC-SHA512
       (default: RSASHA1, or NSEC3RSASHA1 if using -3)
    -b <key size in bits>:
        RSAMD5: [512..4096]
        RSASHA1:        [512..4096]
        NSEC3RSASHA1:   [512..4096]
        RSASHA256:      [512..4096]
        RSASHA512:      [1024..4096]
        DH:             [128..4096]
        DSA:            [512..1024] and divisible by 64
        NSEC3DSA:       [512..1024] and divisible by 64
        ECCGOST:        ignored
        ECDSAP256SHA256:        ignored
        ECDSAP384SHA384:        ignored
        ED25519:        ignored
        ED448:  ignored
        HMAC-MD5:       [1..512]
        HMAC-SHA1:      [1..160]
        HMAC-SHA224:    [1..224]
        HMAC-SHA256:    [1..256]
        HMAC-SHA384:    [1..384]
        HMAC-SHA512:    [1..512]
        (if using the default algorithm, key size
        defaults to 2048 for KSK, or 1024 for all others)

[noseshimself]

I replaced some keys now. No matter what, HMAC-MD5 is not working for me but the rest is working as expected.

I guess we can close this but I would recommend more verbose logging including messages like "got a length of y bits".

[ShreyasZare]

Exactly. But at least for me zone updates are denied if I do not add the source address of the updates to the list of permitted addresses.

If you select the "Allow" option then the source address check is not done. Just check the option you have selected for Dynamic Updates in your zone.

Due to limited debugging I can't tell you whether updates are refused because the key did not match. Adding the IP address to the list without a matching key did not work either so I thought it had to be key and IP address. Please correct me if that assumption is wrong.

The TSIG shared secret and source address are totally not linked. The options you see for Dynamic Updates allow you to restrict access to specific IP addresses if you want to. Using the "Allow" option wont check for source address. The Security Policy is independent of the source address.

The incoming keys are 512 bit (sic) HMAC-MD5 -- I wonder if they are working at all (BIND is accepting them).

The TSIG shared secret size and the Algorithm are totally unrelated. You can have any size of shared secret for TSIG and have any Algorithm. The algorithm is used only for authentication so if you used HMAC-MD5 then the hash generated using it will always be 128 bits irrespective of the size of the shared secret that you use.

This is definitely not working for me; x.y.domain.com required me to add ..domain.com

All these features are tested. Just to be sure, I tested it again by running nsupdate command line tool and its working as expected. I was able to add A record x.y.example.com with *.example.com domain in the Security Policy in the test. So, it seems that you have some config issue which is causing it to not work.

But back to the available algorithms: Are you certain that you are able to accept any possible key length for all algorithms?

Yes. If you still have doubts then you can read this relevant section of RFC 8945.

From dnssec-keygen:

This tool is meant for generating keys for DNSSEC and not related to TSIG. The algorithms listed in there are DNSSEC related algorithms and not related to TSIG despite both using the same kind of HMAC algorithms.

There are some online posts that use this tool for generating TSIG shared secret which is ok since TSIG just needs some random key in base64 format and this tool gives a base64 key output that can be used with TSIG as shared secret. Apart from that, there is nothing common between this tool and TSIG and its being used just for convenience reasons.

If you still have issues with your config then share screenshots of your config over email to support@technitium.com and you will get help with getting them to work.

[ShreyasZare]

I replaced some keys now. No matter what, HMAC-MD5 is not working for me but the rest is working as expected.

HMAC-MD5 has been tested and it works well. It seems to be just a config issue.

I guess we can close this but I would recommend more verbose logging including messages like "got a length of y bits".

For TSIG, the key name, algorithm and shared secret just needs to match exact. Just check if these 3 thing match in your config.