0

I have cPanel & WHM v130.0.14 STANDARD running in an EC2 instance. Trying to setup a reverse proxy with Apache2 by setting a CNAME some.example.com (not the real one) to forward the request to api.demo.com — the catch is that I need to use some.example.com for input and output; that is, I need to be able to use some.example.com for receiving the request on my local server (input) and for sending it out, in order to fetch the right data on api.demo.com (output) — the reason for this is that on api.demo.com's end there's also a reverse proxy setup, but that's besides the point.

For this to work I would need to either set a static IP for some.example.com into /etc/hosts or, what I'm actually trying to achieve, set a CNAME in named (PDNS handled) to make some.example.com translate to whatever address api.demo.com resolves to.

Tried numerous solutions between setting a local zone for demo.com or creating forwarders, but I can't get anything to work; that is, it just resolves to the default record's address published by Cloudflare. As far as I've seen this should work, so for now I just reverted to the simple CNAME approach:

  • /etc/resolv.conf
nameserver 127.0.0.1
nameserver 1.1.1.1
nameserver 8.8.8.8
  • /etc/named.conf
view "internal" {
    match-clients        { localnets; };
    match-destinations    { localnets; };
    recursion yes;

    zone "." IN {
        type hint;
        file "/var/named/named.ca";
    };

zone "192-168-0-10.cprapid.com" {
        type master;
        file "/var/named/192-168-0-10.cprapid.com.db";
};


zone "example.com" {
        type master;
        file "/var/named/example.com.db";
};


};

view    "external" {
    recursion no;

    zone "." IN {
        type hint;
        file "/var/named/named.ca";
    };

zone "192-168-0-10.cprapid.com" {
        type master;
        file "/var/named/192-168-0-10.cprapid.com.db";
};


zone "example.com" {
        type master;
        file "/var/named/example.com.db";
  • /var/named/example.com.db
; cPanel first:124.0.21 (update_time):1760587729 Cpanel::ZoneFile::VERSION:1.3 hostname:192-168-0-10.cprapid.com latest:130.0.14
; Zone file for example.com
$TTL 14400
example.com.     86400   IN      SOA     ns1.192-168-0-10.cprapid.com. root.192-168-0-10.cprapid.com. 2025101605 3600 1800 1209600 86400





example.com.     86400   IN      NS      ns1.192-168-0-10.cprapid.com.
example.com.     86400   IN      NS      ns2.192-168-0-10.cprapid.com.
ns1     14400   IN      A       192.168.0.254
ns2     14400   IN      A       192.168.0.254

example.com.     14400   IN      A       192.168.0.10
some    14400   IN      CNAME   api.demo.com.

Am I missing something?

(reposting from ServerFault)

Improve this question
6
  • Web servers and services are often bound to the name more tightly than to the IP address. In such a situation you cannot passively point a different name at a service (e.g. your API endpoint) and expect it to work. You will need to use an active proxy such as one implemented using either Apache or Nginx Commented Oct 16 at 14:34
  • @ChrisDavies I'm guessing you are saying that because of "... that on api.demo.com's end there's also a reverse proxy setup...", but what I meant by it is at api.demo.com's side this reverse proxy is pointing to a specific DocumentRoot inside the server (within a VirtualHost block) — both some.example.com and api.demo.com serve HTTP requests using Apache 2.4 Commented Oct 16 at 14:47
  • Not really; it's a general comment about dealing with HTTP-based services Commented Oct 16 at 15:31
  • Have you queried the actual name servers for your some.example.com to see if they're serving the data? Have you incremented your SOA serial? This kind of thing is really difficult to diagnose with fake data Commented Oct 16 at 15:33
  • @ChrisDavies the name servers (ns1 and ns2 there at 192.168.0.254) do not have the demo.com zone configured, but when performing either a dig or a nslookup command I can see api.demo.com being resolved correctly, yes. Have the feeling that I'm probably overlooking something very simple here, already stuck for days on this and just can't figure out what is wrong — also I apologize about the mock data, but I'm not sure I can safely divulge these addresses publicly as it's not within my jurisdiction to decide Commented Oct 16 at 15:57

1 Answer 1

Reset to default
3

  • I suspect your BIND configuration is ineffective because your /etc/resolv.conf includes two other unrelated DNS servers (1.1.1.1 and 8.8.8.8).

    Do not rely on resolv.conf being used strictly top-down. If you have any "special" nameservers, then those nameservers should be the sole entry in resolv.conf, and should handle all requests – which BIND can do by default (it is a fully capable resolver, although you can tell it to use 1.1.1.1 as a forwarder if you wish).

  • A better way to achieve this with BIND would be a response policy zone (RPZ), which can contain arbitrary overrides for individual names without "overlapping" the entire example.com zone.

    1. Define a zone, named something like rpz.local or whatever.

    2. Within that zone, define your overrides:

      site.example.com CNAME api.demo.com.

      (This deliberately lacks a trailing . and expands to site.example.com.rpz.local. – data in the RPZ still has to follow the same rules of being within the zone. BIND understands how to look up its contents.)

    3. Enable it using:

      options {
    response-policy {
        zone "rpz.local";
    };
};

    This would be slightly easier using Unbound than BIND, as it would be just a two-line local-zone: and local-data: addition in unbound.conf.

Improve this answer
7
  • Thanks for the answer! Not sure why, but unfortunately I'm getting a syntax error while trying to apply the changes in named.conf, specifically at the zone "rpz.local"; line. I'd be willing to try the first method, but I'm not sure how to set that up — do not have much experience setting up nameservers for a host/network. I'll be looking into it, but if you could give me some kind of "quick and dirty" example I'd appreciate your help! Commented Oct 16 at 18:49
  • There's no "first method" here – the first point is a prerequisite for any method (whether BIND with a fake zone, or BIND with RPZ, or Unbound with local-data). The point is that if you're going to set up any kind of DNS server that returns fake data, then your OS needs to use that server exclusively, and not alongside "normal" servers. (That is, your custom nameserver cannot just "attract" queries to itself. If the OS decides to query 8.8.8.8, it'll just bypass the whole thing.) Commented Oct 16 at 19:02
  • Your internal view already has recursion yes, so your BIND is already prepared to handle all requests; there's no need to have 8.8.8.8 in resolv.conf anyway. Commented Oct 16 at 19:05
  • ok, so I finally made it work after another whole day of hitting my head against a brick wall! I managed to essentially implement your solution, yet in this case I ended up having to use PowerDNS Recursor in order to determine which authority (not sure about this concept) is supposed to answer for each zone. I'll be posting it in full pretty soon, thanks! Commented Oct 16 at 20:49
  • This is very strange. You shouldn't need an RPZ if the name server is authoritative for the domain, as shown in the question's example. Just fix up the domain itself. (Oh, and then have the client use the correct nameservers. Good call there.) Commented Oct 17 at 13:58

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.