gmane.network.dns.dnsmasq.general

Re: A (possibly bad) idea: failover in dnsmasq

Jan-Piet Mens — 2012-05-26T08:17:29

Understood. 


I'll give that a bit of thought. (/dev/rob0's suggestion of using SQLite
is suddenly more appealing in this light, as it involves fewer moving
parts...)

        -JP

Re: A (possibly bad) idea: failover in dnsmasq

Jan-Piet Mens — 2012-05-25T20:08:19

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

Re: A (possibly bad) idea: failover in dnsmasq

/dev/rob0 — 2012-05-25T18:23:08

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.

Re: A (possibly bad) idea: failover in dnsmasq

Simon Kelley — 2012-05-25T15:26:25

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_sam

Re: dnsmasq and sshfp records

Simon Kelley — 2012-05-25T14:11:15

I'll support that as well.

Cheers,

Simon.

Re: release for debian / ARMv5?

Simon Kelley — 2012-05-25T14:10:20

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.

release for debian / ARMv5?

Modem Man — 2012-05-25T13:00:33

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

Re: A (possibly bad) idea: failover in dnsmasq

Jan-Piet Mens — 2012-05-25T12:03:16

1,$s/Tryant/Tyrant/g

        -JP

A (possibly bad) idea: failover in dnsmasq

Jan-Piet Mens — 2012-05-25T11:17:57

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 eas

Re: dnsmasq and sshfp records

Jan-Piet Mens — 2012-05-25T11:14:33

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

Re: dnsmasq and sshfp records

Simon Kelley — 2012-05-25T10:56:27

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 opt

Re: dnsmasq and sshfp records

Gerd Koenig — 2012-05-24T19:58:20

Hi JP,

thanks for your response. I'll work through the discussion and dive into
dnssec. Interesting topic I didn't get in touch...

br...: Gerd :...


On 24 May 2012 20:17, Jan-Piet Mens <jpmens.dns-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss-YFzxfK+dQ3ZKxzGo0kwUX62ZND6+EDdj< at >public.gmane.org
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: dnsmasq and sshfp records

Jan-Piet Mens — 2012-05-24T18:17:48

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


I don't think this is possible at the moment, but we'll have to ask
Simon. Simon? Are you there? :-)

        -JP

[1]: http://jpmens.net/2011/02/18/verifyhostkeydnsmaybe/

Re: dnsmasq and sshfp records

Gerd Koenig — 2012-05-24T17:57:23

Hi Richard,

thanks for answering....

Yes, it is possible to add both lines as a TXT-Record, but this is not what
I really want ;-) .
In the end I want to be able to establish a ssh connection to a remote host
and its public key should be offered by DNS. Therefore I have to add the
keys as "SSHFP-Record"s, so that I'm able to call via <<ssh
user< at >remotehost-o "VerifyHostKeyDNS=yes">> and get a result line like
"Matching host key
fingerprint found in DNS".

Since I've nothing found, seems like dnsmasq doesn't support SSHFP-Records,
right ?!?!

br...: Gerd :...

On 24 May 2012 17:47, richardvoigt-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org <richardvoigt-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss-YFzxfK+dQ3ZKxzGo0kwUX62ZND6+EDdj< at >public.gmane.org
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: dnsmasq and sshfp records

2012-05-24T15:47:34

dnsmasq doesn't use zone files.  You can try with txt-record= (see the
man page for details)

On Thu, May 24, 2012 at 5:44 AM, Gerd Koenig
<koenig.bodensee< at >googlemail.com> wrote:

_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss< at >lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: Any plans on adding ability to storecachetodisk?

Timothy Madden — 2012-05-24T14:32:56


I found out my problem was I had "wins" (for Samba name resolution) before 
"dns" in my /etc/nsswitch.conf file, and that was making all my name lookups 
take 10s of seconds (even minutes), despite my dig command showing lookups 
under 3s without my cache, and under 1s with dnsmasque.

So I guess I do not really need to save the cache anymore, although I still 
think it would be a nice addition anyway.

Thank you,
Timothy Madden

dnsmasq and sshfp records

Gerd Koenig — 2012-05-24T10:44:47

Hi List,

I'm currently looking for a solution to provide ssh-keys via DNS. Seems
like sshfp records will solve this issue ... so far so good.
Since we are using dnsmasq as dns/dhcp/pxe-server I wanted to ask how to
put the generated sshfp records into dnsmasq ???
After searching for a while I got only guides for "how to create sshfp
records" or things like "put your sshfp records into dns"....not that
helpful.

Can somebody enlighten me if it is possible to offer ssh keys via dnsmasq,
and how to configure it ?

I tried it similar to the TXT-Records, therefore I created a config-file
sshfp.conf and inserted:
""
myhost SSHFP 1 1 cbe4...c6dc
myhost SSHFP 2 1 20ea...b241
""
But if I want to start dnsmasq I got the error:
""
Starting DNS forwarder and DHCP server: dnsmasq
dnsmasq: bad option at line 1 of /etc/dnsmasq.d/sshfp.conf
 failed!
""


any help appreciated...: Gerd :....
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss-YFzxfK+dQ3ZKxzGo0kwUX62ZND6+EDdj< at >public.gm

Re: Dhcp discover client source ip not 0.0.0.0

Simon Kelley — 2012-05-23T08:12:59

That's useful information. Many thanks.

Cheers,

Simon.

Re: Dhcp discover client source ip not 0.0.0.0

Sen Haerens — 2012-05-23T07:50:02

Disabling source address verification for the affected interface
solves the packets being discarded by the kernel. It's enabled by
default on an Ubuntu server installation.

sysctl -w net.ipv4.conf.vlan20.rp_filter=0

Dnsmasq then, handles the lease just fine.

kubrick dnsmasq-dhcp[18951]: DHCPDISCOVER(vlan20) 192.168.168.7
74:44:01:78:e1:ed
kubrick dnsmasq-dhcp[18951]: DHCPOFFER(vlan20) 192.168.168.7 74:44:01:78:e1:ed
kubrick dnsmasq-dhcp[18951]: DHCPREQUEST(vlan20) 192.168.168.7
74:44:01:78:e1:ed
kubrick dnsmasq-dhcp[18951]: DHCPACK(vlan20) 192.168.168.7
74:44:01:78:e1:ed switch-02

IP 192.168.0.239.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
74:44:01:78:e1:ed, length 259
IP 192.168.168.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
IP 192.168.0.239.68 > 255.255.255.255.67: BOOTP/DHCP, Request from
74:44:01:78:e1:ed, length 307
IP 192.168.168.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300

Re: Patch: Add --ping-timeout option

John Hanks — 2012-05-22T16:20:32

FWIW I've used dnsmasq to netboot 1368 diskless machines
simultaneously (or as close to simultaneously as possible), which for
each machine meant pxe, tftp kernel/initrd, dhcp address with new
kernel, pull down image, switchroot to image, dhcp primary address
again plus 2 (or more) additional VLAN interfaces. In our case the
bottleneck was distributing the large OS image, but all 1368 nodes
(less a few hardware failures) could be booted in under 15 minutes
from power on to running compute jobs with the dnsmasq portions
fitting into the first 5 - 8 minutes of that 15 minute window. I never
used --no-ping and the only significant observed failures were a small
number of VLAN interfaces for which dhcp failed, which were addressed
by a startup script that waited a random number of seconds and
retried. At least in my experience DNSmasq was capable of handling our
load well. DNSmasq itself ran on a host with a 1 Gbps interface and
images were served from SSD on a host with a 10 Gbe interface. Of
course, YMMV.

jb

Re: Dhcp discover client source ip not 0.0.0.0

Sen Haerens — 2012-05-22T14:53:13

It's logging fine for other clients, but not for the switch.