[Dnsmasq-discuss] Caching issue question

Simon Kelley simon at thekelleys.org.uk
Thu May 31 11:44:13 BST 2012


On 31/05/12 10:48, Nick wrote:
> Hi everybody,
> 
> I updated the powerdns server to version 3.0. The bug with the
> alternating A and AAAA queries to a CNAME which did not get cached seems
> to be solved now. Thanks you very much for the help with the bug.
> 
> Sadly, another issue appeared to me. We have the following 2 CNAMES in
> our DNS:
> 
> """
> sql-master.fd.corp (CNAME to 1-sql.poz.fd.corp)
> sql-master.poz.fd.corp (CNAME to 1-sql.poz.fd.corp)
> """
> 
> If I do alternating requests to those both addresses with dig, it seems
> the cache gets overwritten, because dnsmasq does a new query every time
> I execute the dig (in an alternating way). I do normal A queries:
> 
> """
> root at server:~ # dig sql-master.poz.fd.corp
> 
> ; <<>> DiG 9.7.0-P1 <<>> sql-master.poz.fd.corp
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46380
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;sql-master.poz.fd.corp.                IN      A
> 
> ;; ANSWER SECTION:
> sql-master.poz.fd.corp. 60      IN      CNAME   1-sql.poz.fd.corp.
> 1-sql.poz.fd.corp.      60      IN      A       10.193.7.130
> 
> ;; Query time: 1 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Thu May 31 12:39:39 2012
> ;; MSG SIZE  rcvd: 76
> 
> root at server:~ # dig sql-master.fd.corp
> 
> ; <<>> DiG 9.7.0-P1 <<>> sql-master.fd.corp
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51308
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;sql-master.fd.corp.            IN      A
> 
> ;; ANSWER SECTION:
> sql-master.fd.corp.     60      IN      CNAME   1-sql.poz.fd.corp.
> 1-sql.poz.fd.corp.      60      IN      A       10.193.7.130
> 
> ;; Query time: 1 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Thu May 31 12:39:41 2012
> ;; MSG SIZE  rcvd: 76
> 
> root at server:~ # dig sql-master.poz.fd.corp
> 
> ; <<>> DiG 9.7.0-P1 <<>> sql-master.poz.fd.corp
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64093
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;sql-master.poz.fd.corp.                IN      A
> 
> ;; ANSWER SECTION:
> sql-master.poz.fd.corp. 60      IN      CNAME   1-sql.poz.fd.corp.
> 1-sql.poz.fd.corp.      60      IN      A       10.193.7.130
> 
> ;; Query time: 1 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Thu May 31 12:39:43 2012
> ;; MSG SIZE  rcvd: 76
> 
> root at server:~ # dig sql-master.fd.corp
> 
> ; <<>> DiG 9.7.0-P1 <<>> sql-master.fd.corp
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36772
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;sql-master.fd.corp.            IN      A
> 
> ;; ANSWER SECTION:
> sql-master.fd.corp.     60      IN      CNAME   1-sql.poz.fd.corp.
> 1-sql.poz.fd.corp.      60      IN      A       10.193.7.130
> 
> ;; Query time: 1 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Thu May 31 12:39:44 2012
> ;; MSG SIZE  rcvd: 76
> """
> 
> You can see that the TTL stays (60 seconds) and so dnsmasq does a new
> query for every request. The issue does not appear if I do several dig
> queries in a row to the same address. Could somebody please explain that
> to me? Because now there are 2 different hostnames which I query with dig.
> 
> I use version 2.59-4 of dnsmasq (the package from ubuntu 12.04 rebuild
> for ubuntu 10.04).
> 

This is a dnsmasq quirk. (It's not really a bug, because the correct
answers are returned: caching is an optimisation.)

When inserting a record into the cache, existing entries are first
removed. For a CNAME, this includes that names that the CNAMES "point
to" This invalidates other CNAMES in the cache that "point" to the same
A record (or AAAA record).

I don't think there's any reason why this has to work this way, it's
just a situation that wasn't considered when the code was written. I'll
look at optimising it.

Cheers,

Simon.





More information about the Dnsmasq-discuss mailing list