inwx - URL Type

[MarcSN311]

Hi! INWX supports a URL Type, which is basically a Header Redirect. When you have a URTL Type entry configured and try to do dnscontrol get-zones or dnscontrol preview it throws the following error:

failed GetZone gzr: 1 error(s) decoding:

* 'record[1].prio' expected type 'int', got unconvertible type 'string', value: '302'

[tlimoncelli]

CC @svenpeter42

[svenpeter42]

sure, i'll take a look and fix it. feel free to assign the issue to me

[svenpeter42]

Alright, this is a combination of two things

• The INWX API returns 301 as a string even though its documentation claims it should always be an integer. I'll contact INWX support about this issue since it should likely be fixed on their side
• The INWX provider right now has no support for the special record type URL. I'm in-between jobs right now but will add that support once things have settled down a little bit :)

[patschi]

This issue has been getting more serious it looks. When pushing changes the output is:

******************** Domain: domain3.tld
WARNING: Error creating domain: 1 error(s) decoding:
* 'Count' expected type 'int', got unconvertible type 'string', value: '15'
******************** Domain: domain2.tld
WARNING: Error creating domain: 1 error(s) decoding:
* 'Count' expected type 'int', got unconvertible type 'string', value: '15'
******************** Domain: domain.tld
WARNING: Error creating domain: 1 error(s) decoding:
* 'Count' expected type 'int', got unconvertible type 'string', value: '15'

But it doesn't push any changes and skips to the next domain completely. Because there's a continue; if any error occurs: https://github.com/StackExchange/dnscontrol/blob/8bb63be8f5ed996a7ae0a21091954fcab996621b/commands/previewPush.go#L156-L159

I'm currently trying to understand where this comes from and if this is the same issue as outlined here. Some significant changes in dnscontrol seems to have changed the priority of this bug.

Currently I've been able to identify following API call which reports the error: https://github.com/StackExchange/dnscontrol/blob/ccb582b2781a36dcf5698c61da30ab1db2007bca/providers/inwx/inwxProvider.go#L384

Small note aside:

@tlimoncelli This might need some changes in the core code of dnscontrol @tlimoncelli.

I'm running dnscontrol in a CI environment and haven't noticed that latest changes haven't been actually pushed. The exit code still remains 0, so job completes without signalizing any error.

I think this is an oversight and that this alert should indeed exit with non-zero exit code to signalize and make awareness about unexpected error.

[patschi]

I might have found the relevant parts as svenpeter42 mentioned earlier.

As per documentation it returns Count as int: https://www.inwx.com/en/help/apidoc/f/ch02s08.html#domain.list

Therefore the goinwx structure also uses int obviously: https://github.com/nrdcg/goinwx/blob/0507edb5934746bf334b8c2f109c0cf47b4a9601/domain.go#L321-L322

However the API looks like returning a string instead:

I'm reaching out to INWX to get this addressed ASAP.

Edit: Raised ticket IX#10026265 with INWX.

[patschi]

The INWX implementation is still broken, because INWX doesn't seem to be able to fix the type-casting within the last 3 weeks.

@tlimoncelli Any idea how we can workaround this?

[tlimoncelli]

Hmm.. yes, that's an interesting problem!

Here's my advice:

1. Submit a PR to https://github.com/nrdcg/goinwx/ that updates the code to match the protocol. That is, change the type of Count to be string, and have the function List decode the string into an int, possibly stored in the struct as CountInt. They'll either accept the PR or it will make the API problem visible and easier to get fixed.

2. Copy the code for struct DomainList and the function List to a file (suggested name: dnscontrol/providers/inwx/goinwxfix.go) and decode the string into an int. Include a comment that this is a temporary work-around until they fix the API. It might even be possible to write the code so that it works now and after they fix the API.

Do either of those appeal to you?

Tom

[patschi]

I think option 2 would be best. As per their own API documentation the value should be integer. As it was working earlier, I think any change in their API backend broke and changed the data type, breaking the go-API implementation.

As it's only a mistake, I think option 2 would be best suited for a temporary workaround. I'm really disappointed INWX not taking this more serious and taking now many weeks to address this. (Should only be a quick type cast change from string to integer)

I might take a look into option 2 when I've got some time. Not sure how I can implement the change that it works with string and integer, when they finally fix it someday, but let's see.

[patschi]

I have sent a PR for goinwx. Let's see if we can get this merged and released: https://github.com/nrdcg/goinwx/pull/6

I was able to verify the workaround using the added code - it's working fine after that. Fixing it in upstream repo will be way easier going forward.