Discussion:
[Dnsmasq-discuss] Two questions about authoritative mode
Raphaël Halimi
2018-05-31 10:50:55 UTC
Permalink
Hi,

I have two questions about authoritative mode.

I have a home LAN, with a classic Bind / ISC DHCP / HPA TFTP setup
(started long before dnsmasq ever existed).

Recently I decided to rent a server to externalize some public services
(web, mail and DNS servers). This server is a libvirt/KVM hypervisor and
all virtual machines are connected through a purely virtual bridge, and
dnsmasq handles the DNS/DHCP/TFTP part of this LAN (the private part
only, no relation to the the public DNS mentioned above). So I'm quite
new to dnsmasq and so far I'm quite impressed by the vast possibilities
it allows with such a small footprint. Note that for practical reasons,
I don't use libvirt's builtin iptables/dnsmasq configurations, I made my
own.

So, I interconnected both LANs through a VPN (OpenVPN) and all machines
can happily communicate. Now I'm trying to ease the DNS administration
part, and that's where I'm stuck on a couple of minor problems (really
minor, since my setup works quite well, I'm just trying to perfect it a
bit).

What I'm trying to do is to allow my home LAN's DNS system (Bind) to
know about the remote LAN's zone, and fetch the zone data from the
remote LAN's dnsmasq (through AXFR). It was quite easy to define a slave
type zone, in Bind, and then allow zone transfers in dnsmasq with two
configuration lines:

auth-sec-servers=<Bind server's IP>
auth-peer=<Bind server's IP>

Now, the problem is that I'd like the remote LAN to be completely
unaware (DNS-wise, at least) of the home LAN's DNS system; in other
words, I don't want the Bind server's IP to be listed as a secondary
server in the remote LAN's zone data. So I tried to remove the
"auth-sec-servers=..." line, but unfortunately this prevented the zone
transfer to work.

I know it works with Bind: I can define slave zones on some server,
while the actual zone file on the master has no mention of any slave
server (of course, it's still allowed in the server's configuration by
an "allow-transfer" directive, though), making the slave server
completely stealth. So this is my first question: is there a way to
achieve this with dnsmasq ? If not, is this planned, or could it be
considered for a future release ?

My second question is more of a feature... inquiry (I was about to write
"request" but that would be not only rude, but also not totally faithful
to my state of mind).

As stated in dnsmasq's manual page (version 2.76, Debian stretch): "at
present, reverse (in-addr.arpa and ip6.arpa) zones are not available in
zone transfers, so there is no point arranging secondary servers for
reverse lookups". So my second question is quite simple: is it planned
for a future release ? By searching the mailing list, I saw that a lot
of features were considered by the developer(s ?) kind of "outside of
scope for such a tiny tool" a decade ago, yet they were finally
implemented and are nowadays supported (the power of popular demand, I
guess). Since the code for managing AXFR requests is already there,
would this feature be hard to implement ?

(note that as much as I'd like to, I couldn't help with this, since I'm
a pure admin, my development skills are limited to shell and, to some
extent, Perl).

Thanks a lot in advance for answering those two questions.

Regards,
--
Raphaël Halimi
Simon Kelley
2018-06-02 17:39:17 UTC
Permalink
Post by Raphaël Halimi
Hi,
I have two questions about authoritative mode.
I have a home LAN, with a classic Bind / ISC DHCP / HPA TFTP setup
(started long before dnsmasq ever existed).
Recently I decided to rent a server to externalize some public services
(web, mail and DNS servers). This server is a libvirt/KVM hypervisor and
all virtual machines are connected through a purely virtual bridge, and
dnsmasq handles the DNS/DHCP/TFTP part of this LAN (the private part
only, no relation to the the public DNS mentioned above). So I'm quite
new to dnsmasq and so far I'm quite impressed by the vast possibilities
it allows with such a small footprint. Note that for practical reasons,
I don't use libvirt's builtin iptables/dnsmasq configurations, I made my
own.
So, I interconnected both LANs through a VPN (OpenVPN) and all machines
can happily communicate. Now I'm trying to ease the DNS administration
part, and that's where I'm stuck on a couple of minor problems (really
minor, since my setup works quite well, I'm just trying to perfect it a
bit).
What I'm trying to do is to allow my home LAN's DNS system (Bind) to
know about the remote LAN's zone, and fetch the zone data from the
remote LAN's dnsmasq (through AXFR). It was quite easy to define a slave
type zone, in Bind, and then allow zone transfers in dnsmasq with two
auth-sec-servers=<Bind server's IP>
auth-peer=<Bind server's IP>
Now, the problem is that I'd like the remote LAN to be completely
unaware (DNS-wise, at least) of the home LAN's DNS system; in other
words, I don't want the Bind server's IP to be listed as a secondary
server in the remote LAN's zone data. So I tried to remove the
"auth-sec-servers=..." line, but unfortunately this prevented the zone
transfer to work.
I know it works with Bind: I can define slave zones on some server,
while the actual zone file on the master has no mention of any slave
server (of course, it's still allowed in the server's configuration by
an "allow-transfer" directive, though), making the slave server
completely stealth. So this is my first question: is there a way to
achieve this with dnsmasq ? If not, is this planned, or could it be
considered for a future release ?
This is just some security logic, since omiting auth-peer is allowed,
and accepts AXFR requests from anywhere, AXFR is inhibited unless
auth-sec-servers is specified. Otherwise, a dnsmasq instance without any
secondary-server configuration would be open to zone transfers from
anywhere, which is not a good default. The obvious solution is to allow
zone transfers even if there is no auth-sec-servers config, as long as
auth-peer is specified and satisfied.

This commit implements that.

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=090856c7e6d483bc4d7ec41f55208a9842769c45
Post by Raphaël Halimi
My second question is more of a feature... inquiry (I was about to write
"request" but that would be not only rude, but also not totally faithful
to my state of mind).
As stated in dnsmasq's manual page (version 2.76, Debian stretch): "at
present, reverse (in-addr.arpa and ip6.arpa) zones are not available in
zone transfers, so there is no point arranging secondary servers for
reverse lookups". So my second question is quite simple: is it planned
for a future release ? By searching the mailing list, I saw that a lot
of features were considered by the developer(s ?) kind of "outside of
scope for such a tiny tool" a decade ago, yet they were finally
implemented and are nowadays supported (the power of popular demand, I
guess). Since the code for managing AXFR requests is already there,
would this feature be hard to implement ?
The complexity arises because dnsmasq doesn't store "reverse" records
and PTR records in an in-addr.arpa zone. To answer individual queries,
it essentially extracts the IP address encoded in the domain name, and
looks up IP addresses in the internal data structures. This is a result
of a very old design decision.

Doing a AXFR of a in-addr.arpa zone, therefore requires iterating over
all the name<->IP address mappings, and looking for addresses that end
up in the zone in question. It would be possible, but it would be a lot
of new code, especially for IPv6.

Cheers,

Simon.
Post by Raphaël Halimi
(note that as much as I'd like to, I couldn't help with this, since I'm
a pure admin, my development skills are limited to shell and, to some
extent, Perl).
Thanks a lot in advance for answering those two questions.
Regards,
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Raphaël Halimi
2018-06-02 20:58:17 UTC
Permalink
Post by Simon Kelley
This is just some security logic, since omiting auth-peer is allowed,
and accepts AXFR requests from anywhere, AXFR is inhibited unless
auth-sec-servers is specified. Otherwise, a dnsmasq instance without any
secondary-server configuration would be open to zone transfers from
anywhere, which is not a good default. The obvious solution is to allow
zone transfers even if there is no auth-sec-servers config, as long as
auth-peer is specified and satisfied.
This commit implements that.
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=090856c7e6d483bc4d7ec41f55208a9842769c45
The complexity arises because dnsmasq doesn't store "reverse" records
and PTR records in an in-addr.arpa zone. To answer individual queries,
it essentially extracts the IP address encoded in the domain name, and
looks up IP addresses in the internal data structures. This is a result
of a very old design decision.
Doing a AXFR of a in-addr.arpa zone, therefore requires iterating over
all the name<->IP address mappings, and looking for addresses that end
up in the zone in question. It would be possible, but it would be a lot
of new code, especially for IPv6.
Thank you very much for answering both questions, and implementing the
solution to the first one so quickly.

For the second one, I can live with a tiny script that converts the A
records from the zone data to PTR records and build a zone file.

Thanks again !

Regards,
--
Raphaël Halimi
Loading...