On 3/4/2013 3:26 PM, Verne Britton wrote:
On 3/4/2013 2:45 PM, Barry Margolin wrote:
In article <[email protected]>,
Verne Britton <[email protected]> wrote:
I have been testing and testing and either just don't see what I'm doing
wrong, or have a learning block :-)
current thinking is that a open recursion DNS server is bad, so we want to
implement an allow-recursion clause; perhaps even make some views so our
local users still recurse while the general public cannot ...
but I am running into a roadblock with our Google Apps cname:
gmail.wvstateu.edu is a cname to ghs.google.com
and bind wants recursion turned on in order to translate it.
What's the problem?
If the query comes from a local user, recursion will be allowed, and the
CNAME will be resolved.
If the query comes from a remote resolver, recursion shouldn't even be
requested. You'll respond with the CNAME, and the remote resolver will
then do its own lookup of that.
Barry asks whats my problem ...
***** it doesn't work :-) :-)
for some reason my server wants to do the CNAME resolution itself instead of
just returning the CNAME alone ... perhaps I have something configured wrong.
Don't know if I'm being hit with queries from other DNS servers or from end
users ...
HEY ... maybe thats the answer ... perhaps all my testing and all my complaints
are from staff who go home and use their campus configs at home ... and try to
use the public authoritative server as their personal resolving (recursing)
server ... let me see how to test that ...
anyway, here is my test named.conf
include "/etc/named-masters.conf";
// 18-feb-2013 use TRUSTED later for Recursive Resolution filter
acl "trusted" {
localhost;
129.71.0.0/16; /* WVNET network */
168.216.0.0/16; /* K12 network */
};
options {
directory "/var/named/slaves";
allow-transfer {127.0.0.1; /* loopback */
129.71.1.1; /* NameServ */
};
auth-nxdomain yes; /* respond as authoritative for everything */
transfer-format one-answer ;
notify no;
recursion no ; /* 18-feb-2013 efault=YES, adding anyway */
additional-from-auth no ; /* turn back on in VIEW when needed */
additional-from-cache no ; /* turn back on in VIEW when needed */
recursive-clients 9123 ; /* Google says default is 1k */
files 8192 ; /* bump it up from 1024 default */
/* and to match Max Sockets */
/* fixes info msgs when starting */
/* and "too many open files" msgs */
/* 10-sep-2012 double it from 4k to 8k */
tcp-clients 400; /* 6-sep-2012 bump up from the default of 100
*/
/* 10-sep-2012 double it from 200 to 400 */
allow-query { any; };
allow-recursion { trusted; };
}; /* end of OPTIONS */
include "/etc/named-logging.conf";
include "/etc/named-key.conf";
view "public-2"
{
match-clients { any; };
match-destinations { any; };
// for additional-from-auth to be YES, must have recursion NO
recursion yes;
allow-recursion { trusted; };
additional-from-auth yes ;
additional-from-cache yes ;
// somewhere someone suggests each view must have its own HINTS entry
zone "." {
type hint;
file "/var/named/data/cache.dat";
};
zone "10.in-addr.arpa" {type master; file
"/var/named/data/inverse-private-dummy.dat"; };
zone "16.172.in-addr.arpa" {type master; file
"/var/named/data/inverse-private-dummy.dat"; };
zone "17.172.in-addr.arpa" {type master; file
"/var/named/data/inverse-private-dummy.dat"; };
zone "18.172.in-addr.arpa" {type master; file
"/var/named/data/inverse-private-dummy.dat"; };
zone "19.172.in-addr.arpa" {type master; file
"/var/named/data/inverse-private-dummy.dat"; };
zone "20.172.in-addr.arpa" {type master; file
"/var/named/data/inverse-private-dummy.dat"; };
zone "21.172.in-addr.arpa" {type master; file
"/var/named/data/inverse-private-dummy.dat"; };
zone "22.172.in-addr.arpa" {type master; file
"/var/named/data/inverse-private-dummy.dat"; };
zone "23.172.in-addr.arpa" {type master; file
"/var/named/data/inverse-private-dummy.dat"; };
zone "24.172.in-addr.arpa" {type master; file
"/var/named/data/inverse-private-dummy.dat"; };
zone "25.172.in-addr.arpa" {type master; file
"/var/named/data/inverse-private-dummy.dat"; };
zone "26.172.in-addr.arpa" {type master; file
"/var/named/data/inverse-private-dummy.dat"; };
zone "27.172.in-addr.arpa" {type master; file
"/var/named/data/inverse-private-dummy.dat"; };
zone "28.172.in-addr.arpa" {type master; file
"/var/named/data/inverse-private-dummy.dat"; };
zone "29.172.in-addr.arpa" {type master; file
"/var/named/data/inverse-private-dummy.dat"; };
zone "30.172.in-addr.arpa" {type master; file
"/var/named/data/inverse-private-dummy.dat"; };
zone "31.172.in-addr.arpa" {type master; file
"/var/named/data/inverse-private-dummy.dat"; };
zone "168.192.in-addr.arpa" {type master; file
"/var/named/data/inverse-private-dummy.dat"; };
zone "2.71.129.in-addr.arpa" {
type slave;
file "wvnet2_rev.dat";
masters { stealth-source;
};
};
zone "southernwv.edu" {
type master;
file "southernwv.dat";
};
zone "wvstateu.edu" {
type master;
file "wvstateu.dat";
};
// end of view public-2
};
//
//
// end of file
and are my two test zones (if it matters):
$ORIGIN wvstateu.edu.
$TTL 86400 ; 1 day
wvstateu.edu. IN SOA nameserv.wvnet.edu. hostmaster.wvnet.edu. (
102 ; serial
7200 ; refresh (2 hours)
3600 ; retry (1 hour)
2592000 ; expire (4 weeks 2 days)
900 ; minimum (15 minutes)
)
NS nameserv3.wvnet.edu.
A 98.129.177.93
MX 10 mailfoundry
$TTL 3600 ; 1 hour
mailfoundry A 129.71.208.204
gmail CNAME ghs.l.google.com.
sso IN A 129.71.208.239
In A 65.78.203.230
IN A 129.71.208.235
;;
;; end of zone
$ORIGIN .
$TTL 86400 ; 1 day
southernwv.edu IN SOA nameserv3.wvnet.edu. hostmaster.wvnet.edu. (
7 ; serial
7200 ; refresh (2 hours)
3600 ; retry (1 hour)
2592000 ; expire (4 weeks 2 days)
900 ; minimum (15 minutes)
)
NS nameserv3.wvnet.edu.
A 67.222.2.224
MX 10 mailin1.wvnet.edu.
MX 20 mailin2.wvnet.edu.
$ORIGIN southernwv.edu.
gmail CNAME ghs.l.google.com.
sip CNAME sipdir.online.lync.com.
www A 67.222.2.224
;;
;; end of zone
my test server (its up and down a lot) is at 129.71.2.224 with these two test
zones ... what I want to be able to do is:
1. serve the A records as authoritative
2. somehow handle resolutions coming at me for the CNAMEs
3. not have a public open recursive server
You can achieve all of that as long as you provide recursive service
only *selectively* (otherwise, #2 degenerates into what you're trying to
avoid with #3). If you can't convince your users to use their own
resolvers when they are on the Internet, and you can't constrain them to
only certain source-address ranges (because they are geographically
and/or topologically diverse when they're on the Internet) the only
technical fix that comes to mind is to set up some sort of
crypto-authentication of your client's queries (e.g. TSIG or GSS-TSIG)
on the endpoints. You could use that to allow/deny recursion and/or
match views.
- Kevin
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
