Enabling test RadioDNS services
Robin Cooksey
Hi All,
A problem that I suspect other people may have encountered is of testing and developing prototype RadioDNS based services, on a RadioVIS enabled radio receiver.
I know that people have user a variety of techniques to “trick” receivers into using test or development services (e.g. using a specific DNS server with hard-coded entries in radiodns.org, or intercepting specific TCP connections); but I wondered whether there was anything we could do to make this easier on arbitrary devices, particularly out in the “wild” – i.e. outside of closely controlled network environments.
One idea that I can think of is allow for alternative “search domains” to be used, which radios try first (before radiodns.org), so entries in an alternative search domain would effectively override actual radiodns.org entries. This would allow new services for stations that don’t currently have any RadioDNS services available to be tested, but also alternative test services to be tested for stations that already have live services.
I’d envisage users being able to add alternative search domains via a menu on the device (possibly using some kind of test mode, or build), which will then be tried first, before radiodns.org.
In this way, users need to know a piece of information (the relevant alternative search domain) in order to get access to these test services – there would not be a way of just enabling test services, or even discovering what services might be available.
This would allow broadcasters (and others) to experiment with services, without those being publically available, or discoverable without knowledge of the search domain.
It would be possible to extend this idea to have a common, generic domain which could be easily “opted-in-to” by users, if that was desirable (e.g. “beta.radiodns.org”).
Obviously this kind of approach will only work well if it is generally made use of – e.g. if receivers with RadioDNS capabilities allow alternative search domains to be entered, and people developing RadioDNS services make use of alternative search domains in this way to allow the services to be tested.
So, initially, I’m just wondering whether people think this is an idea that could be useful – and should be developed further?
Best regards,
Robin
James Cridland
You're not the only one to have this thought. I have been pushing for this for a while.
I would like an alternative test DNS server, run by the RadioDNS Project, with a developer's front end to let you enter dummy entries. It should pass through to the main DNS server otherwise.
The problem I would like to fix - and this is a real life issue - is to encourage a developer to put RadioVIS functionality into the FM tuner he writes for Cyanogenmod (a popular alternative Android ROM). But he's in Melbourne, and there are no RadioVIS/FM services there, so he can't test. I'd like him to be able to add a dummy service for Fox FM, which (could) connect to a dummy RadioDNS VIS server, to enable him to test properly.
Is the Amazon or Rackspace DNS API good enough for this? Anyone want to write something (we can host)?
J
--
You received this message because you are subscribed to the RadioDNS developers group. RadioDNS is at http://radiodns.org/
To post to this group, send email to
radiodns-...@googlegroups.com
To unsubscribe from this group, send email to
radiodns-develo...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/radiodns-developers?hl=en
Andy Buckingham (RadioDNS)
for RadioDNS.
Happy to take this on and investigate further?
Andy.
Andy Buckingham
RadioTAG Application Team Lead
RadioDNS Project and Global Radio (UK)
t: +44 (0)117 900 5357
e: andy.bu...@radiodns.org
w: http://radiodns.org/
Follow the RadioDNS Project via Twitter: @radiodns
Dave Cridland
> You're not the only one to have this thought. I have been pushing
> for this
> for a while.
>
> I would like an alternative test DNS server, run by the RadioDNS
> Project,
> with a developer's front end to let you enter dummy entries. It
> should pass
> through to the main DNS server otherwise.
>
> The problem I would like to fix - and this is a real life issue -
> is to
> encourage a developer to put RadioVIS functionality into the FM
> tuner he
> writes for Cyanogenmod (a popular alternative Android ROM). But
> he's in
> Melbourne, and there are no RadioVIS/FM services there, so he can't
> test.
> I'd like him to be able to add a dummy service for Fox FM, which
> (could)
> connect to a dummy RadioDNS VIS server, to enable him to test
> properly.
>
> Is the Amazon or Rackspace DNS API good enough for this? Anyone
> want to
> write something (we can host)?
think the developer would be far better off running dnsmasq somewhere
and using that as the DNS server.
dnsmasq allows you to specify overriding SRV and TXT records (amongst
others) on the command line, so you could "spoof" RadioDNS records
just fine.
It does need a Linux system of some kind to run on. Of course,
Android *is* such a system, in this case.
Dave.
--
Dave Cridland - mailto:da...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Casagranda Paolo
Hi Robin and all,
the idea is very useful, specially with a common “beta” domain for testing purposes. We spent time setting up a tricky solution, working only in our intranet.
Kind regards
Paolo
Da: radiodns-...@googlegroups.com [mailto:radiodns-...@googlegroups.com] Per conto di Robin Cooksey
Inviato: venerdì 4 maggio 2012 12:55
A: radiodns-...@googlegroups.com
Oggetto: [RadioDNS-Dev] Enabling test RadioDNS services
--
You received this message because you are subscribed to the RadioDNS developers group. RadioDNS is at http://radiodns.org/
To post to this group, send email to
radiodns-...@googlegroups.com
To unsubscribe from this group, send email to
radiodns-develo...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/radiodns-developers?hl=en
James Cridland
Where new platforms and radio collide: http://james.cridland.net/blog/
Andy Buckingham (RadioDNS)
specify an alternative suffix/search domain in conjunction with
RadioDNS providing a temporary/sandpit DNS domain.
This way a broadcaster can be stealth and use their own domain, with
RadioDNS style prefixes (08770.c000.ce1.fm.mydomain.net) or
alternatively use a RadioDNS test area
(08770.c000.ce1.fm.demo.radiodns.org) - the client simply being
configured to use mydomain.net or demo.radiodns.org as the search
suffix.
With regards to a model for the sandpit, could we have a simple
registration approval, which allows someone to then request leases (up
to a period of, say, 14 days) in the test area?
James Cridland
could we have a simple
registration approval, which allows someone to then request leases (up
to a period of, say, 14 days) in the test area?
Andy Buckingham (RadioDNS)
that allows the inclusion of records in the pit, purely to reduce the
risk of abuse.
I am concerned about automatically looking through the pit to "live"
records in the public NS due to the risk of a device being
accidentally left on the sandpit NS. I think it should be clear if you
reconfigure your device you will only see test entries.
If we have a use case for a developer being able to scan through
multiple stations and check it changes properly, could I suggest we
fall back to a demo service that, for example, serves a VIS slide that
says "You're using the server on frequency X, PI code Y"? RadioDNS
could provide a similar demo tag implementation and RadioEPG too.
Robin Cooksey
So, I think the idea of user configurable "alternative" RadioDNS search domains (at least in test or demo binaries) fits in with this proposal for a generic common sandpit.
To opt in to the sandpit, the user configures the radio with the generic sandpit search domain (test.radiodns.org? demo.radiodns.org?).
Alternatively, (as you mentioned elsewhere in this thread), it also allows the user to provide their own search domain, with radiodns.org-style entries, which enables them to get access to test or demo services, while remaining more stealthy about there availability.
The reason why I think this is still worthwhile (rather than just running dnsmasq somewhere - and pointing at that as a DNS server) is that this would make it much easier to create test and prototype services which can then be easily accessed from anywhere, with a simple configuration change. This can be important for demos which are more portable, or to enable field triallers to get to test services; without having to be inside a corporate network.
In terms of the automatic fallback to "live" records, I had envisaged the "alternative" search domains as being tried first - and then falling back to the real radiodns.org. My reasoning was that it's often only a small number of services that you want to override for test or demo purposes, while still keeping live services available.
I think it probably still makes sense to do this, but I agree it might be better for the "generic" sand-pit domain to fall-back to a demo service as you describe (i.e., so the radio will never in practice fall-back to raidodns.org).
The reason why I think it makes sense for there to be a difference, is that in the "private" alternative search domain case, the owner of that private domain (and therefore the person who has provided that information) will know exactly which services are in that domain - so which services will not pick up the live services. However, for the generic, common sand-pit domain; nobody knows which services someone else might have added a test entry for at any given time - so it makes sense for it to be more obvious that this sand-pit domain is in use.
Does this make sense?
Cheers,
Robin
Nick Piggott (RadioDNS)
Hello,
I may well be getting this wrong, but could we potentially enable testns1.radiodns.org which would hold entries on test, but refer other queries in the radiodns.org zone to the mainline ns server?
Would that make it an easier option for the device to use either normal DNS or test DNS for queries in the radiodns.org zone?
Nick
James Cridland
I would be keen to avoid automatic fallback to live records, since I would not want this test server to ever be mistakenly used as a live one.
Should live services be desirable, I would expect sandpit users to configure these as they would any other service: and all sandpit entries should automatically delete themselves after two weeks (or the user be given an option to renew).
Ideally, the Project might host a "default" RadioVIS and EPG entry that feeds back "This is 98.8 C163 on GB FM" or similar?
J
Nick Piggott (RadioDNS)
Andy Buckingham (RadioDNS)
> Yes, I understand the concern. A couple of things could offset that risk:
> * Real devices access their "local" DNS which in turn refers upstream
> etc.etc. to finally get to ns1/2/3.radiodns.org
> * The test.radiodns.org would only forward queries into radiodns.org. We
> couldn't risk setting up ns1/2/3.radiodns.org as general referrers.
device via this new method to test.radiodns.org, walks away and
forgets about it. Weeks later wonders why Station X's VIS feed is
being overriden by some unusual VIS service which happens to just be a
configuration in the sandpit, complains to service
provider/manufacturer etc. etc.
The only way I can see of making it obvious to a user that test is
still on is that any non-test configured station shows a very obvious
"test card" rather than forwarding to live services. Ideally this card
would carry a note that they're pointing to test NS, or should view
radiodns.org/tests etc. for details of why they might be seeing it.
A
Robin Cooksey
Thank you for the feedback and contributions on this issue. I think the general consensus is that while it's possible to work around this problem, at least in a controlled environment, it would be useful to have some easier solutions - and having a publically editable test domain (albeit with prior per-user approval, and timeouts for entries) seems to be something that would solve at least some of the problems people have.
I think I agree that for the publically editable sandpit (test.radiodns.org?), fall-back to the live radiodns.org entries is probably a bad thing - for the reasons that you mention, and also the fact that entries could be changed by anyone else at any time.
I also like the idea of dynamically creating slides (with the service parameters on them, and a reference to radiodns.org) for any entry which hasn't specifically been overridden - so effectively, every service demonstrates working RadioVIS.
However, I still think that (for test and demo builds at least), it would be useful to have alternative search domains (which contain only specific services to override), before falling back to radiodns.org. I accept that there's a risk of forgetting that these alternative domains have been entered - but I think that's a relatively small risk, especially as it isn't just a generic flag that can be enabled without some knowledge. Also, once enabled, the entries within the alternative domain are presumably under much more limited control than the publically editable sandpit.
So, I think these two approaches fit together - the ability to add alternative search domains will solve some issues, and this also enables the test sandpit to be easily accessible, without re-directing all DNS queries, or having to change to actual DNS server addresses.
Cheers,
Robin
> -----Original Message-----
> From: radiodns-...@googlegroups.com [mailto:radiodns-
> devel...@googlegroups.com] On Behalf Of Andy Buckingham (RadioDNS)
> Sent: 09 May 2012 07:26
> To: radiodns-...@googlegroups.com
> Subject: Re: [RadioDNS-Dev] Enabling test RadioDNS services
>