Responses erroneously marked "invalid response"?

[Havard Eidnes]

Hi,

I've semi-recently updated a public resolver to running a bit newer
version of BIND, currently at 9.8.4-P3.

I've noticed that quite a number of query responses it receives
are logged with "DNS format error" ... "invalid response". Some
semi-random examples picked from the log:

apis.markets.ft.com/AAAA 209.234.224.42
apis.markets.ft.com/AAAA 209.234.234.42
apis.markets.ft.com/AAAA 66.150.28.2
eu-sonar.sociomantic.com/AAAA 204.69.234.1
eu-sonar.sociomantic.com/AAAA 204.74.101.1
sn2.storage.msn.com/AAAA 207.46.0.139
sn2.storage.msn.com/AAAA 207.46.0.140
sn2.storage.msn.com/AAAA 65.55.195.203
sn2.storage.msn.com/AAAA 65.55.195.204
sb3-alt.map.media6degrees.com/AAAA 2001:500:90:1::27
sb3-alt.map.media6degrees.com/AAAA 2001:500:94:1::27
sb3-alt.map.media6degrees.com/AAAA 204.13.250.27
sb3-alt.map.media6degrees.com/AAAA 204.13.251.27
sb3-alt.map.media6degrees.com/AAAA 208.78.70.27
sb3-alt.map.media6degrees.com/AAAA 208.78.71.27
ws.mcafee.com/AAAA 161.69.13.53
ws.mcafee.com/AAAA 205.227.136.200
ws.mcafee.com/AAAA 67.97.80.200
www.euskadi.net/AAAA 195.77.108.238
www.euskadi.net/AAAA 212.55.29.238

These are the "queried-for name + type" and "IP address of name
server response came from".

Common for all of these is that the clients have quried for AAAA
records (I've also seen a query for SRV which ended up in this
category). Inspecting the output from "dig" when querying these
name servers directly with e.g. +norec +dnssec, it doesn't look (to
the naked eye, interpreting "dig" output) like there is anything
wrong with the responses from these name servers. Common among them
is that they have an empty answer section, and one SOA record in the
authority section.

The client after a while gets SERVFAIL for most of these, though for
www.euskadi.net I get no response before the client times out, and
BIND moans about FORMERR and "invalid response" in the log, many,
many times per original client query.

Now, I've on a test machine tried to instrument the
noanswer_response() function in lib/dns/resolver.c with some code to
log if it finds the SOA record in the authority section, but
apparently that's not happening for these particular answers (but it
hits for others). So we end up in the "no SOA, no NS, no CNAME, no
answer => formerr" part of the code where log_formerr() is called
with "invalid response" as argument.

Unbound returns empty responses to the client with status=NOERROR
when queried for these names + types, which I think is the correct
behaviour.

So I'm sitting here scrathing my head even more confused than
usual. Anyone have any insights?

Regards,

- Håvard

[Tony Finch]

Havard Eidnes <h...@uninett.no> wrote:

> So I'm sitting here scrathing my head even more confused than
> usual. Anyone have any insights?

The SOA has the wrong owner name. Bind followed a referral for
map.media6degrees.com but the SOA wrongly says the zone apex is
media6degrees.com.

https://lists.isc.org/pipermail/bind-users/2009-December/078403.html
http://fanf.livejournal.com/107721.html

Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

[Havard Eidnes]

>> So I'm sitting here scrathing my head even more confused than
>> usual. Anyone have any insights?
>
> The SOA has the wrong owner name. Bind followed a referral for
> map.media6degrees.com but the SOA wrongly says the zone apex is
> media6degrees.com.
>
> https://lists.isc.org/pipermail/bind-users/2009-December/078403.html
> http://fanf.livejournal.com/107721.html

Ah! OK, then let me offer the following patch to reduce
confusion among those who might inadvertently start following my
tracks:

--- lib/dns/resolver.c.orig 2012-08-24 04:40:57.000000000 +0000
+++ lib/dns/resolver.c
@@ -5418,10 +5418,10 @@ noanswer_response(fetchctx_t *fctx, dns_
{
isc_result_t result;
dns_message_t *message;
- dns_name_t *name, *qname, *ns_name, *soa_name, *ds_name;
+ dns_name_t *name, *qname, *ns_name, *soa_name, *ds_name, *save_name;
dns_rdataset_t *rdataset, *ns_rdataset;
isc_boolean_t aa, negative_response;
- dns_rdatatype_t type;
+ dns_rdatatype_t type, save_type;
dns_section_t section;

FCTXTRACE("noanswer_response");
@@ -5488,6 +5488,8 @@ noanswer_response(fetchctx_t *fctx, dns_
ns_rdataset = NULL;
soa_name = NULL;
ds_name = NULL;
+ save_name = NULL;
+ save_type = dns_rdatatype_none;
result = dns_message_firstname(message, section);
while (result == ISC_R_SUCCESS) {
name = NULL;
@@ -5580,6 +5582,9 @@ noanswer_response(fetchctx_t *fctx, dns_
dns_trust_additional;
}
}
+ } else {
+ save_name = name;
+ save_type = ISC_LIST_HEAD(name->list)->type;
}
result = dns_message_nextname(message, section);
if (result == ISC_R_NOMORE)
@@ -5721,7 +5726,35 @@ noanswer_response(fetchctx_t *fctx, dns_
/*
* The responder is insane.
*/
- log_formerr(fctx, "invalid response");
+ if (save_name == NULL) {
+ log_formerr(fctx, "invalid response");
+ return (DNS_R_FORMERR);
+ }
+ if (!dns_name_issubdomain(save_name, &fctx->domain)) {
+ char nbuf[DNS_NAME_FORMATSIZE];
+ char dbuf[DNS_NAME_FORMATSIZE];
+ char tbuf[DNS_RDATATYPE_FORMATSIZE];
+ const char *s;
+
+ dns_rdatatype_format(save_type,
+ tbuf, sizeof(tbuf));
+ dns_name_format(save_name, nbuf,
+ sizeof(nbuf));
+ dns_name_format(&fctx->domain, dbuf,
+ sizeof(dbuf));
+
+ if (section == DNS_SECTION_ANSWER)
+ s = "answer";
+ else
+ s = "authority";
+
+ log_formerr(fctx, "Name %s (%s) in %s section"
+ " not subdomain of"
+ " known-to-be zone %s --"
+ " invalid response",
+ nbuf, tbuf, s, dbuf);
+ } else
+ log_formerr(fctx, "invalid response");
return (DNS_R_FORMERR);
}
}

- Havard