Notes below On 3/7/19 6:09 PM, Simon Kelley wrote: > 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. Always forwarding upstream seems very wrong to me. If I receive query without rd bit set, it is asking me for authoritative contents OR direction where should I ask.
I understand dnsmasq does not really undestands zones, it cannot direct me to NS of authoritative server. But IF queried bit IS provided by dnsmasq, then it MUST respond with data. That is purpose of that bit, that is reason it is in queries. I admit cache snooping could be bad, but I am not confident it such behaviour should not be configurable. In the first place, queries from untrusted networks should be blocked at all. I think it is useful for admin to be able look inside cache for remaining timeouts. I think it would be nice, if localhost queries without rd were accepted by default and it was possible specify somehow, who should be able to do that. > > 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? No, I do not think so. I think proper delegation reply should be generated instead. In this case, it might help, if all names NOT provided by dnsmasq were forwarded upstream for proper delegation, but dnsmasq served data should be answered by dnsmasq without delegation. Cheers, Petr -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: 65C6C973 _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
