• GoDaddy Community
  • Website Design & Development
  • Website Design & Development

    cancel
    Showing results for 
    Show  only  | Search instead for 
    Did you mean: 
    Go to solution
    New

    GoDaddy API Returns Stale/Incorrect Data

    Hi,

     

    I used the API to successfully set new nameservers for my domain. I send the request, I get an HTTP 200 response, and then viewing the web console shows that the changes have been made, and querying DNS for the nameservers of the domain returns the updated values. You can see this in my console screenshot and nslookup output:

    81996745-d2044500-961b-11ea-94a4-3e1612cbed2e Screen Shot 2020-05-14 at 8.16.01 PM.png

     

    The API itself does not reflect this change. If I query the API to check the nameservers, the returned information is wrong, and the API behaves as if I had made no changes at all:

    Nitor_0-1589501939199.png

     

    I made my first changes more than 18 hours ago. This is completely broken, and this issue on github indicates that it has been broken for at least six months. 

     

    Regards,

    Andrew

    1 ACCEPTED SOLUTION

    Hi @JesseW 

     

    You were right. The API team eventually got back to me and pointed out that the apex-level NS glue (?) is changed via a PATCH method on /v1/domains/{domain}. While I had set this information via the API, I was using a library with verbose debugging. As far as I can tell, it performed both an apex Nameserver update and a zone file nameserver update, which only made things more confusing for me.

     

    So while the API is indeed returning stale data for quite some time, it's not wrong in the way I thought it was. The zone file info in the API is stale for up to 48 hours after the zone is erased due to the custom NS entries, but AFAIK the endpoint I just showed _should_ deliver correct information immediately after a successful API call. If that proves to be false, I'll update this thread again later.

     

    Thanks for your time!

     

    -Andrew

    View solution in original post

    4 REPLIES 4
    Community Manager

    Hi @Nitor. Thanks for posting. I'm not super familiar with how the API works, but from what you've shared, it looks like you might be trying to change your domain's nameservers by updating the nameserver record in the domain's zone file. This would not work. The nameserver records in a zone file don't affect where the registry looks for the domain's zone file. I'd recommend reaching out to api@godaddy.com if you have further questions. 

     

    JesseW - GoDaddy | Community Manager | 24/7 support available at x.co/247support | Remember to choose a solution and give kudos.

    Hi Jesse,

     

    I appreciate the time you took to reply, but I have to push back on your suggestion that this wouldn't work—I configured custom nameservers through the API, and those settings stuck. My view of the DNS config for the domain is unchanged from the screenshot above. The only thing that has changed since last week is that now the API complains about my domain having no zone file.

     

    It seems like there's undocumented behavior going on here.

     

    Thanks.

    Community Manager

    @Nitor Just to be clear, I'm not saying you wouldn't be able to change nameservers via our API (in truth, I'm not sure). If you continue having trouble, I suggest reaching out to the email address I mentioned above. If there is an issue with the API, that would be the best place to report it. 

     

    JesseW - GoDaddy | Community Manager | 24/7 support available at x.co/247support | Remember to choose a solution and give kudos.

    Hi @JesseW 

     

    You were right. The API team eventually got back to me and pointed out that the apex-level NS glue (?) is changed via a PATCH method on /v1/domains/{domain}. While I had set this information via the API, I was using a library with verbose debugging. As far as I can tell, it performed both an apex Nameserver update and a zone file nameserver update, which only made things more confusing for me.

     

    So while the API is indeed returning stale data for quite some time, it's not wrong in the way I thought it was. The zone file info in the API is stale for up to 48 hours after the zone is erased due to the custom NS entries, but AFAIK the endpoint I just showed _should_ deliver correct information immediately after a successful API call. If that proves to be false, I'll update this thread again later.

     

    Thanks for your time!

     

    -Andrew

    View solution in original post