1

I use bind9 server (A.A.A.A) as forwarder only: queries are forwarded to other DNS server (B.B.B.B). I manually ask B.B.B.B to resolve domain and got correct result:

$ dig a downloadcenter.intel.com @B.B.B.B
;; ANSWER SECTION:
downloadcenter.intel.com. 182   IN      CNAME   downloadcenter.intel.com.edgekey.net.
downloadcenter.intel.com.edgekey.net. 17879 IN CNAME e11.b.akamaiedge.net.
e11.b.akamaiedge.net.   19      IN      A       172.231.112.37

I expect that bind9 server A.A.A.A will do the same single query to server B.B.B.B and will return address 172.231.112.37. But in reality it does two queries: first it asks for A downloadcenter.intel.com, second it asks for A e11.b.akamaiedge.net. Is there any way to trust the first answer and do only one query to B.B.B.B?

I need this because I need to have the same resolved IP on both A.A.A.A and B.B.B.B. But if two queries are done, then sometimes servers may cache different IPs. This is very often with low TTL records, like this one.

I've digged documentation and most close section is about Content Filtering, but I can't find direct answer. I've also tried Unbound, but it has the same issue; here is a related part of source code.

Log of server B.B.B.B that explains the issue:

Mon Feb  1 06:56:34 2016 daemon.info dnsmasq[9664]: query[A] downloadcenter.intel.com from 192.168.0.175 ← first query
Mon Feb  1 06:56:34 2016 daemon.info dnsmasq[9664]: forwarded downloadcenter.intel.com to 8.8.8.8
Mon Feb  1 06:56:34 2016 daemon.info dnsmasq[9664]: reply downloadcenter.intel.com is <CNAME>
Mon Feb  1 06:56:34 2016 daemon.info dnsmasq[9664]: reply downloadcenter.intel.com.edgekey.net is <CNAME>
Mon Feb  1 06:56:34 2016 daemon.info dnsmasq[9664]: reply e11.b.akamaiedge.net is 172.231.112.37
Mon Feb  1 06:56:34 2016 daemon.info dnsmasq[9664]: query[A] e11.b.akamaiedge.net from 192.168.0.175 ← extra query
Mon Feb  1 06:56:34 2016 daemon.info dnsmasq[9664]: forwarded e11.b.akamaiedge.net to 8.8.8.8
Mon Feb  1 06:56:34 2016 daemon.info dnsmasq[9664]: reply e11.b.akamaiedge.net is 2.21.192.37

The other issue is that if client asks A.A.A.A to resolve downloadcenter.intel.com again, CNAME is not yet expired, but A is expired, so bind9 asks B.B.B.B only for A:

Mon Feb  1 07:08:02 2016 daemon.info dnsmasq[9664]: query[A] e11.b.akamaiedge.net from 192.168.0.175
Mon Feb  1 07:08:02 2016 daemon.info dnsmasq[9664]: forwarded e11.b.akamaiedge.net to 8.8.8.8
Mon Feb  1 07:08:02 2016 daemon.info dnsmasq[9664]: reply e11.b.akamaiedge.net is 23.53.35.18

I need a way to forward query exactly as it was asked. Bind9 is too intellectual here. Is there a way to disable bind9 cache?

This is required in my setup because I want server B.B.B.B to see the original client's request downloadcenter.intel.com every time.

Replace bind9 with something more dumb? dnsmasq is perfect answer, except that A.A.A.A is a Windows host, so alternatives are limited.

Config of Bind9 (A.A.A.A):

options {
    dnssec-validation no;
    auth-nxdomain no;    # conform to RFC1035
    listen-on-v6 { any; };
    forwarders {
        B.B.B.B;
    };
    forward only;
};

B.B.B.B server is a dnsmasq.

Vanav
  • 186
  • 4
  • As a side note, the actual problem you're trying to solve is somewhat puzzling. CDNs like Akamai serve information based on the source IP and/or route taken by the server performing the authoritative lookup. The server performing the authoritative lookup is *Server B*, not *Server A*, so the benefit if what you're trying to accomplish is suspect. If you're actually forwarding to *two* servers, each in a different geographic location, then *Server A* is going to bounce back and forth between answers from *B1* and *B2* and nothing can stop this. – Andrew B Feb 01 '16 at 06:49
  • Servers `A` and `B` are in same location. I can explain my setup more: when server `B` sees query `downloadcenter.intel.com`, it adds a special firewall rule for resulting IP. But if server `A` somehow got different IP, or server `B` will not see this request, then this firewall rule will not apply. So, I need that all client's requests for `downloadcenter.intel.com` will be visible by `B`. – Vanav Feb 01 '16 at 08:35
  • Sounds like you should be using a [proxy](http://serverfault.com/a/376796/152073) instead. Automating your firewall holes to facilitate outbound HTTP connections rarely works as well as one hopes. – Andrew B Feb 01 '16 at 13:21
  • I don't want a web proxy, because my current DNS+firewall setup works good and is transparent for clients. But I need to replace `bind9` with DNS proxy. Is there any DNS proxy that have conditional forwarding and run on Windows? – Vanav Feb 01 '16 at 18:16
  • The linked standards below explain why DNS doesn't work the way you expect it to. If you like what you have, you are going to need to start reading standards and make sure your software anticipates those behaviors. (it should conform to the expectations of DNS, not the other way around) – Andrew B Feb 01 '16 at 18:20

1 Answers1

1

Your starting assumption is incorrect:

I expect that server A.A.A.A will do the same single query to server B.B.B.B and will return address 172.231.112.37.

Let's break this down.

  • The client is asking for an record of type A named downloadcenter.intel.com..
  • There is no such A record.
  • The recursive server cannot lie and say that the A record value of that record is an IP address. It must instead report the alias that was encountered.

The rest is just recursion. In layman's terms, if a recursive server receives a recursive query (RD flag is set), it must assume that the client is completely stupid and that it will not be able to perform any recursive lookups of its own. There is no room for splitting the hair, because in most cases that's 100% accurate. This forces the recursive server to chase the aliases until arriving at a terminal answer, should one exist. The standard is explicit in this regard.

Community
  • 1
Andrew B
  • 32,588
  • 12
  • 93
  • 131