2

So I have managed to setup my DNS resolving server. I can share details of doing the same here (just in case if someone is curious to know). I have used Fedora, however, it is pretty much the same in every distribution if you are going to use bind, nonetheless.

My question is with regard to the named.conf file which we edit in our resolving server (basically to make it accept connections for resolution).

An excerpt from my named.conf file is this:

acl goodclients {
                localnets;
                55.55.55.55;
};
options {
        listen-on port 53 { 127.0.0.1; goodclients; };
        listen-on-v6 port 53 { ::1; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        allow-query     { localhost; goodclients; };
        allow-query-cache       { localhost; goodclients; };
.....
.....
.....
};

55.55.55.55 is my client's public IP.

In my client, I have edited the resolv.conf file to include server's IP address as a resolver (one and only resolving server).

UDP traffic is accepted on port 53 on my resolver.

I have used bind and everything is happening between 2 instances of Amazon EC2 (both are Fedora instances).

I want to ask why is it a necessity to include "localnets" in the ACL configuration part of named.conf in the resolver and why it is not working just by adding the public IP of my client in my resolver's named.conf?

What I have seen is they both complement each other; either if missing, will stop the client from resolving any address.

A workaround can be just to include "any; " in the options part of named.conf file in place of "goodclients; " to avoid the ACL configuration, however, I am not willing to allow this resolver to be used by anyone but my chosen client.

P.S. :: I can include more details about how Amazon EC2 works in terms of deploying instances or anything else, if needed.

  • 1
    I believe the reason could be that since both of them are a part of some local network, localnets is needed and once we use localnets to access, we then further need the public IP of the client, to return the resolving request back properly because, the client instance (of EC2) might not be contacting the resolving instance (of EC2) as an IP and rather some relative name with respect to their local network setup. I am saying this because I have analyzed UDP packets using tcpdump in my client instance and they don't seem to communicate, even outside the network, using their IP addresses. – Avineshwar Mar 21 '16 at 4:39
  • It has been several years since I had to deal with ACLs. At the time, the machine needed access to itself at least, hence the localnets, localhost references. It could be a simple routing issue for localnets. Of course you can drop the ACLs and just use the firewall, however, ACLs are a good thing to have to CYA. It sounds like you are on track to answering your own question. – closetnoc Mar 21 '16 at 4:52
1

Adding localnets to the acl authorises any connection on the local network which is in the same local subnet as the DNS server. What this means is that not only will your client's IP of 55.55.55.55 be allowed but if we assume a local netblock of 192.168.1.1-255 then any machine with the IP of 192.168.1.* will be allowed to work with the DNS server.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.