Feature request: rename host -> owner #360

New Issue

saavagebueno · 2025-11-20T04:23:07-05:00

saavagebueno commented

2025-11-20 04:23:07 -05:00

Originally created by @qdm12 on GitHub (Feb 3, 2024).

The current parameter host is a computer name in a network and is not a perfect name, despite being used by a few providers on their Web UI. subdomain is problematic/misleading since for example a.b.c.com is a subdomain of b.c.com, despite the domain being c.com; plus @ or * are not really subdomains. The technical DNS name for this left part for a certain domain is owner, and we should use it to avoid confusion.

Rename JSON parameter in all docs/ documents
Rename with retro-compatibility the JSON field host in the code

Originally created by @qdm12 on GitHub (Feb 3, 2024). The current parameter `host` is a computer name in a network and is not a perfect name, despite being used by a few providers on their Web UI. `subdomain` is problematic/misleading since for example `a.b.c.com` is a subdomain of `b.c.com`, despite the domain being `c.com`; plus `@` or `*` are not really *subdomains*. The technical DNS name for this left part for a certain domain is `owner`, and we should use it to avoid confusion. - [ ] Rename JSON parameter in all docs/ documents - [ ] Rename with retro-compatibility the JSON field host in the code

saavagebueno added the Status: 🔒 After next release Complexity: 🟩 Easy to do Category: Motivated! 🙌Priority: 🚨 Urgent Category: Documentation ✒️Category: Foolproof settings 👼 labels 2025-11-20 04:23:07 -05:00

saavagebueno closed this issue

2025-11-20 04:23:07 -05:00

saavagebueno commented

2025-11-20 04:23:08 -05:00

@Peronia commented on GitHub (Feb 16, 2024):

Well, I think owner is not really better than host. I agree with you, host have nothing todo with this parameter. But in my view owner is very technically. In my case I have a lot of confusion even when I found that issue, see here.
I would suggest a name like prefix/domainprefix or subpart. Yeah I know this terms are not 100% correct, but my case is about understanding. And I agree also with you that subdomain can be misleading.
I could add a part at the readme that add more explanation, when you want I can open a PR.

@Peronia commented on GitHub (Feb 16, 2024): Well, I think `owner` is not really better than `host`. I agree with you, `host` have nothing todo with this parameter. But in my view `owner` is very technically. In my case I have a lot of confusion even when I found that issue, see [here](https://github.com/qdm12/ddns-updater/discussions/648). I would suggest a name like `prefix`/`domainprefix` or `subpart`. Yeah I know this terms are not 100% correct, but my case is about understanding. And I agree also with you that `subdomain` can be misleading. I could add a part at the readme that add more explanation, when you want I can open a PR.

saavagebueno commented

2025-11-20 04:23:08 -05:00

@qdm12 commented on GitHub (Feb 19, 2024):

Why not otherwise have domain accept forms such as *.domain.com, domain.com and abc.domain.com, and remove (keep it for retro compat) the host field? 🤔

@qdm12 commented on GitHub (Feb 19, 2024): Why not otherwise have domain accept forms such as `*.domain.com`, `domain.com` and `abc.domain.com`, and remove (keep it for retro compat) the `host` field? 🤔

saavagebueno commented

2025-11-20 04:23:08 -05:00

@Peronia commented on GitHub (Feb 20, 2024):

Well, thats the best way of understanding. But is this technically possible? I know you are the maintainer so you don't suggest things that won't work I think. Do we need this host/owner value as a seperate info?

@Peronia commented on GitHub (Feb 20, 2024): Well, thats the best way of understanding. But is this technically possible? I know you are the maintainer so you don't suggest things that won't work I think. Do we need this `host`/`owner` value as a seperate info?

saavagebueno commented

2025-11-20 04:23:08 -05:00

@qdm12 commented on GitHub (Feb 29, 2024):

In general, domains are of the form domain.tld. It's possible maybe to have do.main.tld but it's rather uncommon. If one uses such form, he/she can set the owner in the old (kept for retro-compatibility) "host" field to make sure ddns-updater understands do.main.tld is the domain and not main.tld. Not something I want to document unless someone raises an issue about this, since I have never seen such case. So in general it will be s.u.bdomain.domain.tld and ddns-updater will understand s.u.bdomain as the owner and domain.tld as the domain.

Overall I think what's needed:

commit 1: add an owner field to mimic the host field, and replace host with owner in the documentation. Just plain bad naming that needs to go away. Add a note to remove the host field in a future breaking changes v3 release. We may want to keep the owner field for weird edge cases where the (dns technical sense) domain has more than 1 dot.
commit 2:
- if owner/host is set, use it as the owner and use the domain value as.. the domain (in the dns technical terminology sense)
- if owner/host is not set, get the owner and domain from the domain field of the form optional.domain.com. The owner can be empty (-> @) if the domain is just domain.com.
- remove any documentation on the owner field
- update documentation on the domain field
- pay attention to special cases duckdns.org and goip.de not having a domain really but only an owner configurable, but that should fit fine with the above.

So in the end, we would just have the "domain" field, except for the weird domain names where "owner" may come into play, but we keep it secret 😄

@qdm12 commented on GitHub (Feb 29, 2024): In general, domains are of the form `domain.tld`. It's possible maybe to have `do.main.tld` but it's rather uncommon. If one uses such form, he/she can set the owner in the old (kept for retro-compatibility) `"host"` field to make sure ddns-updater understands `do.main.tld` is the domain and not `main.tld`. Not something I want to document unless someone raises an issue about this, since I have never seen such case. So in general it will be `s.u.bdomain.domain.tld` and ddns-updater will understand `s.u.bdomain` as the owner and `domain.tld` as the domain. Overall I think what's needed: 1. commit 1: add an `owner` field to mimic the `host` field, and replace host with owner in the documentation. Just plain bad naming that needs to go away. Add a note to remove the host field in a future breaking changes v3 release. We may want to keep the owner field for weird edge cases where the (dns technical sense) domain has more than 1 dot. 2. commit 2: - if owner/host is set, use it as the owner and use the domain value as.. the domain (in the dns technical terminology sense) - if owner/host is not set, get the owner and domain from the domain field of the form `optional.domain.com`. The owner can be empty (-> `@`) if the domain is just `domain.com`. - remove any documentation on the `owner` field - update documentation on the `domain` field - pay attention to special cases duckdns.org and goip.de not having a domain really but only an owner configurable, but that should fit fine with the above. So in the end, we would just have the `"domain"` field, except for the weird domain names where `"owner"` may come into play, but we keep it secret 😄

saavagebueno commented

2025-11-20 04:23:08 -05:00

@Peronia commented on GitHub (Mar 4, 2024):

Okay, got it. But why remove the documentation? Then we have an undocumentated field, that is not very nice. I would suggest to move the documentation to another plac, like archive or something like that.

@Peronia commented on GitHub (Mar 4, 2024): Okay, got it. But why remove the documentation? Then we have an undocumentated field, that is not very nice. I would suggest to move the documentation to another plac, like archive or something like that.

saavagebueno commented

2025-11-20 04:23:09 -05:00

@qdm12 commented on GitHub (Mar 7, 2024):

Because the code would still be functional with the older host field, and I hope we wouldn't need it going forward. Older documentation can still be accessed by accessing release tagged trees on github (or specific commits). If people already using the program can migrate to the newer format, that's also better for a smoother migration to a v3 release 😉

@qdm12 commented on GitHub (Mar 7, 2024): Because the code would still be functional with the older host field, and I hope we wouldn't need it going forward. Older documentation can still be accessed by accessing release tagged trees on github (or specific commits). If people already using the program can migrate to the newer format, that's also better for a smoother migration to a v3 release 😉

saavagebueno commented

2025-11-20 04:23:09 -05:00

@Peronia commented on GitHub (Mar 10, 2024):

I'm still not convinced about having an undocumented field, but it's not my project, I would solve it differently.
The github tree thing sounds more complicated, I'm not familiar with it anyway.

@Peronia commented on GitHub (Mar 10, 2024): I'm still not convinced about having an undocumented field, but it's not my project, I would solve it differently. The github tree thing sounds more complicated, I'm not familiar with it anyway.

saavagebueno commented

2025-11-20 04:23:09 -05:00

@qdm12 commented on GitHub (Jun 27, 2024):

55d8c0d703 added versioned readme+docs/ links to the readme
32fafeca95 host renamed to owner in documentation, code, and config.json. This is retro-compatible with the JSON host field key still.
07d7645d78 both host and owner removed in favor of getting the owner and "eTLD+1" from the domain field value, using golang.org/x/net/publicsuffix and a bit of string manipulation logic. This is still retro-compatible with both the host and owner JSON config field keys, which takes precedence if set to a non empty string.

Closing this since all these points should resolve this 😉

@qdm12 commented on GitHub (Jun 27, 2024): 1. 55d8c0d7030c657394653e814ed8efa5ca33fc13 added versioned readme+docs/ links to the readme 2. 32fafeca95473b608931522cce643158bc4ad6b8 `host` renamed to `owner` in documentation, code, and config.json. This is retro-compatible with the JSON `host` field key still. 3. 07d7645d787a81e3a6c5ee52b9ec3ccf65a4c2ea both `host` and `owner` removed in favor of getting the owner and "*eTLD+1*" from the domain field value, using golang.org/x/net/publicsuffix and a bit of string manipulation logic. This is still retro-compatible with both the `host` and `owner` JSON config field keys, which takes precedence if set to a non empty string. Closing this since all these points should resolve this 😉

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/ddns-updater#360

Feature request: rename host -> owner #360

Feature request: rename `host` -> `owner` #360