pfSense

Formatting removed the {@} symbol

{@}.sub.domain.com

rather than having to modify gui and the xml values separately, its better to modify the logic such that u consider only the first part as host and the remaining as domain

eg: host.some.domain.com currently just takes domain.com as domain and the earlier part as host unless its a .uk domain in which some.domain.uk is considered a domain

so just one line of code will take host as hostname and some.domain.com as domain which can solve this easily

easy fix would be to edit the /etc/inc/dyndns.class file on line 537

replace
$domain_part_count = ($dparts[count($dparts)-1] == "uk") ? 3 : 2;

with
$domain_part_count = count($dparts)-1;

Modifying that test would break other domains that function correctly now. That may be an "easy fix" for this specific case but it would break others in the process.

But that would then break in scenarios such as

parta.partb.domain.tld

"parta.partb" is a valid A record. Using the logic you said, there would be no possibility of updating that. It would try to update the A record for "parta" at the domain "partb.domain.tld" which is not an existing A record.

An example case here

do an NS lookup on this: parta.partb.raidio.co
The A record is for parta.partb NOT parta

The safest solution would be the two input boxes to allow the user to define how much is the host name, and how much is the domain.
It allows for all scenarios.

Trel S wrote:

"parta.partb" is a valid A record. Using the logic you said, there would be no possibility of updating that. It would try to update the A record for "parta" at the domain "partb.domain.tld" which is not an existing A record.

That's not the problem. There are cases when the domain has more than two parts, specifically the case in the test with .uk, so the domain is domain.co.uk for example, not just domain.com.

Having separate input boxes is the safest method, perhaps even just co-opting the "username" field since it is unused with Namecheap, but the logic would still need to be carefully crafted so it does not break existing users.

There are cases when the domain has more than two parts, specifically the case in the test with .uk, so the domain is domain.co.uk for example, not just domain.com.

It looks like both of cases we mentioned would break if it just uses the left most part automatically.

well then the current logic uses 3 parts when on domain.co.uk whereas namecheap has other domains with 3 parts like x.com.sg, x.net.pe, com.pe etc etc so if any1 would be using those for dyndns then again it wouldnt work so i believe if we follow the 3 part domain for .uk then it would be meaningful to do so for all other such domains that namecheap provides or the other method is to have a separate hostname box

The main problem isn't if the domain is 2 or 3 part. It's that hard coding the number of parts breaks it for anything either non-standard (such as the "parta.partb" as a single A record) or anything over the hard coded parts.

For example, if you hard code it to 3 parts, how would it handle "suba.subb.subc.domain.co.uk"?

Anything hardcoded will have to make assumptions that will break anything that doesn't meet them.

The only option that allows for any possible case is the separate boxes which lets the user define which part is the host and which is the domain.

one easy way this could be done is, add the extra box but store the values of both in the same field in the xml but just add a | or ; or any such character to separate them, later can just find that split it again.