I found a strange behavior with unbound 1.6.0 as resolver. When I send a
request for a "TXT" record unbound first asks for a "A" record.
Normally this is not a problem, but we now have a problem with a DNS server
which only answers to "TXT" records. When you ask for a "A" record you
get no response and you have to wait for the timeout.
Here is an example:
DNS-Name: urvfr.qr.m.05.s.sophosxl.net
authoritative name server for m.05.s.sophosxl.net: ns.sxl31.sophosxl.net.
DNS-IP1: 34.252.84.252
DNS-IP2: 52.19.19.59
Unbound tries to fetch the "A" records from both nameserver and runs into
a timeout and after the timeout there is the "TXT" record request.
12:01:31.279241 34.252.84.252.53: 19073% [1au] A? urvfr.qr.m.05.s.sophosxl.net. (57)
12:01:31.329441 34.252.84.252.53: 49899% [1au] A? urvfr.qr.m.05.s.sophosxl.net. (57)
12:01:31.430434 52.19.19.59.53: 55169% [1au] A? urvfr.qr.m.05.s.sophosxl.net. (57)
12:01:31.530833 52.19.19.59.53: 20653% [1au] A? urvfr.qr.m.05.s.sophosxl.net. (57)
12:01:31.731961 34.252.84.252.53: 18091% [1au] A? urvfr.qr.m.05.s.sophosxl.net. (57)
12:01:32.132984 34.252.84.252.53: 54968% [1au] A? urvfr.qr.m.05.s.sophosxl.net. (57)
12:01:32.933638 52.19.19.59.53: 1330% [1au] TXT? urvfr.qr.m.05.s.sophosxl.net. (57)
12:01:32.963046 52.19.19.59.53: 47544% [1au] TXT? urvfr.qr.m.05.s.sophosxl.net. (57)
12:01:32.994500 52.19.19.59.53: 9287% [1au] TXT? urvfr.qr.m.05.s.sophosxl.net. (57)
12:01:33.026025 52.19.19.59.53: 28622% [1au] TXT? urvfr.qr.m.05.s.sophosxl.net. (57)
12:01:33.057624 34.252.84.252.53: 8529% [1au] TXT? urvfr.qr.m.05.s.sophosxl.net. (57)
12:01:33.088539 34.252.84.252.53: 30851% [1au] TXT? urvfr.qr.m.05.s.sophosxl.net. (57)
Because the TTL for the entry is only 10 seconds this problems happens very
often. Also the part before m.05.s.sophosxl.net is dynamic.
This is used by some kind of sophos endpoint protection. The client sends
several request for each website he tries to reach. So this endsup in a total
wait time of 60 seconds for every website the client tries to reach.
I found a strange behavior with unbound 1.6.0 as resolver. When
I send a request for a "TXT" record unbound first asks for a
"A" record.
That is indeed a little strange.
Normally this is not a problem, but we now have a problem with
a DNS server which only answers to "TXT" records. When you ask
for a "A" record you get no response and you have to wait for
the timeout.
I hope there is no disagreement that this is Utterly Broken
Behaviour. The correct thing to do would be to send a NODATA
response if there is a TXT record or other record types attached
to the queried-for name.
“qname-minimisation: no” will improve query time. qname-minimisation generates lot of queries not identical to original query.
I believe that there is no standard (all DNS responders must be compliant to it) saying that authoritative servers must respond to all well-formed queries, so I don’t blame Sophos’ servers.
FWIW, this behavior is essentially against the “expected behavior”
described in RFC4074, too. One can still say that it’s just an
informational RFC without an RFC2119 keyword. But in that sense “we
can’t expect that all implementers strictly follow XXX”, whether XXX
is an individual draft, a non-standards-track RFC, a standards-track
RFC without RFC2119 keywords, or a standards-track RFC with a bunch of
RFC2119 keywords. After all, there’s no protocol police, and there’s
always a broken implementation whatever the standard says.
It’s still nice to have something to show to protocol abusers. It
doesn’t always work, but often does.
This is misunderstanding! draft-ietf-dnsop-no-response-issue simply points out common non-compliance, it does not change the DNS protocol in any significant way.
Responding to well-formed queries is the very basic of DNS protocol - there is no such thing as "ignore query" in the very basic DNS resolution algorithm as standardized in RFC 1034: https://tools.ietf.org/html/rfc1034#section-4.3.2
Any implementation which is unable to respond to well-formed queries is just broken and there is no excuse for it.
in DNS RRL (www.redbarn.org/dns/ratelimits) a motive and a method is described whereby queries which appear to be uselessly duplicative are dropped without response. this is the main method of managed nonparticipation in DNS-amplified DDoS attacks.
perhaps this is exempted from your otherwise broad statement, since the implementation of DNS RRL does not render an implementation "unable" to respond to all well-formed queries, but rather, "unwilling" to do so.
