![](https://seccdn.libravatar.org/avatar/03f977b763487de21403593533d8ee18.jpg?s=120&d=mm&r=g)
I am trying to figure out how to configure BIND 9.x and have come across these two questions. In the example files there is a tag named "forwarders" which I am a bit confused about. As I understand things, *named* will, by default, resolve on behalf of cleints by querying other name servers on the Internet looking for the domain name the client has requested. If I set *forwarders* to a list of DNS servers, then my DNS sever will ask these servers for the query results. This works whether or not I have the *forward* variable explicitly set. If I have a null *forwarders* list then my DNS server will look for answers on the basis of the root.hints file. In either case, if my internal hosts have their /etc/resolv.conf set to the IP Address of my DNS server, then my internal hosts will not be hitting other DNS servers directly. They will ask my server for an answer and it will do the rest of the work. This is the default behavior, but it can be changed. This paragraph from _The Bind 9 Administrator's Reference Manual_ ( http://www.nominum.com/resources/documentation/ ) seems to contradict that understanding: "1.4.3.4 Forwarding Server "Instead of interacting with the nameservers for the root and other domains, a forwarding server always forwards queries it cannot satisfy from its authoritative data or cache to a fixed list of other servers. The forwarded queries are also known as recursive queries, the same type as a client would send to a server. There may be one or more servers forwarded to, and they are queried in turn until the list is exhausted or an answer is found. A forwarding server is typically used when you do not wish all the servers at a given site to interact with the rest of the Internet servers. A typical scenario would involve a number of internal DNS servers and an Internet firewall. Servers unable to pass packets through the firewall would forward to the server that can do it, and that server would query the Internet DNS servers on the internal server s behalf. An added benefit of using the forwarding feature is that the central machine develops a much more complete cache of information that all the workstations can take advantage of." The above paragraph makes me think that hosts would go out on the internet looking for answers if they didn't get them from my DNS server. Can anybody clarify this for me? In summary, my first question is as follows: what is the default behavior of the clients and DNS servers within my zone with respect to resolutions which go outside of my zone? My second question is something I believe I should know the answer to, but I have never understood it. This is the 168.117.138.0/24 notation. I believe /24 means the same as a net mask of 255.255.255.0 the 24 indicates the number of bits counting from the left which are masked. 255.255.255.0 base 10 = 11111111.11111111.11111111.00000000 which has 24 '1's. Is this correct? TIA, Steve -- What is Truth? Truth is something so noble that if God could turn aside from it, I could keep to the Truth and let God go. -- Meister Eckhart
![](https://seccdn.libravatar.org/avatar/4c27a583d12246b34aec3874e75c9ee6.jpg?s=120&d=mm&r=g)
On Thu, Feb 15, 2001 at 01:13:10AM -0500, Steven T. Hatton wrote:
In summary, my first question is as follows: what is the default behavior of the clients and DNS servers within my zone with respect to resolutions which go outside of my zone?
Clients are dumb. They can only query a server, and wait for an answer. If the server that was queried cannot provide an answer then the query fails, and the client assumes that the domain does not exist. The server must do all of the work for a client. When a server receives a query, it goes out and queries as many other name servers as needed in order to resolve a domain name. A DNS server first checks its cache for the answer. If the answer is not in cache, or in its authoritative data, then the server queries the root nameservers. Then it queries the TLD name servers, followed by the servers for the specified domain, and so on until it finds the answer. It caches all of this data, but only returns the final IP address to the client. Next time a client queries the server for the same address, the server can respond from cache. The "forwarders" option in named.conf changes the default behavior above. Basically, if you include a list of servers with the forwarding option, then the server will query them for the answer. The server starts by looking in its cache and authoritative data. If the answer is not there it queries the forwarders. They then do all of the work, and just return the answer to your nameserver. If the forwarders are not available for some reason, then your server falls back on the default behavior that I outlined above. Finally, there is the "forward-only" option. If this is set, your nameserver will act as a "caching only" nameserver. However, it will not fall back into default behavior if the forwarders are not available. If the forwarders are not available, the query fails.
My second question is something I believe I should know the answer to, but I have never understood it. This is the 168.117.138.0/24 notation. I believe /24 means the same as a net mask of 255.255.255.0 the 24 indicates the number of bits counting from the left which are masked. 255.255.255.0 base 10 = 11111111.11111111.11111111.00000000 which has 24 '1's. Is this correct?
That is correct. HTH, Victor Cardona
![](https://seccdn.libravatar.org/avatar/03f977b763487de21403593533d8ee18.jpg?s=120&d=mm&r=g)
On Thursday 15 February 2001 03:52, Victor R. Cardona wrote:
On Thu, Feb 15, 2001 at 01:13:10AM -0500, Steven T. Hatton wrote:
In summary, my first question is as follows: what is the default behavior of the clients and DNS servers within my zone with respect to resolutions which go outside of my zone?
Clients are dumb. They can only query a server, and wait for an answer. If the server that was queried cannot provide an answer then the query fails, and the client assumes that the domain does not exist.
The server must do all of the work for a client. When a server receives a query, it goes out and queries as many other name servers as needed in order to resolve a domain name. A DNS server first checks its cache for the answer. If the answer is not in cache, or in its authoritative data, then the server queries the root nameservers. Then it queries the TLD name servers, followed by the servers for the specified domain, and so on until it finds the answer. It caches all of this data, but only returns the final IP address to the client.
Next time a client queries the server for the same address, the server can respond from cache.
The "forwarders" option in named.conf changes the default behavior above. Basically, if you include a list of servers with the forwarding option, then the server will query them for the answer. The server starts by looking in its cache and authoritative data. If the answer is not there it queries the forwarders. They then do all of the work, and just return the answer to your nameserver. If the forwarders are not available for some reason, then your server falls back on the default behavior that I outlined above.
Finally, there is the "forward-only" option. If this is set, your nameserver will act as a "caching only" nameserver. However, it will not fall back into default behavior if the forwarders are not available. If the forwarders are not available, the query fails.
My second question is something I believe I should know the answer to, but I have never understood it. This is the 168.117.138.0/24 notation. I believe /24 means the same as a net mask of 255.255.255.0 the 24 indicates the number of bits counting from the left which are masked. 255.255.255.0 base 10 = 11111111.11111111.11111111.00000000 which has 24 '1's. Is this correct?
That is correct.
HTH, Victor Cardona
Victor, This clarifies things for me once again. :-) Now I understand the meaning of the paragraph I was confused by. The use of forwarders would allow the network administrator to "focus" all DNS traffic to the forwarders in the list. The concern was not for the behavior of the end-clients, rather it was for the internal DNS servers. If they attempted to query in the default manner, they would be trying to hit an undetermined number of different IP Addresses. On thing I'm still not clear on. You said "If the answer is not in cache, or in its authoritative data, then the server queries the root nameservers." Does that mean my system reaches out to the highest level name server in my root domain? I had always there there was some kind of recursive process taking place by default. Now it looks as though this type of recursion must be explicitly configured. As an example, I configure my internal network to mynet.bellatlantic.net. (Bellatlantic's DNS knows nothing about my network however - but that's a special case) If I don't set a forwarders list, my DNS will jump directly to the root server for .net? This is how I am understanding things now. That makes me think the root servers are getting an unnecessarily high level of traffic. Perhaps it's just a few lightweight hackers like me who are being this reckless, and real network admins have things configured correctly. Is this perception correct? Do I burden the root of .net every time I get a cache miss? Steve
![](https://seccdn.libravatar.org/avatar/2e846a486bb47d24595d540de089fe0d.jpg?s=120&d=mm&r=g)
"Steven T. Hatton" wrote:
On Thursday 15 February 2001 03:52, Victor R. Cardona wrote:
On Thu, Feb 15, 2001 at 01:13:10AM -0500, Steven T. Hatton wrote:
In summary, my first question is as follows: what is the default behavior of the clients and DNS servers within my zone with respect to resolutions which go outside of my zone?
Clients are dumb. They can only query a server, and wait for an answer. If the server that was queried cannot provide an answer then the query fails, and the client assumes that the domain does not exist.
The server must do all of the work for a client. When a server receives a query, it goes out and queries as many other name servers as needed in order to resolve a domain name. A DNS server first checks its cache for the answer. If the answer is not in cache, or in its authoritative data, then the server queries the root nameservers. Then it queries the TLD name servers, followed by the servers for the specified domain, and so on until it finds the answer. It caches all of this data, but only returns the final IP address to the client.
Next time a client queries the server for the same address, the server can respond from cache.
The "forwarders" option in named.conf changes the default behavior above. Basically, if you include a list of servers with the forwarding option, then the server will query them for the answer. The server starts by looking in its cache and authoritative data. If the answer is not there it queries the forwarders. They then do all of the work, and just return the answer to your nameserver. If the forwarders are not available for some reason, then your server falls back on the default behavior that I outlined above.
Finally, there is the "forward-only" option. If this is set, your nameserver will act as a "caching only" nameserver. However, it will not fall back into default behavior if the forwarders are not available. If the forwarders are not available, the query fails.
My second question is something I believe I should know the answer to, but I have never understood it. This is the 168.117.138.0/24 notation. I believe /24 means the same as a net mask of 255.255.255.0 the 24 indicates the number of bits counting from the left which are masked. 255.255.255.0 base 10 = 11111111.11111111.11111111.00000000 which has 24 '1's. Is this correct?
That is correct.
HTH, Victor Cardona
Victor,
This clarifies things for me once again. :-) Now I understand the meaning of the paragraph I was confused by. The use of forwarders would allow the network administrator to "focus" all DNS traffic to the forwarders in the list. The concern was not for the behavior of the end-clients, rather it was for the internal DNS servers. If they attempted to query in the default manner, they would be trying to hit an undetermined number of different IP Addresses.
On thing I'm still not clear on. You said "If the answer is not in cache, or in its authoritative data, then the server queries the root nameservers." Does that mean my system reaches out to the highest level name server in my root domain? I had always there there was some kind of recursive process taking place by default. Now it looks as though this type of recursion must be explicitly configured. As an example, I configure my internal network to mynet.bellatlantic.net. (Bellatlantic's DNS knows nothing about my network however - but that's a special case) If I don't set a forwarders list, my DNS will jump directly to the root server for .net? This is how I am understanding things now. That makes me think the root servers are getting an unnecessarily high level of traffic. Perhaps it's just a few lightweight hackers like me who are being this reckless, and real network admins have things configured correctly.
Is this perception correct? Do I burden the root of .net every time I get a cache miss?
Nope - although you may not have the particular internal IP address in your cache, you are the 'authoritative' server for your domain. Assuming you have appropriate DNS records for the boxes on your network, a lookup for their IP addresss will take its result from your 'authoritative' data. Not sure I've explained that clearly, but let me know... Bye, Chris -- __ _ -o)/ / (_)__ __ ____ __ Chris Reeves /\\ /__/ / _ \/ // /\ \/ / ICQ# 22219005 _\_v __/_/_//_/\_,_/ /_/\_\
![](https://seccdn.libravatar.org/avatar/1de49c59d43fa5bd3ac5a00d1538a8ce.jpg?s=120&d=mm&r=g)
"Steven T. Hatton" wrote:
<snip>
On thing I'm still not clear on. You said "If the answer is not in cache, or in its authoritative data, then the server queries the root nameservers." Does that mean my system reaches out to the highest level name server in my root domain? I had always there there was some kind of recursive process taking place by default. Now it looks as though this type of recursion must be explicitly configured. As an example, I configure my internal network to mynet.bellatlantic.net. (Bellatlantic's DNS knows nothing about my network however - but that's a special case) If I don't set a forwarders list, my DNS will jump directly to the root server for .net? This is how I am understanding things now. That makes me think the root servers are getting an unnecessarily high level of traffic. Perhaps it's just a few lightweight hackers like me who are being this reckless, and real network admins have things configured correctly.
Is this perception correct? Do I burden the root of .net every time I get a cache miss?
If a nameserver gets a recursive query, it looks into its cache for a possible answer, if found it returns it. Otherwise, it looks for a cached referral to the authoritative nameserver for the queried domain, if found, it queries it, if not found, it queries one of the root nameservers, which will return with a referral to the autoritative nameserver for the domain, that nameserver would then be queried and it will either return an answer or a referrel to another nameserver, so on. This recursion goes on till a positive or negative answer is found. Look at the following: (I have added my comments with //) floyd:~ # nslookup Default Server: ns1.nadmm.com Address: 216.112.234.66 // Start with one of the root nameservers
server a.root-servers.net Default Server: a.root-servers.net Address: 198.41.0.4
// Query for the A record of the host
floyd.nadmm.com. Server: a.root-servers.net Address: 198.41.0.4
// Root nameserver returns a referral to all the // authoritative nameservers it knows for nadmm.com. domain Name: floyd.nadmm.com Served by: - NAMESERVER.CONCENTRIC.NET 207.155.183.72 NADMM.COM - NAMESERVER3.CONCENTRIC.NET 206.173.119.72 NADMM.COM - NS.NADMM.COM 216.112.234.68 NADMM.COM - NS1.NADMM.COM 216.112.234.66 NADMM.COM // Use one of the referred nameservers
server nameserver.concentric.net Default Server: nameserver.concentric.net Address: 207.155.183.72
// Now query it for an answer
floyd.nadmm.com. Server: nameserver.concentric.net Address: 207.155.183.72
// Got a positive answer. Stop. Name: floyd.nadmm.com Address: 216.112.234.66 // Now query for a bad hostname
aa.nadmm.com. Server: nameserver.concentric.net Address: 207.155.183.72
// Got a negative answer. Stop. *** nameserver.concentric.net can't find aa.nadmm.com.: Non-existent host/domain Hope this helps you :) Cheers, -- Nadeem Hasan nhasan@nadmm.com http://www.nadmm.com/
![](https://seccdn.libravatar.org/avatar/03f977b763487de21403593533d8ee18.jpg?s=120&d=mm&r=g)
On Thursday 15 February 2001 10:11, Nadeem Hasan wrote:
"Steven T. Hatton" wrote:
<snip>
On thing I'm still not clear on. You said "If the answer is not in cache, or in its authoritative data, then the server queries the root nameservers." Does that mean my system reaches out to the highest level name server in my root domain? I had always there there was some kind of recursive process taking place by default. Now it looks as though this type of recursion must be explicitly configured. As an example, I configure my internal network to mynet.bellatlantic.net. (Bellatlantic's DNS knows nothing about my network however - but that's a special case) If I don't set a forwarders list, my DNS will jump directly to the root server for .net? This is how I am understanding things now. That makes me think the root servers are getting an unnecessarily high level of traffic. Perhaps it's just a few lightweight hackers like me who are being this reckless, and real network admins have things configured correctly.
Is this perception correct? Do I burden the root of .net every time I get a cache miss?
If a nameserver gets a recursive query, it looks into its cache for a possible answer, if found it returns it. Otherwise, it looks for a cached referral to the authoritative nameserver for the queried domain, if found, it queries it, if not found, it queries one of the root nameservers, which will return with a referral to the autoritative nameserver for the domain, that nameserver would then be queried and it will either return an answer or a referrel to another nameserver, so on. This recursion goes on till a positive or negative answer is found.
Look at the following: (I have added my comments with //)
floyd:~ # nslookup Default Server: ns1.nadmm.com Address: 216.112.234.66
// Start with one of the root nameservers
server a.root-servers.net
Default Server: a.root-servers.net Address: 198.41.0.4
// Query for the A record of the host
floyd.nadmm.com.
Server: a.root-servers.net Address: 198.41.0.4
// Root nameserver returns a referral to all the // authoritative nameservers it knows for nadmm.com. domain Name: floyd.nadmm.com Served by: - NAMESERVER.CONCENTRIC.NET 207.155.183.72 NADMM.COM - NAMESERVER3.CONCENTRIC.NET 206.173.119.72 NADMM.COM - NS.NADMM.COM 216.112.234.68 NADMM.COM - NS1.NADMM.COM 216.112.234.66 NADMM.COM
// Use one of the referred nameservers
server nameserver.concentric.net
Default Server: nameserver.concentric.net Address: 207.155.183.72
// Now query it for an answer
floyd.nadmm.com.
Server: nameserver.concentric.net Address: 207.155.183.72
// Got a positive answer. Stop. Name: floyd.nadmm.com Address: 216.112.234.66
// Now query for a bad hostname
aa.nadmm.com.
Server: nameserver.concentric.net Address: 207.155.183.72
// Got a negative answer. Stop. *** nameserver.concentric.net can't find aa.nadmm.com.: Non-existent host/domain
Hope this helps you :)
Cheers, -- Nadeem Hasan nhasan@nadmm.com http://www.nadmm.com/
Nadeem, This does add to my understanding. Thanks. Unfortunately as my knowledge grows linearly with time (at best,) my ignorance grows exponentially :-/ I think this my be a recursive process. The key word in what you said above is *recursive*. As I read the BIND 9 Reference, *recursive* has a special meaning. It means using forwarders rather than default *iterative*. This is not clear to me. It is simply my best guess as to the intent of the author. This is my current understanding of how things work (which is changing as I write): * Client student.physics.university.edu queries local name server dns.physics.university.edu for portal.suse.com ** this is almost certainly a "recursive" query. *** The recursive nature of the query from student tells dns.physics.university.edu that student will only understand an answer containing the IP Address of portal.suse.com or a "can't find it" message. * dns.physics.university.edu checks its records and cache for the result and doesn't find it. ** It may, however, find the IP Address for a name server "closer" to the answer in its cache thus allowing it to skip the intermediate parts of the lookup process, jumping directly to the "closer" name server. We'll assume this didn't happen this time around. * dns.physics.university.edu will behave in one of the following two ways: ** dns.physics.university.edu has a forwarders list so it asks its forwarders to look up the answer on its behalf. This means dns.physics sends the same kind of query to its forwarders that student sent to dns.physics. The forwarder(s) will only return the IP Address of portal.suse.com or a "can't find it" message. They will not return a referal. *** This possible branch continues until an answer (positive or negative) is found, or a sever that does not have a forwarders list is queried. In the latter case that server acts in the same manner described in the second ** of this section. ** dns.physics.university.edu does _not_ have a forwarders list so it will query a root name server of the .com domain for the answer. (assuming no cached information.) *** The address of the root name server of .com is provided to dns.physics.university.edu by the root.hints file located on its local file system. * The root name server of .com returns either the IP Address of portal.suse.com or the address of a name server "closer" to portal.suse.com. (perhaps the address of something similar to dns.suse.com) ** if the actual IP Address is found, it is sent back to the first name server performing an iterative query (as opposed to a recursive query.) *** From that point in time the answer is simply returned down the stack of open queries until it reaches student. ** if the root sever does not have an answer in its cache nor in its zone it will return either the address of a "closer" name sever or a "don't know how to find something in that name space" message. I guess the algorithm is something like the following: /* please note that I have "over killed" many booleans in what follows. */ /* all queries start here */ handle_query(requested_name, query_type, forward, forwarders) { if (name_is_in_zone(requested_name) { return address_from_db(requested_name); // I think this could also be a "blackhole" negative } else if (name_is_in_cache(requested_name)) { if (address_found_in_cache(requested_name)) { return address_from_cache(requested_name); else { return negative; } //else } else if (query_type == recursive) { return resolve(requested_name, forward, forwarders); // the address or negative, no referal } else if (query_type == iterative) { return iterative_query(requested_name, forward, forwarders); // the IP Address, a negative or a referal } // else if } // handle_query /* must return an IP Address or a negative, no referal */ resolve(requested_name, forward, forwarders) { if (forwarders == null) { return iterative_resolve(requested_name, forward); else if (is_list_of_ip_addresses(forwarders)) { for (i = 0; i < forwarders.length; i++) { result = iterative_resolve(forwarders[i]); if (result != null) { return result; // I don't know what it would do with an explicit negative } // if } // for if (forward == only && result == null) { return negative; // didn't find it and I don't handle referals } else if (forward == first && result == null) { //default behavior return iterative_resolve(requested_name, forward, forwarders); // this is what we would have already done if forwarders == null; } // else if } // else if } // reslove /* Must return an IP Address or a negative, no referal, so keep checking till you can do this. */ iterative_resolve (requested_name, forward, forwarders) { result = iterative_query(requested_name); while (is_referal(result)) { result = iterative_query(requested_name, result); }// while retrun result; //either an address or a negative } // iterative_resolve /* returns the first good result. IP Address, a negative or a referal */ iterative_query(requested_name, start_dns=localhost) { if (name_is_in_cache(requested_name)) { if (address_found_in_cache(requested_name)) { return address_from_cache(requested_name); else { return negative; } //else } else if (start_dns==localhost) { close_dns = check_hash_for_close_dns(requested_name); if (close_dns != null) { return close_dns; else { return get_root_for_domain(requested_name) // user root.hints } // else } else if (is_dns_ip_address(start_dns) { return send_iterative_query(start_dns, requested_name); // address of requested_name || negative || referal } // else if } // iterative_query I'm sure there are holes in this. It may be way off track, but it reflects my current understanding. Steve
participants (4)
-
Chris Reeves
-
Nadeem Hasan
-
Steven T. Hatton
-
Victor R. Cardona