Re: [Dnsmasq-discuss] dnsmasq and sshfp records
On 24/05/12 19:17, Jan-Piet Mens wrote: keys as SSHFP-Records, so that I'm able to call via ssh user@remotehost-o VerifyHostKeyDNS=yes and get a result line like Matching host key fingerprint found in DNS. This may or not be painful, if you're not using DNSSEC. (You may like to glance at a discussion, and the comments, at [1].) Since I've nothing found, seems like dnsmasq doesn't support SSHFP-Records, right ?!?! I don't think this is possible at the moment, but we'll have to ask Simon. Simon? Are you there? :-) No! The sun is shining and I'm lying in my hammock :-) Well I was yesterday, back now. Dnsmasq doesn't support SSHFP records. It doesn't support arbitrary DNS records types at all and historically, support for particular record types has been added ad-hoc for particular types that have proved to be useful. It would be possible to do the same thing for SSHFP, but possibly of minimal use, given JP's discoveries. An alternative would be to add some general RR-type support, rather like the DHCP option support. You can specify any DHCP option, but if its one dnsmasq doesn't know, you may have to do the encoding to hex yourself. dhcp-option=30,00:01:02:03 This makes any option at least possible, even if you have to deal with IETF's propensity for designing a new and interesting encoding for each and every new option. The same thing could by done for DNS RRs dns-rr=44,02:01:34:56:. (44 is the RR type for SSHFP, according to RFC 4255) relaxing the hex parsing to make colons and leading zeros optional gets the possibility of something that's almost an natural encoding in this case, and may be generally useful if less easy to use. dns-rr=44,2:1:123456789abcdef67890123456789abcdef67890 Opinions? Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq and sshfp records
relaxing the hex parsing to make colons and leading zeros optional gets the possibility of something that's almost an natural encoding in this case, and may be generally useful if less easy to use. dns-rr=44,2:1:123456789abcdef67890123456789abcdef67890 Opinions? Go for it! I recommend reading RFC 3597, Section 5 on the text-representation of arbitrary DNS RR types, and if possible lean towards that, making lives of people who copy paste RDATA easier. :) -JP ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] A (possibly bad) idea: failover in dnsmasq
Starting just a few days before the day the machine running dnsmasq in my SOHO died, I was giving some thought to how I'd go about ensuring a backup copy of dnsmasq could take over if my only running instance died. Needless to say, the death of the machine left my small network in shambles, because I couldn't connect to anything to fix things without first configuring temporary static addresses; sans DHCP, stuff fails... :) I'm anything but a DHCP specialist, but I want to bounce this idea off you anyway, even if you mind. ;-) The trick, as I understand it, in setting up more than a single dnsmasq instance in a network, is to ensure that it uses --dhcp-script to STORE the leases and --leasefile-ro to force the script to produce a list of current leases (init) from which a launching dnsmasq obtains its data before going on its usual business. If we were able to ensure the data store (i.e. lease database) were available on two machines A and B (and up to date on both of course) the solution would be easy, except for the fact that dnsmasq does not LOOKUP (i.e. query) for a lease in the data store except upon startup. I'm thinking along the lines of having a function lease_query() in lease.c which dnsmasq invokes to determine whether a lease exists before issuing a new lease for a device. Being very lightweight, dnsmasq must not be bloated by having a huge MySQL or other database attached to it. I've been searching the Internets and finally landed upon Tokyo Tryant [1] which I've discussed a long time ago [2]. What I'm basically getting at is providing dnsmasq with an optional very lightweight replicating server which it (optionally) uses to ensure the lease database can be propagated to a second (or third or fourth) dnsmasq instance. The reason I'm suggesting Tryant is that, it too, is lightweight and offers multi-master setups. ++ +-+ | dnsmasq | | dnsmasq| | A | | B | +-+--+ +-+ | + | | | | +-v---+ +--v---+ | Tryant| | Tryant | | A |+- B| | |-+ | +-+ +--+ +-+ +---+ | leases| |leases | |-| |---| +-+ +---+ In other words, dnsmasq (A) reads/writes leases from Tryant (A) and dnsmasq (B) read/writes from/to Tryant (B). If Tryant (A) and (B) can speak to eachother, the database is replicated, irrespective of which dnsmasq (A) or (B) has last written a lease. I'll stop here, before boring you even more, but I'll gladly send you snippets of code and a short howto set up a multi-master system. Most important IMO is to keep things very light-weight in the spirit of dnsmasq. Best regards, -JP [1] http://fallabs.com/tokyocabinet/tokyoproducts.pdf [2] http://jpmens.net/2009/09/06/tokyocabinet-a-wow-replacement-for-dbm/ ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] A (possibly bad) idea: failover in dnsmasq
1,$s/Tryant/Tyrant/g -JP ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] release for debian / ARMv5?
Can anyone tell me, if and where I can get a Debian testing version of IPv6 enabled DnsMasq for Squeeze 2.6.38.8 armv5tel? I don't like to compile it by myself, so I hope anybody here has contact to the .deb packet maintainer here , or just knows about the state. Same question aplies for SlugOS/LE 5.3 (2.6.27.8) from Optware with: Dnsmasq version 2.47 Copyright (C) 2000-2009 Simon Kelley Compile time options IPv6 GNU-getopt no-DBus no-I18N TFTP regards, MM ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] release for debian / ARMv5?
On 25/05/12 14:00, Modem Man wrote: Can anyone tell me, if and where I can get a Debian testing version of IPv6 enabled DnsMasq for Squeeze 2.6.38.8 armv5tel? I don't like to compile it by myself, so I hope anybody here has contact to the .deb packet maintainer here , or just knows about the state. Same question aplies for SlugOS/LE 5.3 (2.6.27.8) from Optware with: Dnsmasq version 2.47 Copyright (C) 2000-2009 Simon Kelley Compile time options IPv6 GNU-getopt no-DBus no-I18N TFTP regards, MM Well, the Debian maintainer is me. The latest release (2.61) with DHCPv6 support is in the testing distro, so you should be able to download it from the Debian mirrors. If you need a backport to Squeeze, I'm afraid that building it yourself is the best bet: it's not in squeeze-backports and I can't offer as I don't have an ARM system available. 2.47 may be more difficult: the source is probably gone from Debian by now and whilst it is available in the dnsmasq Git repo, that doesn't include the debian directory for old releases. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq and sshfp records
On 25/05/12 12:14, Jan-Piet Mens wrote: relaxing the hex parsing to make colons and leading zeros optional gets the possibility of something that's almost an natural encoding in this case, and may be generally useful if less easy to use. dns-rr=44,2:1:123456789abcdef67890123456789abcdef67890 Opinions? Go for it! I recommend reading RFC 3597, Section 5 on the text-representation of arbitrary DNS RR types, and if possible lean towards that, making lives of people who copy paste RDATA easier. :) I'll support that as well. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] A (possibly bad) idea: failover in dnsmasq
On 25/05/12 12:17, Jan-Piet Mens wrote: Starting just a few days before the day the machine running dnsmasq in my SOHO died, I was giving some thought to how I'd go about ensuring a backup copy of dnsmasq could take over if my only running instance died. Needless to say, the death of the machine left my small network in shambles, because I couldn't connect to anything to fix things without first configuring temporary static addresses; sans DHCP, stuff fails... :) I'm anything but a DHCP specialist, but I want to bounce this idea off you anyway, even if you mind. ;-) The trick, as I understand it, in setting up more than a single dnsmasq instance in a network, is to ensure that it uses --dhcp-script to STORE the leases and --leasefile-ro to force the script to produce a list of current leases (init) from which a launching dnsmasq obtains its data before going on its usual business. If we were able to ensure the data store (i.e. lease database) were available on two machines A and B (and up to date on both of course) the solution would be easy, except for the fact that dnsmasq does not LOOKUP (i.e. query) for a lease in the data store except upon startup. I'm thinking along the lines of having a function lease_query() in lease.c which dnsmasq invokes to determine whether a lease exists before issuing a new lease for a device. Being very lightweight, dnsmasq must not be bloated by having a huge MySQL or other database attached to it. I've been searching the Internets and finally landed upon Tokyo Tryant [1] which I've discussed a long time ago [2]. What I'm basically getting at is providing dnsmasq with an optional very lightweight replicating server which it (optionally) uses to ensure the lease database can be propagated to a second (or third or fourth) dnsmasq instance. The reason I'm suggesting Tryant is that, it too, is lightweight and offers multi-master setups. ++ +-+ | dnsmasq | | dnsmasq| | A | | B | +-+--+ +-+ | + | | | | +-v---+ +--v---+ | Tryant| | Tryant | | A |+- B| | |-+ | +-+ +--+ +-+ +---+ | leases| |leases | |-| |---| +-+ +---+ In other words, dnsmasq (A) reads/writes leases from Tryant (A) and dnsmasq (B) read/writes from/to Tryant (B). If Tryant (A) and (B) can speak to eachother, the database is replicated, irrespective of which dnsmasq (A) or (B) has last written a lease. I'll stop here, before boring you even more, but I'll gladly send you snippets of code and a short howto set up a multi-master system. Most important IMO is to keep things very light-weight in the spirit of dnsmasq. Best regards, -JP It's necessary to decide what you're trying to achieve for failover. If you want a system which just transparently keeps working when a DHCP server fails, then the ISC server is the best bet, without a doubt. Let's assume you don't want that, but don't want to be dead in the water when a machine running dnsmasq fails. The first thing to note is that DHCP sort of keeps working anyway. Even if the server goes down and the lease database is lost, the clients will continue to work until the leases expire. What's more, if they get towards the end of the lease period without contacting the DHCP server that gave them a lease, they'll broadcast and accept a renewal from any server. This works now. If you set the lease time to 2 days, and then take down the dnsmasq server, you have a day to bring up dnsmasq on another machine before any client loses network connectivity, and once that second server is up, its lease database will gradually populate with the all the clients that were in the old database, _at_the_same_IP_addresses_. The problem with this, is that until a client talks to the new server and appears in the new lease database, it effectively disappears from the DNS. That's what will break things and why preserving a copy of the lease database is useful. The above applies to active-passive. Active-active, as you suggest, is more complex, because either server can talk to a client, so things like lease times have to be co-ordinated. This is what the ISC failover protocol does, I believe. For dnsmasq, I can see that active-passive is easy to do. Take your diagram above, and
Re: [Dnsmasq-discuss] A (possibly bad) idea: failover in dnsmasq
On Fri, May 25, 2012 at 01:17:57PM +0200, Jan-Piet Mens wrote: Being very lightweight, dnsmasq must not be bloated by having a huge MySQL or other database attached to it. I'd suggest SQLite as a possibility. Easy to include, and as they say: Small. Fast. Reliable. Choose any three. http://sqlite.org/ I'm not sure how/if this would help with the goal of failover, but I think it might be worth considering if there is to be external database/storage for dnsmasq. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject: ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] A (possibly bad) idea: failover in dnsmasq
I'd suggest SQLite as a possibility. Easy to include, and as they say: Small. Fast. Reliable. Choose any three. SQLite was my first option, but it doesn't replicate automatically. Easy to set up with rsync or something like it, of course, but that wouldn't enable two dnsmasq servers to consult the same live data. -JP ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
