DNS domain Pointing to a DSL U/verse host

[m3047]

I've read through this a couple of times. Seems like you've got Apache 
running on 162.201.66.177 (and presumably you know that it is in fact 
visible to the world). The provider's reverse record points to 
162-201-66-177.lightspeed.sntcca.sbcglobal.net. You run the DNS for the 
zone, and you've got the address in question in there as www. You've also
usurped the zone 66.201.162.in-addr.arpa and configured it on that server.

The problem statement seems to be some variation of "when I do a reverse 
lookup on 162.201.66.177 I get 
162-201-66-177.lightspeed.sntcca.sbcglobal.net instead of www.bonsi.org".

The problem statement has the following variations:

1) Doing a DNS lookup with a DNS tool, e.g. dig.
2) Apache
2a) Doing name lookups during/access control.
2b) Where it's doing them.

I very assiduously stated "usurped" above. For starters, out of the /24 
you only defined the record you're interested in. If you were 
authoritative, you'd better expect complaints. ;-)

NOTE: This is a perfect use case for off-label use of RPZ, you could 
define your PTR record in an RPZ and you wouldn't need to take over the 
whole zone.

Fundamentally, you're not authoritative for the zone:

# dig 66.201.162.in-addr.arpa ns +short
ns10b.attdns.net.
ns10a.attdns.net.

You're not authoritative for bonsi.org either:

# dig bonsi.org soa +short
ns-cloud-b1.googledomains.com. cloud-dns-hostmaster.google.com. 55 21600 
3600 259200 300
# dig bonsi.org soa ns +short
;; Warning, extra type option
ns-cloud-b3.googledomains.com.
ns-cloud-b4.googledomains.com.
ns-cloud-b1.googledomains.com.
ns-cloud-b2.googledomains.com.

If you want to get your definition, you need to refer to your server:

# dig @216.239.32.107 www.bonsi.org +short
162.201.66.177

And...

dig @216.239.32.107 -x 162.201.66.177

; <<>> DiG 9.8.3-P1 <<>> @216.239.32.107 -x 162.201.66.177
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 59075
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;177.66.201.162.in-addr.arpa.	IN	PTR

;; Query time: 21 msec
;; SERVER: 216.239.32.107#53(216.239.32.107)
;; WHEN: Thu Aug 15 09:06:24 2019
;; MSG SIZE  rcvd: 45

Oh drat that didn't work! What's the ground truth here? The ground truth 
is that this isn't truly your server, it's Google's:

# dig -x 216.239.32.107 +short
ns-cloud-b1.googledomains.com.

Google isn't going to let you do that. For one thing, Google probably 
knows they're not authoritative for the reverse zone (previously shown).

Now we're going to talk about running your own nameserver (like BIND) 
because it's useful. I'm going to ignore the forward DNS for bonsi.org, 
which is working. FTR, if you were running your own server (and committed 
to managing it for use as an auth) you could request that the zone be 
delegated there from .org.

The use cases we're concerned with here are having a local vanity zone, 
and the unquestioned virtues of a local caching resolver. We are going to 
assume that the caching resolver is not open to the world. You could even 
run your bonsi.org authoritatively on the caching resolver but not 
delegated, if you wanted to have stuff which resolved locally but wasn't 
in the zone for world + dog (see previous note regarding RPZ).

I'm going to assume that your configuration for the reverse zone will 
work, subject to the previous caveats regarding multiple PTR records, 
ignoring completeness (see previous note regarding RPZ).

Assuming that you've got the reverse zone defined (in a DNS server which 
will serve it) you can query it with "dig @<nameserver-address> ..." 
(which we tried above and got REFUSED).

That's not particularly convenient. What you'd do is set this resolver as 
the DNS for your subnet (either manually or via DHCP). Having done so, 
zones which are authoritatively (or via RPZ) served from the caching 
resolver will mask the properly delegated configuration.

If you configure your local caching resolver for the server running 
Apache, then Apache will use it when resolving addresses to names, as it 
is wont to do for access control and logging. This is also likely to be 
faster than reaching out over the internet; it will also continue to work 
if Google's DNS goes down for some reason.

Looks like you've got IPv6 too, we'll leave that for aother day.

We'll leave search lists and information leakage for another day.

On Wed, 14 Aug 2019, Eduardo Bonsi wrote:

> [...]
> bonsi.org hosted by Google Domain (In view external) zone;

> [...]
> ;
> 177                                        IN      PTR  ns1.bonsi.org.
> 177                                        IN      PTR  ns2.bonsi.org.
> 177                                        IN      PTR  ns3.bonsi.org.
> ;
> 177	                                       IN      PTR  bonsi.org.
> 177	                                       IN      PTR  www.bonsi.org.
>
NOTE: Multiple PTR records is allowed, but funny things will happen to 
services restricted by FQDN when you do so. DAMHIK!

--

Fred Morris
m3047 at m3047.net