DNS domain Pointing to a DSL U/verse host

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

DNS domain Pointing to a DSL U/verse host

Eduardo Bonsi
Hi,

I have a DSL/Uverse connection behind a generic router that does not give me much option to configure but I got it working running DNS/Apache. As some of you know, AT&T does not reverse their Uverse connection to any domain. But since they provide a static IPv4 address, I thought, "what a hack, I will design a network to run a server from this static ip address."

The AT&T ip address is 162.201.66.177 that reverses to 162-201-66-177.lightspeed.sntcca.sbcglobal.net.

# dig -x 162.201.66.177

; <<>> DiG 9.10.6 <<>> -x 162.201.66.177
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16066
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;177.66.201.162.in-addr.arpa. IN PTR

;; ANSWER SECTION:
177.66.201.162.in-addr.arpa. 7200 IN PTR 162-201-66-177.lightspeed.sntcca.sbcglobal.net.

;; Query time: 43 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Wed Aug 14 14:07:59 PDT 2019
;; MSG SIZE  rcvd: 116

#####
; <<>> DiG 9.10.6 <<>> @2001:4860:4860::8888 162-201-66-177.lightspeed.sntcca.sbcglobal.net A +cd
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17986
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;162-201-66-177.lightspeed.sntcca.sbcglobal.net. IN A

;; ANSWER SECTION:
162-201-66-177.lightspeed.sntcca.sbcglobal.net. 7199 IN A 162.201.66.177

;; Query time: 120 msec
;; SERVER: 2001:4860:4860::8888#53(2001:4860:4860::8888)
;; WHEN: Wed Aug 14 20:28:00 PDT 2019
;; MSG SIZE  rcvd: 91

So, I have my domain (bonsi.org) pointing to this ip address through BIND. However, lately I observed that the connection host, "162-201-66-177.lightspeed.sntcca.sbcglobal.net.", without any DNS or Apache configuration from my part is resolving to a section of the server that I only reserve for the localhost, (I mean, is not that this host is connecting to the localhost but it is resolving in a part that Apache is reserved for the localhost). I would like to know if I can fix that by pointing this host to my domain.

For my WAN network I have;

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

$TTL 21600
$ORIGIN bonsi.org.
@ IN SOA ns1.bonsi.org. hostmaster.bonsi.org. (
                        2019032901
                        10800
                        3600
                        604800
                        21600 )
@                                          IN NS ns1.bonsi.org.
@                                          IN NS ns2.bonsi.org.
@                                          IN NS ns3.bonsi.org.
;
ns1                                        IN AAAA 2600:1700:b310:c2e0::21
ns2                                        IN AAAA 2600:1700:b310:c2e0::31
ns3                                        IN AAAA 2600:1700:b310:c2e0::41
;
ns1                                        IN A   216.239.32.107
ns2                                        IN A   216.239.34.107
ns3                                        IN A   216.239.36.107
;
ns1                                        IN AAAA 2001:4860:4802:32::6b
ns2                                        IN AAAA 2001:4860:4802:34::6b
ns3                                        IN AAAA 2001:4860:4802:36::6b
;
@                                          IN A 162.201.66.177
www                                      IN A 162.201.66.177
@                                          IN AAAA 2600:1700:b310:c2e0::2
www                                      IN AAAA 2600:1700:b310:c2e0::2
;
ftp                                         IN CNAME www

then, I have the 162.201.66 (In view external) Zone for the ip address.

$TTL    86400
$ORIGIN 66.201.162.in-addr.arpa.
@ IN SOA ns1.bonsi.org. hostmaster.bonsi.org. (
                        2018011600
                        10800
                        3600
                        604800
                        86400 )
@                                      IN      NS   ns1.bonsi.org.
@                                      IN      NS   ns2.bonsi.org.
@                                      IN      NS   ns3.bonsi.org.
;
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.

Now, not to extend this too much, here is my question;

- Do you think this is a DNS issue and if it is, what is the possibility to point the host "162-201-66-177.lightspeed.sntcca.sbcglobal.net." to my domain bonsi.org so the AT&T host won't resolve on the no man's land in the server?

Thanks for your help!


Eduardo Bonsi
[hidden email]



_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: DNS domain Pointing to a DSL U/verse host

Fred Morris
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
[hidden email]
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: DNS domain Pointing to a DSL U/verse host

Eduardo Bonsi
Dear Fred,

> First, thank you for taking the time to layout your views and suggestion!


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.

> Thank you for this suggestion! It would be great to have some examples, if is not to ask you too much already!

Fundamentally, you're not authoritative for the zone:

> I am totally aware about that! That would be more simple if I just go ahead and order some static ips from AT&T ...and that would cost me an arm and a leg and get done with it! Then, "probably" I would not > be here asking this question at all.

> However, I am trying to use what is available to me, (something but not too much! but with not intention to use unduly) and do the best I can with this something! Thanks for using the word "usurped" because > it did raise my awareness to fix something that I thought would just facilitate the resolution of the the domain. It was not my deliberate intention to "usurp" the 66.201.162.in-addr.arpa zone even thou
> your use of the word is totally correct for this case.

# 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.

> Yes, I am aware about that too! Even thou, I am not authoritative according to the BIND rules, I do have authoritative control of the zone bonsi.org at the registrar 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).

> The only one with authority to reverse that ip is AT&T and as I mention before, AT&T is not going to do that unless I pay them the extra, extra bucks for static IPs.

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.

> I am aware of that! I just could ask AT&T to reverse the domain. I am only running a catching namesever locally, (No recursion) and for that I am only authoritative for the internal zones. Here, I can do >that without having to request anybody ... :)

> [server:~] root# dig @127.0.0.1 -x 192.168.1.3

> ; <<>> DiG 9.10.6 <<>> @127.0.0.1 -x 192.168.1.3
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48149
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;3.1.168.192.in-addr.arpa. IN PTR
>
> ;; ANSWER SECTION:
> 3.1.168.192.in-addr.arpa. 3600 IN PTR bonsi.org.
>
> ;; AUTHORITY SECTION:
> 1.168.192.in-addr.arpa. 3600 IN NS ns1.bonsi.org.
> 1.168.192.in-addr.arpa. 3600 IN NS ns3.bonsi.org.
> 1.168.192.in-addr.arpa. 3600 IN NS ns2.bonsi.org.
>
> ;; ADDITIONAL SECTION:
> ns1.bonsi.org. 3600 IN A 192.168.1.21
> ns2.bonsi.org. 3600 IN A 192.168.1.31
> ns3.bonsi.org. 3600 IN A 192.168.1.41
>
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Thu Aug 15 14:27:33 PDT 2019
> ;; MSG SIZE  rcvd: 178
 

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!

> Thanks, I can definitely correct that!


> On Aug 15, 2019, at 9:36 AM, m3047 <[hidden email]> wrote:
>
> 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
> [hidden email]

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

MX, SPF and RPZ Re: DNS domain Pointing to a DSL U/verse host

Fred Morris
Hi Eduardo.

On Thu, 15 Aug 2019, Eduardo Bonsi wrote:
> First, thank you for taking the time to layout your views and suggestion!

;-)

>> 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.
>
> Thank you for this suggestion! It would be great to have some examples,
> if is not to ask you too much already!

Sure. 8-) Do you have waldo in your domain?

# dig waldo.bonsi.org

; <<>> DiG 9.8.3-P1 <<>> waldo.bonsi.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10359
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;waldo.bonsi.org. IN A

;; AUTHORITY SECTION:
bonsi.org. 300 IN SOA
ns-cloud-b1.googledomains.com. cloud-dns-hostmaster.google.com. 56 21600
3600 259200 300

;; Query time: 540 msec
;; SERVER: 10.0.0.220#53(10.0.0.220)
;; WHEN: Fri Aug 16 09:52:54 2019
;; MSG SIZE  rcvd: 129

Let's fix that:

# net-dns.pl add white waldo.bonsi.org A 10.9.8.7

(That's a script which dynamically updates the zone whitelist.m3047.net, a
local vanity domain.)

# dig waldo.bonsi.org.whitelist.m3047.net

; <<>> DiG 9.8.3-P1 <<>> waldo.bonsi.org.whitelist.m3047.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42402
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;waldo.bonsi.org.whitelist.m3047.net. IN A

;; ANSWER SECTION:
WALDO.BONSI.ORG.whitelist.m3047.net. 600 IN A 10.9.8.7

;; Query time: 7 msec
;; SERVER: 10.0.0.220#53(10.0.0.220)
;; WHEN: Fri Aug 16 09:55:41 2019
;; MSG SIZE  rcvd: 104

Let's make sure I didn't break your zone:

# dig www.bonsi.org

; <<>> DiG 9.8.3-P1 <<>> www.bonsi.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42111
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.bonsi.org. IN A

;; ANSWER SECTION:
www.bonsi.org. 21600 IN A 162.201.66.177

;; Query time: 126 msec
;; SERVER: 10.0.0.220#53(10.0.0.220)
;; WHEN: Fri Aug 16 09:56:49 2019
;; MSG SIZE  rcvd: 47

Looks good. Where's waldo?

# dig waldo.bonsi.org

; <<>> DiG 9.8.3-P1 <<>> waldo.bonsi.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16655
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;waldo.bonsi.org. IN A

;; ANSWER SECTION:
WALDO.BONSI.ORG. 5 IN A 10.9.8.7

;; ADDITIONAL SECTION:
whitelist.m3047.net. 1 IN SOA DEV.NULL. M3047.M3047.NET.
364 600 60 86400 600

;; Query time: 7 msec
;; SERVER: 10.0.0.220#53(10.0.0.220)
;; WHEN: Fri Aug 16 09:57:26 2019
;; MSG SIZE  rcvd: 142

You'll notice that the authority comes from whitelist.m3047.net, and that
I didn't have to take over your entire zone in order to rewrite that
particular FQDN. This does break DNSSEC.

How does this hang together in the BIND config?

# cat /etc/named.conf
...
options {
     ...
      // RPZs
      response-policy {
  zone "whitelist.m3047.net";
          zone "rpz1.m3047.net";
      };
     ...
};
...
zone "whitelist.m3047.net" {
      type master;
      check-names ignore;
      file "whitelist.m3047.net";
};
...

# rndc freeze whitelist.m3047.net
# rndc thaw whitelist.m3047.net
# cat whitelist.m3047.net
$ORIGIN .
$TTL 900 ; 15 minutes
whitelist.m3047.net IN SOA DEV.NULL. M3047.M3047.NET. (
  364        ; serial
  600        ; refresh (10 minutes)
  60         ; retry (1 minute)
  86400      ; expire (1 day)
  600        ; minimum (10 minutes)
  )
  NS LOCALHOST.
...
$ORIGIN AP.ORG.whitelist.m3047.net.
* CNAME rpz-passthru.
$ORIGIN ORG.whitelist.m3047.net.
WALDO.BONSI A 10.9.8.7
$ORIGIN CONSUMERREPORTSCDN.ORG.whitelist.m3047.net.
* CNAME rpz-passthru.
...

(RPZs have special semantics for actions like passthrough and NXDOMAIN.)

>> Fundamentally, you're not authoritative for the zone:
>
> I am totally aware about that! That would be more simple if I just go
> ahead and order some static ips from AT&T ...and that would cost me an
> arm and a leg and get done with it! Then, "probably" I would not > be
> here asking this question at all.

We are referring to the in-addr.arpa zone, just to be clear. There is
reverse for it, it's just provided by SW Bell. It's not pointing to an
FQDN within your zone (bonsi.org). That could be seen as "spammy", but a
lot of people outsource email these days. (It would be interesting to know
just how "spammy" that is as a feature in reality and in perception.) Some
people view anything with a reverse like that to be "customer prem" and
therefore spammy. Regardless, they provide forward that matches the
reverse:

# dig 162-201-66-177.lightspeed.sntcca.sbcglobal.net +short
162.201.66.177

Having an MTA for your zone which announces its name as something
different than what it reverses to is widely considered spammy. You do
control the domain bonsi.org however, and I don't see why you can't name
162-201-66-177.lightspeed.sntcca.sbcglobal.net as your MX. Define SPF for
good measure. If you've got the host named something else, you may have to
take special measures configuring the MTA software so that it uses the
sbcglobal.net FQDN in headers it generates.

> Yes, I am aware about that too! Even thou, I am not authoritative
> according to the BIND rules, I do have authoritative control of the
> zone bonsi.org at the registrar GoogleDomains.com.

bonsi.org is (ultimately) delegated from .org. 177.66.201.162.in-addr.arpa
is delegated from .arpa. There is no explicit control between the two. An
organization might be delegated control over the reverse for a block of
addresses it is pointing into or it might not. According to whois:

66.201.162.in-addr.arpa: not delegated
201.162.in-addr.arpa: SBC Global / SW Bell
162.in-addr.arpa: ARIN

Google has no control at any level of the delegation chain.

> The only one with authority to reverse that ip is AT&T and as I mention
> before, AT&T is not going to do that unless I pay them the extra, extra
> bucks for static IPs.
> [...]
> I am aware of that! I just could ask AT&T to reverse the domain. I am
> only running a catching namesever locally, (No recursion) and for that
> I am only authoritative for the internal zones. Here, I can do >that
> without having to request anybody ... :)
>
> [server:~] root# dig @127.0.0.1 -x 192.168.1.3
>
> ; <<>> DiG 9.10.6 <<>> @127.0.0.1 -x 192.168.1.3
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48149
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;3.1.168.192.in-addr.arpa. IN PTR
>
> ;; ANSWER SECTION:
> 3.1.168.192.in-addr.arpa. 3600 IN PTR bonsi.org.
>
> ;; AUTHORITY SECTION:
> 1.168.192.in-addr.arpa. 3600 IN NS ns1.bonsi.org.
> 1.168.192.in-addr.arpa. 3600 IN NS ns3.bonsi.org.
> 1.168.192.in-addr.arpa. 3600 IN NS ns2.bonsi.org.
>
> ;; ADDITIONAL SECTION:
> ns1.bonsi.org. 3600 IN A 192.168.1.21
> ns2.bonsi.org. 3600 IN A 192.168.1.31
> ns3.bonsi.org. 3600 IN A 192.168.1.41
>
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Thu Aug 15 14:27:33 PDT 2019
> ;; MSG SIZE  rcvd: 178

Yup.

--

Fred
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users