<div dir="ltr"><div>So... without stub zones, you know the drill: your local resolver follows delegation, starting from the root nameservers. Delegation happens, and life is good. If you're running views, then things work fine as well: your view just needs to be configured to allow queries from your local resolvers.<br>
<br></div><div>Let's say you're testing out a new set of authoritative DNS servers for your domain. These are authoritative-only nameservers (not necessarily BIND, either: plenty of other software and cloud services out there). You want your local resolvers to not follow the usual delegation process: you want them to begin delegation with your authoritative NSs.<br>
<br></div><div>From my experience, the biggest difference between stub zones and forward zones is that with stub zones, the RD bit is unset--it's up to the local resolver to follow delegation, starting with the nameservers configured in the stub zone, rather than starting with the root NS.<br>
<br>With forwarders, the RD bit is unchanged--you can easily end up sending recursive queries to a server that isn't set up to handle them. You might also end up not getting a full answer to your query: the forwarder destination isn't doing recursion, so your answer will only be one level deep.<br>
<br></div><div>John<br></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 2, 2014 at 5:37 PM, Nex6|Bill <span dir="ltr"><<a href="mailto:n6ghost@yahoo.com" target="_blank">n6ghost@yahoo.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:10pt">
<div><span>I guess, i am having issues with this(maybe i am not fully getting it), and yea I know large environments sometimes have multiple sets of name servers. sometimes department level (i have this issue in my shop its a damn mess)</span></div>
<div style="color:rgb(0,0,0);font-size:13.3333px;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;background-color:transparent;font-style:normal"><br><span></span></div><div style="color:rgb(0,0,0);font-size:13.3333px;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;background-color:transparent;font-style:normal">
<span>if all the zones are delegated
properly the local resolver will query its NS, and that NS will know where it should go next, whether its a internet side query or navigating the mess of local NS servers that some folks have. in the case of DNS views, where the local resolver may NOT be able to get to the correct view a forwarder would be better so you can point to the internal view NS. This keeps NS servers that are authoritative and responsible for handing out resource records</span></div>
<div style="color:rgb(0,0,0);font-size:13.3333px;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;background-color:transparent;font-style:normal"><span>they hand them out. and unless, your dealing with a load balancer (which is its own exception) which needs short TTLs, a caching forwarder is far better in most cases.. <br>
</span></div><div style="color:rgb(0,0,0);font-size:13.3333px;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;background-color:transparent;font-style:normal"><span><br></span></div><div style="color:rgb(0,0,0);font-size:13.3333px;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;background-color:transparent;font-style:normal">
<span>I guess, I am still not sure of the point of a stub zone, where you point to a different NS? than the </span><span><span>authoritative NS for that zone? unless your changing the records <br></span></span></div><div style="color:rgb(0,0,0);font-size:13.3333px;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;background-color:transparent;font-style:normal">
<span><span>which is all bad....</span></span></div><div style="color:rgb(0,0,0);font-size:13.3333px;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;background-color:transparent;font-style:normal">
<br><span><span></span></span></div><div style="color:rgb(0,0,0);font-size:13.3333px;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;background-color:transparent;font-style:normal"><span><span></span> </span></div>
<div><br><br></div><div style="display:block"> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:10pt"> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:12pt">
<div dir="ltr"> <font face="Arial"> On Monday, June
2, 2014 2:18 PM, John Miller <<a href="mailto:johnmill@brandeis.edu" target="_blank">johnmill@brandeis.edu</a>> wrote:<br> </font> </div> <blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;margin-top:5px;padding-left:5px">
<br><br> <div>Not quite, Bill. You point the zone at a different name server, but <br clear="none">_your_own_nameserver_ still does the iterative queries to make things <br clear="none">happen. It just queries a different set of nameservers than would <br clear="none">
happen through normal delegation.<br clear="none"><br clear="none">The only recursive query going on is from the client to your nameserver.<br clear="none"><br clear="none">Since you asked the question, what would you propose as an alternative <br clear="none">
for folks running multiple sets of nameservers with different info on them?<br clear="none"><br clear="none">John<br clear="none"><br clear="none"><br clear="none">On 06/02/2014 04:52 PM, Nex6|Bill wrote:<br clear="none">
> so, stub zones allow you to point a zone to a different name server, and<br clear="none">> that name-server; to recurse to get the records for that zone. why? why<br clear="none">> not let DNS work the way it is suppose to and let your name servers work<br clear="none">
> for you to the authoritative name-server to get the records? unless,<br clear="none">> your changing the zone records, which is why most people I know use it<br clear="none">> for, which is evil :)<br clear="none">
><br clear="none">> its almost the same, as creating a local zone for something your not<br clear="none">> authoritative for and then having to maintain those records. but, i<br clear="none">> guess their may be cases where it may be useful.... i guess....<br clear="none">
><br clear="none">><br clear="none">> On Monday, June 2, 2014 1:33 PM, John Miller <<a shape="rect" href="mailto:johnmill@brandeis.edu" target="_blank">johnmill@brandeis.edu</a>> wrote:<br clear="none">><br clear="none">
><br clear="none">><br clear="none">> Evil? Seems a bit strong. Unusual? Use with caution? OK.<br clear="none">><br clear="none">>
Stub zones mean that you're using a different set of authoritative<br clear="none">> nameservers for a particular domain. You're not storing all of that<br clear="none">> domain's records, except through the usual caching process. If it's<br clear="none">
> a domain you control, where's the harm?<br clear="none">><br clear="none">> Also, let's say that you're nominally a caching-only nameserver.<br clear="none">> You're responsible for making iterative queries, and you do not want<br clear="none">
> the RD bit set. AFAIK, stub zones are the way to accomplish that.<br clear="none">> Forward zones just pass recursive queries on to someplace else.<br clear="none">><br clear="none">> John<br clear="none">
><br clear="none">><br clear="none">><br clear="none">><br clear="none">> On Mon, Jun 2, 2014 at 4:02 PM, Nex6|Bill <<a shape="rect" href="mailto:n6ghost@yahoo.com" target="_blank">n6ghost@yahoo.com</a><br clear="none">
> <mailto:<a shape="rect" href="mailto:n6ghost@yahoo.com" target="_blank">n6ghost@yahoo.com</a>>> wrote:<br clear="none">><br clear="none">> recently, a question came up about "stub" zones came up and what<br clear="none">
> they are and are they part of the DNS standards or are they a<br clear="none">> good idea. i said, they are evil and should not be used if you<br clear="none">> can avoid it. they way I understand them is the are when you<br clear="none">
> create local zones for zones you are NOT authoritative for. and;<br clear="none">> the records in the stub zone do not update when the<br clear="none">> authoritative NS does.<br clear="none">
><br clear="none">> correct? thoughts?<br clear="none">><br clear="none">> -Nex6<br clear="none">><br clear="none">><br clear="none">><br clear="none">> _______________________________________________<br clear="none">
> Please visit <a shape="rect" href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br clear="none">> to unsubscribe from this list<br clear="none">
><br clear="none">> bind-users mailing list<br clear="none">> <a shape="rect" href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a> <mailto:<a shape="rect" href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a>><br clear="none">
> <a shape="rect" href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br clear="none">><br clear="none">><br clear="none">><br clear="none">
><br clear="none">> --<br clear="none">> John Miller<br clear="none">> Systems Engineer<br clear="none">> Brandeis University<br clear="none">> <a shape="rect" href="mailto:johnmill@brandeis.edu" target="_blank">johnmill@brandeis.edu</a> <mailto:<a shape="rect" href="mailto:johnmill@brandeis.edu" target="_blank">johnmill@brandeis.edu</a>><div>
<br clear="none">><br clear="none">><br clear="none"></div><br><br></div> </blockquote> </div> </div> </div> </div></div></blockquote></div><br><br clear="all"><br>-- <br>John Miller<br>Systems Engineer<br>Brandeis University<br>
<a href="mailto:johnmill@brandeis.edu">johnmill@brandeis.edu</a><br>(781) 736-4619
</div></div></div></div>