Join Log in
Score:0
Joppe avatar Server

BIND9 local reverse lookup with public IPs - is the setup broken or is the setup faulty?

mw flag
Joppe

We are having a prelaunch-site to test DNS (and other services) before going hot. I've never involved public IPs here previously and it may not work as I've intended. We have a /29-net from our ISP that are public IPs. 121.24.124.144/29. To test our DNS for different "view"s we have set up the LAN side of a router to emulate this net; with the router as the GW to our ISP. Apart from not being able to actually connect from the outside (which of course could be done through port forwarding) this is not the intention here.)

Topology:

Network topology

The router that is connected to our ISP is dhcp-connected with NAT to our network. LAN IP set as 121.24.124.145/29 (This is our own IP-net so it is not meant to be connected to from outside at this point) It should (and it does) work as prisoner in the local area world. For the time being.

The router (shelby) where our DNS is connected has WAN IP as 121.24.124.146 and LAN 192.168.13.1. DNS-server (emma) at 192.168.13.2.

> dig -x 121.24.124.146 @192.168.13.2

results in:

;; ANSWER SECTION:
146.124.24.121.in-addr.arpa. 86400 IN   PTR static-121-24-124-146.cust.com.

;; AUTHORITY SECTION:
124.24.121.in-addr.arpa. 77013  IN  NS  o.dns.cust.com.
124.24.121.in-addr.arpa. 77013  IN  NS  f.dns.cust.com.

;; ADDITIONAL SECTION:
f.dns.cust.com.          76895  IN  A   19.71.22.3
o.dns.cust.com.          77013  IN  A   19.71.18.5

(Which is the current owner (the ISP) of the IP-address at this time)

where I assumed our dns would reply with

;; ANSWER SECTION:
146.124.24.121.in-addr.arpa. 86400 IN   PTR fw-shelby.energia.com.

Any other local host works as intended when making a reverse lookup, with correct IP/FQDN. Forwarding address works fine.

> dig fw-shelby.energia.com
;; ANSWER SECTION:
fw-shelby.energia.com.  10800   IN  CNAME   shelby.energia.com.
shelby.energia.com.     10800   IN  A       121.24.124.146

;; AUTHORITY SECTION:
energia.com.            10800   IN  NS      emma.energia.com.

;; ADDITIONAL SECTION:
emma.energia.com.       10800   IN  A       192.168.13.1

Some questions arises from this result.

  1. Is BIND aware of Public IPs compared to internal (192.168. etc) ? [such that a reverslookup will result in an external lookup instead of our local fqdn]
  2. Our reverse file is configured from the fact that the network is /29 meaning it starts at .144 which suggests that the reverse lookup file also starts at 144.124.24.121.in-addr.arpa. I can't find any information nor examples of small networks and reverse-lookup files starting anywhere but at 0....in-addr.arpa. Is this a limitation, an unusual solution or a fault doing like this?
  3. If this is not broken nor correct - how would this be setup to work then?

Files affected:

/etc/bind/zonefiles/public/named.reverse.zone.conf
zone "144.124.24.121.in-addr.arpa"
{
    type master;
    file "/etc/bind/zonefiles/public/reverse-144.124.24.121.zone";
    allow-update { none; };
};

; /etc/bind/zonefiles/public/reverse-144.124.24.121.zone
; 121.24.124.144 (-121.24.124.151)

$ORIGIN 144.124.24.121.in-addr.arpa.
$TTL        345600
@           IN      SOA     emma.energia.com. root.emma.energia.com. (
                                    2022101102      ;Serial
                                    86400           ;Refresh 24 hours
                                    7200            ;Retry 2 hours
                                    2592000         ;Expire 30 days
                                    345600 )        ;Minimum 4 days
            IN      NS      emma.energia.com.

145         IN      PTR     gw-isp.energia.com.
146         IN      PTR     shelby.energia.com.
147         IN      PTR     shelley.energia.com.
148         IN      PTR     mailis.energia.com.
149         IN      PTR     ava.energia.com.
150         IN      PTR     www.energia.com.

I checked setting zone to $ORIGIN 124.24.121.in-addr.arpa. Just to rule out that reverse zone may not be allowed so "small". But no, No difference.

As for a reference:

; Bind reverse hosts
$ORIGIN 13.168.192.in-addr.arpa.
$TTL            345600
@               IN      SOA     emma.energia.com. root.emma.energia.com. (
                                    1998030900      ;Serial
                                    86400           ;Refresh 24 hours
                                    7200            ;Retry 2 hours
                                    2592000         ;Expire 30 days
                                    345600 )        ;Minimum 4 days
                IN      NS      emma.energia.com.

1               IN      PTR     gw-shelby.energia.com.
2               IN      PTR     emma.energia.com.
3               IN      PTR     gw-rivendale-link-br.energia.com.
4               IN      PTR     unused-ip-rd4.energia.com.

Works fine both forward and reverse. I havn't submitted any other named config files as the rest works and the logs confirms the zones has loaded. But if needed please ask!

It would be less frustrating getting our own reverse names coming up. The ISPs reverse names are only confusing.

553
1 + 0
Score:0
diya avatar Server
la flag
diya

What you do internally with the reverse DNS records for the public IP-addresses assigned to by your provider is up to you, but the rest of the internet will only see whatever your ISP offers/supports/sets up for you.

Personally I would align with them rather than locally override whatever their reverse DNS records for 121.24.124.144/29 are or aren't set to.

Usually ISP's either:

  • do not offer any support for setting custom PTR records
  • offer a control panel to adjust the PTR records for the few IP-addresses assigned to you, which are then entered in their DNS , between the other PTR records for IP's from the 121.24.124.0/24 range.
  • they follow RFC 2317 and set up CNAME records in their DNS to delegate the PTR records to a zone managed by you.

The problem in your current configuration:

/etc/bind/zonefiles/public/named.reverse.zone.conf
zone "144.124.24.121.in-addr.arpa"
  {
    type master;
    file "/etc/bind/zonefiles/public/reverse-144.124.24.121.zone";
    allow-update { none; };
  };

This sets up a reverse DNS zone for only 1 IP-address, for 121.24.124.144 and not for a subnet.
dig -x 121.24.124.14 6 fails because it isn't 121.24.124.14 4 .

There isn't really a nice solution:

  • Use zone "124.24.121.in-addr.arpa" in your named.conf and you locally override the PTR records for all IP's from the whole 121.24.124.0/24 range.
    You could (regularly/once-off) populate the zone file with the current values of the PTR records (of all the IP's not assigned to you) to mitigate.

  • You set a stanza for each separate IP-address that is assigned to you:

      zone "144.124.24.121.in-addr.arpa"
    {
      type master;
      file "/etc/bind/zonefiles/public/reverse-124.24.121.zone";
      allow-update { none; };
    };
  zone "145.124.24.121.in-addr.arpa"
    {
      type master;
      file "/etc/bind/zonefiles/public/reverse-124.24.121.zone";
      allow-update { none; };
    };

    ...

  zone "150.124.24.121.in-addr.arpa"
    {
      type master;
      file "/etc/bind/zonefiles/public/reverse-124.24.121.zone";
      allow-update { none; };
    };

And then set up a (single) zone file (that uses a bit of $ORIGIN trickery to allow you to use shorthand and a single zone file rather than creating a unique zone file one for each IP) :

; /etc/bind/zonefiles/public/reverse-124.24.121.zone
; used for the 121.24.124.144-121.24.124.151 range

$TTL        345600
@           IN      SOA     emma.energia.com. root.emma.energia.com. (
                                    2022101102      ;Serial
                                    86400           ;Refresh 24 hours
                                    7200            ;Retry 2 hours
                                    2592000         ;Expire 30 days
                                    345600 )        ;Minimum 4 days
            IN      NS      emma.energia.com.

$ORIGIN 124.24.121.in-addr.arpa.   
145         IN      PTR     gw-isp.energia.com.
146         IN      PTR     shelby.energia.com.
147         IN      PTR     shelley.energia.com.
148         IN      PTR     mailis.energia.com.
149         IN      PTR     ava.energia.com.
150         IN      PTR     www.energia.com.
+ 3
Joppe avatar
mw flag
Joppe
Just to be clear. The network given is a "/29" network starting at .144 (121.24.124.144/29 (-121.24.124.151)). As with network I thought it would be possible to use the same thinking here, but that seems not be the case.Are
0
Reply
Joppe avatar
mw flag
Joppe
What you wrote was clear and well formulated. I don't know how I've read the RFC previously, but I got it. I've tried setting the whole range (as you pointed out above) with no effect to the replies from local dig. It still takes the outside public reverse zone entries. I will try this new approach. Your answer makes all sense in every way. Thank you!
0
Reply
Joppe avatar
mw flag
Joppe
As always with small faults, easy to make, hard to spot. You even wrote explicitly my mistake: zone "144.124.24.121.in-addr.arpa" (from zone.conf-file) I only deleted "144." from the zonefile itself, not the conf file... Now works. And your suggestion as well. Both works!
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.