[dns-operations] Cache-altering queries (was: Re: Spoofing DNS with fragments)

[Florian Weimer]

* Mukund Sivaraman:

> I am asking because this author is known to us from a previous paper
> making claims that could not be reproduced. In the recent years, a paper
> was forwarded to us (at my previous employer) that claimed of various
> CNAME chain and additional section based poisoning and claimed that a
> variety of DNS implementations were found vulnerable including BIND. We
> could not test other implementations, but we did check the author's
> claims and didn't find BIND vulnerable to any of the recipes provided in
> the paper.
>
> http://www.cs.colostate.edu/~cs557/papers/KSW17.pdf

I've been working on replicating part of the findings independently.

There's now a set of magic test names of the form

  target$SUFFIX.caq.enyo.de

You can randomize $SUFFIX to force cache misses in your cache.  For
these names, the server answers with an IP address of 192.0.2.1 when
queried with IN/A, but will respond with a CNAME record to
www.example.com for IN/CNAME and IN/TYPE1000.

So you can do this:

$ dig target.caq.enyo.de

; <<>> DiG 9.10.3-P4-Debian <<>> target.caq.enyo.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18379
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1200
;; QUESTION SECTION:
;target.caq.enyo.de.		IN	A

;; ANSWER SECTION:
target.caq.enyo.de.	60	IN	A	192.0.2.1

;; Query time: 118 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Oct 08 19:19:21 CEST 2018
;; MSG SIZE  rcvd: 63

$ dig target.caq.enyo.de TYPE1000

; <<>> DiG 9.10.3-P4-Debian <<>> target.caq.enyo.de TYPE1000
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12277
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1200
;; QUESTION SECTION:
;target.caq.enyo.de.		IN	TYPE1000

;; ANSWER SECTION:
target.caq.enyo.de.	59	IN	CNAME	www.example.com.

;; AUTHORITY SECTION:
example.com.		3600	IN	SOA	sns.dns.icann.org. noc.dns.icann.org. 2018100701 7200 3600 1209600 3600

;; Query time: 1677 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Oct 08 19:19:34 CEST 2018
;; MSG SIZE  rcvd: 133

$ dig target.caq.enyo.de

; <<>> DiG 9.10.3-P4-Debian <<>> target.caq.enyo.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28293
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1200
;; QUESTION SECTION:
;target.caq.enyo.de.		IN	A

;; ANSWER SECTION:
target.caq.enyo.de.	38	IN	A	192.0.2.1

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Oct 08 19:19:43 CEST 2018
;; MSG SIZE  rcvd: 63


In this particular case, the CNAME record from
target.caq.enyo.de/IN/TYPE1000 did not immediately replace the address
cached for target.caq.enyo.de/IN/A, but it will win eventually, of
course, especially if the CNAME TTL is large enough.

Some implementations know that if a CNAME exists at a name, there
cannot be any other RRsets, and expire all conflicting information.
Others do not.

One caveat: It can be somewhat difficult to determine the precise
server behavior if the server has a small packet cache which is used
to answer queries which exactly match something that was answered
recently.  In this case, a simple test as the one above will show that
the server does not evict on new CNAME records, but it may actually so
for the actual RRset cache.  The packet cache merely hides this
behavior, especially for idle servers.  This is why I have a hard time
verifying whether current BIND 9 evicts on CNAME or not.

The server for caq.enyo.de is obviously not a real name server (it
doesn't even implement TCP yet), but I think the above test is still
useful, which is why I posted this.

> (No CVEs or any bugfixes were released for any of the several claims in
> the paper, because we couldn't reproduce any of them.)

In general, I wouldn't consider those issues bugs or even
vulnerabilities.  There are just an oddity in the cache
implementation.  I think it is just too hard to close all these
vectors to claim that doing so would be a form of hardening against
cache poisoning.