Maintained by: NLnet Labs

[Unbound-users] "harden-referral-path" returns SERVFAIL on subsequent queries

Hauke Lampe
Sun Jun 14 20:03:33 CEST 2009


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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://unbound.nlnetlabs.nl/pipermail/unbound-users/attachments/20090614/3aea7307/attachment.pgp>