Forwarding environment questions

[Chris Buxton]

Hello Josh,

I was mainly trying to simply clarify Mark's answer. In truth, we see  
your situation quite frequently, and although it's not the ideal case,  
it's common enough.

If you're interested, we can help you to migrate toward what Mark had  
suggested:

- A (small) set of authoritative servers that do not perform  
recursion. These are listed in each zone's NS records.
- Resolving name servers that also act as slaves for your zones,  
though they are not listed in the NS records. (Alternatively, they can  
be configured with stub zones instead of slave zones; the effect is  
almost identical, but gives even better separation of roles.)

You can probably see that, because the resolving name servers act as  
slaves, there does not need to be an instant transition; it can be  
done in stages.

Alternatively, yes, you can configure your authoritative servers to  
handle recursive queries in some fashion, either directly or through  
forwarding. Again, this is not the ideal case, and you would do better  
to transition the other way - have these servers primarily act as your  
resolving servers and move the job of authoritative service to other  
machines. However, if you want to go the route you're currently  
suggesting, while forwarding is an option, it may or may not be the  
best option; we can't make a recommendation without a more thorough  
analysis of your network, traffic loads, etc.

Please note that the whitepaper you quoted from does not agree with  
our ideas of best practices. As Mark said, forwarding is rarely  
necessary. There are almost certainly better solutions.

Chris Buxton
Professional Services
Men & Mice
Address: Noatun 17, IS-105, Reykjavik, Iceland
Phone:   +354 412 1500
Email:   cbuxton at menandmice.com
www.menandmice.com

Men & Mice
We bring control and flexibility to network management

This e-mail and its attachments may contain confidential and  
privileged information only intended for the person or entity to which  
it is addressed. If the reader of this message is not the intended  
recipient, you are hereby notified that any retention, dissemination,  
distribution or copy of this e-mail is strictly prohibited. If you  
have received this e-mail in error, please notify us immediately by  
reply e-mail and immediately delete this message and all its attachment.



On Nov 26, 2007, at 10:33 AM, Baird, Josh wrote:

> Chris,
>
> We are actually in contact with M&M now (Rob K.) evaluating your  
> product
> -- looks great.
>
> Yes, I understand that my situation is not an ideal one.  Keep in mind
> that this is for
> Internal DNS only -- external DNS for our environment is handled
> separately (not using views).
>
> All of our client base is currently using these internal authoritative
> servers for name resolution.  This includes internal name resolution,
> but also recursive
> resolution for Internet domains -- so, we can't really separate the  
> two.
> I was, however,
> under the impression that while we can't totally separate the two  
> roles,
> it would be
> better to let these authoritative servers forward their
> non-authoritative requests to designated
> caching only servers that sit on our LAN.
>
> So.. CLIENTA is using 10.1.1.1 as a nameserver.
> 10.1.1.1 is authoritative for our internal zones (resolving to  
> internal
> space)
> 10.1.1.1 also needs to resolve Internet hostnames (yahoo.com, etc)
> Is it better to have 10.1.1.1 resolve hostnames via root hints  
> directly,
> or have it forward requests to designated caching only boxes?
>
> This is from a whitepaper (BCN):
>
> " Separation of Roles
> To accomplish the separation of DNS server roles, it is recommended to
> make use of a concept called DNS
> forwarders. Often, DNS clients are configured to send their queries to
> one of the organization's authoritative
> DNS servers. Recall that we want to be careful regarding recursion on
> our authoritative servers. When the
> client issues a query for an internal record for which the DNS  
> server is
> authoritative, the server can, and
> should, answer this query from its zone information. However, if the
> query is for a zone for which the server
> is not authoritative, rather than disabling recursion, we will  
> configure
> the local DNS server to "forward" the
> recursive queries to a DNS caching server. The caching server "walks"
> the DNS namespace using iterative
> queries starting at the root servers and responds to the querying DNS
> server which then answers the original
> client. By using forwarders, DNS administrators are able to restrict  
> DNS
> servers to their respective roles."
>
> Thanks, and I appreciate the help!
>
> -----Original Message-----
> From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org] On
> Behalf Of Chris Buxton
> Sent: Monday, November 26, 2007 12:22 PM
> To: Bind-Users List
> Subject: Re: Forwarding environment questions
>
> No, he's saying it's better to not have clients send recursive queries
> to your authoritative name servers in the first place. Instead,
> ideally, it should have recursion turned off entirely, at which point
> a forwarding configuration is essentially pointless.
>
> There are two server jobs in DNS, authoritative and resolving. An
> authoritative name server (at least one that is listed in the NS
> records of your zones), ideally, should not also be serving as a
> resolving name server. You are instead suggesting that your servers
> have to do both jobs, and Mark is arguing that this is not ideal.
>
> Is there a reason you cannot separate the two jobs onto separate  
> boxes?
>
> Chris Buxton
> Professional Services
> Men & Mice
> Address: Noatun 17, IS-105, Reykjavik, Iceland
> Phone:   +354 412 1500
> Email:   cbuxton at menandmice.com
> www.menandmice.com
>
> Men & Mice
> We bring control and flexibility to network management
>
> This e-mail and its attachments may contain confidential and
> privileged information only intended for the person or entity to which
> it is addressed. If the reader of this message is not the intended
> recipient, you are hereby notified that any retention, dissemination,
> distribution or copy of this e-mail is strictly prohibited. If you
> have received this e-mail in error, please notify us immediately by
> reply e-mail and immediately delete this message and all its  
> attachment.
>
>
>
> On Nov 26, 2007, at 7:50 AM, Baird, Josh wrote:
>
>> Mark,
>>
>> In order to serve existing clients, our internal authoritative  
>> servers
>> need to be able to answer recursive queries as well.  Are you saying
>> that I should have all of my authoritative slave servers be caching
>> servers as well and answer recursive queries directly?  I was under
>> the
>> impression that it was a better practice to have these authoritative
>> servers forward to caching only servers for recursive queries?
>>
>> Mark -- sorry for the duplicate copy.
>>
>> Thanks,
>>
>> Josh
>>
>> -----Original Message-----
>> From: Mark_Andrews at isc.org [mailto:Mark_Andrews at isc.org]
>> Sent: Sunday, November 25, 2007 11:57 PM
>> To: Baird, Josh
>> Cc: bind-users at isc.org
>> Subject: Re: Forwarding environment questions
>>
>>
>>> I am currently in the process of re-structuring a fairy large BIND
>> environment
>>> and have a few questions regarding forwarding.  Here is a simple
>> overview of the
>>> enviornment that I have in mind for Internal DNS:
>>>
>>> * Internal Master (authoritative, uses forwarders to caching only
>> servers for non-authoritative queries)
>>> `- Slave 1 (authoritative, uses forwarders to caching only servers
>> for non-authoritative queries)
>>> - Slave 2 (authoritative, uses forwarders to caching only servers
>> for non-authoritative queries)
>>> - Slave 3 (authoritative, uses forwarders to caching only servers
>> for non-authoritative queries)
>>> - Slave 4 (authoritative, uses forwarders to caching only servers
>> for non-authoritative queries)
>>> * Caching only nameserver 1 (no authoritative data, all other
>>> internal
>> BIND servers forward to these for recursive queries)
>>> * Caching only nameserver 2
>>>
>>> I am trying to follow best practices in that authoritative servers
>> (masters and slaves) should
>>> not allow recursive lookups, but should use forwarders if necessary.
>> Due to the nature of the
>>
>> 	There is no "but should use forwarders if necessary".
>>
>>> existing environment, all clients are pointing to either the  
>>> internal
>> master or slave servers for
>>> all name resolution (internal resolution, and recursive resolution).
>> In order to keep these
>>> authoritative servers from doing recursive lookups, my plan is to
>>> have
>> them all use a forwarders statement
>>> in the global options to forward all recursive lookups to the two
>> "Caching only nameservers" that
>>> we have in our environment.  Is using forwarders in this way
>> considered to be a good practice versus
>>> these authoritative servers going out to the Internet directly for
>> resucrsive lookups using root hints?
>>>
>>> I am also a bit confused about the forwarders statements on the  
>>> slave
>> servers.  It is my understanding
>>> that they will only use the forwarders (that are defined in options)
>> if the nameserver does not
>>> contain authoritative data for the zone.. this is the case for slave
>> zones as well?  Or do I need
>>> to specify "forwarders { };" for each of the zones on the slaves to
>> force it to use the local authoritative
>>> data?
>>>
>>> I greatly appreciate any input or suggestions that you have.
>>>
>>> Thanks,
>>>
>>> Josh Baird
>>
>> 	You have totally missed the point of seperating recursive
>> 	and authoritative services.
>>
>> 	Firstly, do not use forwarders unless you know what you are
>> 	doing.  Forwarders are there for very specific configuration
>> 	issues.  Forwarders are one of the most abused configuration
>> 	options is named.conf.
>>
>> 	For authoritative servers you really only need.
>>
>> 		options {
>> 			recursion no;
>> 			allow-query-cache { none; };
>> 		};
>>
>> 		<zone definitions>
>>
>> 	That will isolate the clients from anything the server
>> 	learns as it does its notify processing.  Note, authoritative
>> 	servers (masters and slaves) will still ask question so
>> 	they still need a hint zone.
>>
>> 	Caches can be slaves of zones but they should not be listed
>> 	in the NS RRset for the zones.  It is actually common for
>> 	caches to be slave of internal zones as a override mechanism.
>>
>> 	Mark
>> -- 
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org
>>
>>
>
>
>