Hello,
I’m seeing libunbound query results differ depending on cache results for an improperly-configured domain. I’m wondering what options are available to mitigate this.
The domain in question is “ryanjanzen.org”. The problem can be seen by comparing two libunbound invocations (via Perl DNS::Unbound):
I'm seeing libunbound query results differ depending on cache
results for an improperly-configured domain. I'm wondering what
options are available to mitigate this.
"Fix the improperly configured domain?" 
The .org zone delegates to
ryanjanzen.org. 86400 IN NS dns.domainsatcost.ca.
ryanjanzen.org. 86400 IN NS dns2.domainsatcost.ca.
Those two however returns the following NS set:
ryanjanzen.org. 3600 IN NS ns1.a2hosting.com.
ryanjanzen.org. 3600 IN NS ns2.a2hosting.com.
And again those two name servers presents an NS RRset with two more
name servers:
ryanjanzen.org. 86400 IN NS ns4.a2hosting.com.
ryanjanzen.org. 86400 IN NS ns3.a2hosting.com.
ryanjanzen.org. 86400 IN NS ns1.a2hosting.com.
ryanjanzen.org. 86400 IN NS ns2.a2hosting.com.
I bet the first two ones are not in sync (secondary name servers) of
the a2hosting.com servers (confirmed with
dig @dns2.domainsatcost.ca. ryanjanzen.org. soa +norec
dig @ns1.a2hosting.com. ryanjanzen.org. soa +norec
), so when you ask your recursor about something else from that zone
it depends on whether caching state for these NS records which name
server your recursor will end up querying, and you may get different
results depending on this.
There is basically nothing scaleable you as recursive resolver
operator can do about these types of errors -- it's all up to the
domain owner and the control he has over the zone publishing to fix
this properly.
Regards,
- Håvard
Alas, we don’t control the domain. Its misconfiguration is causing our SSL-provisioning logic to misbehave, though.
I’d love to find some sort of reusable code I could deploy to nag domain owners about such things, but thus far I’ve not found any. Kind of surprising given the proliferation of web-based DNS-integrity checkers.
Anyhow, thank you!
cheers,
-Felipe