Re: recursion yes/no?
On Wed, Jan 25, 2023 at 10:23:16AM -, David Carvalho wrote: > Will there be any inconvenient setting minimal-responses to no? Having > that default behaviour when using "dig" can be useful. No, it's quite harmless. Minimal-repsonses saves a bit of time when processing a query, but unless your server gets an overwhelming amount of traffic you won't notice it. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: recursion yes/no?
It helps a lot!! I think I understand now. Have a great day! Regards David From: Greg Choules Sent: 25 January 2023 10:34 To: David Carvalho Cc: bind-users@lists.isc.org Subject: Re: recursion yes/no? Hi David. With "minimal-responses", usually I would set it to "no" for a purely authoritative server because resolvers need all the help they can get. But for a purely recursive server I would set it to "yes" because end users don't need (any wouldn't do anything with it anyway) Authority or Additional data. So a hybrid server is a bit stuck between those two settings. However, from 9.16 BIND now has extra choices (as Evan pointed out). To answer your follow up question I would stick with "no-auth-recursive" as this is exactly the scenario it is designed for. "dig" (by default, like all stub clients) will make recursive queries; i.e. RD=1. If your server has "minimal-responses no-auth-recursive;" set (or nothing at all since that's the default) then a vanilla query from dig will *not* receive anything it doesn't need to, just like real users. If you *want* to see all the Authority and Additional data then add "+norecurse" to your dig command, which causes it to set RD=0. Your server is then not being asked to do recursion, so it will just reply with everything (if anything) it has. Hope that helps. Greg On Wed, 25 Jan 2023 at 10:16, David Carvalho mailto:da...@di.ubi.pt> > wrote: Good morning and thank you so much! Now I understand. My servers are not pure authoritative, so I’ll have to keep the recursion enabled. As for the answers in Authority and Additional sections, after setting minimal-responses to no, now I get the usual output when querying. For what I understand, there is no downside in maintaining this setting, right? Thank you! Kind regards. David From: Greg Choules mailto:gregchoules%2bbindus...@googlemail.com> > Sent: 24 January 2023 18:12 To: David Carvalho mailto:da...@di.ubi.pt> > Cc: bind-users@lists.isc.org <mailto:bind-users@lists.isc.org> Subject: Re: recursion yes/no? Hi David. "recursion yes;" tells named that it can (if it has to) make queries to other places if it needs more information in order to answer a client query. Pure authoritative servers shouldn't need it and should have "recursion no;". So the first question is, do your servers make queries out to other places? If so, recursion must be enabled. Secondly, do you have "minimal-responses" configured on either/both servers? If so, what is it set to? There were changes in 9.16 so maybe these explain your observations. Cheers, Greg On Tue, 24 Jan 2023 at 16:49, David Carvalho via bind-users mailto:bind-users@lists.isc.org> > wrote: Hello. I hope someone could help to understand the following. I have “my.domain.pt <http://my.domain.pt> ” and a master and slave server for the “my” part. I have been using “recursion yes” in both named.conf, as I want them to be both authoritative and cache for my clients. Last week I migrated my slave DNS server to version 9.16 and only today, after having issues with the primary server migration, I realized that for most queries, my slave DNS does not answer the “ADDITIONAL SECTION” unless I specify “+norec” with the dig command. My named.conf files only differ in IPs and “master/slave” setting. My questions: Should I use recursion on both? (Bear in mind that I also want them to provide chache to clients) Why do I need “dig +norec” to get the exact output on my slave server? Kind regards David -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org <mailto:bind-users@lists.isc.org> https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursion yes/no?
Hi David. With "minimal-responses", usually I would set it to "no" for a purely authoritative server because resolvers need all the help they can get. But for a purely recursive server I would set it to "yes" because end users don't need (any wouldn't do anything with it anyway) Authority or Additional data. So a hybrid server is a bit stuck between those two settings. However, from 9.16 BIND now has extra choices (as Evan pointed out). To answer your follow up question I would stick with "no-auth-recursive" as this is exactly the scenario it is designed for. "dig" (by default, like all stub clients) will make recursive queries; i.e. RD=1. If your server has "minimal-responses no-auth-recursive;" set (or nothing at all since that's the default) then a vanilla query from dig will *not* receive anything it doesn't need to, just like real users. If you *want* to see all the Authority and Additional data then add "+norecurse" to your dig command, which causes it to set RD=0. Your server is then not being asked to do recursion, so it will just reply with everything (if anything) it has. Hope that helps. Greg On Wed, 25 Jan 2023 at 10:16, David Carvalho wrote: > Good morning and thank you so much! > > Now I understand. My servers are not pure authoritative, so I’ll have to > keep the recursion enabled. > > As for the answers in Authority and Additional sections, after setting > minimal-responses to no, now I get the usual output when querying. > > For what I understand, there is no downside in maintaining this setting, > right? > > Thank you! > > > > Kind regards. > > David > > > > > > *From:* Greg Choules > *Sent:* 24 January 2023 18:12 > *To:* David Carvalho > *Cc:* bind-users@lists.isc.org > *Subject:* Re: recursion yes/no? > > > > Hi David. > > "recursion yes;" tells named that it can (if it has to) make queries to > other places if it needs more information in order to answer a client > query. Pure authoritative servers shouldn't need it and should have > "recursion no;". So the first question is, do your servers make queries out > to other places? If so, recursion must be enabled. > > Secondly, do you have "minimal-responses" configured on either/both > servers? If so, what is it set to? There were changes in 9.16 so maybe > these explain your observations. > > > > Cheers, Greg > > > > On Tue, 24 Jan 2023 at 16:49, David Carvalho via bind-users < > bind-users@lists.isc.org> wrote: > > Hello. > > I hope someone could help to understand the following. > > I have “my.domain.pt” and a master and slave server for the “my” part. I > have been using “recursion yes” in both named.conf, as I want them to be > both authoritative and cache for my clients. > > Last week I migrated my slave DNS server to version 9.16 and only today, > after having issues with the primary server migration, I realized that for > most queries, my slave DNS does not answer the “ADDITIONAL SECTION” unless > I specify “+norec” with the dig command. > > > > My named.conf files only differ in IPs and “master/slave” setting. > > > > My questions: > > Should I use recursion on both? (Bear in mind that I also want them to > provide chache to clients) > > Why do I need “dig +norec” to get the exact output on my slave server? > > > > Kind regards > > David > > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > > -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: recursion yes/no?
Hello and thank you so much. " no-auth-recursive is meant for use in mixed-mode servers that handle both authoritative and recursive queries" - So I guess the default setting is intended for my purpose. Will there be any inconvenient setting minimal-responses to no? Having that default behaviour when using "dig" can be useful. Thank you! Kind regards. David Os melhores cumprimentos David Alexandre M. de Carvalho ═══ Especialista de Informática Departamento de Informática Universidade da Beira Interior -Original Message- From: Evan Hunt Sent: 24 January 2023 20:12 To: David Carvalho Cc: bind-users@lists.isc.org Subject: Re: recursion yes/no? On Tue, Jan 24, 2023 at 04:48:34PM -, David Carvalho via bind-users wrote: > Hello. > > I hope someone could help to understand the following. > > I have "my.domain.pt" and a master and slave server for the "my" part. > I have been using "recursion yes" in both named.conf, as I want them > to be both authoritative and cache for my clients. > > Last week I migrated my slave DNS server to version 9.16 and only > today, after having issues with the primary server migration, I > realized that for most queries, my slave DNS does not answer the > "ADDITIONAL SECTION" unless I specify "+norec" with the dig command. You didn't mention what version you were upgrading from, but I guess 9.11, because the default setting of "minimal-responses" was changed in 9.12. It used to default to "no", but it now defaults to "no-auth-recursive". From the ARM: minimal-responses takes one of four values: - no: the server is as complete as possible when generating responses. - yes: the server only adds records to the authority and additional sections when such records are required by the DNS protocol (for example, when returning delegations or negative responses). This provides the best server performance but may result in more client queries. - no-auth: the server omits records from the authority section except when they are required, but it may still add records to the additional section. - no-auth-recursive: the same as no-auth when recursion is requested in the query (RD=1), or the same as no if recursion is not requested. no-auth and no-auth-recursive are useful when answering stub clients, which usually ignore the authority section. no-auth-recursive is meant for use in mixed-mode servers that handle both authoritative and recursive queries. So when recursion is requested in the query, the server omits the NS records from the authority section, and if there's no NS records then there won't need to be corresponding A or records in the additional section. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: recursion yes/no?
Good morning and thank you so much! Now I understand. My servers are not pure authoritative, so I’ll have to keep the recursion enabled. As for the answers in Authority and Additional sections, after setting minimal-responses to no, now I get the usual output when querying. For what I understand, there is no downside in maintaining this setting, right? Thank you! Kind regards. David From: Greg Choules Sent: 24 January 2023 18:12 To: David Carvalho Cc: bind-users@lists.isc.org Subject: Re: recursion yes/no? Hi David. "recursion yes;" tells named that it can (if it has to) make queries to other places if it needs more information in order to answer a client query. Pure authoritative servers shouldn't need it and should have "recursion no;". So the first question is, do your servers make queries out to other places? If so, recursion must be enabled. Secondly, do you have "minimal-responses" configured on either/both servers? If so, what is it set to? There were changes in 9.16 so maybe these explain your observations. Cheers, Greg On Tue, 24 Jan 2023 at 16:49, David Carvalho via bind-users mailto:bind-users@lists.isc.org> > wrote: Hello. I hope someone could help to understand the following. I have “my.domain.pt <http://my.domain.pt> ” and a master and slave server for the “my” part. I have been using “recursion yes” in both named.conf, as I want them to be both authoritative and cache for my clients. Last week I migrated my slave DNS server to version 9.16 and only today, after having issues with the primary server migration, I realized that for most queries, my slave DNS does not answer the “ADDITIONAL SECTION” unless I specify “+norec” with the dig command. My named.conf files only differ in IPs and “master/slave” setting. My questions: Should I use recursion on both? (Bear in mind that I also want them to provide chache to clients) Why do I need “dig +norec” to get the exact output on my slave server? Kind regards David -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org <mailto:bind-users@lists.isc.org> https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursion yes/no?
On Tue, Jan 24, 2023 at 04:48:34PM -, David Carvalho via bind-users wrote: > Hello. > > I hope someone could help to understand the following. > > I have "my.domain.pt" and a master and slave server for the "my" part. I > have been using "recursion yes" in both named.conf, as I want them to be > both authoritative and cache for my clients. > > Last week I migrated my slave DNS server to version 9.16 and only today, > after having issues with the primary server migration, I realized that for > most queries, my slave DNS does not answer the "ADDITIONAL SECTION" unless I > specify "+norec" with the dig command. You didn't mention what version you were upgrading from, but I guess 9.11, because the default setting of "minimal-responses" was changed in 9.12. It used to default to "no", but it now defaults to "no-auth-recursive". From the ARM: minimal-responses takes one of four values: - no: the server is as complete as possible when generating responses. - yes: the server only adds records to the authority and additional sections when such records are required by the DNS protocol (for example, when returning delegations or negative responses). This provides the best server performance but may result in more client queries. - no-auth: the server omits records from the authority section except when they are required, but it may still add records to the additional section. - no-auth-recursive: the same as no-auth when recursion is requested in the query (RD=1), or the same as no if recursion is not requested. no-auth and no-auth-recursive are useful when answering stub clients, which usually ignore the authority section. no-auth-recursive is meant for use in mixed-mode servers that handle both authoritative and recursive queries. So when recursion is requested in the query, the server omits the NS records from the authority section, and if there's no NS records then there won't need to be corresponding A or records in the additional section. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursion yes/no?
Hi David. "recursion yes;" tells named that it can (if it has to) make queries to other places if it needs more information in order to answer a client query. Pure authoritative servers shouldn't need it and should have "recursion no;". So the first question is, do your servers make queries out to other places? If so, recursion must be enabled. Secondly, do you have "minimal-responses" configured on either/both servers? If so, what is it set to? There were changes in 9.16 so maybe these explain your observations. Cheers, Greg On Tue, 24 Jan 2023 at 16:49, David Carvalho via bind-users < bind-users@lists.isc.org> wrote: > Hello. > > I hope someone could help to understand the following. > > I have “my.domain.pt” and a master and slave server for the “my” part. I > have been using “recursion yes” in both named.conf, as I want them to be > both authoritative and cache for my clients. > > Last week I migrated my slave DNS server to version 9.16 and only today, > after having issues with the primary server migration, I realized that for > most queries, my slave DNS does not answer the “ADDITIONAL SECTION” unless > I specify “+norec” with the dig command. > > > > My named.conf files only differ in IPs and “master/slave” setting. > > > > My questions: > > Should I use recursion on both? (Bear in mind that I also want them to > provide chache to clients) > > Why do I need “dig +norec” to get the exact output on my slave server? > > > > Kind regards > > David > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Recursion Question
Define an explicit forward-zone on the recursive server for private.dns.com In the zone definition, put the addresses of the servers which can answer for private.dns.com. -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska On 12/20/2021 11:05 AM, LeBlanc, Daniel James via bind-users wrote: The Recursive DNS server is unaware of this domain and sends the request to its Forwarding DNS ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Recursion setting for bind9
Hi Sonal,
I do not think forwarders specified in zone work as fixed order. It
would not work by first contacting 127.0.0.1, if that did not deliver
the answer, try 199.165.24.21. Forwarders in bind are configured as a
set, not ordered list. It would use whatever just gives faster replies.
I am afraid BIND does not work similar to /etc/resolv.conf, where such
approach might work. It expects authoritative server for the zone can be
found and produces the answer. Which is only cached by named. It expects
any configured forwarder would get the same answer, just how fast it is
would be measured.
I think more correct would be setting more specific zones of e164.arpa
configured with only one forwarder.
Regards,
Petr
On 9/29/21 09:21, Sonal Pahuja wrote:
>
> Hi All,
>
>
>
> Is there any option to set recursion =1 in named.conf file for the
> zone. I just want bind9 to do recursion only once.
>
> If bind9 receives answer from one of the forwarders then it should not
> do recursion (forward query) to any other forwarder IP.
>
>
>
> Below is my snapshot of my named.conf file
>
>
>
> options {
>
> listen-on port 53 { any; };
>
> listen-on-v6 port 53 { any; };
>
> directory "/var/named";
>
> dump-file "/var/named/data/cache_dump.db";
>
> statistics-file "/var/named/data/named.stats";
>
> memstatistics-file "/var/named/data/named_mem_stats.txt";
>
> allow-query { localhost; !blocked; allowed; };
>
> // allow-query { localhost; };
>
> recursion yes;
>
> zone-statistics yes;
>
> dnssec-enable no;
>
> dnssec-validation no;
>
> auth-nxdomain no;
>
> // additional-from-auth no;
>
> // additional-from-cache no;
>
> /* Path to ISC DLV key */
>
> bindkeys-file "/etc/named.iscdlv.key";
>
>
>
> managed-keys-directory "/var/named/dynamic";
>
>
>
>
>
> };
>
> zone "e164.arpa" IN {
>
> type forward ;
>
> forwarders { 127.0.0.1 port 49153; 199.165.24.21 port 49153; };
>
> forward only;
>
> };
>
>
>
> Regards,
>
> Sonal
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support subscriptions.
> Contact us at https://www.isc.org/contact/ for more information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Recursion setting for bind9
Maybe a little confused here, but BIND won’t try another server if it gets
an answer. It will only try another forwarder if the query fails.
On Wed, Sep 29, 2021 at 12:21 AM Sonal Pahuja
wrote:
> Hi All,
>
>
>
> Is there any option to set recursion =1 in named.conf file for the zone. I
> just want bind9 to do recursion only once.
>
> If bind9 receives answer from one of the forwarders then it should not do
> recursion (forward query) to any other forwarder IP.
>
>
>
> Below is my snapshot of my named.conf file
>
>
>
> options {
>
> listen-on port 53 { any; };
>
> listen-on-v6 port 53 { any; };
>
> directory "/var/named";
>
> dump-file "/var/named/data/cache_dump.db";
>
> statistics-file "/var/named/data/named.stats";
>
> memstatistics-file "/var/named/data/named_mem_stats.txt";
>
> allow-query { localhost; !blocked; allowed; };
>
> // allow-query { localhost; };
>
> recursion yes;
>
> zone-statisticsyes;
>
> dnssec-enable no;
>
> dnssec-validation no;
>
> auth-nxdomain no;
>
> // additional-from-auth no;
>
> // additional-from-cache no;
>
> /* Path to ISC DLV key */
>
> bindkeys-file "/etc/named.iscdlv.key";
>
>
>
> managed-keys-directory "/var/named/dynamic";
>
>
>
>
>
> };
>
> zone "e164.arpa" IN {
>
> type forward ;
>
> forwarders { 127.0.0.1 port 49153; 199.165.24.21 port 49153; };
>
> forward only;
>
> };
>
>
>
> Regards,
>
> Sonal
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Recursion issue
On Mar 28, 2013, at 7:56 AM, Manson, John wrote: My external authoritative dns does not allow recursion. We have vanity names like speaker.gov. When we add an entry like: www.speaker.gov CNAMEwww.house.gov it fails because of the recursion statement even though the external dns is authoritative for house.gov. Anyone know of a way to modify the recursion behavior since house.gov is already in the outhouse-view along with the vanity .gov names.? Currently we have to use A records with the www.house.gov IP. Web staff and others would like to see the House server name displayed in the browser url bar and in dig results. If you want the browser URL bar to change from what the user typed to www.house.gov, you have to use an HTTP redirect. You cannot do that with DNS. Other than that issue, what part of your current environment is not working? In your public data, I see: www.speaker.gov.300 IN CNAME wc.house.gov.edgekey.net. wc.house.gov.edgekey.net. 17789 IN CNAME e4776.g.akamaiedge.net. e4776.g.akamaiedge.net. 20 IN A 184.26.83.91 Chris Buxton BlueCat Networks ___ 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
RE: Recursion issue
From the internet: Answer records nameclass typedatatime to live test.gopleader.gov IN CNAME testwww.house.gov Testwww from the internet: Answer records nameclass typedatatime to live testwww.house.gov IN A 12.13.14.15 900s(00:15:00) So the first lookup does not fully resolve due to recursion. Does this help? -Original Message- From: Chris Buxton [mailto:cli...@buxtonfamily.us] Sent: Thursday, March 28, 2013 11:13 AM To: Manson, John Cc: bind-users@lists.isc.org Subject: Re: Recursion issue On Mar 28, 2013, at 7:56 AM, Manson, John wrote: My external authoritative dns does not allow recursion. We have vanity names like speaker.gov. When we add an entry like: www.speaker.gov CNAMEwww.house.gov it fails because of the recursion statement even though the external dns is authoritative for house.gov. Anyone know of a way to modify the recursion behavior since house.gov is already in the outhouse-view along with the vanity .gov names.? Currently we have to use A records with the www.house.gov IP. Web staff and others would like to see the House server name displayed in the browser url bar and in dig results. If you want the browser URL bar to change from what the user typed to www.house.gov, you have to use an HTTP redirect. You cannot do that with DNS. Other than that issue, what part of your current environment is not working? In your public data, I see: www.speaker.gov.300 IN CNAME wc.house.gov.edgekey.net. wc.house.gov.edgekey.net. 17789 IN CNAME e4776.g.akamaiedge.net. e4776.g.akamaiedge.net. 20 IN A 184.26.83.91 Chris Buxton BlueCat Networks ___ 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
Re: Recursion issue
On Mar 28, 2013, at 8:27 AM, Manson, John wrote: From the internet: Answer records name class typedatatime to live test.gopleader.govIN CNAME testwww.house.gov Testwww from the internet: Answer records name class typedatatime to live testwww.house.gov IN A 12.13.14.15 900s(00:15:00) So the first lookup does not fully resolve due to recursion. Does this help? Yes it does. It just doesn't all get answered from the one zone. Both of your public servers, chyron and mercury, contain both zones. A non-recursive query to either of them gets both records in an authoritative answer. $ dig test.gopleader.gov +norec @mercury.house.gov ; DiG 9.7.6-P1 test.gopleader.gov +norec @mercury.house.gov ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 26756 ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;test.gopleader.gov.IN A ;; ANSWER SECTION: test.gopleader.gov. 300 IN CNAME testwww.house.gov. testwww.house.gov. 900 IN A 12.13.14.15 ;; Query time: 100 msec ;; SERVER: 143.231.1.67#53(143.231.1.67) ;; WHEN: Thu Mar 28 08:45:23 2013 ;; MSG SIZE rcvd: 80 There is no need to configure recursion on your external authoritative name servers. Other name servers will not query them recursively anyway. I continue to fail to see the problem that you're trying to solve. Chris Buxton BlueCat Networks ___ 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
RE: Recursion issue
Why do the 2 web-based test sites that I use fail? Hostnames or IP addresses: Type: Options: Show command Colorize output Stats Trace Short No recursive Only first nameserver Compare output Nameservers: Resolver: All Authoritative NIC Specify myself: test.gopleader@mercury.house.gov: test.gopleader.gov. 300 IN CNAME testwww.house.gov. -Original Message- From: Chris Buxton [mailto:cli...@buxtonfamily.us] Sent: Thursday, March 28, 2013 11:49 AM To: Manson, John Cc: bind-users@lists.isc.org Subject: Re: Recursion issue On Mar 28, 2013, at 8:27 AM, Manson, John wrote: From the internet: Answer records name class typedatatime to live test.gopleader.govIN CNAME testwww.house.gov Testwww from the internet: Answer records name class typedatatime to live testwww.house.gov IN A 12.13.14.15 900s(00:15:00) So the first lookup does not fully resolve due to recursion. Does this help? Yes it does. It just doesn't all get answered from the one zone. Both of your public servers, chyron and mercury, contain both zones. A non-recursive query to either of them gets both records in an authoritative answer. $ dig test.gopleader.gov +norec @mercury.house.gov ; DiG 9.7.6-P1 test.gopleader.gov +norec @mercury.house.gov ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 26756 ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;test.gopleader.gov.IN A ;; ANSWER SECTION: test.gopleader.gov. 300 IN CNAME testwww.house.gov. testwww.house.gov. 900 IN A 12.13.14.15 ;; Query time: 100 msec ;; SERVER: 143.231.1.67#53(143.231.1.67) ;; WHEN: Thu Mar 28 08:45:23 2013 ;; MSG SIZE rcvd: 80 There is no need to configure recursion on your external authoritative name servers. Other name servers will not query them recursively anyway. I continue to fail to see the problem that you're trying to solve. Chris Buxton BlueCat Networks ___ 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
RE: Recursion issue
I disagree with your statement about recursion. What stops an authoritative server from doing recursion if you do not have the recursion statement? I guess the bind default is recursion yes. -Original Message- From: Chris Buxton [mailto:cli...@buxtonfamily.us] Sent: Thursday, March 28, 2013 11:49 AM To: Manson, John Cc: bind-users@lists.isc.org Subject: Re: Recursion issue On Mar 28, 2013, at 8:27 AM, Manson, John wrote: From the internet: Answer records name class typedatatime to live test.gopleader.govIN CNAME testwww.house.gov Testwww from the internet: Answer records name class typedatatime to live testwww.house.gov IN A 12.13.14.15 900s(00:15:00) So the first lookup does not fully resolve due to recursion. Does this help? Yes it does. It just doesn't all get answered from the one zone. Both of your public servers, chyron and mercury, contain both zones. A non-recursive query to either of them gets both records in an authoritative answer. $ dig test.gopleader.gov +norec @mercury.house.gov ; DiG 9.7.6-P1 test.gopleader.gov +norec @mercury.house.gov ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 26756 ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;test.gopleader.gov.IN A ;; ANSWER SECTION: test.gopleader.gov. 300 IN CNAME testwww.house.gov. testwww.house.gov. 900 IN A 12.13.14.15 ;; Query time: 100 msec ;; SERVER: 143.231.1.67#53(143.231.1.67) ;; WHEN: Thu Mar 28 08:45:23 2013 ;; MSG SIZE rcvd: 80 There is no need to configure recursion on your external authoritative name servers. Other name servers will not query them recursively anyway. I continue to fail to see the problem that you're trying to solve. Chris Buxton BlueCat Networks ___ 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
Re: Recursion issue
On 28.03.13 16:05, Manson, John wrote: I disagree with your statement about recursion. What stops an authoritative server from doing recursion if you do not have the recursion statement? I guess the bind default is recursion yes. if your server does not allow recursion, it will still answer the authoritative data. You have said you do not have recursion allowed, why do you expect it to be allowed now? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease ___ 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
Re: Recursion issue
On Mar 28, 2013, at 9:05 AM, Manson, John wrote: I disagree with your statement about recursion. What stops an authoritative server from doing recursion if you do not have the recursion statement? I guess the bind default is recursion yes. OK, bad choice of words on my part. I did not mean to say that you should not set any configuration options to disable recursion, because as you said, it is on by default (but restricted, by default, to localnets and localhost). What I meant was that there is no reason to permit recursive queries to your authoritative servers. Therefore, I would recommend turning it off using 'recursion no;' in your options or view statement. Chris Buxton BlueCat Networks ___ 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
RE: Recursion issue
Maybe my understanding of how bind works is faulty. I thought bind would do the leg work to get an IP. Especially when it is authoritative for CNAME domain. Even a dig on mercury gives the same 'no IP' result. Sorry for the bother. -Original Message- From: Chris Buxton [mailto:cli...@buxtonfamily.us] Sent: Thursday, March 28, 2013 12:57 PM To: Manson, John Cc: bind-users@lists.isc.org Subject: Re: Recursion issue On Mar 28, 2013, at 9:05 AM, Manson, John wrote: I disagree with your statement about recursion. What stops an authoritative server from doing recursion if you do not have the recursion statement? I guess the bind default is recursion yes. OK, bad choice of words on my part. I did not mean to say that you should not set any configuration options to disable recursion, because as you said, it is on by default (but restricted, by default, to localnets and localhost). What I meant was that there is no reason to permit recursive queries to your authoritative servers. Therefore, I would recommend turning it off using 'recursion no;' in your options or view statement. Chris Buxton BlueCat Networks ___ 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
Re: Recursion issue
On 28.03.13 17:09, Manson, John wrote: Maybe my understanding of how bind works is faulty. I thought bind would do the leg work to get an IP. Especially when it is authoritative for CNAME domain. Even a dig on mercury gives the same 'no IP' result. Sorry for the bother. I got the same result as Chris. Please show us how you do the dig. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759 ___ 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
Re: Recursion Issue
On Mar 28, 2013, at 10:51 AM, Manson, John wrote: http://www.digwebinterface.com/? Is one of the internet sites I use. http://www.digwebinterface.com/?hostnames=test.gopleader.govtype=Ashowcommand=oncolorize=onstats=onnorecursive=onuseresolver=8.8.4.4ns=authnameservers= __ test.gopleader@chyron.house.gov.: dig A +norec test.gopleader.gov. @chyron.house.gov. ; DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.1 A +norec test.gopleader.gov. @chyron.house.gov. ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 48126 ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;test.gopleader.gov.IN A ;; ANSWER SECTION: test.gopleader.gov. 300 IN CNAME www.house.gov. www.house.gov. 900 IN CNAME house.gov.edgesuite.net. ;; Query time: 26 msec ;; SERVER: 143.228.129.38#53(143.228.129.38) ;; WHEN: Thu Mar 28 18:55:49 2013 ;; MSG SIZE rcvd: 97 test.gopleader@mercury.house.gov.: dig A +norec test.gopleader.gov. @mercury.house.gov. ; DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.1 A +norec test.gopleader.gov. @mercury.house.gov. ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 63565 ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;test.gopleader.gov.IN A ;; ANSWER SECTION: test.gopleader.gov. 300 IN CNAME www.house.gov. www.house.gov. 900 IN CNAME house.gov.edgesuite.net. ;; Query time: 23 msec ;; SERVER: 143.231.1.67#53(143.231.1.67) ;; WHEN: Thu Mar 28 18:55:49 2013 ;; MSG SIZE rcvd: 97 __ You've changed the record test.gopleader.gov since last I looked at it -- it's now going to Akamai. The result shown here shows what's called a dangling CNAME -- your CNAME record, pointing to an outside resource. A resolving name server (one with recursion enabled) will then follow that to Akamai, giving this result: test.gopleader.gov. 300 IN CNAME www.house.gov. www.house.gov. 552 IN CNAME house.gov.edgesuite.net. house.gov.edgesuite.net. 12640 IN CNAME a1164.g.akamai.net. a1164.g.akamai.net. 19 IN A 165.254.47.115 a1164.g.akamai.net. 19 IN A 165.254.47.112 Everything is as it should be. Chris Buxton BlueCat Networks ___ 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
Re: recursion and forwarding
You're getting caught up in semantics. The forwarding of the query *is*
recursive resolution. It's not a separate operation.
- Kevin
On 1/12/2012 1:15 PM, Adamiec, Lawrence wrote:
Hi,
I am running one master server and one slave server with BIND
9.6.1-P3. The global options section on both servers are identical.
In the options section I have,
allow-recursion { ck_domain; };
forwarders { 216.47.128.11; 216.47.128.12; 216.47.143.90; };
The ck_domain ACL contains internal IPs only.
The documentation I have read states that forwarders will forward a
client's query if the answer is not in the server's cache and the
server does not know the answer.
So when does recursion occur, before the query is forwarded or never?
I thought recursion was supposed to go looking for the answers. If
recursion does not return an answer then does the query get forwarded?
Larry Adamiec
UNIX Mgr.
312-906-5301
___
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
___
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
RE: recursion and forwarding
This is a very good explanation. Thank you for your help. Larry -Original Message- From: bind-users-bounces+ladamiec=kentlaw@lists.isc.org [mailto:bind-users- bounces+ladamiec=kentlaw@lists.isc.org] On Behalf Of Phil Mayers Sent: Thursday, January 12, 2012 12:35 To: bind-users@lists.isc.org Subject: Re: recursion and forwarding On 01/12/2012 06:15 PM, Adamiec, Lawrence wrote: So when does recursion occur, before the query is forwarded or never? I thought recursion was supposed to go looking for the answers. If recursion does not return an answer then does the query get forwarded? forwarders IIRC works as follows: 1. If query answer in cache, reply from cache to client, stop 2. Send query to forwarders 3. If reply, add to cache, reply to client, stop 4. No reply: if forward only set, error to client, stop 5. Perform normal recursion That is - it tries cache, then the forwarders, then does recursion itself (unless forward only is set). ___ 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 ___ 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
Re: recursion
Hi Kevin,
I followed your advice and I explicitly added:
recursion yes;
allow-recursion { custnets; };
I'm using MRTG for interface bandwidth monitoring and Smokeping for time
response on queries and all look the same as before. So, so far so good!
Thank you!
Julian
- Original Message -
From: Kevin Darcy k...@chrysler.com
To: bind-users@lists.isc.org
Sent: Wednesday, March 10, 2010 4:54 PM
Subject: Re: recursion
On 3/10/2010 4:45 PM, ic.nssip wrote:
I've got the idea!
So even I have no statement recursion yes, the server is still
recursive as time I dont specify recursion no;
It is going to make no difference if I'll add recursion yes; on
options.
No difference.
Is localnets a term I really need to use?
It's predefined. Read the ARM.
Currently I'm using an ACL defined for acl custnets { x.x.x.x; }; and
allow-query { custnets; };
Should I change the name custnets to localnets?
If they're numerically the same thing, then it would just be a matter of
personal preference. If they're different, then it would depend on one's
implementation requirements whether it's ok to switch one for the other.
We don't have enough information about your implementation requirements to
give a definitive answer one way or the other.
Note that both localnets and localhost can change dynamically, if
network interfaces are brought up and/or taken down.
Is my customized name custnets going to affect recursion in any way if
I use it instead of localnets?
If running BIND 9.4.x or higher, allow-query { custnets; } will affect
one's allow-recursion default if custnets is (or _becomes_, as a result
of interfaces being brought up and/or taken down) in any way numerically
different from { localnets; localhost; }.
(Of course, a query that's REFUSED will never get a chance to recurse, but
one can override a *global* allow-query at the zone level, so it still
makes sense for allow-recursion to cross-inherit from allow-query)
If all of this is confusing, then I would recommend explicitly setting all
of them -- allow-query, allow-query-cache, allow-recursion. Then you don't
need to constantly guess at what is inheriting from where.
-
Kevin
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: recursion
On 3/10/2010 11:37 AM, ic.nssip wrote:
If there is no option recursion yes (or no); specified in
named.conf, is the server still recursive?
Is recursion activated by default if option recursion (yes|no) is
missing in named.conf?
Yes, recursion is activated by default, but who is or is not allowed
to recurse in a default configuration, depends on the version of BIND
you're running. Older versions allow *open* recursion by default. The
default for modern versions of BIND, if none of the following are set:
recursion
allow-recursion
allow-query-cache
allow-query
is to restrict recursion to { localnets; localhost; }.
But there is cross-inheritance and override behavior among the options
mentioned above. All of this is explained in the ARM.
- Kevin
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: recursion
ic.nssip wrote:
If there is no option recursion yes (or no); specified in named.conf,
is the server still recursive?
Is recursion activated by default if option recursion (yes|no) is
missing in named.conf?
In modern BIND, allow-recursion defaults to:
{ localhost; localnets; };
so, yes it is enabled and no, it's not available to everyone.
AlanC
signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: recursion
Modern being?
-Original Message-
From: bind-users-bounces+jlightner=water@lists.isc.org
[mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf
Of Alan Clegg
Sent: Wednesday, March 10, 2010 2:25 PM
To: bind-users@lists.isc.org
Subject: Re: recursion
ic.nssip wrote:
If there is no option recursion yes (or no); specified in
named.conf,
is the server still recursive?
Is recursion activated by default if option recursion (yes|no) is
missing in named.conf?
In modern BIND, allow-recursion defaults to:
{ localhost; localnets; };
so, yes it is enabled and no, it's not available to everyone.
AlanC
Proud partner. Susan G. Komen for the Cure.
Please consider our environment before printing this e-mail or attachments.
--
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential
information and is for the sole use of the intended recipient(s). If you are
not the intended recipient, any disclosure, copying, distribution, or use of
the contents of this information is prohibited and may be unlawful. If you have
received this electronic transmission in error, please reply immediately to the
sender that you have received the message in error, and delete it. Thank you.
--
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: recursion
Lightner, Jeff wrote: Modern being? According to CHANGES file: --- 9.5.0a6 released --- 2206. [security] allow-query-cache and allow-recursion now cross inherit from each other. If allow-query-cache is not set in named.conf then allow-recursion is used if set, otherwise allow-query is used if set, otherwise the default (localnets; localhost;) is used. If allow-recursion is not set in named.conf then allow-query-cache is used if set, otherwise allow-query is used if set, otherwise the default (localnets; localhost;) is used. AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursion
Lightner, Jeff wrote: Modern being? Actually In the 9.4 CHANGES file I find: --- 9.4.0a4 released --- [...] 2006. [security]Allow-query-cache and allow-recursion now default to the builtin acls localnets and localhost. This is being done to make caching servers less attractive as reflective amplifying targets for spoofed traffic. This still leave authoritative servers exposed. The best fix is for full BCP 38 deployment to remove spoofed traffic. So, modern (in this case) is any currently supported version of BIND. 9.4, 9.5, 9.6, 9.7 AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursion
I've got the idea!
So even I have no statement recursion yes, the server is still recursive
as time I dont specify recursion no;
It is going to make no difference if I'll add recursion yes; on options.
Is localnets a term I really need to use?
Currently I'm using an ACL defined for acl custnets { x.x.x.x; }; and
allow-query { custnets; };
Should I change the name custnets to localnets?
Is my customized name custnets going to affect recursion in any way if I
use it instead of localnets?
It sounds to me that is fine using custnets too.
Thank you!
Julian
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: recursion
On 3/10/2010 4:45 PM, ic.nssip wrote:
I've got the idea!
So even I have no statement recursion yes, the server is still
recursive as time I dont specify recursion no;
It is going to make no difference if I'll add recursion yes; on
options.
No difference.
Is localnets a term I really need to use?
It's predefined. Read the ARM.
Currently I'm using an ACL defined for acl custnets { x.x.x.x; };
and allow-query { custnets; };
Should I change the name custnets to localnets?
If they're numerically the same thing, then it would just be a matter
of personal preference. If they're different, then it would depend on
one's implementation requirements whether it's ok to switch one for the
other. We don't have enough information about your implementation
requirements to give a definitive answer one way or the other.
Note that both localnets and localhost can change dynamically, if
network interfaces are brought up and/or taken down.
Is my customized name custnets going to affect recursion in any way
if I use it instead of localnets?
If running BIND 9.4.x or higher, allow-query { custnets; } will affect
one's allow-recursion default if custnets is (or _becomes_, as a
result of interfaces being brought up and/or taken down) in any way
numerically different from { localnets; localhost; }.
(Of course, a query that's REFUSED will never get a chance to recurse,
but one can override a *global* allow-query at the zone level, so it
still makes sense for allow-recursion to cross-inherit from allow-query)
If all of this is confusing, then I would recommend explicitly setting
all of them -- allow-query, allow-query-cache, allow-recursion. Then you
don't need to constantly guess at what is inheriting from where.
- Kevin
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: recursion confusion
On Jan 8 2010, Rick Dicaire wrote:
Hi folks, whats the difference between recursion no; and
allow-recursion {none;};
Not a great deal, but recursion no; changes the default for
empty-zones-enable to no, while allow-recursion {none;};
doesn't do that. (Probably there are other niggling things I
have forgotten as well.)
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: recursion on auth-only server
Matus UHLAR - fantomas wrote: I have moved authoritative server to new IP address. I have changed the DNS name pointing to it so the NS would point to the new IP. Now I looked at the traffic and it seems that there are ~4 of 1000 recursive requests sent to it. Are there any known resolvers that can iterate through NS hierarchy, or iterative DNS servers that send resursive requests anywhere? On 02.10.09 18:50, Peter Dambier wrote: I know you can use bind as your local resolver. It does query from the root down until it finds what it is looking for - when you don't use forwarders. I know that too but this particular server isn't designed to be used as recursive and I don't want it to be. dnscache which is part of djbdns does always query from the root down. It never uses forwarders. I don't know for sure if the Authoritative Answer Only bit is set but I guess no. It's RD (recursion desired) flag and my question is if any nameserver is known by sending queries with this flag set. I don't care if they do recursion themselves, but if anyone asks this server with RD flag set, the answer will be venemous. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Remember half the people you know are below average. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursion on auth-only server
In article mailman.674.1254859742.14796.bind-us...@lists.isc.org, Matus UHLAR - fantomas uh...@fantomas.sk wrote: It's RD (recursion desired) flag and my question is if any nameserver is known by sending queries with this flag set. I don't care if they do recursion themselves, but if anyone asks this server with RD flag set, the answer will be venemous. Nameservers should only set the RD flag in the queries they send if they're configured to use forwarders. It should never be sent when they're following the delegation chain themselves. -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursion on auth-only server
Once upon a time, Matus UHLAR - fantomas uh...@fantomas.sk said: I don't care if they do recursion themselves, but if anyone asks this server with RD flag set, the answer will be venemous. You should realize that anybody trying to debug possible DNS issues might issue queries directly to your server with tools like dig, which requests recursion by default. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursion on auth-only server
Matus UHLAR - fantomas wrote: Hello, I have moved authoritative server to new IP address. I have changed the DNS name pointing to it so the NS would point to the new IP. Now I looked at the traffic and it seems that there are ~4 of 1000 recursive requests sent to it. Are there any known resolvers that can iterate through NS hierarchy, or iterative DNS servers that send resursive requests anywhere? I know you can use bind as your local resolver. It does query from the root down until it finds what it is looking for - when you don't use forwarders. dnscache which is part of djbdns does always query from the root down. It never uses forwarders. I don't know for sure if the Authoritative Answer Only bit is set but I guess no. Somebody must resolve. So you will see my ISPs resolver querying you if you don't see my own resolver. With censoring commonplace in europe at least, people with the know do run their own resolvers. You'll see the number increasing. I guess 0.4% is harmless. The number I see looks higher and they do not look for domains I slave. Kind regards Peter -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: pe...@peter-dambier.de http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ULA= fd80:4ce1:c66a::/48 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursion on auth-only server
On Sep 21 2009, Matus UHLAR - fantomas wrote: I have moved authoritative server to new IP address. I have changed the DNS name pointing to it so the NS would point to the new IP. Now I looked at the traffic and it seems that there are ~4 of 1000 recursive requests sent to it. And do you know that this was not the case before the move? Are there any known resolvers that can iterate through NS hierarchy, or iterative DNS servers that send resursive requests anywhere? There are all sorts of reasons, from misconfigured resolvers to manual use of dig (do you always remember to specify +norec when appropriate?). Query logging will help you track them down if you are really concerned. At 0.4%, I wouldn't worry. -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: recursion for reverse/in-addr.arpa zones
On our slave, there are no specific declarations for the 10.131.10 zone, or even 10.131, just 10. On the server we're slaving off of, there would probably be more, but I don't know as I'm not in control of that server/servers. Will reverse lookups by default continue to look for more specific domains, recursing as necessary? If so, how far will it go? I'm slaving an A class, and it went and found a C. If we'd had the B declared, would it have stopped there, or kept going? This behaviour seems odd to me, and I've not been able to find information about this behaviour in the book(s). Merci! Todd. From: Ben Croswell [mailto:ben.crosw...@gmail.com] Sent: Thursday, December 11, 2008 5:15 PM To: Todd Snyder Cc: bind-us...@isc.org Subject: Re: recursion for reverse/in-addr.arpa zones Are there NS records and/or zone forwarding for the 10.131.10.0? If there is the servers will look to the most specfic domain. -- -Ben Croswell On Thu, Dec 11, 2008 at 4:38 PM, Todd Snyder tsny...@rim.com wrote: Good day, We are working on an odd issue. I can provide more detail as necessary, but don't want to fill this email with snips of useless stuff. All IP's/names provided are made up, as they don't matter in this problem as far as I can tell. This is more a functional question than a specific operating question. We have 2 servers acting as a slave for the zone 10.in-addr.arpa. The master(s) for this server are 2 Windows AD servers. Our servers (all bind9.4 of some variety) are doing zone transfers fine, and we're getting whatever is in the zone. We've run in to a couple IP's that when we dig them on these slaves, they are timing out. They are in a specific location, which we have determined are firewalled differently. For example, we are doing a dig for 10.131.10.1 against these 2 different locations. In one location, we get an answer quickly. In the other, it times out. The problem in our case is that in one location, the slave we're querying can't reach anything but the masters. What we've figured out is that the 10.in-addr.arpa zone doesn't contain EVERY 10. address we thought, but is missing some. In this case, our slaved zone doesn't have 10.131.10.1. But, instead of the slave server (which should be authortative) returning an I don't know error, it appears to be doing a recusive query. Against what, we're not 100% sure of yet. Well, we know which server, because DIG tells us, but we aren't sure why that one. When I look at the 10.in-addr.arpa zone, there are approximately 20 NS records for other AD servers. My speculation is that the slave we're querying is recusively looking to one of the servers returned in the additional section? This behaviour seems odd to us, and therein lies my question. Does doing a reverse lookup (dig -x) cause the queried server to behave differently than a forward lookup? My slave server is technically authoritative for the 10.in-addr.arpa zone, but it is still recusively going to another server to find an answer. Why? Is this because we have defined the zone as 10.in-addr.arpa instead of creating/slaving more specific zones (ie: 10.131.10.in-addr.arpa)? How can we control this behaviour? Thank you for any light you can shed on this - we're confident we know what is going on, but we can't figure out why the server behaves differently for reverse zones than it would for forward zones. Cheers, Todd. -- Todd Snyder Data Networks Tools bb.226.338.2617 Always On, Always Connected. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users - This transmission (including any attachments) may contain confidential information, privileged material (including material protected
Re: recursion for reverse/in-addr.arpa zones
In article ghub48$92...@sf1.isc.org, Todd Snyder tsny...@rim.com wrote: On our slave, there are no specific declarations for the 10.131.10 zone, or even 10.131, just 10. On the server we're slaving off of, there would probably be more, but I don't know as I'm not in control of that server/servers. Since your server is a slave, the delegtion records in the 10.in-addr.arpa zone will be received in the zone transfer. Will reverse lookups by default continue to look for more specific domains, recursing as necessary? If so, how far will it go? I'm There's nothing special about reverse domains. All lookups follow delegations, going as far as necessary to get the answer. slaving an A class, and it went and found a C. If we'd had the B declared, would it have stopped there, or kept going? If the B contains a delegation to a C, it will go there. This behaviour seems odd to me, and I've not been able to find information about this behaviour in the book(s). It's just the basic DNS protocol. If a name is in a delegated subdomain, you follow the NS records to get the answer. Read the resolver algorithm description in RFC 1034. -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursion for reverse/in-addr.arpa zones
Are there NS records and/or zone forwarding for the 10.131.10.0? If there is the servers will look to the most specfic domain. -- -Ben Croswell On Thu, Dec 11, 2008 at 4:38 PM, Todd Snyder tsny...@rim.com wrote: Good day, We are working on an odd issue. I can provide more detail as necessary, but don't want to fill this email with snips of useless stuff. All IP's/names provided are made up, as they don't matter in this problem as far as I can tell. This is more a functional question than a specific operating question. We have 2 servers acting as a slave for the zone 10.in-addr.arpa. The master(s) for this server are 2 Windows AD servers. Our servers (all bind9.4 of some variety) are doing zone transfers fine, and we're getting whatever is in the zone. We've run in to a couple IP's that when we dig them on these slaves, they are timing out. They are in a specific location, which we have determined are firewalled differently. For example, we are doing a dig for 10.131.10.1 against these 2 different locations. In one location, we get an answer quickly. In the other, it times out. The problem in our case is that in one location, the slave we're querying can't reach anything but the masters. What we've figured out is that the 10.in-addr.arpa zone doesn't contain EVERY 10. address we thought, but is missing some. In this case, our slaved zone doesn't have 10.131.10.1. But, instead of the slave server (which should be authortative) returning an I don't know error, it appears to be doing a recusive query. Against what, we're not 100% sure of yet. Well, we know which server, because DIG tells us, but we aren't sure why that one. When I look at the 10.in-addr.arpa zone, there are approximately 20 NS records for other AD servers. My speculation is that the slave we're querying is recusively looking to one of the servers returned in the additional section? This behaviour seems odd to us, and therein lies my question. Does doing a reverse lookup (dig -x) cause the queried server to behave differently than a forward lookup? My slave server is technically authoritative for the 10.in-addr.arpa zone, but it is still recusively going to another server to find an answer. Why? Is this because we have defined the zone as 10.in-addr.arpa instead of creating/slaving more specific zones (ie: 10.131.10.in-addr.arpa)? How can we control this behaviour? Thank you for any light you can shed on this - we're confident we know what is going on, but we can't figure out why the server behaves differently for reverse zones than it would for forward zones. Cheers, Todd. -- Todd Snyder Data Networks Tools bb.226.338.2617 Always On, Always Connected. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
