Re: [Sugar-devel] Notes on service discovery XS/XO
On Wed, Apr 22, 2009 at 2:46 AM, da...@lang.hm wrote: I believe this is exactly what has been done over the last few years in the DNS server/DNS cache software. they used to accept extra responses like you are trying to make, but nowdays they don't. As everyone pointed out, I was wrong about plain client resolvers. My understanding of the tightening of the rules is that resolving servers -- which could end up with a poisoned cache -- now apply strict rules to what they accept in the additional section. But it may well be that things have been tightened further and clients completely ignore it. I got the ignore unrelated / non authoritative entries memo, maybe there's been an ignore everything one. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Notes on service discovery XS/XO
martin wrote: On Tue, Apr 21, 2009 at 2:05 AM, da...@lang.hm wrote: also note that this will require that you run some sort of DNS cache on the The standard dns resolver libs on linux (part of glibc?) caches alright. All platforms I know cache things alright, and it's fairly serious bug if your OS doesn't. really? while that was the original design intent of the resolver library, i didn't think it was ever implemented that way in practice (on unix, at any rate) -- user programs tend to only look up a name once, so caching in the resolver library wouldn't do much good. i believe caching is usually only done by servers. paul =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Notes on service discovery XS/XO
On Tue, 21 Apr 2009, Martin Langhoff wrote: On Tue, Apr 21, 2009 at 2:05 AM, da...@lang.hm wrote: 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? They can't. That's how DNS works. Lots of ink have flowed on that very topic. I'm not interested in bikeshedding, I'm interesting in using DNS smartly, and in getting help to get it done. if the client can't tell the difference between what you are doing and what the bad guys are doing, the client has no choice but to ignore any unexpected responses, as they may be bogus. I believe this is exactly what has been done over the last few years in the DNS server/DNS cache software. they used to accept extra responses like you are trying to make, but nowdays they don't. implementing something that is on it's way out (due to it becoming a security problem) is not a smart thing to do. also note that this will require that you run some sort of DNS cache on the The standard dns resolver libs on linux (part of glibc?) caches alright. All platforms I know cache things alright, and it's fairly serious bug if your OS doesn't. actually they don't. you can run a DNS cache on your machine (and many distros do by default), but it's not part of the default resolver. take a look at packetfence. it does exactly that job today, for free, on linux (among other platforms) Doesn't look like a fit for the XS, did you look at it? I'm reasonably familiar with packetfence, I don't know the full requirements that you have for the XS, but your short description sounded like the job that it does (summarized as a hotel-like access control) Weird. I do have some things to build, but everyone ignores them and keeps bikeshedding. Code talks, peoples. you are free to ignore comments, and existing tools, but if that's what you want, why post here, just write the tools and then we'll identify that you have recreated the wheel. David Lang ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Notes on service discovery XS/XO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Langhoff wrote: The short of it is that mdns/dns-sd make sense for a small, underutilised network of peers. They assume that the network is a cheap resource, that broadcast messages are cheap, and that there is no coordinating server. mDNS assumes all of the above things. DNS-SD does not. DNS-SD is perfectly happy to work on a standard DNS server. From the spec This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values. This document simply specifies a convention for how existing resource record types can be named and structured to facilitate service discovery. (http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt) I'm not particularly knowledgeable about the XS service discovery requirements, nor about DNS, so I can't reasonably tell you to use DNS-SD. What I can say is that it seems like it should be workable. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAknsW+UACgkQUJT6e6HFtqSx5QCglzpN+96F9aTAH05KnsQszg3E vy4An0lCtq/z04OKiFVvv5TvXUcNnkZ5 =TRBq -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Notes on service discovery XS/XO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Apr 20, 2009 at 07:26:30AM -0400, Benjamin M. Schwartz wrote: Martin Langhoff wrote: The short of it is that mdns/dns-sd make sense for a small, underutilised network of peers. They assume that the network is a cheap resource, that broadcast messages are cheap, and that there is no coordinating server. mDNS assumes all of the above things. DNS-SD does not. DNS-SD is perfectly happy to work on a standard DNS server. From the spec This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values. This document simply specifies a convention for how existing resource record types can be named and structured to facilitate service discovery. (http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt) I'm not particularly knowledgeable about the XS service discovery requirements, nor about DNS, so I can't reasonably tell you to use DNS-SD. What I can say is that it seems like it should be workable. DNS-SD using unicast DNS seems reasonable to me too. Looking closer at the RFC, the initial service queries do have an added overhead in that a layer of indirection is used (not SRV - A, but instead PTR - SRV + TXT - A). But standard DNS optimizations apply, so SOA record should allow clients to preserve bandwidth through caching. In other words: Install dnsmasq on the XOs, use plain standard DNS internally and on the wire, setup DNS-SD entries in a standard nameserver on the XS, and extend Sugar to support DNS-SD. I'd be happy to help compose standard BIND9 files, if that is what will be used on the XS. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknsflUACgkQn7DbMsAkQLiL2wCfV/HuaLPQ0kv/mvYH4fdImsIs ookAnAu5ir3uxxKNjCdTwu4gfNxdE4hZ =7Jde -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Notes on service discovery XS/XO
On Mon, Apr 20, 2009 at 3:53 PM, Jonas Smedegaard d...@jones.dk wrote: DNS-SD using unicast DNS seems reasonable to me too. If we can do without the avahi gunk, and use it in a way that is not optimised for user driven browsing but for automated selection of services, then it might work. Looking closer at the RFC, the initial service queries do have an added overhead in that a layer of indirection is used (not SRV - A, but instead PTR - SRV + TXT - A). But standard DNS optimizations apply, so SOA record should allow clients to preserve bandwidth through caching. Can we teach dnsmasq to push all the relevant records with the SOA record? In other words: Install dnsmasq on the XOs, use plain standard DNS internally and on the wire, setup DNS-SD entries in a standard nameserver on the XS, and extend Sugar to support DNS-SD. I'd be happy to help compose standard BIND9 files, if that is what will be used on the XS. If we have a dnsmasq resident expert, I rather use your help transitioning to dnsmasq (note - with several bits of weird dhcp rules). There is no upside to BIND and plenty of downsides, starting with the 25MB memory footprint. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Notes on service discovery XS/XO
martin wrote: On Mon, Apr 20, 2009 at 3:53 PM, Jonas Smedegaard d...@jones.dk wrote: DNS-SD using unicast DNS seems reasonable to me too. If we can do without the avahi gunk, and use it in a way that is not optimised for user driven browsing but for automated selection of services, then it might work. Looking closer at the RFC, the initial service queries do have an added overhead in that a layer of indirection is used (not SRV - A, but instead PTR - SRV + TXT - A). But standard DNS optimizations apply, so SOA record should allow clients to preserve bandwidth through caching. Can we teach dnsmasq to push all the relevant records with the SOA record? In other words: Install dnsmasq on the XOs, use plain standard DNS internally and on the wire, setup DNS-SD entries in a standard nameserver on the XS, and extend Sugar to support DNS-SD. I'd be happy to help compose standard BIND9 files, if that is what will be used on the XS. If we have a dnsmasq resident expert, I rather use your help transitioning to dnsmasq (note - with several bits of weird dhcp rules). There is no upside to BIND and plenty of downsides, starting with the 25MB memory footprint. i'm a big fan of dnsmasq, but be sure it will fulfill all your needs before doing too much work on it -- it's not quite a full-fledged DNS server -- as an example, dnsmasq doesn't support CNAME: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2006q1/000583.html - ask interesting questions simon kelley (dnsmasq author) is extremely helpful on the dnsmasq list, btw, so it shouldn't be too hard to get interesting answers, as well. :-) paul =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Notes on service discovery XS/XO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Apr 20, 2009 at 04:08:30PM +0200, Martin Langhoff wrote: On Mon, Apr 20, 2009 at 3:53 PM, Jonas Smedegaard d...@jones.dk wrote: DNS-SD using unicast DNS seems reasonable to me too. If we can do without the avahi gunk, and use it in a way that is not optimised for user driven browsing but for automated selection of services, then it might work. Looking closer at the RFC, the initial service queries do have an added overhead in that a layer of indirection is used (not SRV - A, but instead PTR - SRV + TXT - A). But standard DNS optimizations apply, so SOA record should allow clients to preserve bandwidth through caching. Can we teach dnsmasq to push all the relevant records with the SOA record? I don't understand your question. Sounds like prefetching that isn't part of dns (id you perhaps think of DHCP here?) As I understand dns, if you request a SOA record, then you get a SOA record and only that. You can request the whole domain, but that does not seem bandwidth saving to me. The main bandwidth saver, I believe, is that of sane query caching and knowledge of the segments of the domain structure. In other words: Install dnsmasq on the XOs, use plain standard DNS internally and on the wire, setup DNS-SD entries in a standard nameserver on the XS, and extend Sugar to support DNS-SD. I'd be happy to help compose standard BIND9 files, if that is what will be used on the XS. If we have a dnsmasq resident expert, I rather use your help transitioning to dnsmasq (note - with several bits of weird dhcp rules). There is no upside to BIND and plenty of downsides, starting with the 25MB memory footprint. If that's me you titulate so nicely, then you are way too kind: I have only little experience with dnsmasq used as a caching-only name server, i.e. zero experience with dnsmasq as a real name server containing local data. 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 suggested it as a caching-only on the XOs. ISC DHCPd has a complex macro language, however, which might be the upsight you cannot live without. Beware that it is DHCP, not DNS ;-) It seems from its changelog that dnsmasq supports DNS-SD since version 2.36. Tell me more specifically what you fear can be tricky to handle in dnsmasq, either DHCP or DNS parts, and I shall have a look if I am any good at helping out. - Jonas [1] http://twistedmatrix.com/pipermail/twisted-python/2003-July/004909.html - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknsqTwACgkQn7DbMsAkQLjpwwCfSEhWMNOv6gyo9cGaBb3YTyGU OTYAni/jIMqj2nunJlwUwTNBDQc9t6E9 =ePu7 -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Notes on service discovery XS/XO
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Apr 20, 2009 at 09:45:28AM -0400, p...@laptop.org wrote: benjamin m. schwartz wrote: Martin Langhoff wrote: The short of it is that mdns/dns-sd make sense for a small, underutilised network of peers. They assume that the network is a cheap resource, that broadcast messages are cheap, and that there is no coordinating server. mDNS assumes all of the above things. DNS-SD does not. DNS-SD is perfectly happy to work on a standard DNS server. From the spec This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values. This document simply specifies a convention for how existing resource record types can be named and structured to facilitate service discovery. (http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt) the last i looked at (and actually used) dns-sd to solve the discovery problem, it seemed that dns-sd development had stalled. (and i haven't had a reason to look since.) i believe we used code from Sun, which was all i could find at the time, and it wasn't what you'd call production ready. on the other hand, we were using it in a somewhat non-standard way -- in fact, we switched to mdns soon after because it fit our deployment model better, since we didn't really have a central server. the XS model may be a better fit. (this was all 3 or 4 years ago, btw.) Here's my understanding: * DNS-SD is a formalized use of DNS records to store services (rather than hosts, the most popular use of DNS records). * mDNS is DNS over multicast (using DNS-SD to resolve services). So it seems to me that if you've switched from DNS-SD to mDNS, then in fact you are still relying on DNS-SD, just using an additional layer on top of it. A good introduction (assumably more reliable than Wikipedia) is http://www.dns-sd.org/ - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkns0S8ACgkQn7DbMsAkQLipkACfW9CWHqtdtytFZuNrCzm0Jmrd jIkAn3zqgu6B6Ic7sFeINPjVGpmjmKCA =J4B8 -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Notes on service discovery XS/XO
jonas wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Apr 20, 2009 at 09:45:28AM -0400, p...@laptop.org wrote: benjamin m. schwartz wrote: Martin Langhoff wrote: The short of it is that mdns/dns-sd make sense for a small, underutilised network of peers. They assume that the network is a cheap resource, that broadcast messages are cheap, and that there is no coordinating server. mDNS assumes all of the above things. DNS-SD does not. DNS-SD is perfectly happy to work on a standard DNS server. From the spec This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values. This document simply specifies a convention for how existing resource record types can be named and structured to facilitate service discovery. (http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt) the last i looked at (and actually used) dns-sd to solve the discovery problem, it seemed that dns-sd development had stalled. (and i haven't had a reason to look since.) i believe we used code from Sun, which was all i could find at the time, and it wasn't what you'd call production ready. on the other hand, we were using it in a somewhat non-standard way -- in fact, we switched to mdns soon after because it fit our deployment model better, since we didn't really have a central server. the XS model may be a better fit. (this was all 3 or 4 years ago, btw.) Here's my understanding: * DNS-SD is a formalized use of DNS records to store services (rather than hosts, the most popular use of DNS records). * mDNS is DNS over multicast (using DNS-SD to resolve services). sigh. please disregard everything i wrote in the paragraph above. i was mistakenly referring to DNS-SD when i should have been referring to SLP (service location protocol). we migrated from SLP to mDNS. this has nothing to do with anything martin has proposed for the XS. sorry! :-) paul So it seems to me that if you've switched from DNS-SD to mDNS, then in fact you are still relying on DNS-SD, just using an additional layer on top of it. A good introduction (assumably more reliable than Wikipedia) is http://www.dns-sd.org/ - Jonas =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Notes on service discovery XS/XO
On Mon, Apr 20, 2009 at 9:46 PM, Jonas Smedegaard d...@jones.dk wrote: Here's my understanding: I've read the damned specs, don't worry. I need help getting sh*t done because there's a lot of stuff to do. any takers? m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Notes on service discovery XS/XO
On Mon, 20 Apr 2009, Martin Langhoff wrote: On Mon, Apr 20, 2009 at 6:56 PM, Jonas Smedegaard d...@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___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
