NameCheap DNS Failing but custom works

[Trel]

Jan 30 13:06:46 	php-fpm[47200]: /services_dyndns_edit.php: phpDynDNS: (Success) IP Address Updated Successfully!
Jan 30 13:06:46 	php-fpm[47200]: /services_dyndns_edit.php: phpDynDNS: updating cache file /conf/dyndns_wancustom''1.cache: 999.999.999.999
Jan 30 13:06:46 	check_reload_status: Syncing firewall
Jan 30 13:05:20 	php-fpm[21847]: /services_dyndns_edit.php: phpDynDNS: (Error) CUSTOM-DNS
Jan 30 13:05:20 	php-fpm[21847]: /services_dyndns_edit.php: phpDynDNS: updating cache file /conf/dyndns_wannamecheap'www.my.domain.tld'2.cache: 999.999.999.999

Here's the relavant log info (my IP and actual domain is replaced)

Using the namecheap entry I get "(Error) CUSTOM-DNS", and it does not update.
If I use a custom entry and just hardcode the namecheap update URL, I get the success and it does update

(And to be on the safe side, I tried both with an @ AND a www record)

Is this something on my end or should I open a bug report on this?

[phil.davis]

I think it is reporting some extra response from the Namecheap server "CUSTOM-DNS".
Try editing /etc/inc/dyndns.class and edit the line at about 1007 (inside a case 'namecheap' block):

$status = "phpDynDNS: (Error) " . implode(", ", $ncresponse["interface-response"]["errors"]);

Make the text something unique that you can recognize in the log - change (Error) to (Errrorzzz) or whatever.

Then do the update again, and confirm you get the (Errorzzz) thing reported in the log.

That will confirm that the text "CUSTOM-DNS" is coming back from Namecheap. And that maybe you have something different about your Namecheap account settings? Or Namecheap has changed its interface somehow? Or???

[Trel]

@phil.davis:

I think it is reporting some extra response from the Namecheap server "CUSTOM-DNS".
Try editing /etc/inc/dyndns.class and edit the line at about 1007 (inside a case 'namecheap' block):

$status = "phpDynDNS: (Error) " . implode(", ", $ncresponse["interface-response"]["errors"]);

Make the text something unique that you can recognize in the log - change (Error) to (Errrorzzz) or whatever.

Then do the update again, and confirm you get the (Errorzzz) thing reported in the log.

That will confirm that the text "CUSTOM-DNS" is coming back from Namecheap. And that maybe you have something different about your Namecheap account settings? Or Namecheap has changed its interface somehow? Or???

I'll be able to check that on site tonight.
However, I should note, that the URL in the custom string has not changed in a year, and when I was testing this, I did the following.

1. I set the entry in namecheap to an invalid IP.
2. I tried with the built in one returning the error: It did not update the IP in namecheap
3. I tried with the custom one with the unchanged string: It did update the IP in namecheap

I'll modify that and test it as soon as I'm on site again to verify the error, however, it's not due to extra response as the IP does fail to update as well.

[phil.davis]

I am thinking that somehow the Namecheap interaction might be sending some extra response/prompt that pfSense is not expecting. And so the updating process does not proceed and the unexpected response from Namecheap is what is being logged there.

[Trel]

@phil.davis:

I am thinking that somehow the Namecheap interaction might be sending some extra response/prompt that pfSense is not expecting. And so the updating process does not proceed and the unexpected response from Namecheap is what is being logged there.

With namecheap, the response should occur after the update.  Merely loading the page with the correct information should trigger the update.  If pfsense is getting any response at all, if it's sending it correctly, it should have updated, as evidenced by the custom one working.

It's

https://dynamicdns.park-your-domain.com/update?host=[host_name]&domain=[domain.com]&password=[domain_password]&ip=[your_ip]

With the ip field being optional.  If it's present, it'll set it to whatever the IP specified is, otherwise it'll set it to the the IP that URL is called from.

There shouldn't be any additional prompt.

Still I'll test out what you said when I'm on site tonight.

[Trel]

Ok, I need to open a bug report, I see why it's failing.

I added an extra line to spit out the update url it's using to the system logs

The domain and host I'm updating in namecheap is:

host: @
domain: sub.domain.com

What it's doing is

https://dynamicdns.park-your-domain.com/update?host=@.sub&domain=domain.com&password={password}&ip={ip}

It's not dealing with the domain being sub.domain.com rather than domain.com

[Trel]

Bug report opened here: https://redmine.pfsense.org/issues/4366

[phil.davis]

/etc/inc/dyndns.class has code like this:

	$dparts = explode(".", trim($this->_dnsHost));
	$domain_part_count = ($dparts[count($dparts)-1] == "uk") ? 3 : 2;
	$domain_offset = count($dparts) - $domain_part_count;
	$hostname = implode(".", array_slice($dparts, 0, $domain_offset));
	$domain = implode(".", array_slice($dparts, $domain_offset));

That specifically selects the last 2 parts (or 3 parts for uk names) of the FQDN as the "domain" bit for Namecheap.
e.g. "my.website" "your.name.uk"
Then all the remaining part at the front is put as the "hostname"

I just tried that on Namecheap - made a multi-level sub-domain and updated it directly from the browser:

https://dynamicdns.park-your-domain.com/update?host=my.home&domain=personal.website&password=biglongstringoflettersandnumbers

That format works for actual sub-domains (I made an A record for "home" and an A record for "my.home")

Then I updated my "@" record for my top-level with:

https://dynamicdns.park-your-domain.com/update?host=@&domain=personal.website&password=biglongstringoflettersandnumbers

And the existing dyndns.class code works for that.

Then I tried:

https://dynamicdns.park-your-domain.com/update?host=@&domain=home.personal.website&password=biglongstringoflettersandnumbers

and I get:

SETDNSHOSTeng1Domain name not found1316153Validation error; not found; domain name(s)true

Then:

https://dynamicdns.park-your-domain.com/update?host=@.home&domain=personal.website&password=biglongstringoflettersandnumbers

and returns:

SETDNSHOSTeng1No Records updated. A record not Found;1380091No updates; A record not Found;true

It seems that it always requires domain="the top-level domain that you own at Namecheap" and host="all the sub-domain or @ stuff that comes under that"

On Namecheap, how do I set an entry for "@" under a sub-domain?
If I can get that to work somehow for me, then I will be able to debug this myself with my own Namecheap account.

[doktornotor]

I'm afraid "@" for a subdomain does not make any sense, think about it. You set up normal A record there. @ is just a special syntax for "empty" subdomain/hostname, i.e., A record for yourdomain.tld

[phil.davis]

@doktornotor:

I'm afraid "@" for a subdomain does not make any sense, think about it. You set up normal A record there. @ is just a special syntax for "empty" subdomain/hostname, i.e., A record for yourdomain.tld

I agree - the "@" is just a special thing to indicate that you want all accesses to *.sub.domain.top to return the address of sub.domain.top
In Namecheap it is already set up for the case *.domain.top and I can update that entry OK.
But I can't see how to set up the *.sub.domain.top case in the Namecheap settings. Somehow the OP has done that and has then managed to update that from the browser address bar. If I can get it to work like the OP has, then I can see exactly what is required and sort out dyndns.class code.

[Trel]

There's two things different here.
My domain isn't pointed at namecheap, my subdomain is.

The second is the @ record.

You create the @ record at namecheap directly first and then you can update it.

The problem is still how pfsense is splitting the url

host=@&domain=sub.domain.tld

is the correct form when the domain to be updated at namecheap is @.sub.domain.tld

Plus if I'm reading the code for splitting it right, it would fail the same way for any third-level domain with something like "store.vendor.co.nl" or similar as there appears to be specific logic for the "co.uk" but nothing else.

EDIT: as for my manual update string, that's this:```
https://dynamicdns.park-your-domain.com/update?host=@&domain=sub.domain.tld&password={snip}&ip=%IP%

I guess the most important thing to note here is that my domain pointed at name cheap, is in fact sub.domain.tld and NOT domain.tld

I would like to point out that it ALSO fails for updating www.sub.domain.tld in the same way, eg: it's doing host=www.sub&domain=domain.tld

Because you can point a subdomain at Namecheap and there's no way using code logic to know where that split is in some cases, why not separate host and domain into two fields.

![pf_nc2.jpg](/public/_imported_attachments_/1/pf_nc2.jpg)
![pf_nc2.jpg_thumb](/public/_imported_attachments_/1/pf_nc2.jpg_thumb)

[phil.davis]

Oh, so that might make it not possible for me to emulate that with my Namecheap that has just a 2-level main domain.
The existing code assumes that Namecheap provides dynamic DNS for 2-level domains like "domain.com" domain.org" and 3-level domains in the UK like "domain.co.uk".
It seems that [is no longer | was never] true.
The host and base-domain name parts could be specified in the Hostname field by requiring another separator that is not valid in a FQDN, e.g. the "+" sign:
hostname+sub.domain.tld - would be entered for your type of case
my.home+personal.website - would be entered for my type of case where "personal.website" is the base domain on Namecheap.

The underlying code could easily allow the "+" when validating the Namecheap case, and then process the 2 parts of the name to make the update URL string.

But it does seem a bit of a kludge. As you suggest, an extra field could be added. If the field is filled then it is the base-domain part, if not then the existing logic to "guess" the base-domain part is used - maintaining backward-compatibility with old entries.

[Trel]

Yes, and the good part of the extra field option is, as I've seen javascript used to change the visible fields for example when you choose custom from the list, the extra field could be made to only show when using dynamic DNS providers where this could be an issue.