The list of exceptions to being able to locally answer
cached data for validated records when DNSSEC data is requested
was getting too long, so don't ever do that. This means
that the cache no longer has to hold RRSIGS and allows
us to lose lots of code. Note that cached validated
answers are still returned as long as do=0
Much gnarly special-case code removed and replaced with correct
general implementaion. Checking of zone-status moved to DNSSEC code,
where it should be, vastly simplifying query-forwarding code.
Return INSECURE when validating DNS replies which have RRSIGs, but
when a needed DS record in the trust chain is proved not to exist.
It's allowed for a zone to set up DNSKEY and RRSIG records first, then
add a DS later, completing the chain of trust.
Also, since we don't have the infrastructure to track that these
non-validated replies have RRSIGS, don't cache them, so we don't
provide answers with missing RRSIGS from the cache.
The nasty code with static variable in retry_send() which
avoids looping forever needs to be called on success of the syscall,
to reset the static variable.
check_for_local_domain() was broken due to new code matching F_*
bits in cache entries for DNSSEC. Because F_DNSKEY | F_DS is
used to match RRSIG entries, cache_find_by_name() insists on an exact match
of those bits. So adding F_DS to the bits that check_for_local_domain()
sends to cache_find_by_name() won't result in DS records as well
as the others, it results in only DS records. Add a new bit, F_NSIGMATCH
which suitably changes the behaviour of cache_find_by_name().
This handles the case that more than one interface contains
the network the lease address is on, but the interfaces have different
prefix lengths. Use the longest prefix length.
- With nested prefixes reside on different interfaces of single host
(e.g., in 6to4, 2002::/16 on WAN and 2002:<IPv4>:<subnet>::/64 on LAN),
current matching mechanism might return the interface with shorter prefix
length instead of the longer one, if it appears later in the netlink message.
Signed-off-by: Lung-Pin Chang <changlp@cs.nctu.edu.tw>
This is useful when using dnsmasq as DHCP server for a set of VMs
whose data is routed by the host instead of being bridged. In this
scenario:
- There is an unbounded set of TAP interfaces that have no IP address
at the host end.
- DHCP allocation is done from an IPv4 address range associated with a
dummy interface.
- We run dnsmasq with --interface dummy --interface tap*
--bind-dynamic, so that it listens on all the TAP interfaces, and
--bridge-interface=dummy,tap*, so that it will allocate IP addresses
via the TAP interfaces from the range associated with the dummy
interface.
