Hello. I know referral path hardening is an experimental feature. But when testing new software, I always like to see what all the knobs and switches do and how they work, where they help and, especially, what they break and what the symptoms are, so I can recognize it easier.
I have a (not-DNSSEC-signed) subdomain with what I think is a mostly straight-forward referral path, except that it shares some but not all nameservers with its parent zone. With "harden-referral-path" and DNSSEC validation enabled, I can query every name in that domain once and as long as that answer is in the cache. Subsequent queries after TTL expiry return SERVFAIL. Disabling *either* "harden-referral-path" or "dlv-anchor-file" fixes the problem. This is with Unbound 1.3.0. The authoritative servers for my subdomain run tinydns, BIND 9.6 and NSD 3, although the result is always the same, regardless of which server Unbound queries. Any thoughts on this? Although I probably won't enable "harden-referral-path" in a productive environment, this problem keeps me wondering because I don't see where my delegation path would be wrong. Or is it the path to dlv.isc.org that causes it? I can repeatedly query other low-TTL records, though, without any failures. The first query looks like this: > info: resolving <frell.ambush.de. A IN> > info: response for <frell.ambush.de. A IN> > info: reply from <ambush.de.> 82.197.159.53#53 > info: query response was ANSWER > info: resolving <frell.ambush.de.dlv.isc.org. DLV IN> > info: response for <frell.ambush.de.dlv.isc.org. DLV IN> > info: reply from <dlv.isc.org.> 199.6.1.29#53 > info: query response was ANSWER > info: validate(nxdomain): sec_status_secure > info: validation success <frell.ambush.de.dlv.isc.org. DLV IN> resulting in this response: > ;; ANSWER SECTION: > frell.ambush.de. 23 IN A 85.177.253.56 z > ;; AUTHORITY SECTION: > frell.ambush.de. 230042 IN NS ns1.frell.ambush.de. > frell.ambush.de. 230042 IN NS ns3.frell.ambush.de. > frell.ambush.de. 230042 IN NS ns4.frell.ambush.de. > frell.ambush.de. 230042 IN NS a.ns.ambush.de. > frell.ambush.de. 230042 IN NS b.ns.ambush.de. > frell.ambush.de. 230042 IN NS n.ns.ambush.de. I can repeat the query for the next 23 seconds and get the cached answer. After the TTL expires, the next lookups seems fine in the logfile but return SERVFAIL: > info: resolving <frell.ambush.de. A IN> > info: response for <frell.ambush.de. A IN> > info: reply from <frell.ambush.de.> 213.9.73.106#53 > info: query response was ANSWER > info: resolving <frell.ambush.de.dlv.isc.org. DLV IN> What stands out to me is that Unbound always queries for both the A record and the DLV record. Shouldn't it have cached the NXDOMAIN answer to the DLV query earlier? It never does this for other records with low TTL (like frell.ath.cx). Also, "resolving" is actually the last entry, there are no "reply" and "query response" entries following it. Indeed, tcpdump shows only the A request going out, no query for the DLV record. I can resolve other names in the zone (ie. mail.frell.ambush.de) and always get the same behaviour. The first query suceeds, subsequent queries (after the initial TTL expired) all fail. Hauke.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
