Re: [Dnsmasq-discuss] Is updating dnsmasq.conf supposed to update dnsmasq.plist?

2010-08-04 Thread Perette Barella

On 2010年08月03日, at 18:08, John Puffs wrote:
 Seems silly that certain options in the .plist file are not automatically 
 updated. I will file a bug report as this is not good.
It may make more sense when you consider that the .plist is *not* dnsmasq's 
config file.  It's a config file for launchd, telling launchd how to invoke 
dnsmasq.  Thus, the way I'd suggest reporting the bug is that the .plist file 
should not unnecessarily pass dnsmasq parameters that are particulars of 
dnsmasq configuration.

This way, the automatic update you're envisioning becomes unnecessary.  If the 
.plist doesn't specify -r /etc/resolv.conf at all (because it's not inherently 
part of launching/managing the process anyway) then it'll use the ones from 
dnsmasq.conf.  So if MacPorts takes these lines out of the .plist:
 string-r/string
 string/etc/resolv.conf/string (or whatever you've changed it to)
and it'll work sensibly. (Which, apparently, is the way I suggested it in the 
first place: https://trac.macports.org/ticket/21276 ...  Why they changed it, I 
don't know.)

 One quick question that I think I know the answer to.. You said Since 
 command-line options override the config file options in dnsmasq (as with 
 most other utilities), your config file is ignored in preference of the 
 .plist/command line option.  I understand that options that are listed in 
 the .plist will override the config file. But do the rest of the config file 
 options still work correctly? 

Yes, the rest of your settings are getting picked up from the .conf file.  The 
-r option (equivalent to resolv-file in the config file) is the only option 
being passed to dnsmasq and thus overriding the resolv-file config file 
setting.  (In a pure sequence-of-operations, dnsmasq IS reading your config 
file's setting... But then it's overridden by the -r parameter/command line 
option passed to it.)



And a comment/question on the man page... Under CONFIG FILE, it indicates:
 For options which may only be  specified  once,  the  configuration  file 
 overrides the command line.


Skimming through I don't see any mention of which ones those are.  If any of 
these still exist, they should be noted somehow.

Peri



Re: [Dnsmasq-discuss] Is updating dnsmasq.conf supposed to update dnsmasq.plist?

2010-08-03 Thread Perette Barella
The .plist file is a Mac-only thing.  As such, it is not part of the standard 
dnsmasq distribution, but something that MacPorts adds.

For reference, the full contents of the file are:
?xml version='1.0' encoding='UTF-8'?
!DOCTYPE plist PUBLIC -//Apple Computer//DTD PLIST 1.0//EN
http://www.apple.com/DTDs/PropertyList-1.0.dtd;
plist version='1.0'
  dict
keyLabel/key
stringorg.macports.dnsmasq/string
keyProgramArguments/key
array
  string/opt/local/sbin/dnsmasq/string
  string-k/string
  string-r/string
  string/etc/resolv.conf/string
/array
keyKeepAlive/key
dict
  keyNetworkState/key
  true/
/dict
  /dict
/plist

This file is statically installed this way as part of the MacPorts dnsmasq 
package, and no, it isn't updated programatically.  This XML file is used by 
launchd(8) on OS X to know when and how to launch dnsmasq during boot.  (For 
other UNIX folks, launchd(8) is the replacement for init(8) and inetd(8)).  
This is resulting in dnsmasq being invoked with a command line of:
/opt/local/sbin/dnsmasq/dnsmasq -k -r /etc/resolv.conf
Since command-line options override the config file options in dnsmasq (as with 
most other utilities), your config file is ignored in preference of the 
.plist/command line option.  So it's MacPorts fault.  Why the MacPorts people 
decided that -r /etc/resolv.conf should be specified on the command line, I 
don't know, but it seems like a poor choice to me; you can just remove the 
lines corresponding to -r and /etc/resolv.conf and then it'll use your 
config file.  Maybe you should log a bug report with MacPorts.

-k is a reasonable command-line option for operating under launchd, which 
doesn't want processes to fork/exec.  (It will by default try to spawn another 
instance of the process if/when it dies.)  Don't remove that.

Peri






On 2010年08月03日, at 17:14, John Puffs wrote:

 I could NOT get it to work because my router constantly overwrites my 
 resolv.conf file. So I set up dnsmasq.conf to read a separate file instead 
 (resolv2.conf).  Still did not work. I finally went into the dnsmasq.plist 
 file and saw that /etc/resolv.conf was listed. I changed that and everything 
 was fine.
 
 I have since made other changes to dnsmasq.conf and do not see my 
 dnsmasq.plist updating.
 
 Is updating dnsmasq.conf supposed to re-write options to dnsmasq.plist?
 
 Where does dnsmasq get it's options from; dnsmasq.conf, dnsmasq.plist or 
 both??
 
 I have dnsmasq.conf set to read /etc/hosts as well as a separate hosts file I 
 use for blocking around 16,000 sites. Apparently this is working fine as it 
 does block the sites and doing a dig shows it is going to 127.0.0.1 for any 
 site. YET there is nothing in my plist to indicate that dnsmasq is supposed 
 to read a separate hosts file. This makes me believe idnsmasq gets it's 
 options from both dnsmasq.conf and dnsmasq.plist... 
 
 So I guess I have 2 questions:
 
 1. is updating dsnmasq.conf supposed to pass variables to dnsmasq.plist? If 
 so I don't think mine is.. Why?
 2. What variables NEED to be in the .plist file as compared to the conf file?




[Dnsmasq-discuss] Update: Mac OS X DNS ordering issue

2010-04-01 Thread Perette Barella
A few weeks back I mentioned a DNS reordering issue on OS X. OS X version 
10.6.3 fixes this, although there are some associated settings.  See
http://support.apple.com/kb/HT4030
for details on what you need to set.

Perette




Re: [Dnsmasq-discuss] Add address file option

2010-03-05 Thread Perette Barella
On 2010年03月05日, at 12:16, Jan 'RedBully' Seiffert wrote:
 And there is always the risk the new dnsmasq will not come up, because you 
 made
 a silly typo in the config, or something like that. Depending on how fast you
 can rectify the situation, now you have a real window where you are without 
 name
 resolution.
 If one can avoid that, he will avoid that.

A partial/compromise solution: what about a command-line option to Read the 
options and configuration file, report any errors, and exit, like the -n 
option to the shells.  I realize it doesn't address 100% of everything desired, 
but it does allow you to check the config file syntax before proceeding to a 
restart.  And it's a lot easier to get the error messages from the command 
line, rather than having to dig them up in a log file when dnsmasq is spawned 
from init, inetd, or launchd. (Or is there already such an option?)

As far as coming up with a way to handle restarting dnsmasq without hiccups... 
I tend to agree with Brad... if you need 100% uptime, a better solution is a 
secondary DNS server rather than complexifying the heck out of dnsmasq.

Perette




Re: [Dnsmasq-discuss] Fwd: troubles with cname

2010-03-04 Thread Perette Barella
On 2010年03月04日, at 12:33, Samuel Martà n Moro wrote:
 But there's still a thing I don't understand...
 
 in /etc/hosts, I have:
 10.0.0.1 toto-eth
 10.0.0.201   toto-wif
 88.191.xx.xx dedibox
 
 in /etc/dnsmasq.conf, I have:
 dhcp-host=macaddr,10.0.0.1,infinite
 dhcp-host=macaddr,10.0.0.201,infinite
 cname=toto,toto-eth
 cname=mailbox,dedibox
 
 When I'm testing from the server, I can ping everyone.
 When I'm trying from a DHCP/DNS client from my network, toto and mailbox are 
 not resolved.
 But, still trying from a client, when I nslookup them, I got my answer.

If you are on Macs with Snow Leopard:  They behave strangely and can exhibit 
the behavior you are describing.  Here's what I've been able to ascertain:

* Open-source command line utilities work as expected because they utilize the 
well-known libraries.

* Native Mac (GUI) apps go through a intermediary process that caches / routes/ 
abstracts DNS, mDNS, X501 or whatever that is, and probably a couple other name 
services.  As a feature introduced in Snow Leopard (OS X 10.6), this 
intermediary keeps track of which DNS server is responding fast enough.  If 
your primary hiccups or goes offline for a bit, the order changes and stays 
that way unless/until the secondary hiccups and the primary proves, at that 
time, to be faster.  (There is a similar feature in dnsmasq to ensure best 
performance, but you can override it with the --strict-order option.  And it 
retries periodically, which OS X does not seem to.)

* For native (provided by Apple) command-line stuff, I'm not sure what goes 
which way.

As far as dnsmasq goes, this creates a problem if you've got your dnsmasq 
server set up as a primary and your upstream DNS provider set up as a 
secondary.  It's all running along just fine for days, then the server has a 
senior moment and next thing you know the clients' native apps can't see your 
local servers, but if you try to diagnose it with the command line tools 
everything reports just fine.

The workaround: stick this in root's crontab (sudo crontab -e) to restart the 
cache/intermediary process once a minute:
* * * * * launchctl stop com.apple.mDNSResponder
The side effect of this is that every once in a while, the process gets whacked 
during a lookup and a process reports a server can't be found, mostly evident 
on web browsers.  Hit reload and it all works.

I filed a bug report, and from other discussion lists I've seen others have 
too, but last I knew no official fix yet... it's not a bug, it's a feature.

Perette





Re: [Dnsmasq-discuss] dhcp-range - must ip address of server be outside that?

2009-12-28 Thread Perette Barella
On 2009年12月27日, at 19:47, dnsmasq.to.pee...@spamgourmet.com wrote:
 On to another issue now: static ips outside the allocated pool.
 
 You seem to be implying that it is better not to define static ips in
 dhcpserver config files (that is, it is better to have them outside the
 dhcp range pool). Why?

The obvious failure case is that you boot up a device, dnsmasq happens to give 
out an address via DHCP because it's in the DHCP pool... and at some later 
time, someone powers on the machine with the same (but statically configured) 
IP address.  Now you have two machines with the same IP, and suckage will ensue.

So I'd agree with Rance on this one... Keep your static IPs out of the DHCP 
range.  dnsmasq does what it can to prevent problems, but you're opening the 
door to headaches.

If, on the other hand, you're talking about pseudo-static IPs where dnsmasq is 
configured to give out a specific address from within the pool to a particular 
machine (via dhcp-host)... it would be nice if dnsmasq guaranteed it and 
wouldn't give the address out to anyone but the specific MAC address, I'd even 
guess that it's clever enough to behave this way, but I'm not qualified to 
guarantee it.  Anyone?

Perette




Re: [Dnsmasq-discuss] dnsmasq returns addresses for non-existent hosts - what have I mis-configured?

2009-11-08 Thread Perette Barella
It looks like your provider has set up a wildcard A record, which is  
similar to DNS hijacking as a helpful feature to users who miskey a  
domain name.  It's not isolated to you:


mugenshi:etc x10$ host ghijk.isbd.net
ghijk.isbd.net has address 195.74.61.93
ghijk.isbd.net mail is handled by 10 mail-in-1.lb.gradwell.net.

You could check Gradwell's support pages, but I doubt there is an  
option to shut it off, since the DNS is published this way.  It's a  
publication problem/feature, not a bug in dnsmasq.


Dnsmasq does have a a bogus-nxdomain option, which you give some IP  
addresses and those addresses are translated into NXDOMAIN non- 
existent domain responses.  However, if isbd.net (without leading  
characters) is actually a useful server to you, this solution is not  
viable because the valid use shares the same IP as the bogus responses.


Perette



On 2009年11月08日, at 7:08, Chris G wrote:


I have dnsmasq working quite happily on a Ubuntu Server 9.10 system
providing dns for my small SoHo network.

I have just noticed however that if I ask for the address of a
non-existent name dnsmasq returns the name of one of my hosting
service's machines.  It always returns the same address for any
non-existent name, e.g.:-

   chris$ host abcde.isbd.net
   abcde.isbd.net has address 195.74.61.93
   abcde.isbd.net mail is handled by 10 mail-in-1.lb.gradwell.net.
   chris$ host xyz
   xyz.isbd.net has address 195.74.61.93
   xyz.isbd.net mail is handled by 10 mail-in-1.lb.gradwell.net.
   chris$ host xyz.isbd.net
   xyz.isbd.net has address 195.74.61.93
   xyz.isbd.net mail is handled by 10 mail-in-1.lb.gradwell.net.


I have isbd.net and isbd.co.uk hosted at Gradwell so I do have a
connection with them.  In fact things are becoming clearer now,
195.74.61.93 is the (quite correct) address returned when you
look up isbd.net.

So, how can I prevent dnsmasq from returning the parent domain address
when I look up anyOldRubbish.isbd.net ?  Presumably it can't find  
the

name locally and sends off the request to the upstream name server
which (sort of correctly) returns 195.74.61.93.

However it means that if I mis-type a name or if one of my machines
dies then I may not notice immediately because DNS still succeeds.

--
Chris Green


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss





Re: [Dnsmasq-discuss] macport installation not starting

2009-09-04 Thread Perette Barella


On 2009年09月04日, at 7:10, B. Kamer wrote:
Perhaps things are different on your system or it seems you didn't  
quite got my explanation of the problem.


Sorry about that, I missed a level of indirection.  You are right, the  
dnsmasq.wrapper does try to call the missing script on Leopard too.   
The MacPort people probably know more about this... the whole plist  
invokes daemondo which runs dnsmasq.wrapper which runs dnsmasq.sh  
which finally invokes dnsmasq seems bizarrely complex.  On my server,  
I don't use the MacPorts dnsmasq and rolled my own plist file:


?xml version=1.0 encoding=UTF-8?
!DOCTYPE plist PUBLIC -//Apple Computer//DTD PLIST 1.0//EN
 http://www.apple.com/DTDs/PropertyList-1.0.dtd;
plist version=1.0
dict
keyLabel/key
stringuk.org.thekelleys.dnsmasq/string
keyProgramArguments/key
array
string/opt/local/sbin/dnsmasq/string
string-k/string
/array
keyRunAtLoad/keyfalse/
keyAbandonProcessGroup/keyfalse/
keyKeepAlive/key
dict
keyNetworkState/keytrue/
/dict
/dict
/plist

Give that a try.  If you have bound to a particular interface, though,  
this won't work reliably because there's a race condition between  
dnsmasq starting and the interfaces being up.  A workaround is to  
replace the array in the above:


array
string/bin/bash/string
string-c/string
stringsleep 10 amp;amp; exec /usr/local/sbin/dnsmasq 
-k/string
/array

Perette




Re: [Dnsmasq-discuss] Can dnsmasq 'alias' a host name?

2009-09-02 Thread Perette Barella
A note on the on the .local pseudo-top-level-domain: It's used by  
multicast DNS, implemented on Macs primarily I think.  mDNS is used by  
machines forming an ad-hoc network, and works in parallel with DNS.   
Although I can't remember my problem now, I recall a name-related race  
condition battle on my network when my local DNS domain also  
used .local .  The .local entry at Wikipedia gives a similar warning:


Name resolution issues may arise if Bonjour, Avahi, or other  
Multicast DNS software is used in conjunction with a network that  
implements the local toplevel DNS domain.

[Source: http://en.wikipedia.org/wiki/.local]

Best,

Perette

Chris G wrote:

Can dnsmasq provide an alternative name for a client?

This is going on from my problem with a system that insists on calling
itself garage.local when I want it to be called garage.

Is there a way that I can tell dnsmasq that garage.local is also
garage so that requests for the address of garage will get the address
of garage.local?






[Dnsmasq-discuss] dnsmasq launch race condition

2009-04-08 Thread Perette Barella
dnsmasq has a race condition on OS X.  I believe the problem is that  
if dnsmasq starts before IP V4 is fully up, it can't bind to a IP V4  
port and therefore won't resolve anything.  It will, of course,  
happily resolve local dns requests.


Of course, maybe the problem report should be against launchd, the OS  
X replacement for /etc/rc*, which doesn't have much in the way of  
dependency resolving.


Below is a time-delay launchd.plist file that will, in a rather stupid  
way, fix the problem.  I think 10 seconds might be excessive, but  
then, it's not like UNIX servers are booting more than every few  
months.  If there's a better solution, I'd be glad to learn it.


?xml version=1.0 encoding=UTF-8?
!DOCTYPE plist PUBLIC -//Apple Computer//DTD PLIST 1.0//EN
 http://www.apple.com/DTDs/PropertyList-1.0.dtd;
plist version=1.0
dict
keyLabel/key
stringuk.org.thekelleys.dnsmasq/string
keyProgramArguments/key
array
string/bin/bash/string
string-c/string
stringsleep 10 amp;amp; exec /usr/local/sbin/dnsmasq 
-k/string
/array
keyRunAtLoad/keyfalse/
keyAbandonProcessGroup/keyfalse/
keyKeepAlive/key
dict
keyNetworkState/keytrue/
/dict
/dict
/plist

Perette