Allowed IPs under Authentication - DNS #375

New Issue

2026-10-05T04:16:20+02:00

adam commented

2026-10-05 04:16:20 +02:00

Option to allow it to use DNS lookup and not just ip numbers

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Option to allow it to use DNS lookup and not just ip numbers ## <bountysource-plugin> Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/3656453-allowed-ips-under-authentication-dns?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github). </bountysource-plugin>

adam commented

2026-10-05 04:16:20 +02:00

I do a new commit to this again to clear things out, its a bit annoying that ZNC only allow IP-Adress in "ZNC » webadmin » Edit User - Authentication - Allowed IPs" and not DNS Adress.

Because as many others i have dynamic ip, it changes quite often and because I like to have my ZNC safe so I let only my IP enter.

But every time this happens, I had to go in and change the IP manually in the config file and then restart ZNC which is very annoying.

Instead of just having it locked against a DNS address instead like znc.myhost.com which always has the current IP

I do a new commit to this again to clear things out, its a bit annoying that ZNC only allow IP-Adress in "ZNC » webadmin » Edit User - Authentication - Allowed IPs" and not DNS Adress. Because as many others i have dynamic ip, it changes quite often and because I like to have my ZNC safe so I let only my IP enter. But every time this happens, I had to go in and change the IP manually in the config file and then restart ZNC which is very annoying. Instead of just having it locked against a DNS address instead like znc.myhost.com which always has the current IP

adam commented

2026-10-05 04:16:21 +02:00

I see two options here.

Disallow wildcards in the list; when a client connects, resolve all domains in the list, and match IPs. Domains may be prefetched before actual connect.
When client connects, lookup its PTR record, then lookup A/AAAA records for that client-controlled domain, then match IP of client to be in the list (from the A/AAAA lookup), and finally match the domain against the configured list of allowed hosts. This option allows wildcards, but attempt to resolve domain controlled by an attacker perhaps can be harmful.

I see two options here. 1. Disallow wildcards in the list; when a client connects, resolve all domains in the list, and match IPs. Domains may be prefetched before actual connect. 2. When client connects, lookup its PTR record, then lookup A/AAAA records for that client-controlled domain, then match IP of client to be in the list (from the A/AAAA lookup), and finally match the domain against the configured list of allowed hosts. This option allows wildcards, but attempt to resolve domain controlled by an attacker perhaps can be harmful.

adam commented

2026-10-05 04:16:22 +02:00

As hashed out on IRC with @DarthGandalf, this would look something like the following (subject to revision after feedback):

As hashed out on IRC with @DarthGandalf, this would look something like the following (subject to revision after feedback): ![image](https://cloud.githubusercontent.com/assets/164140/8888804/2483b800-328b-11e5-8cb0-3be85921b755.png)

adam commented

2026-10-05 04:16:23 +02:00

Zaba said:

it would probably be useful to explicitly distinguish IPs and hosts in the allowed list, so that 1.2.3.* doesn't match 1.2.3.example.com by accident (or malice)

Zaba said: > it would probably be useful to explicitly distinguish IPs and hosts in the allowed list, so that 1.2.3.\* doesn't match 1.2.3.example.com by accident (or malice)

adam commented

2026-10-05 04:16:23 +02:00

Would wildcards like client.domain.* be allowed? I guess I was operating under the general assumption that IP wildcards come at the end of the IP, and domain wildcards come at the beginning.

Unless the idea is to have separate settings for "Allowed IPs" and "Allowed Hosts", which I would not oppose.

Would wildcards like `client.domain.*` be allowed? I guess I was operating under the general assumption that IP wildcards come at the end of the IP, and domain wildcards come at the beginning. Unless the idea is to have separate settings for "Allowed IPs" and "Allowed Hosts", which I would not oppose.

adam commented

2026-10-05 04:16:24 +02:00

Also related: #207

Also related: #207

adam commented

2026-10-05 04:16:25 +02:00

From my perspective, you may want to do "Allowed IPs" as one option box, and "Allowed Hosts" as another, and have the system handle DNS resolution, and failing DNS resolution fall back to IPs.

Separating it in this way, as well, allows you to process CIDR subnets as well easier, so you aren't trying to figure what's an IP and what's not through one field. However, CIDR processing gets really complicated when you add in v6, so you still have to either call in other libraries or write your own processor functions.

From my perspective, you may want to do "Allowed IPs" as one option box, and "Allowed Hosts" as another, and have the system handle DNS resolution, and failing DNS resolution fall back to IPs. Separating it in this way, as well, allows you to process CIDR subnets as well easier, so you aren't trying to figure what's an IP and what's not through one field. However, CIDR processing gets _really_ complicated when you add in v6, so you still have to either call in other libraries or write your own processor functions.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#375