Possible bug introduced by #3775 with Namecheap provider; Zone "xxx" does not exist ...

[ajkavanagh]

Describe the bug

I think that #3775 may have introduced a bug in the namecheap provider. With 4.25.0 it works correctly, but with 4.26.0 it says:

Note I've switch my domain name for 'example.com' in this bug, but I was using my domain name

 $ dnscontrol preview --creds "./creds.sh" --config "./dnsconfig.js" --domains example.com
CONCURRENTLY checking for 1 zone(s)
SERIALLY checking for 0 zone(s)
Waiting for concurrent checking(s) to complete...DONE
******************** Domain: example.com
1 correction (namecheap)
INFO#1: Zone "example.com" does not exist. Can not create because "namecheap" does not implement ZoneCreator
CONCURRENTLY gathering records of 1 zone(s)
SERIALLY gathering records of 0 zone(s)
Waiting for concurrent gathering(s) to complete...DONE
******************** Domain: tulipgirl.uk
Done. 1 corrections.
completed with errors

Whereas with 4.25.0:

# dnscontrol preview --creds "./creds.sh" --config "./dnsconfig.js" --domains example.com
CONCURRENTLY checking for 1 zone(s)
SERIALLY checking for 0 zone(s)
Waiting for concurrent checking(s) to complete...DONE
CONCURRENTLY gathering records of 1 zone(s)
SERIALLY gathering records of 0 zone(s)
Waiting for concurrent gathering(s) to complete...DONE
******************** Domain: example.com
Done. 0 corrections.

Note I've switch my domain name for 'example.com'.

Expected behavior

I expected that 4.26.0 would work like 4.25.0. The domain

DNS Provider

Namecheap

[tlimoncelli]

CC @willpower232

That's quite interesting! Some questions:

1. Does the domain exist at namecheap?

2. What the output of this command?

Change "CHANGEME" to the cred key name in creds.json:

dnscontrol get-zones --format=nameonly CHANGEME - all

Thanks!

[ajkavanagh]

Thanks for looking at this.

In answer to your questions:

Does the domain exist at namecheap?

Yes, the domain does exist.

The output of the command:

So I ran:

dnscontrol get-zones --creds="./creds.sh" --format=nameonly namecheap  - all

And got back a list of all the domains but it didn't include the one I was looking for! So some additional information:

1. The domain I was expecting is the last one in the list on the namecheap dashboard. It is also alphabetically the last domain.
2. The get-zones command lists the zones alphabetically.
3. The count of the zones returned (using | wc -l) is 20.
4. I have 26 zones at namecheap, so it looks like 6 zones are missing from get-zones.

I wondered if it is possible that the get-zones command has a limit on the zones it replies at namecheap for a single call.

Looking at https://www.namecheap.com/support/api/methods/domains/get-list/ it looks like the default pageSize is 20, which concurs with the above listing provided. Maybe it's something to do with needing to fetch more than one page?

[tlimoncelli]

Yes, it is likely that we're just getting the first 20 domains and the code needs to be updated to get the "next page". A lot of providers "page" their data.

Is there a chance you added zones between 4.25.0 and 4.26.0 and you're just now triggering a bug that always existed?

[tlimoncelli]

CC @willpower232

I don't have access to Namecheap, so the fix will have to come from the community.

[willpower232]

Looks like the third party library has no concept of paging in spite of the APIs best efforts so will have to get creative.

I hope we can keep it all inside the third party library and return a huge list rather than having to return multiple things from it and challenge a lot of backwards compatibility.

I'll end up needing to have my fork as the one used in here if thats okay? Not sure how much effort is required to publish a package in golang 😅

[tlimoncelli]

Whatever you think is best (sending a PR to the third party library, forking it, etc).

Publishing a package in Go is easy. If its on github, it's published.

[ajkavanagh]

Is there a chance you added zones between 4.25.0 and 4.26.0 and you're just now triggering a bug that always existed?

I actually upgraded from 4.19.0. However, I did a "bisect", in that, I tried all the versions from 4.22.0 onwards (effectively) and 4.19.0 -> 4.25.0 all worked, whereas the bug showed up at 4.26.0. Not entirely scientific as I should have actually pulled the source code, etc., but hopefully it has some value as a test.

[tlimoncelli]

Is there a chance you added zones between 4.25.0 and 4.26.0 and you're just now triggering a bug that always existed?

I actually upgraded from 4.19.0. However, I did a "bisect", in that, I tried all the versions from 4.22.0 onwards (effectively) and 4.19.0 -> 4.25.0 all worked, whereas the bug showed up at 4.26.0. Not entirely scientific as I should have actually pulled the source code, etc., but hopefully it has some value as a test.

That's some smart investigation! Which commit was the first to fail?