Bug 1412 - QNAME minimisation strict mode not honored
QNAME minimisation strict mode not honored
Status: ASSIGNED
Product: unbound
Classification: Unclassified
Component: server
1.6.4
x86_64 Linux
: P5 critical
Assigned To: unbound team
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-08-17 14:21 CEST by Jerry Lundström
Modified: 2017-09-05 08:32 CEST (History)
2 users (show)

See Also:


Attachments
Full log of QNAME minimisation check (15.26 KB, text/plain)
2017-08-17 14:21 CEST, Jerry Lundström
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jerry Lundström 2017-08-17 14:21:30 CEST
Created attachment 434 [details]
Full log of QNAME minimisation check

Hi,

After launching Check My DNS v2 I got a report that QNAME minimisation check was not working with 1.6.x+ even with strict mode.

I've now had the time to test myself and it is not working 100%. I have a Debian Sid VM running the packaged Unbound 1.6.4 using:

  server:
    verbosity: 3
    qname-minimisation: yes
    qname-minimisation-strict: yes

When I use it to browse to https://cmdns.dev.dns-oarc.net/ the QNAME minimisation check fails and in the syslog I found this. For background, the Check My DNS has a root zone at ::250/.250, this delegates the QNAME check zone to ::254/.254 and the check will fail if anything more then $id.$base is sent to ::250/.250. Note; I do not have IPv6 but Check My DNS does.

  info: resolving qname.fs3n3enjuh2jlf64f7ie0mtl28.cmdns.dev.dns-oarc.net. A IN
  info: resolving (init part 2):  qname.fs3n3enjuh2jlf64f7ie0mtl28.cmdns.dev.dns-oarc.net. A IN
  info: resolving (init part 3):  qname.fs3n3enjuh2jlf64f7ie0mtl28.cmdns.dev.dns-oarc.net. A IN
  info: processQueryTargets: qname.fs3n3enjuh2jlf64f7ie0mtl28.cmdns.dev.dns-oarc.net. A IN
  debug: removing 1 labels
  info: sending query: fs3n3enjuh2jlf64f7ie0mtl28.cmdns.dev.dns-oarc.net. A IN
  debug: sending to target: <cmdns.dev.dns-oarc.net.> 2a01:3f0:0:57::250#53
  info: error sending query to auth server 2a01:3f0:0:57::250 port 53
  info: processQueryTargets: qname.fs3n3enjuh2jlf64f7ie0mtl28.cmdns.dev.dns-oarc.net. A IN
  info: sending query: qname.fs3n3enjuh2jlf64f7ie0mtl28.cmdns.dev.dns-oarc.net. A IN
  debug: sending to target: <cmdns.dev.dns-oarc.net.> 77.72.225.250#53

As you can see, it sends the first query to the IPv6 address but that will of course fail. What it does then is resent it to the IPv4 address but using the full QNAME.

One could argue that I have not configured not to use IPv6 but this is very plain install and it doesn't feel like something you would need to configure. It would be better if strict more was strict or if Unbound was smarter at knowing if IPv6 can be used or not.

Full log of QNAME minimisation check attached.

Cheers,
Jerry
Comment 1 Ralph Dolmans 2017-09-04 17:20:49 CEST
Thanks for the detailed report Jerry!

Increasing the QNAME when the query could not be sent is indeed not correct. I committed this patch to trunk which should fix this issue:

Index: iterator/iterator.c
===================================================================
--- iterator/iterator.c	(revision 4335)
+++ iterator/iterator.c	(working copy)
@@ -2169,7 +2169,6 @@
 		}
 	}
 	if(iq->minimisation_state == SKIP_MINIMISE_STATE) {
-		iq->minimise_timeout_count++;
 		if(iq->minimise_timeout_count < MAX_MINIMISE_TIMEOUT_COUNT)
 			/* Do not increment qname, continue incrementing next 
 			 * iteration */
@@ -2210,6 +2209,8 @@
 		if(!(iq->chase_flags & BIT_RD) && !iq->ratelimit_ok)
 		    infra_ratelimit_dec(qstate->env->infra_cache, iq->dp->name,
 			iq->dp->namelen, *qstate->env->now);
+		if(qstate->env->cfg->qname_minimisation)
+			iq->minimisation_state = SKIP_MINIMISE_STATE;
 		return next_state(iq, QUERYTARGETS_STATE);
 	}
 	outbound_list_insert(&iq->outlist, outq);
@@ -2259,8 +2260,10 @@
 
 	if(iq->response == NULL) {
 		/* Don't increment qname when QNAME minimisation is enabled */
-		if(qstate->env->cfg->qname_minimisation)
+		if(qstate->env->cfg->qname_minimisation) {
+			iq->minimise_timeout_count++;
 			iq->minimisation_state = SKIP_MINIMISE_STATE;
+		}
 		iq->chase_to_rd = 0;
 		iq->dnssec_lame_query = 0;
 		verbose(VERB_ALGO, "query response was timeout");
Comment 2 Jerry Lundström 2017-09-05 08:32:16 CEST
Hi Ralph,

I applied the patch to the Debian sid package 1.6.5-1, rebuilt the package, installed it and it seems to have solved the issue.

  info: resolving qname.mb76vta0c551fep01q8ho8hfh4.cmdns.dev.dns-oarc.net. A IN
  info: resolving (init part 2):  qname.mb76vta0c551fep01q8ho8hfh4.cmdns.dev.dns-oarc.net. A IN
  info: resolving (init part 3):  qname.mb76vta0c551fep01q8ho8hfh4.cmdns.dev.dns-oarc.net. A IN
  info: processQueryTargets: qname.mb76vta0c551fep01q8ho8hfh4.cmdns.dev.dns-oarc.net. A IN
  debug: removing 1 labels
  info: sending query: mb76vta0c551fep01q8ho8hfh4.cmdns.dev.dns-oarc.net. A IN
  debug: sending to target: <cmdns.dev.dns-oarc.net.> 2a01:3f0:0:57::250#53
  info: error sending query to auth server 2a01:3f0:0:57::250 port 53
  info: processQueryTargets: qname.mb76vta0c551fep01q8ho8hfh4.cmdns.dev.dns-oarc.net. A IN
  info: sending query: mb76vta0c551fep01q8ho8hfh4.cmdns.dev.dns-oarc.net. A IN
  debug: sending to target: <cmdns.dev.dns-oarc.net.> 2a01:3f0:0:57::250#53
  info: error sending query to auth server 2a01:3f0:0:57::250 port 53
  info: processQueryTargets: qname.mb76vta0c551fep01q8ho8hfh4.cmdns.dev.dns-oarc.net. A IN
  info: sending query: mb76vta0c551fep01q8ho8hfh4.cmdns.dev.dns-oarc.net. A IN
  debug: sending to target: <cmdns.dev.dns-oarc.net.> 2a01:3f0:0:57::250#53
  info: error sending query to auth server 2a01:3f0:0:57::250 port 53
  info: processQueryTargets: qname.mb76vta0c551fep01q8ho8hfh4.cmdns.dev.dns-oarc.net. A IN
  info: sending query: mb76vta0c551fep01q8ho8hfh4.cmdns.dev.dns-oarc.net. A IN
  debug: sending to target: <cmdns.dev.dns-oarc.net.> 77.72.225.250#53

Cheers,
Jerry