[Dnsmasq-discuss] [PATCH] --dont-mirror-queries option

Simon Kelley simon at thekelleys.org.uk
Fri Feb 5 22:22:59 GMT 2016


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

That's very ingenious!

Your post begs the question "Will you merge the patch?"

I'm not sure: it's a pretty niche application, and there are lots of
cases where it does the wrong thing. For instance when a query arrives
from area1, there's nothing to check (and no way of checking) that the
query comes from dnsmasq, and not a stub resolver running on the same
machine.

Is there not a conceptually simpler fix for this by splitting master
in two, maybe listening on different ports?

area1 is configured to forward to master1, which is configured to
forward again to area2. area2 forwards to master2, which forwards to
area1 when it can't answer.


Cheers,

Simon.


On 29/01/16 13:38, Chris Novakovic wrote:
> I have a (rather odd, and perhaps ill-advised) network setup in
> which names in a particular domain (e.g. example.com) are split
> across three sites, and I need three dnsmasq servers to be mutually
> dependent in the following hierarchy to resolve names for that
> domain:
> 
> master / \ /   \ area1   area2
> 
> If a client sends a query for x.example.com to area1 that area1
> can't answer, or if another client sends a query for y.example.com
> to area2 that area2 can't answer, both servers will forward the
> query to master, which is configured (with --server) to be the sole
> upstream DNS server for example.com on both area1 and area2. If
> master can't answer a query for example.com, it is configured to
> forward the query to area1 and area2. Clearly, master shouldn't
> forward queries that originate from area1 back to area1: this would
> lead to an infinite forwarding loop.
> 
> The attached patch implements a new option, --dont-mirror-queries.
> When enabled, this option prevents dnsmasq from forwarding a
> request to an upstream server if its IP address matches that of the
> sender of the query. I suppose this could be considered a dynamic,
> per-query version of the --dns-loop-detect option that is only
> capable of detecting 1-hop loops.
> 
> Kurt H Maier <khm at sciops.net> was the brains of this operation,
> helping me figure out the part of forward.c that needed patching.
> 
> Cheers, Chris
> 
> 
> 
> _______________________________________________ Dnsmasq-discuss
> mailing list Dnsmasq-discuss at lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJWtSDDAAoJEBXN2mrhkTWiMTsP/01/udie3LnYh9ptmg6tY3pc
F4uVIaO/G1g2Q8d/hUqt3XS6OBV46sy9RNPbNH+f3PtTWS+9QeC+9lQe8mnQMKuk
9G6Fch7J/Yqx3TZ1xJdhei0BgWAzN0S1yqVWZfnrciWfj8xy8wipOTD1M8vmLn+1
h9CKSCE6hNP7HhBu7svcjc1QMKLimNbdB63w9g2mYE97ilQYaPVLF5OLbw/lV6m1
cg+s9dAoXs+OVwO+hRhK3MbA0KrEnk8c3huV3VmEi0CjmqjlF0bKncyZQqUG+xUK
4j7QjkZNtodR87GJGE5faeQ9Sv4v7ddws47StajAKgznHzN4Pofe0ean3ETMLdKR
esiYr9OF7Ga93Tfw4bLESYzZc5cnmvjMe7Hnds2Sd03o9XK4clJVMmIFqnWTtC1S
SH/hRRxku+QqPbuoxNiIhTdGyE3J7VHZLvLmI0M5nzsJJZJsCAE75MSZZS57BpyH
vqNAgluD+o4nybgNn9gnmFfcX2xLfLWjrizdgj8mUSxmZoa2/s0HU6JMYIyND5J6
T7+VxB/nDG2cQm4+6RgyKtq6qbJ+4EI/000Tb0ZiDmoGC5QURBy3+MuHEkpS6rpu
6NyC9ObYT8GXptADoJaPT3RxNsFBo6/jZilhm1SfBauX3pl6DDmSINv1+s3YIMyb
WsaZr2xg620btWy4X2lW
=aELU
-----END PGP SIGNATURE-----



More information about the Dnsmasq-discuss mailing list