A single anycast IP address does not give you the same redundancy as two unicast IP addresses in distinct IP prefixes would.
Often the hardest problem for redundancy is not when something fails completely, but rather when it is misbehaving just enough to still pass the health checks, but not actually be functional.
I have seen an anycast DNS setup where a DNS server went down, but packets would still get routed to that DNS server. Whatever was taking care of advertising the prefix might simply not be aware, that the DNS server had gone down.
It becomes even more tricky if the DNS server in question is not an authoritative DNS server, but rather a recursive resolver.
Such a recursive resolver would need to have both the anycast address for receiving queries from clients and unicast addresses for querying authoritative DNS servers. But if the unicast addresses went down, it could easily look healthy enough that it would still be routed queries.
Anycast is a great tool for scalability and reducing latency. But for redundancy it should not stand alone.
Multiple redundant anycast pools is however a good solution for availability. A well known example is 8.8.8.8 and 8.8.4.4. Both are anycast addresses, but they should never be routed to the same physical DNS server (assuming Google did their job well).
If you have 10 physical DNS servers, you could configure them as 2 pools with 5 servers in each pool or 5 pools with 2 in each pool. You want to avoid having one physical DNS server be in multiple pools simultaneously.
So how many IPs should you allocate? You need to have IPs that can be configured as anycast independently of each other. That usually means you'll need to allocate an entire /24 of IPv4 address space or /48 of IPv6 address space for each pool. This may very well limit the number of pools you can have.
Additionally if we are talking authoritative servers the DNS reply with all your NS records and A and AAAA glue should fit in a single 512 byte packet. For the root servers this worked out to 13 addresses. But that did not include glue and IPv6, so the number you'd reach would be lower.
Each pool should be as geographically distributed as possible. If you have 5 servers in Europe and 5 in Noth America and 2 anycast IPs, you do not create one pool spanning each continent. You put 2 from Europe in a pool with 3 from North America, and the other 5 in the other pool.
If you have more than 2 anycast pools, you can let a physical server temporarily be in more than one pool. But you should never allow a physical server to be in all pools at the same time.
Combining anycast and unicast is possible, but care must be taken. If you have IPs for two pools, I wouldn't combine. But if you only have a single anycast IP to work with, it may make sense to also include unicast IPs. The problem is that including unicast IPs will not give you as good latency and load balancing.
If a physical server is made available by both unicast and anycast, you may risk users reaching the same server as primary and secondary and lose access if it goes down. This can be avoided by only using unicast addresses of servers not in the anycast pool or by always providing users with two unicast addresses.
The more unicast addresses you put into the mix, the less queries will be sent to the anycast address, and the less benefit you will get from anycast in terms of latency and scalability.
