[Dnsmasq-discuss] Authoritative zone and no recursion replies

[Simon Kelley]

On 15/02/2019 12:54, Petr Mensik wrote:
> Hi everyone.
> 
> I think it is handy to be able to delegate some suffix from internal
> domain, lets say example.com provided by BIND or any bigger server. But
> recursive servers do not set recursive queries on normal delegation.
> Delegation is when I just add line into zone file:
> 
> $ORIGIN example.com.
> dnsmasq-private IN A 10.0.0.53
> private IN NS dnsmasq-private
> 
> Then query to xy.private.example.com would be forwarded to dnsmasq. It
> is great this can be configured by dynamic update of a zone. No change
> of configuration is necessary. It requires dnsmasq to be accessible by
> recursive resolvers. Great for trusted network configuration.
> 
> Unfortunately, dnsmasq does not cooperate very well with them. Recursive
> servers use queries without recursion desired flag set. Dnsmasq tends to
> refuse it or servfail if any forwarder is configured. For each host it
> reads from /etc/hosts or configured from DHCP, I think it would be nice
> to respond also without recursion to every host from hosts. The same way
> for DHCP assigned names. AFAIK it is denied to disallow cache probing.
> What is point to deny provided names without recursion set, when it
> gracefully offers it when recursion is desired?
> 
> compare when at least one server is set:
> dig +rec mydnsmasqhost
> dig +norec mydnsmasqhost
> 
> where mydnsmasqhost is hostname which obtained address from dnsmasq.
> 
> It just makes delegation from big resolvers difficult. Without auth-zone
> with common prefix, it would not work. Is there a good reason for it? If
> domain is set, it would be easy to create delegation without need to
> auth-zone set.
> 
> My example would work if --auth-zone=private.example.com would be used.
> While it is better, why should not --domain private.example.com be
> sufficient? It would be quite useful for VM configuration, because
> current libvirt does not support adding auth-zone to dnsmasq
> configuration file.
> 
> Any comments welcome.
> 
> Have a nice day,
> Petr
> 

The behaviour in receiving a query without RD set changed in

http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=4139298d287eb5c57f4aa53c459cb02fc5be2495

which doesn't directly help you, but does need to be taken into account.

If I understand you correctly, you want the behaviour to change if the
query can be answered from configured (/etc/hosts and so on) data,
whilst keeping the same behaviour for answers which came from upstream,
but are merely cached.

To answer the question "What is point to deny provided names without
recursion set, when it gracefully offers it when recursion is desired?"
The aim is to avoid a client being able to tell the difference between
an answer coming from the dnsmasq cache, and one coming from upstream.
If RD is set, it will get an answer, either from upstream, or from the
cache. It can't tell the difference. The original behaviour with RD
_unset_ was to either answer from the cache, or fail (not sending
upstream), allowing the client to deduce the contents of the cache. That
was changed to always SERVFAIL, and then the latest change is to always
forward upstream. The reason given for this is to allow dig +trace to
operate through dnsmasq.

It seems that actually just ignoring the RD bit i) disallows cache
snooping, ii) allows dig +trace to operate. Maybe that should be the
behaviour?


Simon.