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
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] digging SOA records doesn't work
Vaidotas Kaminskas wrote: Hi, I'm using version 2.35-1 from debian etch. I cannot dig for SOA records while behind dnsmasq: # dig soa google.com ; <<>> DiG 9.4.2 <<>> soa google.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45820 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;google.com.IN SOA ;; Query time: 10 msec ;; SERVER: 192.168.0.254#53(192.168.0.254) ;; WHEN: Thu Mar 20 21:14:45 2008 ;; MSG SIZE rcvd: 28 # While doing this I'm running tcpdump on the dnsmasqing router like this: tcpdump -n -i eth0 udp and port 53 and it shows no activity. The command below, however, does produce the packets requesting google.com's SOA in the tcpdump output. # dig @88.223.0.1 soa google.com ; <<>> DiG 9.4.2 <<>> @88.223.0.1 soa google.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39935 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;google.com.IN SOA ;; ANSWER SECTION: google.com. 54201 IN SOA ns1.google.com. dns-admin.google.com. 2008031700 7200 1800 1209600 300 ;; AUTHORITY SECTION: google.com. 68055 IN NS ns1.google.com. google.com. 68055 IN NS ns2.google.com. google.com. 68055 IN NS ns3.google.com. google.com. 68055 IN NS ns4.google.com. ;; ADDITIONAL SECTION: ns1.google.com. 49703 IN A 216.239.32.10 ns2.google.com. 49703 IN A 216.239.34.10 ns3.google.com. 49703 IN A 216.239.36.10 ns4.google.com. 49703 IN A 216.239.38.10 ;; Query time: 10 msec ;; SERVER: 88.223.0.1#53(88.223.0.1) ;; WHEN: Thu Mar 20 21:22:32 2008 ;; MSG SIZE rcvd: 210 # 88.223.0.1 is the DNS server that the router running dnsmasq uses. So it seems that dnsmasq isn't even trying to query for SOA records. Are you using filterwin2k? -f, --filterwin2k Later versions of windows make periodic DNS requests which don't get sensible answers from the public DNS and can cause problems by triggering dial-on-demand links. This flag turns on an option to filter such requests. The requests blocked are for records of types SOA and SRV, and type ANY where the requested name has underscores, to catch LDAP requests. That would explain things. Simon. Regards, Vaidotas ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] digging SOA records doesn't work
Hi, I'm using version 2.35-1 from debian etch. I cannot dig for SOA records while behind dnsmasq: # dig soa google.com ; <<>> DiG 9.4.2 <<>> soa google.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45820 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;google.com.IN SOA ;; Query time: 10 msec ;; SERVER: 192.168.0.254#53(192.168.0.254) ;; WHEN: Thu Mar 20 21:14:45 2008 ;; MSG SIZE rcvd: 28 # While doing this I'm running tcpdump on the dnsmasqing router like this: tcpdump -n -i eth0 udp and port 53 and it shows no activity. The command below, however, does produce the packets requesting google.com's SOA in the tcpdump output. # dig @88.223.0.1 soa google.com ; <<>> DiG 9.4.2 <<>> @88.223.0.1 soa google.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39935 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;google.com.IN SOA ;; ANSWER SECTION: google.com. 54201 IN SOA ns1.google.com. dns-admin.google.com. 2008031700 7200 1800 1209600 300 ;; AUTHORITY SECTION: google.com. 68055 IN NS ns1.google.com. google.com. 68055 IN NS ns2.google.com. google.com. 68055 IN NS ns3.google.com. google.com. 68055 IN NS ns4.google.com. ;; ADDITIONAL SECTION: ns1.google.com. 49703 IN A 216.239.32.10 ns2.google.com. 49703 IN A 216.239.34.10 ns3.google.com. 49703 IN A 216.239.36.10 ns4.google.com. 49703 IN A 216.239.38.10 ;; Query time: 10 msec ;; SERVER: 88.223.0.1#53(88.223.0.1) ;; WHEN: Thu Mar 20 21:22:32 2008 ;; MSG SIZE rcvd: 210 # 88.223.0.1 is the DNS server that the router running dnsmasq uses. So it seems that dnsmasq isn't even trying to query for SOA records. Regards, Vaidotas
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 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.
