Technical Information

RadioDNS is primarily designed for broadcast radio services. You won’t need any DNS entries if you have no broadcast signals.

You can create / publish content using our standards. You can have an SI file that describes your service(s) and PI file that describe your programme schedule, as well as implementing visuals.

Follow the guidance in TS 102 818 about placing <link rel> elements in the head of your website home page. This provides the necessary hint to any passing robot crawlers about where to find your SI / PI files. You should also set up the relevant SRV records on your Fully Qualified Domain Name.

You just don’t need to tell us about it, or ask for DNS records to be created.

The exact details depend on how each manufacturer has implemented it.

In short, the normal approach is:

• Listener tunes to the radio station
• The receiver uses RadioDNS lookup to find the SI for that service, and within that, the stream URL
• The radio starts streaming in the background, long enough to work out the latency between broadcast and streaming. (So if your stream is 30s behind broadcast, it may stream for about 30seconds)
• Having worked out the latency, it starts to delay the broadcast radio audio by the same amount
• After a period of time, the broadcast radio is now delayed by the same amount as the stream – the two sources are mostly time aligned
• When the broadcast signal is bad, the streaming starts again, and any small timing errors (jitter) are corrected fairly quickly, before the audio source switches to the stream.
• The radio continues to monitor the broadcast signal and does a similar process in reverse to return the audio back to the broadcast signal when the quality is good enough

If you don’t want a receiver to switch to your stream, or only do it in certain areas, you can use the geo-fencing definitions in the SI file to restrict where it happens.

The DNS lookup (to radiodns.org) is authoritative and trusted.

When you acquire information about a <service> through some means other than a direct DNS lookup, you should validate all the <bearer> elements on it against DNS. Make sure that if you do a DNS query using the details in the bearer that it leads back to the same SI file.

We have a handy tool in our Github called radiodns-cli. You can use this to validate an SI file. Give it the FQDN of the SI file you want, and it’ll download it, validate it, and give you the validated output as an XML file.

You need to let us know (on registrations@radiodns.org) every time one of the <bearer> elements in your SI file changes. That’s because we need to make sure the DNS records correlate with each broadcast bearer you have.

The easiest way to update us is to give us your FQDN (Fully Qualified Domain Name), and tell us that your SI file has changed. You can do that with an automated email if you prefer.

Usually we’ll be able to process changes immediately. Sometimes we may need to verify that you own / have permission to change the DNS record(s) for the bearer(s) you’re claiming.

We can’t. We don’t hold any radio station data. Here’s our advice on what to do:

• Make sure you’re providing your up-to-date station logo using our standard – you can use our testing tool to check
• Some car manufacturers buy databases from third parties. We can’t update those databases. Contact the car manufacturer to find out who they use, and how to get it updated
• If you’re not able to contact the manufacturer, let us know, and we might be able to.