Re: [Dnsmasq-discuss] dnsmasq listening on 0.0.0.0
richardvo...@gmail.com wrote: On Wed, Mar 19, 2008 at 11:24 AM, Simon Kelley si...@thekelleys.org.uk wrote: richardvo...@gmail.com wrote: DHCP that always binds the wildcard - doing otherwise _may_ be possible, but be prepared for much testing and strange behaviour. For instance, you need to be able to receive packets whose destination address in 255.255.255.255. But the DHCP socket is (or can be with a config file setting) bound to a particular interface, even if not a particular IP, correct? At kernel level, it's not bound to anything. Dnsmasq sees DHCP packets which arrive on all interfaces. The first thing it does is to filter them based on --interface --except-interface and --no-dhcp-interface. Anything which doesn't pass the filter is thrown away with no action. The OP wants to be have the kernel do the filtering. There's no practical benefit to doing that in most cases. The benefit would be the ability to run multiple instances of dnsmasq to serve different interfaces. I thought that capability existed. It does, using a slightly different mechanism. You need to set bind interfaces for the DNS stuff, and that also sets a flag on the DHCP socket so that more than one interface is allowed to listen on 0.0.0.0 It's important to make sure that only one instance serves a particular network; if this is not done, strange things may occur. Simon.
Re: [Dnsmasq-discuss] digging SOA records doesn't work
On Thu March 20 2008 14:35:14 Vaidotas Kaminskas wrote: I'm using version 2.35-1 from debian etch. I cannot dig for SOA records while behind dnsmasq: # dig soa google.com $ /usr/sbin/dnsmasq --version Dnsmasq version 2.41 Copyright (C) 2000-2008 Simon Kelley Compile time options IPv6 GNU-getopt no-ISC-leasefile no-DBus I18N TFTP and DiG 9.4.1-P1 soa google.com. works for me. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: [Dnsmasq-discuss] domain per interface
On Wed March 19 2008 11:28:37 Simon Kelley wrote: I think that in ISC dhcpd/named, this could be done with a subnet declaration block with option domain-name wifi.example.net; inside it, and of course a corresponding dynamic zone declaration in named.conf. That's another avenue I don't want to pursue, because I want to keep dnsmasq for authoritative DNS. (I'm using named for recursion only, on port 35, with dnsmasq using server=127.0.0.1#35.) Simon, am I out of luck here? Yes. This has come up before. The problem is that no domain information is stored in the lease database: dnsmasq assumes that the domain is that given by --domain. To support multiple domains, the lease file format would need to change, which is a compatibility problem. Or maybe separate files, take the domain from the filename? Just a thought: /var/state/dnsmasq/$DOMAIN.leases ? I guess I could also do dhcp-script and nsupdate(8) to update a zone in named.conf. But even then, will the dnsmasq block it? If dnsmasq knows the answer, named is never consulted. What about this: server=/wifi.example.net/127.0.0.1#35 server=/3.168.192.in-addr.arpa/127.0.0.1#35 Will dnsmasq ignore the names it has served to DHCP clients? DHCP names take preference over server config, sorry. Before I saw this, I thought it was working fine. I can axfr the 3.168.192.in-addr.arpa. zone, which means dnsmasq consults named on port 35, but individual PTR queries are indeed intercepted by dnsmasq. The whole thing is incredibly silly (I was intoxicated when I got the idea, so I did it anyway), but it was a cute idea. I could switch to ISC if it was worth the trouble, but it isn't. Please file this under feature requests that should only be considered if they don't create too much complexity, because the whole point of using dnsmasq in the first place was for simplicity. :) -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
