Hi,

Why Centova Cast is not allowing using domain name instead of IP address.

This is issue if machine IP address will change.

I have this issue now when I have migrated my server and all my customer have ip based url in playlists (as this is set within sc config files)

Please can you allow using domain names in SC config files (destip, srcip) through panel ?

You have already hostname field so why don't use this and allow customer to choose domain or ip based listen urls.

You could also change IP address field to be IP/Hostname address and allow to enter host/domain names in this field.

Regards

I mean of course 'destip' and 'srcip' settings in sc_trans and sc_serv which are set using IP Address filed in centova and NOT CentovaCast 'Admin' and listen links URLs in panel

The srcip/destip values have nothing to do with tune-in URLs.  srcip/destip are the IP addresses to which the SHOUTcast server binds to accept connections.  You almost certainly don't want to set those to hostnames (even if it's possible to do so) because it adds another potential (and substantial) point of failure -- in the event that your server ever has a problem with its local DNS resolver, your clients' streams will be unable to start.

The URLs generated by Centova Cast to point to the streaming server (including those in the tune-in playlists) can be configured to use the stream's hostname instead of IP address by enabling SELFREF_HOSTNAME in centovacast.conf.

destip is used by the current DNAS as part of the listen playlists it generates as well as what will be provided to people via the SHOUTcast Directory (if the stream is set to be publically listed). yes using DNS can be a possible point of failure for stream access (though no more than the IP of a stream changing).

however the benefits it provides over IP only listings massively outweighs the possible issues and for the listeners gives a far better experience than accessing streams with IP addresses (is an all too common complaint that bookmarks to the direct stream break due to IP changes when a DNS based url for the stream would resolve the issue in most cases).


srcip is never publically used in any responses and is a bit of a hack at best anyway (not even sure it works with DNS entries anyway).

destip is used by the current DNAS as part of the listen playlists it generates as well as what will be provided to people via the SHOUTcast Directory (if the stream is set to be publically listed).

Ah, my mistake -- I thought we were talking about the use of destip within Centova Cast's generated playlists, as opposed to DNAS' generated playlists.

yes using DNS can be a possible point of failure for stream access (though no more than the IP of a stream changing).

I guess my concern is more about unplanned failures.  The IP address for a stream is never going to change spontaneously -- the server administrator will always be in direct control of that, and can make arrangements/announcements to mitigate the impact of the change.

Conversely, the DNS resolver used by the server could go down at any time.  The server administrator may not (and in most realistic cases, will not) even be in charge of his local DNS resolver -- in most cases that's maintained by his datacenter or upstream.  And if the resolver goes down, then DNAS will not even be able to start, because DNAS' call to bind() will fail since it cannot resolve the hostname into an IP address.

however the benefits it provides over IP only listings massively outweighs the possible issues and for the listeners gives a far better experience than accessing streams with IP addresses

Oh, absolutely no argument there.  My concern is just the reuse of destip as both the bind address *and* the address used for URL generation... usually (at least in the UNIX world) configuring a daemon to bind to a hostname rather than an explicit IP address is considered a "no-no".

the DNAS will skip over things if the binding failis to work (due to whatever issue on the machine / setup when loaded) so if DNS does fail, it's not going to prevent the DNAS from starting (unless something really screws with the DNAS at that stage). sure it's probably not how it's meant to work but from internal usage and from working with config issues, it allowed users to achieve what they want even if things on the machine aren't something that they can easily change or is not configured correctly (as it will go back to running like destip has not been set if the checks report absolute junk).

the only possible problem is that if the bind does fail and destip is set to a DNS value, then the responses from the DNAS will still use the DNS entry for DNAS generated playlists for example which could be an issue (though even in that case, it will most likely work as expected since it bases most things off the request url before generating things and if someone can access the DNAS, then that's the main issue already resolved).

Thanks guys for this conversation.
I have used domain names in SC outside of Centova and I've never had any problems with those.

I know that there are advantages and disadvantages so my suggestion is to allow users to choose which option they want to use.

You can make this configurable even more:

- use domain name based addresses Yes/No
--If Yes
--- Do you want to use domain name for AutoDJ connection ? Yes/No
-----Yes - set source binding and destination address as domain name
-----No - set source binding address as IP, set destination address as domain name
--If No - use IP everywhere

What do you think ?

You have already some engine to write configuration so I think it quite quick to do.

Thanks Again

I second this request. Using a hostname for destip is a very good idea. This will make a migration of physical server, when IP address changes, much less painful. And clients will not have problems with their listings in the directory - last time we migrated our server we had a huge number of support requests about failed directory listings...