Q: Why does dnsmasq open a UDP port number >1024 as well as port 53.
   Is this a security problem/trojan/backdoor?

A: The high port that dnsmasq opens is for replies from the upstream
   nameserver(s). Queries from dnsmasq to upstream nameservers are sent
   from this port and replies received to it. The reason for doing this is
   that most firewall setups block incoming packets _to_ port 53, in order
   to stop DNS queries from the outside world. If dnsmasq sent it's queries
   from port 53 the replies would be _to_ port 53 and get blocked.

   It's not a security hole since dnsmasq will only accept replies to that
   port: queries are  dropped. The replies must be to oustanding queries
   which dnsmasq has forwarded, otherwise they are dropped too.


Q: Why doesn't dnsmasq support DNS queries over TCP? Don't the RFC's specify
   that?

A: Yes, they do, so technically dnsmasq is not RFC-compliant. In practice, the
   sorts of queries which dnsmasq is used for are always sent via UDP. Adding 
   TCP support would make dnsmasq much more heavyweight for no practical 
   benefit. If you really want to do zone transfers, forward port 53 TCP 
   using in-kernel port-forwarding or a port-fowarder like rinetd.


Q: When I send SIGUSR1 to dump the contents of the cache, some entries have
   no IP address and are for names like mymachine.mydomain.com.mydomain.com.
   What are these?

A: They are negative entries: that's what the N flag means. Dnsmasq asked 
   an upstream nameserver to resolve that address and it replied "doesn't 
   exist, and won't exist for <n> hours" so dnsmasq saved that information so
   that if _it_ gets asked the same question it can answer directly without
   having to go back to the upstream server again. The strange repeated domains
   result from the way resolvers search short names. See "man resolv.conf" for
   details.


Q: Will dnsmasq compile/run on non-Linux systems?

A: Yes, but you might need to alter the settings in config.h, especially
   HAVE_GETOPT_LONG.
