Yes, you are confused :-)
I am simply trying to get the domain slave to make queries for hosts in the subdomain which is hosted on other servers, instead of forwarding the queries to the domain master. I thought a stub zone would facilitate this by giving my server the lookup information it needed to do this. Apparently this is not the case. Even though it receives a db file with the NS and SOA information for the subdomain, it is ignoring it. Forwarding works. Being a slave for the subdomain works. Stub zone doesn't work. If it's supposed to "ignore" the stub zone in my configuration, what is the value of a stub zone? _____ From: Nex6 [mailto:b...@borg1911.com] Sent: Tuesday, February 28, 2012 9:32 AM To: Mike Bernhardt; bind-users@lists.isc.org; 'Mark Andrews' Subject: RE: Configuring a domain slave to look up subdomain hosts -------- Original Message -------- Subject: RE: Configuring a domain slave to look up subdomain hosts From: "Mike Bernhardt" < <mailto:bernha...@bart.gov> bernha...@bart.gov> Date: Tue, February 28, 2012 10:15 am To: < <mailto:bind-users@lists.isc.org> bind-users@lists.isc.org>, "'Mark Andrews'" < <mailto:ma...@isc.org> ma...@isc.org> So it sounds like in this case, stub zones don't buy me anything? What I wanted was for this secondary to query the subdomain name servers directly instead of relying on the domain primary via forwarding. Is making this server a secondary for the subdomain the only way? /answer: I am a little confused on what your trying to do, I think your terminology may be making things harder. generally a stub zone is a local copy of a zone thats not yours. the reason for doing this, is many fold like its an internal zone in another entity. or, to make sure your name servers always have a copy. but generally its not needed. and the DNS Architecture accounts for much, with caching and TTL. what you would do, is have your primary Name Server, thats authoritative for the zones that it owns. and maybe some slaves to that name server to spread things around. with local caching, on the name servers that ensure good lookup times for oft requested zones. if your worried about "slow" lookups, or things always going out to the forwarder just make sure the local name servers caches are working. and check the TTLs for the zones your worried about. hope this helps clear things up. -Nex6 _____ From: Nex6 [ <mailto:b...@borg1911.com> mailto:b...@borg1911.com] Sent: Monday, February 27, 2012 4:59 PM To: Mike Bernhardt; <mailto:bind-users@lists.isc.org> bind-users@lists.isc.org Subject: RE: Configuring a domain slave to look up subdomain hosts -------- Original Message -------- Subject: Configuring a domain slave to look up subdomain hosts From: "Mike Bernhardt" < <mailto:bernha...@bart.gov> bernha...@bart.gov> Date: Mon, February 27, 2012 4:50 pm To: < <mailto:bind-users@lists.isc.org> bind-users@lists.isc.org> I have a domain and a subdomain which is delegated by the I am trying to figure out the correct way to have the slave of a parent domain look up hosts in a subdomain managed by others. I'm running BIND 9.8.1-P1. The current working configuration for the subdomain is this: options { directory "/var/named"; allow-recursion { any; }; allow-query { any; }; allow-query-cache { any; }; forwarders { 148.165.3.10; }; forward only; recursive-clients 2000; zone-statistics yes; }; zone "domain.com" { type slave; masters { 10.130.1.30; }; file "db.domain"; forwarders { }; }; But using "forwarders" doesn't seem like the correct way to do it. It's in the options in order to forward internet queries to our external name server instead of to the root servers, which aren't accessible from inside. I've been messing with stub zones but that doesn't seem to work: zone "domain.com" { type slave; masters { 10.130.1.30; }; file "db.domain"; }; zone "subdomain.domain.com" { type stub; masters { 10.2.241.101; 10.2.242.222; }; file "db.subdomain"; }; With this configuration, the zone file for <http://subdomain.domain.com> subdomain.domain.com is correctly created but when I run tcpdump I can see that queries for <http://host.subdomain.domain.com> host.subdomain.domain.com are being forwarded to 148.165.3.10, not to the subdomain name servers. The result of course is NXDOMAIN. With forwarders set for the zone <http://domain.com> domain.com, the slave queries the zone master, which then queries the subdomain name server as it should. So the stub zone is apparently being ignored. What is wrong? Perhaps I'm misunderstanding the purpose of stub zones? Let me know if you need additional config details. /answer: This post, requires a much longer response then I have time for, but i will take a quick stab. a "stub" zone, is generally only used for cross corporate, or cross partner resolving. it gives you a "local" copy of possibly internal zone data. a "slave" is a type of Nameserver, not a type of zone. generally youll have authoritative name servers, and sometimes in bigger shops a number if "salves" or now called secondary name servers. for example, you could have your authoritative name servers behind your firewall, and put a slave in the DMZ sorta thing. or have a few authoritative name servers, a several salves, so you may have salves in each datacenter. a delegation, is where you "delagate" a subzone to someone else. example, you own say <http://example.org> example.org, and a subgroup wants to manage their own namespace of <http://depart1.example.org> depart1.example.org, so you delegate <http://depart1.example.org> depart1.example.org to there name servers. and they will "own" the zone depart1. hope this helps clears a few things up. -Nex6 _______________________________________________ Please visit <https://lists.isc.org/mailman/listinfo/bind-users> https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list <mailto:bind-users@lists.isc.org> bind-users@lists.isc.org <https://lists.isc.org/mailman/listinfo/bind-users> https://lists.isc.org/mailman/listinfo/bind-users _____ _______________________________________________ Please visit <https://lists.isc.org/mailman/listinfo/bind-users> https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list <mailto:bind-users@lists.isc.org> bind-users@lists.isc.org <https://lists.isc.org/mailman/listinfo/bind-users> 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
