Edit: I've simplified target goal as suggested by Andrew B.

The goal is basically setting an authoritative name server to only give real answer on recursive requests, which means breaking the iterative procedure of dns resolving. Makes no sense for any real use but what I try here is for research purposes, specifically on identifying misbehaving open resolvers.

What I want is answering with no data to non-recursive dns requests even if we know otherwise (e.g. if we are the authoritative nameserver for the requested domain). i.e.:

Case 1: REQUEST(RD=0) -> RESPONSE(rcode=NOERROR, All sections Empty, RA=1) 
Case 2: REQUEST(RD=1) -> RESPONSE(Real Answer, RA=1) 

My available resources are one Authoritative name server for specific domain and one dns resolver on separate machines. The behavior should be similar for any sub-domain of my controlled domain.

My current setup:

  • Machine-1 (M1 in short): BIND authoritative name server registered for research.lab.mydomain.com
  • Machine-2 (M2 in short): BIND resolver (open)

Both allow recursive calls (for research purposes). Currently, 'A' queries for research.lab.mydomain.com sub-domains go to M1's nameserver and return NXDOMAIN results (there are no sub domains registered). M2 is currently not in use.

What I thought should be done

Make all queries of research.lab.mydomain.com subdomains go to the resolver instead of the name server. The resolver in turns queries the nameserver if recursion desired is set or return cached answers with no error otherwise. All queries from the outside world should go through the resolver.

What I tried

I though about changing M1 to be the resolver and M2 to be the nameserver, so research.lab.mydomain.com would still be registered to M1's address. So I moved the zone configuration from M1 to M2 and also set forwarding from M1 to M2 in named.conf.options.

named.conf.local in M1 is now empty and in M2 is now:

zone "research.lab.mydomain.com" {
        type master;
        file "/var/lib/bind/research.lab.mydomain.com.hosts";

The content of /var/lib/bind/research.lab.mydomain.com.hosts is a modified version of the one that was in M1 (substituted m1 with m2):

$ttl 38400
research.lab.mydomain.com.  IN  SOA m2.lab.mydomain.com. roee88.gmail.com. (
            38400 )
research.lab.mydomain.com.  IN  NS  m2.lab.sit.cased.de.
research.lab.mydomain.com.  IN  NS  ns1.research.lab.mydomain.com.
ns1.research.lab.mydomain.com.  IN  A   {IP ADDRESS OF M2}

Unfortunately that didn't work. queries received on m2 resulted in SERVFAIL responses.

  • Do the delegatory NS (and glue A/AAAA) records match this? dig +trace +add research.lab.example.com NS may be helpful for confirming this. I don't, however, understand why you would want to delegate something to a resolver, that's generally a really bad thing to do. As you indicate in the question the resolver will only do its thing when the RD bit is set, meaning that in this scenario it will not be looking up the requested things, and there is no guarantee that they will already be in the cache. Oct 12 '14 at 9:35
  • Additionally the AA flag would never be set, which could also pose a problem. Oct 12 '14 at 10:39
  • 1
    Could you edit your presentation to focus on what you are trying to accomplish by having this configuration? I want to make sure that we don't have an X-Y problem going on here. If you add a paragraph to the beginning explaining your goal, it will make it easier for us to identify if there is a better way of accomplishing it. (i.e. whether RPZ is a better tool for the job)
    – Andrew B
    Oct 12 '14 at 18:50
  • @AndrewB I've added a simplified goal at the top of the question. Could you please take a look and see if there is an easier way to achieve this than what I described originally? I will update the title of the question accordingly if so. Thanks!
    – roee88
    Nov 8 '14 at 16:04
  • 1
    @roee88 I think a crucial thing that is still missing is what you are actually trying to achieve (as opposed to your idea of how it can be achieved). What you are describing as your goal sounds broken, which I think is why both I and Andrew B are asking about why you want to do this. Nov 8 '14 at 18:52

Have you tried telling M1 that M2 is responsible for the subdomain by ip address rather than name, eg with

zone "research.lab.mydomain.com." {
        type forward;
        forward first;
        forwarders {
                a.b.c.d ;
        } ;
} ;

in M1's named.conf, where a.b.c.d is the IP address of M2?

  • Thanks, I'll try. I'm now trying to configure M2 as name server but keep getting SERVFAIL (testing with "dig @{ip_of_m2} 1.research.lab.mydomain.com"). Is there anything wrong with the zone file I posted earlier? Any other files needed to be modified/added for making it work as a name server?
    – roee88
    Oct 12 '14 at 9:37
  • 1
    The zonefile looks fine, but it doesn't define the host 1.research.lab.mydomain.com, so that lookup would be expected to fail. You will need to get M2 setup correctly to serve the zone research.lab.mydomain.com before the forwarding I describe above will work.
    – MadHatter
    Oct 12 '14 at 9:54

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.