Bind with views: forward any public domain in one view
Dear, I have a BIND 9 working with two views.
One view forwards two public domains to our resolver.
And I want the second view to forward any public domain to our resolver in
order to let navigate withouth restrictions.
I need something like this:
zone "ANY" {
type forward;
forward only;
forwarders {
8.8.8.8;
};
};
How can I implement this second option ??? Can I replace ANY for the
correct wildcard ???
Thanks a lot !!!
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind with views: forward any public domain in one view
On 15.08.19 12:18, Roberto Carna wrote:
Dear, I have a BIND 9 working with two views.
One view forwards two public domains to our resolver.
And I want the second view to forward any public domain to our resolver in
order to let navigate withouth restrictions.
what restricions and where are they applied?
I need something like this:
zone "ANY" {
type forward;
forward only;
forwarders {
8.8.8.8;
};
};
How can I implement this second option ??? Can I replace ANY for the
correct wildcard ???
"." should be enough, but note that BIND can do the same that google servers
(8.8.8.8) can do, and you'll avoid one hop.
simply don't forward but let BIND to resolve.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
The early bird may get the worm, but the second mouse gets the cheese.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind with views: forward any public domain in one view
Thanks a lot !!!
El jue., 15 ago. 2019 a las 13:09, Matus UHLAR - fantomas (<
uh...@fantomas.sk>) escribió:
> On 15.08.19 12:18, Roberto Carna wrote:
> >Dear, I have a BIND 9 working with two views.
> >
> >One view forwards two public domains to our resolver.
> >
> >And I want the second view to forward any public domain to our resolver in
> >order to let navigate withouth restrictions.
>
> what restricions and where are they applied?
>
> >I need something like this:
> >
> >zone "ANY" {
> >type forward;
> >forward only;
> >forwarders {
> >8.8.8.8;
> >};
> >};
> >
> >How can I implement this second option ??? Can I replace ANY for the
> >correct wildcard ???
>
> "." should be enough, but note that BIND can do the same that google
> servers
> (8.8.8.8) can do, and you'll avoid one hop.
>
> simply don't forward but let BIND to resolve.
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> The early bird may get the worm, but the second mouse gets the cheese.
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS domain Pointing to a DSL U/verse host
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 @ ..." (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; [...] ; 177IN PTR ns1.bonsi.org. 177IN PTR ns2.bonsi.org. 177IN PTR ns3.bonsi.org. ; 177IN PTR bonsi.org. 177IN PTR www.bonsi.org. NOTE: Multiple PTR records is
Re: DNS domain Pointing to a DSL U/verse host
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.
