Discussion:
[Dnsmasq-discuss] make synth-domain a authoritative response
Markus Hartung
2018-03-11 02:43:06 UTC
Permalink
I have dug a little more and I can't think of this behaviour to be
nothing else than a bug.

I have made a simple config now to reproduce the bug:

Start server with this command:

dnsmasq -p 1153 --synth-domain=hartmark.se,2001:db8::/64,dynamic-
--auth-server=ns1.hartmark.se,192.168.1.1
--auth-zone=hartmark.se,192.168.1.1,2001:db8::/64
--auth-soa=,hostmaster.hartmark.se,1200,180,1209600 --ho
st-record=foo.hartmark.se,2001:db8::f00 -d --bind-dynamic

Replace 192.168.1.1 with your local ip.

Run these dig:s

1. dig -p 1153 -x 2001:db8::f00

2. dig -p 1153 -x 2001:db8::f00 @192.168.1.1

3. dig -p 1153 -x 2001:db8::d00

4. dig -p 1153 -x 2001:db8::d00 @192.168.1.1


dig 1 and 2 both return foo.hartmark.se as response. 1 is using
localhost (127.0.0.1 or ::1) and that is not part of neither auth-server
and auth-zone

dig 3 returns dynamic-2001-db8--d00.hartmark.se

dig 4 returns NXDOMAIN


Have I misunderstood something?? From my understanding it seems dnsmasq
doesn't check synth-domain when responding on requests where dnsmasq is
authoritative.



Kind regards,

Markus
Simon Kelley
2018-03-15 16:14:01 UTC
Permalink
Post by Markus Hartung
I have dug a little more and I can't think of this behaviour to be
nothing else than a bug.
dnsmasq -p 1153 --synth-domain=hartmark.se,2001:db8::/64,dynamic-
--auth-server=ns1.hartmark.se,192.168.1.1
--auth-zone=hartmark.se,192.168.1.1,2001:db8::/64
--auth-soa=,hostmaster.hartmark.se,1200,180,1209600 --ho
st-record=foo.hartmark.se,2001:db8::f00 -d --bind-dynamic
Replace 192.168.1.1 with your local ip.
Run these dig:s
1. dig -p 1153 -x 2001:db8::f00
3. dig -p 1153 -x 2001:db8::d00
dig 1 and 2 both return foo.hartmark.se as response. 1 is using
localhost (127.0.0.1 or ::1) and that is not part of neither auth-server
and auth-zone
dig 3 returns dynamic-2001-db8--d00.hartmark.se
dig 4 returns NXDOMAIN
Have I misunderstood something?? From my understanding it seems dnsmasq
doesn't check synth-domain when responding on requests where dnsmasq is
authoritative.
Is it a bug if it fulfils the specification? :-)

The section of the man page on AUTHORITATIVE CONFIGURATION lists all the
sources of data for an auth zone, and it doesn't include synth-domain.
So there's no bug :)

The main reason that synth-domain is not included is that it makes doing
domain-transfer difficult. That sends every record in the domain to a
secondary server, and synth-domain would rapdily balloon into a LOT of
records (especially in IPv6-land).

Cheers,

Simon.
Markus Hartung
2018-03-15 23:00:08 UTC
Permalink
Post by Simon Kelley
Is it a bug if it fulfils the specification? :-)
The section of the man page on AUTHORITATIVE CONFIGURATION lists all the
sources of data for an auth zone, and it doesn't include synth-domain.
So there's no bug :)
The main reason that synth-domain is not included is that it makes doing
domain-transfer difficult. That sends every record in the domain to a
secondary server, and synth-domain would rapdily balloon into a LOT of
records (especially in IPv6-land).
Cheers,
Simon.
I see. It seems to have missed that part in the documentation. Didn't
think of domain-transfers, but I guess you're right that it won't be
possible to have IPv6 and synth-domain transferred.

So I agree it's not a bug ;)

I guess I have to live with that the reverse-dns name will be unknown
when doing for example a "last -da" on a remote system that you have
connected to.

One option would be to allow reverse lookups to get the synth-domain
name but that it won't be forward-lookup:able, so we won't get the issue
with having hostnames that we can't zone-transfer.

When connecting to my local server from my phone I always get this
reverse-hostname for my IPv6-address on cell network.
"m-ipv6.cust.tele2.se", so I guess it's "allowed" for a ip to resolve to
a hostname and have that hostname resolve to NXDOMAIN

But then again I won't loose any sleep over this because my
IPv6-addresses resolve properly locally on my network because queries
from LAN gets the non-authoritative response.

Keep up the good work!

BR,
Harre

Loading...