server=/example.com/<ip-of-server>

The rationale is that the chain-of-trust will not be complete to
private servers. If it was, it would not be necessary to access the
server direct.

Thanks to Michał Kępień for spotting this.

A zone which has at least one key with an algorithm we don't
support should be considered as insecure.

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.

Thanks to Brian Carpenter and American Fuzzy Lop for finding the bug.

When we can validate a DS RRset, but don't speak the hash algo it
contains, treat that the same as an NSEC/3 proving that the DS
doesn't exist. 4025 5.2

RFC6303 specifies & recommends following zones not be forwarded
to globally facing servers.
+------------------------------+-----------------------+
| Zone                         | Description           |
+------------------------------+-----------------------+
| 0.IN-ADDR.ARPA               | IPv4 "THIS" NETWORK   |
| 127.IN-ADDR.ARPA             | IPv4 Loopback NETWORK |
| 254.169.IN-ADDR.ARPA         | IPv4 LINK LOCAL       |
| 2.0.192.IN-ADDR.ARPA         | IPv4 TEST-NET-1       |
| 100.51.198.IN-ADDR.ARPA      | IPv4 TEST-NET-2       |
| 113.0.203.IN-ADDR.ARPA       | IPv4 TEST-NET-3       |
| 255.255.255.255.IN-ADDR.ARPA | IPv4 BROADCAST        |
+------------------------------+-----------------------+
Signed-off-by: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>

 Logs, eg,  iptables DROPS of dest 255.255.255.255