Bug: ERROR bad HTTP status: 403 with Host * in Godaddy #110

Originally created by @rlibanez on GitHub (Mar 22, 2021).

Originally assigned to: @qdm12 on GitHub.

TLDR: Host * doesn't work with GoDaddy.

Is this urgent: Yes
DNS provider(s) you use: GoDaddy
Program version:

Running version latest built on 2021-03-22T01:52:47Z (commit 106bcae)
What are you using to run the container: docker-compose
Extra information (optional)

I tried both with the entry * created in the Godaddy DNS record and without it.

The host @ with the shame key and secret works without problem:

Logs:

2021/03/22 09:35:32 main.go:114: INFO Found single setting to update record

2021/03/22 09:35:32 main.go:123: INFO Reading history from database: domain asdf.com host *

2021/03/22 09:35:32 INFO healthcheck server: listening on 127.0.0.1:9999

2021/03/22 09:35:32 INFO backup: disabled

2021/03/22 09:35:32 INFO http server: listening on 0.0.0.0:8000

2021/03/22 09:35:33 run.go:175: WARN cannot DNS resolve any.asdf.com after 5 tries: lookup any.asdf.com on 192.168.1.2:53: no such host

2021/03/22 09:35:33 run.go:190: INFO IPv4 address of any.asdf.com is <nil> and your IPv4 address is 77.66.55.77

2021/03/22 09:35:33 run.go:259: INFO Updating record [domain: asdf.com | host: * | provider: godaddy | ip: ipv4] to use 77.66.55.77

2021/03/22 09:35:38 run.go:262: ERROR bad HTTP status: 403: <html><head><title>403 Forbidden</title></head><body><center><h1>403 Forbidden</h1></center></body></html>

Configuration file (remove your credentials!):

{
  "settings": [
    {
      "provider": "godaddy",
      "domain": "asdf.com",
      "host": "*",
      "key": "key",
      "secret": "secret",
      "ip_version": "ipv4"
    }
  ]
}

In the second image:
{
  "settings": [
    {
      "provider": "godaddy",
      "domain": "asdf.com",
      "host": "*,@",
      "key": "key",
      "secret": "secret",
      "ip_version": "ipv4"
    }
  ]
}

Host OS: Debian 10 buster

Originally created by @rlibanez on GitHub (Mar 22, 2021). Originally assigned to: @qdm12 on GitHub.  **TLDR**: *Host * doesn't work with GoDaddy.* 1. Is this urgent: Yes 2. DNS provider(s) you use: GoDaddy 3. Program version:  `Running version latest built on 2021-03-22T01:52:47Z (commit 106bcae)` 4. What are you using to run the container: docker-compose 5. Extra information (optional) I tried both with the entry * created in the Godaddy DNS record and without it. ![error03b](https://user-images.githubusercontent.com/10696658/111961054-d0839300-8af0-11eb-9919-03ae7338c62e.png) The host @ with the shame key and secret works without problem: ![error02b](https://user-images.githubusercontent.com/10696658/111959283-88fc0780-8aee-11eb-9252-8e580d861eee.png) Logs: ```log 2021/03/22 09:35:32 main.go:114: INFO Found single setting to update record 2021/03/22 09:35:32 main.go:123: INFO Reading history from database: domain asdf.com host * 2021/03/22 09:35:32 INFO healthcheck server: listening on 127.0.0.1:9999 2021/03/22 09:35:32 INFO backup: disabled 2021/03/22 09:35:32 INFO http server: listening on 0.0.0.0:8000 2021/03/22 09:35:33 run.go:175: WARN cannot DNS resolve any.asdf.com after 5 tries: lookup any.asdf.com on 192.168.1.2:53: no such host 2021/03/22 09:35:33 run.go:190: INFO IPv4 address of any.asdf.com is <nil> and your IPv4 address is 77.66.55.77 2021/03/22 09:35:33 run.go:259: INFO Updating record [domain: asdf.com | host: * | provider: godaddy | ip: ipv4] to use 77.66.55.77 2021/03/22 09:35:38 run.go:262: ERROR bad HTTP status: 403: <html><head><title>403 Forbidden</title></head><body><center><h1>403 Forbidden</h1></center></body></html> ``` Configuration file (**remove your credentials!**): ```json { "settings": [ { "provider": "godaddy", "domain": "asdf.com", "host": "*", "key": "key", "secret": "secret", "ip_version": "ipv4" } ] } In the second image: { "settings": [ { "provider": "godaddy", "domain": "asdf.com", "host": "*,@", "key": "key", "secret": "secret", "ip_version": "ipv4" } ] } ``` Host OS: Debian 10 buster

saavagebueno closed this issue

saavagebueno commented

@qdm12 commented on GitHub (Mar 22, 2021):

Can you try

docker run -it --rm alpine
apk add curl
curl -H "Authorization: sso-key YOURKEY:YOURSECRET" -X GET https://api.godaddy.com/v1/domains/YOURDOMAIN.com/records/A
exit

What name do you get for the wildcard record?

Right now the program sends queries to https://api.godaddy.com/v1/domains/YOURDOMAIN.com/records/A/* for wildcards hosts, but maybe that's invalid and there is another special name instead of * but I cannot find it in their documentation.

@qdm12 commented on GitHub (Mar 22, 2021): Can you try ```sh docker run -it --rm alpine apk add curl curl -H "Authorization: sso-key YOURKEY:YOURSECRET" -X GET https://api.godaddy.com/v1/domains/YOURDOMAIN.com/records/A exit ``` What `name` do you get for the wildcard record? Right now the program sends queries to `https://api.godaddy.com/v1/domains/YOURDOMAIN.com/records/A/*` for wildcards hosts, but maybe that's invalid and there is another special name instead of `*` but I cannot find it [in their documentation](https://developer.godaddy.com/doc/endpoint/domains#/v1/recordReplaceTypeName).

saavagebueno commented

@rlibanez commented on GitHub (Mar 22, 2021):

/ # curl -H "Authorization: sso-key aabbcc:xxyy" -X GET https://api.godaddy.com/v1/domains/asdf.com/records/A
[{"data":"77.66.55.77","name":"@","ttl":600,"type":"A"},{"data":"127.0.0.1","name":"*","ttl":600,"type":"A"}]
/ # curl -H "Authorization: sso-key aabbcc:xxyy" -X GET https://api.godaddy.com/v1/domains/asdf.com/records/A/*
<html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
</body>
</html>
/ # curl -H "Authorization: sso-key aabbcc:xxyy" -X GET https://api.godaddy.com/v1/domains/asdf.com/records/A/@
[{"data":"77.66.55.77","name":"@","ttl":600,"type":"A"}]
/ # exit

Thank you very much.

@rlibanez commented on GitHub (Mar 22, 2021): ``` / # curl -H "Authorization: sso-key aabbcc:xxyy" -X GET https://api.godaddy.com/v1/domains/asdf.com/records/A [{"data":"77.66.55.77","name":"@","ttl":600,"type":"A"},{"data":"127.0.0.1","name":"*","ttl":600,"type":"A"}] / # curl -H "Authorization: sso-key aabbcc:xxyy" -X GET https://api.godaddy.com/v1/domains/asdf.com/records/A/* <html> <head><title>403 Forbidden</title></head> <body> <center><h1>403 Forbidden</h1></center> </body> </html> / # curl -H "Authorization: sso-key aabbcc:xxyy" -X GET https://api.godaddy.com/v1/domains/asdf.com/records/A/@ [{"data":"77.66.55.77","name":"@","ttl":600,"type":"A"}] / # exit ``` ![curl02b](https://user-images.githubusercontent.com/10696658/112030114-35171000-8b3a-11eb-8e39-7b4b9d990089.png) Thank you very much.

saavagebueno commented

@qdm12 commented on GitHub (Mar 22, 2021):

So how can you update a wildcard record? Is this even supported? Maybe reach out to their support and let me know how to query their server, because right now passing * as the host doesn't work. Was it working before?

@qdm12 commented on GitHub (Mar 22, 2021): So how can you update a wildcard record? Is this even supported? Maybe reach out to their support and let me know how to query their server, because right now passing `*` as the host doesn't work. Was it working before?

saavagebueno commented

@rlibanez commented on GitHub (Mar 22, 2021):

I am new to this, I don't know if it worked before. I will contact them and keep you informed.

@rlibanez commented on GitHub (Mar 22, 2021): I am new to this, I don't know if it worked before. I will contact them and keep you informed.

saavagebueno commented

@FHeilmann commented on GitHub (Mar 26, 2021):

I'm experiencing the same issue. I switched to ddns-updater (from godaddy_ddns) due to this issue, but it seems the issue is on godaddy's end (it was working fine before).

Edit: I got in touch with Level-2 support and they told me that the API is OOS for them, but they told me to contact api@godaddy.com to inquire about this problem. I'll update this comment as I receive more information.

@FHeilmann commented on GitHub (Mar 26, 2021): I'm experiencing the same issue. I switched to ddns-updater (from godaddy_ddns) due to this issue, but it seems the issue is on godaddy's end (it was working fine before). Edit: I got in touch with Level-2 support and they told me that the API is OOS for them, but they told me to contact api@godaddy.com to inquire about this problem. I'll update this comment as I receive more information.

saavagebueno commented

@FHeilmann commented on GitHub (Mar 31, 2021):

Dear Sir/Madam,

I understand that you are writing in about the error using our APIS.  
With review of your script you are defining A record in the URL and in your body.  
You should only be doing 1 or the other, either defining you are wanting to check 
for A records in your URL call or in your body but not both.  I am able to onfirm that 
DNS records using the wildcard record do work witohut any issues.

Regards,

not very helpful. I'll continue talking to them.

(for reference, here's the eMail I sent:

Hi, I have been using the GoDaddy API to query/update the wildcard (*) 
record of my godaddy domain for several months. Over the course of the last 2-3 weeks, 
I have now become unable to do so, due to 403 errors in the API. 
Generating a new key has not resolved the issue. Basically I am able to query my records just fine via  

curl -H "Authorization: sso-key MY_KEY:MY_SECRET" -X GET https://api.godaddy.com/v1/domains/MY_DOMAIN/records/A 

which yields: 

[{"data":"IP_1","name":"*","ttl":600,"type":"A"},{"data":"IP_2","name":"mail","ttl":600,"type":"A"}] 

but performing the same query for the wildcard record: 

curl -H "Authorization: sso-key MY_KEY:MY_SECRET" -X GET https://api.godaddy.com/v1/domains/MY_DOMAIN/records/A/* 

yields 403 Forbidden


I am therefore unable to query or update this wildcard record using the API. 
This has worked fine previously, but stopped working a couple of weeks ago.
 Is this an intended change in the API or is this an error that has somehow 
crept into the API recently? In case of the latter, I am asking for assistance to 
remedy this issue. Thanks in advance,

@FHeilmann commented on GitHub (Mar 31, 2021): ``` Dear Sir/Madam, I understand that you are writing in about the error using our APIS. With review of your script you are defining A record in the URL and in your body. You should only be doing 1 or the other, either defining you are wanting to check for A records in your URL call or in your body but not both. I am able to onfirm that DNS records using the wildcard record do work witohut any issues. Regards, ``` not very helpful. I'll continue talking to them. (for reference, here's the eMail I sent: ``` Hi, I have been using the GoDaddy API to query/update the wildcard (*) record of my godaddy domain for several months. Over the course of the last 2-3 weeks, I have now become unable to do so, due to 403 errors in the API. Generating a new key has not resolved the issue. Basically I am able to query my records just fine via curl -H "Authorization: sso-key MY_KEY:MY_SECRET" -X GET https://api.godaddy.com/v1/domains/MY_DOMAIN/records/A which yields: [{"data":"IP_1","name":"*","ttl":600,"type":"A"},{"data":"IP_2","name":"mail","ttl":600,"type":"A"}] but performing the same query for the wildcard record: curl -H "Authorization: sso-key MY_KEY:MY_SECRET" -X GET https://api.godaddy.com/v1/domains/MY_DOMAIN/records/A/* yields 403 Forbidden I am therefore unable to query or update this wildcard record using the API. This has worked fine previously, but stopped working a couple of weeks ago. Is this an intended change in the API or is this an error that has somehow crept into the API recently? In case of the latter, I am asking for assistance to remedy this issue. Thanks in advance, ```

saavagebueno commented

@qdm12 commented on GitHub (Mar 31, 2021):

Yeah that endpoint is screwed. The GET doesn't work nor does the PUT contrary to their API docs. Maybe send the a screenshot of their docs?

For info in this program only the IP is sent in the body, the rest is in the URL as they precise in their API Documentation.

@qdm12 commented on GitHub (Mar 31, 2021): Yeah that endpoint is screwed. The GET doesn't work nor does the PUT contrary to their API docs. Maybe send the a screenshot of their docs? For info in this program only the IP is sent in the body, the rest is in the URL as they precise in their API Documentation.

saavagebueno commented

@FHeilmann commented on GitHub (Apr 1, 2021):

There's a higher level endpoint that we can maybe use in the mean-time? i.e. retrieve all A records
GET /v1/domains/{domain}/records/{type}
update the relevant records and then update all records with
PUT /v1/domains/{domain}/records/{type} ?

@FHeilmann commented on GitHub (Apr 1, 2021): There's a higher level endpoint that we can maybe use in the mean-time? i.e. retrieve all A records `GET /v1/domains/{domain}/records/{type}` update the relevant records and then update all records with `PUT /v1/domains/{domain}/records/{type}` ?

saavagebueno commented

@FHeilmann commented on GitHub (Apr 1, 2021):

Just got another reply from the API support

Dear Sir/Madam,

We got the needed information to review this from 
another customer and we think it has been resolved.

Regards,

Unfortunately I'm unable to verify until early next week.

@FHeilmann commented on GitHub (Apr 1, 2021): Just got another reply from the API support ``` Dear Sir/Madam, We got the needed information to review this from another customer and we think it has been resolved. Regards, ``` Unfortunately I'm unable to verify until early next week.

saavagebueno commented

@qdm12 commented on GitHub (Apr 1, 2021):

Ah cool thanks for letting me know. I haven't done the code changes yet, I'll wait until you (or someone else in this thread) can test it before investing time changing it, in case they actually fixed it on their end.

@qdm12 commented on GitHub (Apr 1, 2021): Ah cool thanks for letting me know. I haven't done the code changes yet, I'll wait until you (or someone else in this thread) can test it before investing time changing it, in case they actually fixed it on their end.

saavagebueno commented

@rlibanez commented on GitHub (Apr 3, 2021):

After several tests and no errors, it seems that everything is correct now.
Do we close now or expect more results?

Thank you all.

@rlibanez commented on GitHub (Apr 3, 2021): After several tests and no errors, it seems that everything is correct now. Do we close now or expect more results? Thank you all.

saavagebueno commented

@qdm12 commented on GitHub (Apr 3, 2021):

Cool! Let's wait for @FHeilmann to verify as well and we can then close, thank you guys for poking around their customer service.

@qdm12 commented on GitHub (Apr 3, 2021): Cool! Let's wait for @FHeilmann to verify as well and we can then close, thank you guys for poking around their customer service.

saavagebueno commented