@ipv4.dnsp.co
Pin which transport your query travels over.
What it does
dnsp.co resolves to both an IPv4 and an IPv6 address, so a normal query reaches us over whichever your resolver happens to prefer. That is usually what you want, and occasionally exactly what you do not: if you are testing whether a v6 path works at all, you need to be able to force it.
ipv4.dnsp.co and ipv6.dnsp.co are the same server published one family at a time. Aim a query at one of them and the query has to travel that way or not at all. Pair it with reflect.dnsp.co and the answer tells you the address we saw you arrive from, which confirms the family end to end rather than just the intent.
ipv6.dnsp.co has no A record, deliberately. A client with no working IPv6 cannot reach it, and the failure is the result.
Reading the answer
You are talking to us directly and nothing re-originated the query.
A resolver or proxy is asking on your behalf, which is normal when you did not use @dnsp.co.
Something inside your network is terminating DNS and forwarding it itself.
You are behind a resolver fleet. Repeat a few times before concluding anything.
Notes
- ipv6.dnsp.co publishes AAAA only. dig may report that it cannot get an address for the server name, which is the same finding stated differently.
- Both names answer every option this server offers. The only thing that changes is how your query got here.