[Sugar-devel] Notes on service discovery XS/XO

[david at lang.hm]

On Mon, 20 Apr 2009, Martin Langhoff wrote:

> On Mon, Apr 20, 2009 at 6:56 PM, Jonas Smedegaard <dr at jones.dk> wrote:
>> I don't understand your question.  Sounds like prefetching that isn't
>> part of dns (id you perhaps think of DHCP here?)
>
> I don't have my well-worn "DNS and BIND" book with me right now but I
> am positive that the server side can decide to give the client
> additional entries. It's colloquially known as the "additional
> section". Been doing BIND and djbdns admin for 10+ years.
>
> If we have - for example - <10 services, it is an excellent bw saving
> strategy to push the 10 services in the additional section, so that
> the client caches it in the first request, rather than issuing 10
> separate requests.

my initial reaction to this is that it's going to look to the client 
exactly the same as a bad guy trying to poison DNS by sending unasked for 
responses, how do the clients tell the difference?

also note that this will require that you run some sort of DNS cache on 
the client, otherwise the particular app that did the DNS request will go 
on with life and make the exact same request again.

>> You are right that BIND9 is a bastard with memory consumption, and it
>> makes sense to use dnsmasq on the XS.  I just didn't think of that - I
>
> Well, right now we have BIND + DHCP. BIND is a serious mismatch for
> the XS. We are doing quite a bit of advanced dhcpd configuration which
> we will want to replicate. For a quick summary:
>
> - We just have a small handful of important local names to serve via
> DNS (but we may want to push them in the 'additional section' as
> oulined above).
>
> - For the DHCP svc we listen on various network interfaces and assign
> addresses in _different netblocks_ according to the network interface
> that received the request. Tricky! See
> http://dev.laptop.org/git/projects/xs-config/tree/altfiles/etc/sysconfig/olpc-scripts/dhcpd.conf.1
>
> - To make matters more complex, my plan is to evolve towards
> assigning different addresses once the user registered -- to
> cordon-off internet access, a bit like pay-to-play internet-cafe
> routers do. That requires a bit of poking at the dhcp daemon to
> whitelist specific MAC addresses and forcing the user to re-request
> the lease.

take a look at packetfence. it does exactly that job today, for free, on 
linux (among other platforms)

I think it even handles the multiple interfaces/netblocks problem, but I 
could be wrong.

David Lang