[Dnsmasq-discuss] A reason for setting NS records in dnsmasq

[Simon Kelley]

On 09/12/12 22:54, Gui Iribarren wrote:
> On Sun, Dec 9, 2012 at 6:48 PM, Simon Kelley <simon at thekelleys.org.uk> wrote:
>> On 01/11/12 21:58, Gui Iribarren wrote:
>>
>>> What do you think? would that be an argument for implementing this into
>>> dnsmasq?
>>> (or maybe there's another way to do this i'm overlooking)
>>> (dnsmasq is running on a space-tight openwrt, so running bind9+dnsmasq is
>>> not an option)
>>>
>>
>>
>> OK, I started with this and ended up with something that looks really very
>> useful, but I'm not sure it solves exactly your problem. This is still very
>> much work in progress, so the configuration and functions may change.
> 
> Impressive!
>>From your description, it looks like it solves exactly my problem :)
> 
> It compiled fine in openwrt build environment, so i'm currently
> building a new firmware to test it
> 
> in the meanwhile, a few comments,
> 
>> auth-server=<nameserver>,<interface>
>>
>> The nameserver is the DNS name that resolves (from the outside) to the
>> address of the dnsmasq server, and the interface is where those queries will
>> arrive, so that dnsmasq treats then as authoritative.
> 
> In my setup, things are not so isolated: there's only one interface
> "br-lan" with RFC1918 ipv4 which serves dhcp relay to local lan, and
> at the same time has a global ipv6 address set, where it receives
> queries from outside.
> 
> 
>> With the caveat that for A and AAAA records, the address must lie in one of
>> the subnets given in the --auth-zone option. This means that, for instance,
>> the RFC1918 addresses of my internal machines don't escape, since I've not
>> specified those subnets.
> 
> Excellent!
> 
> 
>> Importantly, queries via the auth interface are _only_ answered with
>> internal data, they are never forwarded, so it's safe to make the service
>> available on the internet and doesn't set up an open DNS relay.
> 
> I guess this won't hold up in my promiscuous setup, right? I should
> separate the interface connected to the "private" network.
> 
> The funny thing is that "private" is resignified in ipv6 world.
> 
> I mean, say i get from my isp, public ipv4 8.7.6.5 and ipv6
> 2001:db8::1/64, in addition to a routed /64 for me =
> 2001:db8:FFFF::1/64
> 
> wan: 2001:db8::1/64 , 8.7.6.5
> lan: 2001:db8:FFFF::1/64 , 10.0.0.1
> 
> i use auth-server=domain.org,wan
> so, only the lan interface allows dns relay for my local ipv4/ipv6 network.
> 
> still, the 2001:db8:FFFF::1 is globally accesible :)
>  and so while there's no open dns relay at 2001:db8::1, there's one at
> 2001:db8:FFFF::1
> 
> How did you manage to avoid that? Looks like a firewall rule to me
> $ dig spike.lan.thekelleys.org.uk -taaaa +all @2a01:348:29f::1
> ;; connection timed out; no servers could be reached
> 



OK, so it looks like I need to allow address(es) as well as interface
names in the auth-server statement, so you could do something like

auth-server=guisnet.com, 2001:db8:FFFF::1

analogous to the --interface and --listen-address options for internal
DNS access control.

That shouldn't be difficult to implement. Give me a day or so to get
'round to it.

Cheers,

Simon.