Technical Information

Everything you need to implement RadioDNS Hybrid Radio

Documentation and Information


RadioDNS Technical Standards and Guidelines


HowTo Guides

Simplified guides to implementing the main RadioDNS functionality

HowTo Guides

Register your station

How to create DNS entries for your station

Register a Station with RadioDNS

Project Logo

The baseline of RadioDNS functionality

Read more


Simple Testing Tool

Use this to carry out basic checks on your RadioDNS configuration

Simple Testing Tool

SI Builder

A browser based tool to construct SI (Service Information) files - the building block of RadioDNS

SI Builder

Testing Platform

Our Members have access to a more extensive suite of testing tools

Testing Platform

Software Libraries

Links to useful software libraries that you can use in development

Software Libraries

Chat, discuss and share with our community


Open source code and discussions

Goto Github

Discussion Boards

Ask your questions and get answers about building with RadioDNS

View Discussions

Technical Group

Members can join our technical group and working teams

Read more

How to implement RadioDNS

Implement yourself

If you have your own web / software development team, they can probably add RadioDNS functionality to your existing systems. Once it’s set up, it should be entirely self-managing, meaning one less thing to think about keeping updated. Just read through the documentation, browse the HowTo guides¬†and ask for help in our forums.

Implement with a Service Provider

You can work with one of our partners to implement RadioDNS. They’ll do all the work to integrate with your existing systems and get your content out into our standardised formats. Some partners offer a basic service for free.

Technical FAQ

The technical questions we get asked most often.

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 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 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.