Re: Problem with recursion for windows bind for Teamviewer
So here is a theory if a client asks a query and bind goes out for that query and the reply is delayed but you get the answer then for what ever reason the reply to the client from bind is delayed more! So the quicker the answer the quicker the answer to the client. Why? I have no idea? -- 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: Problem with recursion for windows bind for Teamviewer
and this from dig maybe a routing iusse why it take so long for me? C:\Program Files\ISC BIND 9\bin>dig @213.227.191.1 router14.teamviewer.com +norecurs ; <<>> DiG 9.16.45 <<>> @213.227.191.1 router14.teamviewer.com +norecurs ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36405 ;; flags: qr aa; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;router14.teamviewer.com. IN A ;; ANSWER SECTION: router14.teamviewer.com. 3600 IN CNAME routerpool14.rlb.teamviewer.com. routerpool14.rlb.teamviewer.com. 120 IN A 188.172.235.146 routerpool14.rlb.teamviewer.com. 120 IN A 217.146.13.137 routerpool14.rlb.teamviewer.com. 120 IN A 34.17.240.4 routerpool14.rlb.teamviewer.com. 120 IN A 217.146.21.139 routerpool14.rlb.teamviewer.com. 120 IN A 37.252.234.165 ;; Query time: 3106 msec ;; SERVER: 213.227.191.1#53(213.227.191.1) ;; WHEN: Mon Nov 20 18:49:09 GMT Standard Time 2023 ;; MSG SIZE rcvd: 177 -- 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: Problem with recursion for windows bind for Teamviewer
This is the thing the setup works for many site fast just this Teamviewer and their DNS servers are a problem and bind does reply to 192.168.53.19 all be it 26 seconds later! but Teamviewer trys over and over then it connects yet the for the WAN side took under 4 seconds to get the answer WAN side https://ufile.io/6ofm19ng -- 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: Problem with recursion for windows bind for Teamviewer
Have you checked the routeing table on this server? Without any other evidence, this looks to me like packets are going places you aren't expecting. In the first screenshot the query goes to 213.227.191.1 and apparently a response doesn't come back until 4s later. When I try it using dig I get an immediate response: ; <<>> DiG 9.18.17 <<>> @213.227.191.1 router14.teamviewer.com +norecurs ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32608 ;; flags: qr aa; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;router14.teamviewer.com. IN A ;; ANSWER SECTION: router14.teamviewer.com. 3600 IN CNAME routerpool14.rlb.teamviewer.com. routerpool14.rlb.teamviewer.com. 120 IN A 188.172.219.139 routerpool14.rlb.teamviewer.com. 120 IN A 188.172.198.141 routerpool14.rlb.teamviewer.com. 120 IN A 37.252.232.103 routerpool14.rlb.teamviewer.com. 120 IN A 37.252.246.104 routerpool14.rlb.teamviewer.com. 120 IN A 217.146.4.136 ;; Query time: 11 msec ;; SERVER: 213.227.191.1#53(213.227.191.1) (UDP) ;; WHEN: Mon Nov 20 17:40:22 GMT 2023 ;; MSG SIZE rcvd: 177 In the second screenshot you see no response to #60. My suspicion again is that it went somewhere you weren't monitoring, or just wasn't routed at all. I would capture ALL packets, not just DNS, on ALL interfaces. See if you can see where key packets are going, whether you receive ICMP unreachables or retries etc. Also do some tests. If you have BIND you should also have dig. If you don't have dig, use Windows nslookup in interactive mode and send queries to the teamviewer NSs. Right now I would prove that the network is clean first. I see no reason to suspect BIND at the moment. Cheers, Greg On Mon, 20 Nov 2023 at 17:40, legacyone via bind-users < bind-users@lists.isc.org> wrote: > This might show the problem even more on two interfaces WAN side and LAN > you can see 192.168.53.19 ask for routerpool8 #60 then bind goes out #62 > gets a answer # 75 and no reply back to 192.168.53.19 > > https://ufile.io/v8oob3jg > -- > 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: Problem with recursion for windows bind for Teamviewer
This might show the problem even more on two interfaces WAN side and LAN you can see 192.168.53.19 ask for routerpool8 #60 then bind goes out #62 gets a answer # 75 and no reply back to 192.168.53.19 https://ufile.io/v8oob3jg -- 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: Problem with recursion for windows bind for Teamviewer
On starting Teamviewer it can say no connection when bind does the lookup with this delay it cause bind to not reply LAN side sometimes which causes the app to fail yet with a bind on Ubuntu there is no problem. -- 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: Problem with recursion for windows bind for Teamviewer
I'm just using bind to do my DNS look ups with no forwarders thats all Teamviewer app uses DNS to find its servers from what I can tell it can take over 4000ms to get a answer. The following seems to help in bind resolver-retry-interval 5000; I think if I can then find a setting in windows to do the same thing that might help even over here is what I see from Wireshark https://ufile.io/q0kxqltc -- 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: Problem with recursion for windows bind for Teamviewer
Hi there. Can you send some information, for those unfamiliar with what you're trying to do? - Full BIND config - IP addresses of relevant things, like interfaces of the servers on which you are running BIND and of Teamviewer. - What does Teamviewer need from DNS? What kinds of queries is it making and to where? A binary pcap would be very useful. - Is this an AD environment? i.e. do you have Domain Controllers and other such AD components? - How are your Windows boxes configured to use DNS? What IP address(es) do they get given and what are those addresses? Diagnosing a problem is difficult if you only have snippets of information to work from. Cheers, Greg On Mon, 20 Nov 2023 at 13:48, legacyone via bind-users < bind-users@lists.isc.org> wrote: > Now its not working fast again! I don't know now must be Teamviewer DNS > delaying replies causing windows bind to fail in some way. > -- > 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: Problem with recursion for windows bind for Teamviewer
Now its not working fast again! I don't know now must be Teamviewer DNS delaying replies causing windows bind to fail in some way. -- 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: Problem with recursion for windows bind for Teamviewer
So more tests and the problem has come back but I think I know why thinking internet sharing was the problem I found a way to disable it because it bind shared access for port 53 on 0.0.0.0 so that the problem I think now after testing with it on. For any interested MS has made it really hard to disable ICS on windows 11 I have tried many ways to disable it all over the web none worked but what did work was to delete the start key for: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess -- 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: Problem with recursion for windows bind for Teamviewer
I'm by no means an expert in DNS or how it fully works so I can't be of any more help about this problem then I already have. But it seems Teamviewer have rebooted their DNS servers and now windows bind allows the Teamviewer to load faster -- 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: Problem with recursion for windows bind for Teamviewer
Hey, BIND 9.16 is in security-and-critical-only mode, so this won’t get fixed in any case. However, your message is incomprehensible. If you want to get anything fixed, we will need more clarity in the report - describe your setup (clients, recursive servers, authoritative servers) and properly describe the communication between those. Logs from the failing servers are absolute minimum. Perhaps (annotated) tcpdump (wireshark) dumps would be also helpful. Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 19. 11. 2023, at 19:40, legacyone via bind-users > wrote: > > > I don't know if this will be fixed before EOL for windows bind but here is > the problem > Teamviewer (and maybe other sites too) when you do the recursion when no > answer under 1000ms it tries again which is trigged by client windows (not > the one running bind) which also tries again for a answer this seems to > causes the bind server not to give a answer but it tries and tries then > Teamviewer works so Teamviewer DNS is doing a delayed reply which seems to be > causing a problem for bind for windows because I tested bind in Ubuntu having > DNS forward for teamviewer.com to it and Teamviewer loads faster. > So it be nice if this could be fixed but I will not hold my breath. > Thanks for any insight on this > -- > 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
Problem with recursion for windows bind for Teamviewer
I don't know if this will be fixed before EOL for windows bind but here is the problem Teamviewer (and maybe other sites too) when you do the recursion when no answer under 1000ms it tries again which is trigged by client windows (not the one running bind) which also tries again for a answer this seems to causes the bind server not to give a answer but it tries and tries then Teamviewer works so Teamviewer DNS is doing a delayed reply which seems to be causing a problem for bind for windows because I tested bind in Ubuntu having DNS forward for teamviewer.com to it and Teamviewer loads faster. So it be nice if this could be fixed but I will not hold my breath. Thanks for any insight on this -- 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 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
recursion yes/no?
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
Re: How to allow recursion on my own (cross) domains only after upgrade to 9.16.27 (lack of additional-from-auth option) ?
Mark Andrews wrote: > Unless you are pointing recursive clients directly at your > authoritative servers there is no need. The recursive servers will > lookup the CNAME target themselves. Additionally recursive servers just > process the CNAME and ignore the rest of the response to prevent cache > poisoning if there is more there. I think that implicit in Mark's answer is that the additional data that was being returned was just wasted bytes, since it could never be trusted by clients so why waste bytes. Thus the change? signature.asc Description: PGP signature -- 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: How to allow recursion on my own (cross) domains only after upgrade to 9.16.27 (lack of additional-from-auth option) ?
Ok, thanks for the confirmation (no recursive clients are pointing to
this server, it's only used as an authoritative server).
Le lun. 18 avr. 2022 à 10:08, Mark Andrews a écrit :
>
> Unless you are pointing recursive clients directly at your authoritative
> servers there is no need. The recursive servers will lookup the CNAME target
> themselves. Additionally recursive servers just process the CNAME and ignore
> the rest of the response to prevent cache poisoning if there is more there.
>
> --
> Mark Andrews
>
> > On 18 Apr 2022, at 17:57, Thomas Martin wrote:
> >
> > Hello,
> >
> > I recently upgraded from Debian Buster to Debian Bullseye and I'm
> > having a hard time having the same behavior as before with the new
> > bind9 version.
> >
> > Here is my setup :
> > - I have two DNS domain (domain A.com and domain Z.com) for which my
> > server is authoritative (as a slave in this case),
> > - A few of my DNS records on domain Z are CNAME to domain A.
> >
> > My server configuration looks like this :
> > zone "A.com" {
> >type slave;
> >file "A";
> >masters { a.b.c.d; };
> > };
> > zone "Z.com" {
> >type slave;
> >file "Z";
> >masters { a.b.c.d; };
> > };
> >
> > I don't want my server to be recursive but I would like him to answer
> > the full CNAME and A like in 9.11.5 (thanks to additional-from-auth
> > AFAIK) :
> >> $ host www.Z.com 1.2.3.4
> >> www.Z.com is an alias for www.A.com.
> >> www.A.com has address 10.10.10.1
> >
> > Now, with 9.16.27 my answer is only returning the CNAME record, not
> > the A record despite being authoritative for both domains :
> >> $ host www.Z.com 1.2.3.4
> >> www.Z.com is an alias for www.A.com.
> >
> > Is there any chance I can have the same behavior as before ?
> > if I enable recursion it works of course, but I don't want my server
> > to be a public resolver.
> > I tried to play with the "minimal-responses" option with no luck.
> >
> >
> > Thanks.
> > --
> > 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: How to allow recursion on my own (cross) domains only after upgrade to 9.16.27 (lack of additional-from-auth option) ?
Unless you are pointing recursive clients directly at your authoritative
servers there is no need. The recursive servers will lookup the CNAME target
themselves. Additionally recursive servers just process the CNAME and ignore
the rest of the response to prevent cache poisoning if there is more there.
--
Mark Andrews
> On 18 Apr 2022, at 17:57, Thomas Martin wrote:
>
> Hello,
>
> I recently upgraded from Debian Buster to Debian Bullseye and I'm
> having a hard time having the same behavior as before with the new
> bind9 version.
>
> Here is my setup :
> - I have two DNS domain (domain A.com and domain Z.com) for which my
> server is authoritative (as a slave in this case),
> - A few of my DNS records on domain Z are CNAME to domain A.
>
> My server configuration looks like this :
> zone "A.com" {
>type slave;
>file "A";
>masters { a.b.c.d; };
> };
> zone "Z.com" {
>type slave;
>file "Z";
>masters { a.b.c.d; };
> };
>
> I don't want my server to be recursive but I would like him to answer
> the full CNAME and A like in 9.11.5 (thanks to additional-from-auth
> AFAIK) :
>> $ host www.Z.com 1.2.3.4
>> www.Z.com is an alias for www.A.com.
>> www.A.com has address 10.10.10.1
>
> Now, with 9.16.27 my answer is only returning the CNAME record, not
> the A record despite being authoritative for both domains :
>> $ host www.Z.com 1.2.3.4
>> www.Z.com is an alias for www.A.com.
>
> Is there any chance I can have the same behavior as before ?
> if I enable recursion it works of course, but I don't want my server
> to be a public resolver.
> I tried to play with the "minimal-responses" option with no luck.
>
>
> Thanks.
> --
> 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
How to allow recursion on my own (cross) domains only after upgrade to 9.16.27 (lack of additional-from-auth option) ?
Hello,
I recently upgraded from Debian Buster to Debian Bullseye and I'm
having a hard time having the same behavior as before with the new
bind9 version.
Here is my setup :
- I have two DNS domain (domain A.com and domain Z.com) for which my
server is authoritative (as a slave in this case),
- A few of my DNS records on domain Z are CNAME to domain A.
My server configuration looks like this :
zone "A.com" {
type slave;
file "A";
masters { a.b.c.d; };
};
zone "Z.com" {
type slave;
file "Z";
masters { a.b.c.d; };
};
I don't want my server to be recursive but I would like him to answer
the full CNAME and A like in 9.11.5 (thanks to additional-from-auth
AFAIK) :
> $ host www.Z.com 1.2.3.4
> www.Z.com is an alias for www.A.com.
> www.A.com has address 10.10.10.1
Now, with 9.16.27 my answer is only returning the CNAME record, not
the A record despite being authoritative for both domains :
> $ host www.Z.com 1.2.3.4
> www.Z.com is an alias for www.A.com.
Is there any chance I can have the same behavior as before ?
if I enable recursion it works of course, but I don't want my server
to be a public resolver.
I tried to play with the "minimal-responses" option with no luck.
Thanks.
--
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: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
On 04/01/2022 21:12, Grant Taylor via bind-users wrote: Yep. This is where I have settled. But I don't feel I can defend it when asked. Hence my seeking to better understand. There are categories of bugs that specifically affect recursion, and in BIND these are _much_ more common than those that affect authoritative service. Adding auth service barely touches the attack surface. And with BIND's separation between authoritative and recursively cached trees there is (AFAIK) no risk of cache pollution affecting the authoritative data. Furthermore, having the auth data for your own zones present there actually ensures that your own zones' data: 1. will always be served in preference to cached data 2. will be fresher (i.e. not subject to TTLs) assuming that NOTIFYs and/or a short SOA refresh is in place 3. will be present if access to the authoritatives is lost for some period of time (/me waves at Facebook!) I really can't see any downside. Ray ___ 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: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
On 1/4/22 4:37 AM, Ray Bellis wrote: Better yet, use BIND's mirror zones feature so that the zone is also DNSSEC validated. Completely agreed. I think the type of authoritative information is somewhat independent of the fact that any authoritative information exists. IMHO, the strictures against running authoritative and recursive on the same server seem to get mis-applied a lot of the time. I think it's perfectly fine for an *internal* recursive server to also hold authoritative copies of your own zones. Yep. This is where I have settled. But I don't feel I can defend it when asked. Hence my seeking to better understand. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ 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: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
On 04/01/2022 03:52, Grant Taylor via bind-users wrote: If I'm allowing recursion and authoritative on the same server, I'd have the recursive + authoritative server do secondary zone transfers off of the internal MS-DNS / AD server. That way the clients can get the info off of the first server they talk to. To me, the secondary copy of the zone is a form of authoritative information on the otherwise recursive server. Better yet, use BIND's mirror zones feature so that the zone is also DNSSEC validated. IMHO, the strictures against running authoritative and recursive on the same server seem to get mis-applied a lot of the time. I think it's perfectly fine for an *internal* recursive server to also hold authoritative copies of your own zones. Ray ___ 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: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
On 1/3/22 10:57 AM, John Thurston wrote: It must have a 'forward' zone defined on it for each of those stupid domains. And yes, you are right . . at that point it is no longer only performing recursion. ;-) But there is no other way to do it. Even in a combined recursive/authoritative design, your server would have no way to resolve names in those stupid domains; there must be an explicit 'forward' zone defined. If I'm allowing recursion and authoritative on the same server, I'd have the recursive + authoritative server do secondary zone transfers off of the internal MS-DNS / AD server. That way the clients can get the info off of the first server they talk to. To me, the secondary copy of the zone is a form of authoritative information on the otherwise recursive server. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ 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: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
On 1/3/22 12:15 AM, Borja Marcos wrote: If you separate the roles it is much simpler to implement an effective access control. On 03.01.22 10:35, Grant Taylor via bind-users wrote: The problem I have with separating recursive and authoritative servers has to do with internal LANs and things like Microsoft Active Directory on non-globally-recognized domains. In short, how do you get a /purely/ /recursive/ server to know that internal-corp-lan.example (or any domain not in the global DNS hierarchy) is served by some other /purely/ /authoritative/ DNS server inside the company? you configure your recursive server with internal-corp-lan.example as type forward or static-stub pointing to your authoritative server. however, the "purely recursive" and "purely authoritative" split is not designed to cover domains like "internal-corp-lan.example" but "example.com" that has to be seen from the world clients. I feel like anything you do to the /purely/ /recursive/ DNS server to get it to know that it needs to route based on the DNS domain information slides away from the /purely/ /recursive/ role to somewhat /mixed/ /recursive/ & /authoritative/ role. This is to prevent recursive servers from providing domains to the public. in these cases I recommend setup purely authoritative servers for "example.com" to be accessible from the internet and "purely recursive" server accessible from your LAN, even if it would fetch "example.com" domain from your public authoritative servers. Just don't point NS record for "example.com" to this server as it's designes as internal recursive server. This niche role is the one nagging thing that I have that prevents me from supporting and proselytizing the role separation anywhere and everywhere. -- I've been looking for, but have not yet found, what I consider to be a good method that maintains strict separation of roles in this niche use case. Note: I'm completely on board with the separate roles for public / Internet facing servers. then, you should understand the need for separation of roles well. just the "recursive only" and "authoritative only" have a bit different meaning I tried to explain above. -- 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. The 3 biggets disasters: Hiroshima 45, Tschernobyl 86, Windows 95 ___ 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: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
On 1/3/2022 8:35 AM, Grant Taylor via bind-users wrote: In short, how do you get a /purely/ /recursive/ server to know that internal-corp-lan.example (or any domain not in the global DNS hierarchy) is served by some other /purely/ /authoritative/ DNS server inside the company? It must have a 'forward' zone defined on it for each of those stupid domains. And yes, you are right . . at that point it is no longer only performing recursion. But there is no other way to do it. Even in a combined recursive/authoritative design, your server would have no way to resolve names in those stupid domains; there must be an explicit 'forward' zone defined. -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska ___ 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: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
On 1/3/22 12:15 AM, Borja Marcos wrote: If you separate the roles it is much simpler to implement an effective access control. The problem I have with separating recursive and authoritative servers has to do with internal LANs and things like Microsoft Active Directory on non-globally-recognized domains. In short, how do you get a /purely/ /recursive/ server to know that internal-corp-lan.example (or any domain not in the global DNS hierarchy) is served by some other /purely/ /authoritative/ DNS server inside the company? I feel like anything you do to the /purely/ /recursive/ DNS server to get it to know that it needs to route based on the DNS domain information slides away from the /purely/ /recursive/ role to somewhat /mixed/ /recursive/ & /authoritative/ role. This niche role is the one nagging thing that I have that prevents me from supporting and proselytizing the role separation anywhere and everywhere. -- I've been looking for, but have not yet found, what I consider to be a good method that maintains strict separation of roles in this niche use case. Note: I'm completely on board with the separate roles for public / Internet facing servers. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ 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: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
> On 30 Dec 2021, at 09:07, Danilo Godec via bind-users > wrote: > > The source is a security audit report, claiming that using a single server > for both authoritative (for public use) and recursive (limited to internal > clients by means of 'allow-recursion' directive) roles increases the risk of > DoS attacks and DNS cache poisoning... They mentioned CVE-2021-20322 that > supposedly makes cache poisoning feasible (again) - that made them increase > the concern level to a 'medium'. > > > While I understand how and why DoS and cache poisoning are bad, I don't > understand how separating these two roles would help mitigate the risk. Well, it’s certainly best practice to separate the roles. First and foremost: If you separate the roles it is much simpler to implement an effective access control. You can completely disable requests to a recursive DNS server using traffic filtering. If you implement both network filtering and BIND access lists an exploitation would require two mechanisms to fail/be buggy. Assuming that you are using dual role servers, imagine that a bug that allows cache poisoning by crafting requests in some way is discovered. If you are separating roles exploitation will be harder/less likely. Note that traffic filtering to a recursive DNS server is trickier than it seems. You also need to filter out spoofed requests at the network edge or it would be possible to use your own DNS server(s) to launch DoS attacks against your own users. Cheers, Borja. ___ 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: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
On Fri, Dec 31, 2021 at 10:45:12AM +1100, raf wrote: > On Thu, Dec 30, 2021 at 09:07:54AM +0100, Danilo Godec via bind-users > wrote: > > > On 29. 12. 21 19:24, tale wrote: > > > On Wed, Dec 29, 2021 at 5:31 AM Danilo Godec via bind-users > > > wrote: > > > > I have an authoritative DNS server for a domain, but I was also going to > > > > use the same server as a recursive DNS for my internal network, limiting > > > > recursion by the IP. Apparently, this is a bad idea that can lead to > > > > cache poisoning... > > > In short, no, this configuration with a BIND 9 server does not > > > increase your risk of cache poisoning any more than running your local > > > server in pure recursive mode. I'm curious to hear more from the > > > source that has given you this impression. I suspect there were some > > > additional qualifications that don't align with what you've described. > > > > > The source is a security audit report, claiming that using a single server > > for both authoritative (for public use) and recursive (limited to internal > > clients by means of 'allow-recursion' directive) roles increases the risk of > > DoS attacks and DNS cache poisoning... They mentioned CVE-2021-20322 that > > supposedly makes cache poisoning feasible (again) - that made them increase > > the concern level to a 'medium'. > > > > While I understand how and why DoS and cache poisoning are bad, I don't > > understand how separating these two roles would help mitigate the risk. > > > > Thanks for helping me understand, > > > > Danilo > > This site might explain it: https://www.saddns.net/ > > If it doesn't, perhaps you could ask the vendor of the > system that produced the security audit report to explain > their rationale. The only theory I can think of is that > separating the functions makes it more likely that the > resolving server would reside on a non-publically accessible > network, but it should still be possible to inject ICMP > packets directed at it by an attacker that can observe > its outgoing query packets. But that's an on-path attacker, > not an off-path attacker, so it would count as an improvement. > But even if the above isn't nonsense, it's not the separation > of functions that improves the situation, it's the location > of the resolving server. So it's probably a dumb theory. > > But the main thing is that the Linux kernel has been patched, > so it shouldn't be a problem after your next security update. > > Until then, you could block outgoing ICMP if doing so doesn't > cause more problems than it solves. > > cheers, > raf I've just watched the two videos referred to on that site, and I think what I said above refers mostly to the original SADDNS (CVE-2020-25705), not the new variant (CVE-2021-20322). But I think the second video might answer your question: https://dl.acm.org/action/downloadSupplement?doi=10.1145%2F3460120.3486219=CCS21-fp236ab.mp4 It does make a distinction between "public-facing" and "private-facing" port scans, but they seem to just be terms used for referring to the difference between un-"connect()"ed and "connect()"ed UDP sockets, and how the kernel handles them. It's complicated. The attacks are different in each case, and the attack for the "private-facing" (i.e. "connect()"-ed sockets) is much more complicated, but still possible. So it didn't help me understand how separating functions in the name server would matter. I think asking your security vulnerability scanner vendor for an explanation is probably a good idea. cheers, raf ___ 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: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
On Thu, Dec 30, 2021 at 09:07:54AM +0100, Danilo Godec via bind-users wrote: > On 29. 12. 21 19:24, tale wrote: > > On Wed, Dec 29, 2021 at 5:31 AM Danilo Godec via bind-users > > wrote: > > > I have an authoritative DNS server for a domain, but I was also going to > > > use the same server as a recursive DNS for my internal network, limiting > > > recursion by the IP. Apparently, this is a bad idea that can lead to > > > cache poisoning... > > In short, no, this configuration with a BIND 9 server does not > > increase your risk of cache poisoning any more than running your local > > server in pure recursive mode. I'm curious to hear more from the > > source that has given you this impression. I suspect there were some > > additional qualifications that don't align with what you've described. > > > The source is a security audit report, claiming that using a single server > for both authoritative (for public use) and recursive (limited to internal > clients by means of 'allow-recursion' directive) roles increases the risk of > DoS attacks and DNS cache poisoning... They mentioned CVE-2021-20322 that > supposedly makes cache poisoning feasible (again) - that made them increase > the concern level to a 'medium'. > > While I understand how and why DoS and cache poisoning are bad, I don't > understand how separating these two roles would help mitigate the risk. > > Thanks for helping me understand, > > Danilo This site might explain it: https://www.saddns.net/ If it doesn't, perhaps you could ask the vendor of the system that produced the security audit report to explain their rationale. The only theory I can think of is that separating the functions makes it more likely that the resolving server would reside on a non-publically accessible network, but it should still be possible to inject ICMP packets directed at it by an attacker that can observe its outgoing query packets. But that's an on-path attacker, not an off-path attacker, so it would count as an improvement. But even if the above isn't nonsense, it's not the separation of functions that improves the situation, it's the location of the resolving server. So it's probably a dumb theory. But the main thing is that the Linux kernel has been patched, so it shouldn't be a problem after your next security update. Until then, you could block outgoing ICMP if doing so doesn't cause more problems than it solves. cheers, raf ___ 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: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
Am 30.12.21 um 09:07 schrieb Danilo Godec via bind-users: On 29. 12. 21 19:24, tale wrote: On Wed, Dec 29, 2021 at 5:31 AM Danilo Godec via bind-users wrote: I have an authoritative DNS server for a domain, but I was also going to use the same server as a recursive DNS for my internal network, limiting recursion by the IP. Apparently, this is a bad idea that can lead to cache poisoning... In short, no, this configuration with a BIND 9 server does not increase your risk of cache poisoning any more than running your local server in pure recursive mode. I'm curious to hear more from the source that has given you this impression. I suspect there were some additional qualifications that don't align with what you've described. The source is a security audit report, claiming that using a single server for both authoritative (for public use) and recursive (limited to internal clients by means of 'allow-recursion' directive) roles increases the risk of DoS attacks and DNS cache poisoning... They mentioned CVE-2021-20322 that supposedly makes cache poisoning feasible (again) - that made them increase the concern level to a 'medium'. While I understand how and why DoS and cache poisoning are bad, I don't understand how separating these two roles would help mitigate the risk it don't ___ 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: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
On 29. 12. 21 19:24, tale wrote: On Wed, Dec 29, 2021 at 5:31 AM Danilo Godec via bind-users wrote: I have an authoritative DNS server for a domain, but I was also going to use the same server as a recursive DNS for my internal network, limiting recursion by the IP. Apparently, this is a bad idea that can lead to cache poisoning... In short, no, this configuration with a BIND 9 server does not increase your risk of cache poisoning any more than running your local server in pure recursive mode. I'm curious to hear more from the source that has given you this impression. I suspect there were some additional qualifications that don't align with what you've described. The source is a security audit report, claiming that using a single server for both authoritative (for public use) and recursive (limited to internal clients by means of 'allow-recursion' directive) roles increases the risk of DoS attacks and DNS cache poisoning... They mentioned CVE-2021-20322 that supposedly makes cache poisoning feasible (again) - that made them increase the concern level to a 'medium'. While I understand how and why DoS and cache poisoning are bad, I don't understand how separating these two roles would help mitigate the risk. Thanks for helping me understand, Danilo ___ 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: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
On Wed, Dec 29, 2021 at 5:31 AM Danilo Godec via bind-users wrote: > I have an authoritative DNS server for a domain, but I was also going to > use the same server as a recursive DNS for my internal network, limiting > recursion by the IP. Apparently, this is a bad idea that can lead to > cache poisoning... In short, no, this configuration with a BIND 9 server does not increase your risk of cache poisoning any more than running your local server in pure recursive mode. I'm curious to hear more from the source that has given you this impression. I suspect there were some additional qualifications that don't align with what you've described. -- tale ___ 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: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
Danilo Godec via bind-users wrote: > > I have an authoritative DNS server for a domain, but I was also going to > use the same server as a recursive DNS for my internal network, limiting > recursion by the IP. Apparently, this is a bad idea that can lead to > cache poisoning... Sort of. It's complicated. Of course DNSSEC can prevent cache poisoning, but there is more to this particular question. In older DNS software (BIND 8 and before) there was not much separation between the recursive cache and authoritative data. It was possible for recursive clients to get data into the cache that could leak into authoritative responses, e.g. glue addresses, and addresses of CNAME or MX targets that pointed out-of-zone. This could lead to cache poisoning of other recursive servers, especially those that trusted additional data too much (before RFC 2181). BIND 9 keeps its authoritative and recursive data more separate. As a user you can see this in the ACL options, allow-recursion, allow-query-cache, etc. It is possible to configure BIND 9 so that remote clients see an authoritative-only view, and local clients have access to a recursive view, but it isn't entirely straightforward. Best practice is still to configure servers that appeaar in NS records to be authoritative-only. Tony. -- f.anthony.n.finchhttps://dotat.at/ Trafalgar: Variable 4 or less, but southerly 5 or 6 in northwest. Moderate or rough in southeast, rough or very rough in northwest. Fog patches. Moderate or good, occasionally very poor. ___ 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
DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
Hello, I have an authoritative DNS server for a domain, but I was also going to use the same server as a recursive DNS for my internal network, limiting recursion by the IP. Apparently, this is a bad idea that can lead to cache poisoning... After watching a Computerphile Youtube video (https://www.youtube.com/watch?v=7MT1F0O3_Yw) on that topic I have a rough understanding of how cache poisoning works, but it doesn't explain why limiting recursion to 'trusted' IP networks doesn't help. Is it because with UDP IP's can be 'easily' spoofed and if someone guessed my internal network IPs and spoofed the IP, my DNS server would happily accept their requests? Or is it even wider than that? Danilo ___ 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 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
Recursion Question
Hello All. I have a recursion via forwarder question. Consider the following scenario: - A client sends a query to an internal recursive DNS server for the following A record: 'a.b.c.private.dns.com' - The Recursive DNS server is unaware of this domain and sends the request to its Forwarding DNS - The Forwarding DNS server has Internet access and begins the recursion process o It successfully determines the NS authoritative for 'private.dns.com' o It is unable to continue the resolution process as it does not have access to the NS authoritative for 'private.dns.com' o It times out and returns a failed response to the Recursive DNS Is it possible to return the information that it has to the Recursive DNS server? And if so, is it possible for the Recursive DNS server to complete the lookup against NS private.dns.com (it has network access)? I have been unable to find any guidance on this and am concerned that this is not a supported scenario. Alternatives under consideration are: - Allow Forwarding DNS access to NS responsible for 'private.dns.com' - Make Recursive DNS aware of zone 'private.dns.com' so that it does not use the Forwarding DNS - ?? (open to suggestions!) Thanks in advance! Daniel J. LeBlanc, P.Eng., MBA, DTME ___ 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
Recursion setting for bind9
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
Re: forwarding zone setup from a BIND slave (without recursion?)
So why doesn’t it work to make your limited server authoritative for the root and only forward the zones you want? Anything that isn’t in a forwarded zone does not exist (except the root itself). On Sat, Apr 17, 2021 at 11:07 PM Marki wrote: > > On 4/14/2021 12:44 AM, Sebby, Brian A. via bind-users wrote: > > > My situation is due to a security requirement. We have DNS servers at our > site running BIND that allow recursion, but I’ve been requested to set up > some additional DNS servers for another project that is expected to * > *only** access the data that we’re authoritative for. And of course …. > there’s a chance that it might need to look up one or two external zones. > Essentially, what I really need is a recursive whitelist that doesn’t tell > BIND what clients are allowed to do recursive lookups, but to limit BIND to > only allow recursive lookups on a very small list of allowed domains. > > > > I was trying to set up a forwarding zone to forward queries to our DNS > servers that do allow recursion, but as I discovered (and as was discussed > earlier in the thread), if recursion is not allowed, then forwarding is > also not allowed. I had tried setting the “allow-recursion” field to > “localhost” and setting up a forward zone to forward to 127.0.0.1, but that > didn’t work either. > > Hello, > > So they do _not_ only look up internal/authoritative zones, but external > ones as well. (It's always the exceptions that kill you.) > > I think we have previously established that there is not a good way to do > whitelisting using Bind, see the thread "Authority and forwarding, but not > recursion/iteration". > > If you can live with non-allowed zones returning SERVFAIL (instead of > NXDOMAIN for example), then using a recursive service with a bogus global > forwarder and static stubs pointing to the authoritative/non-recursive > service might do the trick. > > You might also be able to leverage RPZ if there are no complex conditions > associated to your rules (everyone will have the same white/blacklists). > You configure passthrough for the allowed zones and deny the rest. > > Alternatively, there is dnsdist which, while being a load-balancer, could > be considered the swiss army knife of DNS filtering. > > Finally, some firewalls like Fortigates provide a "DNS filter" that lets > you define custom white and blacklists. Palo Altos currently are not able > to whitelist AFAIK. > > Best regards, > > Marki > ___ > 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: forwarding zone setup from a BIND slave (without recursion?)
On 4/14/2021 12:44 AM, Sebby, Brian A. via bind-users wrote: My situation is due to a security requirement. We have DNS servers at our site running BIND that allow recursion, but I’ve been requested to set up some additional DNS servers for another project that is expected to **only** access the data that we’re authoritative for. And of course …. there’s a chance that it might need to look up one or two external zones. Essentially, what I really need is a recursive whitelist that doesn’t tell BIND what clients are allowed to do recursive lookups, but to limit BIND to only allow recursive lookups on a very small list of allowed domains. I was trying to set up a forwarding zone to forward queries to our DNS servers that do allow recursion, but as I discovered (and as was discussed earlier in the thread), if recursion is not allowed, then forwarding is also not allowed. I had tried setting the “allow-recursion” field to “localhost” and setting up a forward zone to forward to 127.0.0.1, but that didn’t work either. Hello, So they do _not_ only look up internal/authoritative zones, but external ones as well. (It's always the exceptions that kill you.) I think we have previously established that there is not a good way to do whitelisting using Bind, see the thread "Authority and forwarding, but not recursion/iteration". If you can live with non-allowed zones returning SERVFAIL (instead of NXDOMAIN for example), then using a recursive service with a bogus global forwarder and static stubs pointing to the authoritative/non-recursive service might do the trick. You might also be able to leverage RPZ if there are no complex conditions associated to your rules (everyone will have the same white/blacklists). You configure passthrough for the allowed zones and deny the rest. Alternatively, there is dnsdist which, while being a load-balancer, could be considered the swiss army knife of DNS filtering. Finally, some firewalls like Fortigates provide a "DNS filter" that lets you define custom white and blacklists. Palo Altos currently are not able to whitelist AFAIK. Best regards, Marki ___ 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: forwarding zone setup from a BIND slave (without recursion?)
I have been banging my head against the wall regarding this very topic and then found this thread from last week. I’m also looking for a solution to this problem, and wondered if anyone may have some suggestions (including potential alternatives). My situation is due to a security requirement. We have DNS servers at our site running BIND that allow recursion, but I’ve been requested to set up some additional DNS servers for another project that is expected to *only* access the data that we’re authoritative for. And of course …. there’s a chance that it might need to look up one or two external zones. Essentially, what I really need is a recursive whitelist that doesn’t tell BIND what clients are allowed to do recursive lookups, but to limit BIND to only allow recursive lookups on a very small list of allowed domains. I was trying to set up a forwarding zone to forward queries to our DNS servers that do allow recursion, but as I discovered (and as was discussed earlier in the thread), if recursion is not allowed, then forwarding is also not allowed. I had tried setting the “allow-recursion” field to “localhost” and setting up a forward zone to forward to 127.0.0.1, but that didn’t work either. Is there any potential workaround for this, or do I just need to tell the person who requested this that they can only get all or nothing for recursive queries? We’re still running BIND 9.11, but I was wondering if there may be new features in BIND 9.16 or 17 that I’m not aware of. Thanks, Brian -- Brian Sebby (he/him/his) | Lead Systems Engineer Email: se...@anl.gov<mailto:se...@anl.gov> | Information Technology Infrastructure Phone: +1 630.252.9935| Business Information Services Cell: +1 630.921.4305| Argonne National Laboratory From: bind-users on behalf of RK K Date: Wednesday, April 7, 2021 at 7:40 PM To: "bind-users@lists.isc.org" Subject: Re: forwarding zone setup from a BIND slave (without recursion?) Hello Marki, Matus, Thank you for the insights on this topic. Answering Marki's question about why the secondary-authoritative (slaves) are used for lookups is some-what history and there was no need to be recursive (until now) as all the queries are authoritatively answered or refused. May be security is another reason. Much appreciated your ideas Thank you Kind Regards RK On Wed, Apr 7, 2021 at 8:01 AM mailto:bind-users-requ...@lists.isc.org>> wrote: Send bind-users mailing list submissions to bind-users@lists.isc.org<mailto:bind-users@lists.isc.org> To subscribe or unsubscribe via the World Wide Web, visit https://lists.isc.org/mailman/listinfo/bind-users or, via email, send a message with subject or body 'help' to bind-users-requ...@lists.isc.org<mailto:bind-users-requ...@lists.isc.org> You can reach the person managing the list at bind-users-ow...@lists.isc.org<mailto:bind-users-ow...@lists.isc.org> When replying, please edit your Subject line so it is more specific than "Re: Contents of bind-users digest..." Today's Topics: 1. forwarding zone setup from a BIND slave (without recursion?) (RK K) 2. Re: forwarding zone setup from a BIND slave (without recursion?) (Matus UHLAR - fantomas) 3. Re: forwarding zone setup from a BIND slave (without recursion?) (Marki) -- Message: 1 Date: Tue, 6 Apr 2021 22:47:23 -0400 From: RK K mailto:rvk...@gmail.com>> To: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org> Subject: forwarding zone setup from a BIND slave (without recursion?) Message-ID: mailto:caotbjrubejlxc6-uff5kgkd_ignoytg_ku2pkdxbhpovyzs...@mail.gmail.com>> Content-Type: text/plain; charset="utf-8" All, We have a set of BIND primary servers (MASTERs) and a set of secondary servers (slaves to the MASTERs). The secondary BIND DNS servers disabled recursion ( with "*recursion no;" *) in the global options. All the applications/systems do use secondary DNS servers for name resolution. Now there is a need to configure a forwarding zone in the "secondary DNS servers" to an external DNS server. In this scenario, in-order for the secondary server to forward the DNS query to an external DNS server, is it required to enable the recursion in the global options on the secondary servers? Based on reference material, I did not see such a requirement. But my observation is the query is not getting forwarded ( tried to check using the packet trace) When recursion is enabled, the query is getting forwarded. The BIND version I am using is 9.11.2.x. Appreciate your ideas and help. Thank you Kind Regards, Ravi Kota -- next part -- An HTML attachment was scrubbed... URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210406/15bb6cad/attachment-0001.ht
Re: forwarding zone setup from a BIND slave (without recursion?)
Mark Andrews wrote: > > On 8 Apr 2021, at 00:37, Tony Finch wrote: > > > > Forward zones require the upstream server to be recursive too. > > More correctly, the upstream server has to serve the entire namespace being > forwarded if it does not off recursion to the client for forwarding to > work. I thought forwarding expected the target server to resolve CNAMEs? If so, any out-of-zone CNAMEs in the target namespace would cause problems. Tony. -- f.anthony.n.finchhttps://dotat.at/ Cape Wrath to Rattray Head including Orkney: Southwesterly 6 to gale 8, occasionally 5 at first in east, then veering westerly or northwesterly 7 to severe gale 9 later. Moderate or rough, becoming very rough or high in north. Rain at times, squally snow showers later. Moderate or good, occasionally very poor later. ___ 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: forwarding zone setup from a BIND slave (without recursion?)
Chuck, Tony, Thank you all for sharing the ideas.. very much appreciated. Thank you Kind Regards, Ravi Kota On Wed, Apr 7, 2021 at 7:25 PM wrote: > Send bind-users mailing list submissions to > bind-users@lists.isc.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.isc.org/mailman/listinfo/bind-users > or, via email, send a message with subject or body 'help' to > bind-users-requ...@lists.isc.org > > You can reach the person managing the list at > bind-users-ow...@lists.isc.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of bind-users digest..." > > > Today's Topics: > >1. Re: forwarding zone setup from a BIND slave (without > recursion?) (Chuck Aurora) >2. Re: forwarding zone setup from a BIND slave (without > recursion?) (Tony Finch) >3. Re: rndc stops listening (John Thurston) >4. Re: rndc stops listening (Ond?ej Sur?) >5. Re: forwarding zone setup from a BIND slave (without > recursion?) (Mark Andrews) > > > -- > > Message: 1 > Date: Wed, 07 Apr 2021 07:53:01 -0500 > From: Chuck Aurora > To: bind-users@lists.isc.org > Subject: Re: forwarding zone setup from a BIND slave (without > recursion?) > Message-ID: > Content-Type: text/plain; charset=US-ASCII; format=flowed > > On 2021-04-07 03:59, Marki wrote: > > To elaborate a little bit on that... Indeed that is how it works, > > unfortunately. When you start using forwarders or stubs, recursion > > needs to be enabled because you're no longer looking for your own > > authoritative data only. > > A stub or static-stub zone would not require recursion. In that case > named is asking for authoritative data from upstream. But type > forward zones indeed cannot work if recursion is disabled. > > > What I've learned from this list is that you should split > > authoritative and recursive service. > > I would suggest that as a general best practice, but not an absolute > one. There's nothing wrong with having internal-only authoritative > zones on your recursive resolver. The potential problem comes when > you're a globally-published NS for your zones; having recursion > enabled can make you vulnerable to more possible attacks. > > I'd say it depends more who/what you are. Small-timers are not at so > much risk for this than large sites and ISPs. But there too, the > paranoid would go for two instances of named, authoritative and > recursive, on a small hosted server even where it's only offering > recursion to itself. > > > May I ask what is the reasoning behind your current setup (pointing > > your users to the non-recursive service)? What would you like to > > achieve? What would you like to prevent? > > Agreed, that is strange. It does not seem that an authoritative-only > named can be very useful for end users. > > > -- > > Message: 2 > Date: Wed, 7 Apr 2021 15:37:33 +0100 > From: Tony Finch > To: Chuck Aurora > Cc: bind-users@lists.isc.org > Subject: Re: forwarding zone setup from a BIND slave (without > recursion?) > Message-ID: > Content-Type: text/plain; charset=US-ASCII > > Chuck Aurora wrote: > > > > A stub or static-stub zone would not require recursion. In that case > > named is asking for authoritative data from upstream. But type > > forward zones indeed cannot work if recursion is disabled. > > Be careful in this kind of situation to be very clear about which client > or server is doing what: in this case, it isn't clear what doesn't require > recursion for stub or static stub. > > All three types of zone configuration (stub, static stub, and forward) > are only useful on a server that is providing recursive service. > > Forward zones require the upstream server to be recursive too. > > Stub and static-stub expect the upstream server to be authoritative; > the stub server list is a hint that gets replaced by the authoritative > server list from the zone (a bit like the root hints) whereas static-stub > only uses the configured upstream servers. > > > > What I've learned from this list is that you should split > > > authoritative and recursive service. > > > > I would suggest that as a general best practice, but not an absolute > > one. There's nothing wrong with having internal-only authoritative > > zones on your recursive resolver. The potential problem comes when > > you're a globally-published NS for your zones; having recursion > > enabled can make you vulnera
Re: forwarding zone setup from a BIND slave (without recursion?)
Hello Marki, Matus, Thank you for the insights on this topic. Answering Marki's question about why the secondary-authoritative (slaves) are used for lookups is some-what history and there was no need to be recursive (until now) as all the queries are authoritatively answered or refused. May be security is another reason. Much appreciated your ideas Thank you Kind Regards RK On Wed, Apr 7, 2021 at 8:01 AM wrote: > Send bind-users mailing list submissions to > bind-users@lists.isc.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.isc.org/mailman/listinfo/bind-users > or, via email, send a message with subject or body 'help' to > bind-users-requ...@lists.isc.org > > You can reach the person managing the list at > bind-users-ow...@lists.isc.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of bind-users digest..." > > > Today's Topics: > > 1. forwarding zone setup from a BIND slave (without recursion?) > (RK K) >2. Re: forwarding zone setup from a BIND slave (without > recursion?) (Matus UHLAR - fantomas) > 3. Re: forwarding zone setup from a BIND slave (without > recursion?) (Marki) > > > -- > > Message: 1 > Date: Tue, 6 Apr 2021 22:47:23 -0400 > From: RK K > To: bind-users@lists.isc.org > Subject: forwarding zone setup from a BIND slave (without recursion?) > Message-ID: > < > caotbjrubejlxc6-uff5kgkd_ignoytg_ku2pkdxbhpovyzs...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > All, > > We have a set of BIND primary servers (MASTERs) and a set of secondary > servers (slaves to the MASTERs). > The secondary BIND DNS servers disabled recursion ( with "*recursion no;" > *) > in the global options. > All the applications/systems do use secondary DNS servers for name > resolution. > > Now there is a need to configure a forwarding zone in the "secondary DNS > servers" to an external DNS server. > > In this scenario, in-order for the secondary server to forward the DNS > query to an external DNS server, is it required to enable the recursion in > the global options on the secondary servers? > Based on reference material, I did not see such a requirement. But my > observation is the query is not getting forwarded ( tried to check using > the packet trace) > When recursion is enabled, the query is getting forwarded. > > The BIND version I am using is 9.11.2.x. > > Appreciate your ideas and help. > > Thank you > Kind Regards, > Ravi Kota > -- next part -- > An HTML attachment was scrubbed... > URL: < > https://lists.isc.org/pipermail/bind-users/attachments/20210406/15bb6cad/attachment-0001.htm > > > > -- > > Message: 2 > Date: Wed, 7 Apr 2021 10:35:12 +0200 > From: Matus UHLAR - fantomas > To: bind-users@lists.isc.org > Subject: Re: forwarding zone setup from a BIND slave (without > recursion?) > Message-ID: <20210407083512.ga19...@fantomas.sk> > Content-Type: text/plain; charset=us-ascii; format=flowed > > On 06.04.21 22:47, RK K wrote: > >We have a set of BIND primary servers (MASTERs) and a set of secondary > >servers (slaves to the MASTERs). > >The secondary BIND DNS servers disabled recursion ( with "*recursion no;" > *) > >in the global options. > >All the applications/systems do use secondary DNS servers for name > >resolution. > > > >Now there is a need to configure a forwarding zone in the "secondary DNS > >servers" to an external DNS server. > > > >In this scenario, in-order for the secondary server to forward the DNS > >query to an external DNS server, is it required to enable the recursion in > >the global options on the secondary servers? > > yes. > > >Based on reference material, I did not see such a requirement. But my > >observation is the query is not getting forwarded ( tried to check using > >the packet trace) > >When recursion is enabled, the query is getting forwarded. > > > >The BIND version I am using is 9.11.2.x. > > -- > 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. > It's now safe to throw off your computer. > > > -- > > Message: 3 > Date: Wed, 7 Apr 2021 10:59:30 +0200 > From: Marki > To: bind-users@lists.isc.org > Subj
Re: forwarding zone setup from a BIND slave (without recursion?)
> On 8 Apr 2021, at 00:37, Tony Finch wrote: > > Chuck Aurora wrote: >> >> A stub or static-stub zone would not require recursion. In that case >> named is asking for authoritative data from upstream. But type >> forward zones indeed cannot work if recursion is disabled. > > Be careful in this kind of situation to be very clear about which client > or server is doing what: in this case, it isn't clear what doesn't require > recursion for stub or static stub. > > All three types of zone configuration (stub, static stub, and forward) > are only useful on a server that is providing recursive service. > > Forward zones require the upstream server to be recursive too. More correctly, the upstream server has to serve the entire namespace being forwarded if it does not off recursion to the client for forwarding to work. > Stub and static-stub expect the upstream server to be authoritative; > the stub server list is a hint that gets replaced by the authoritative > server list from the zone (a bit like the root hints) whereas static-stub > only uses the configured upstream servers. > >>> What I've learned from this list is that you should split >>> authoritative and recursive service. >> >> I would suggest that as a general best practice, but not an absolute >> one. There's nothing wrong with having internal-only authoritative >> zones on your recursive resolver. The potential problem comes when >> you're a globally-published NS for your zones; having recursion >> enabled can make you vulnerable to more possible attacks. > > Right: the rule is that authoritative servers listed as targets of NS > records should be authoritative-only; it's OK if recursive servers have > authoritative copies of zones: it can make them more resilient to outages, > though it does slightly weird things to DNSSEC validation. > > Tony. > -- > f.anthony.n.finchhttps://dotat.at/ > Whitby to Gibraltar Point: Northwest 4 to 6 becoming variable 2 to 4, > then southwest 4 to 6 later. Very rough at first in north, otherwise > moderate or rough. Snow showers, then rain for a time later. Good, > occasionally very poor at first. > > ___ > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: forwarding zone setup from a BIND slave (without recursion?)
Chuck Aurora wrote: > > A stub or static-stub zone would not require recursion. In that case > named is asking for authoritative data from upstream. But type > forward zones indeed cannot work if recursion is disabled. Be careful in this kind of situation to be very clear about which client or server is doing what: in this case, it isn't clear what doesn't require recursion for stub or static stub. All three types of zone configuration (stub, static stub, and forward) are only useful on a server that is providing recursive service. Forward zones require the upstream server to be recursive too. Stub and static-stub expect the upstream server to be authoritative; the stub server list is a hint that gets replaced by the authoritative server list from the zone (a bit like the root hints) whereas static-stub only uses the configured upstream servers. > > What I've learned from this list is that you should split > > authoritative and recursive service. > > I would suggest that as a general best practice, but not an absolute > one. There's nothing wrong with having internal-only authoritative > zones on your recursive resolver. The potential problem comes when > you're a globally-published NS for your zones; having recursion > enabled can make you vulnerable to more possible attacks. Right: the rule is that authoritative servers listed as targets of NS records should be authoritative-only; it's OK if recursive servers have authoritative copies of zones: it can make them more resilient to outages, though it does slightly weird things to DNSSEC validation. Tony. -- f.anthony.n.finchhttps://dotat.at/ Whitby to Gibraltar Point: Northwest 4 to 6 becoming variable 2 to 4, then southwest 4 to 6 later. Very rough at first in north, otherwise moderate or rough. Snow showers, then rain for a time later. Good, occasionally very poor at first. ___ 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: forwarding zone setup from a BIND slave (without recursion?)
On 2021-04-07 03:59, Marki wrote: To elaborate a little bit on that... Indeed that is how it works, unfortunately. When you start using forwarders or stubs, recursion needs to be enabled because you're no longer looking for your own authoritative data only. A stub or static-stub zone would not require recursion. In that case named is asking for authoritative data from upstream. But type forward zones indeed cannot work if recursion is disabled. What I've learned from this list is that you should split authoritative and recursive service. I would suggest that as a general best practice, but not an absolute one. There's nothing wrong with having internal-only authoritative zones on your recursive resolver. The potential problem comes when you're a globally-published NS for your zones; having recursion enabled can make you vulnerable to more possible attacks. I'd say it depends more who/what you are. Small-timers are not at so much risk for this than large sites and ISPs. But there too, the paranoid would go for two instances of named, authoritative and recursive, on a small hosted server even where it's only offering recursion to itself. May I ask what is the reasoning behind your current setup (pointing your users to the non-recursive service)? What would you like to achieve? What would you like to prevent? Agreed, that is strange. It does not seem that an authoritative-only named can be very useful for end 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: forwarding zone setup from a BIND slave (without recursion?)
Hello, On 4/7/2021 10:35 AM, Matus UHLAR - fantomas wrote: On 06.04.21 22:47, RK K wrote: In this scenario, in-order for the secondary server to forward the DNS query to an external DNS server, is it required to enable the recursion in the global options on the secondary servers? yes. To elaborate a little bit on that... Indeed that is how it works, unfortunately. When you start using forwarders or stubs, recursion needs to be enabled because you're no longer looking for your own authoritative data only. What I've learned from this list is that you should split authoritative and recursive service. In other words, you need two types of servers: 1) A non-recursive one in the backend containing your authoritative zones only. This can be a hidden master setup, somewhat like what you are using now. 2) The one your users access has recursion enabled, and contains stubs to the authoritative service. Obviously, it can also contain stubs (or forwarders) to anywhere else. At the same time it is performing full recursive service unless you take authority for the root zone. May I ask what is the reasoning behind your current setup (pointing your users to the non-recursive service)? What would you like to achieve? What would you like to prevent? Bye, Marki ___ 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: forwarding zone setup from a BIND slave (without recursion?)
On 06.04.21 22:47, RK K wrote: We have a set of BIND primary servers (MASTERs) and a set of secondary servers (slaves to the MASTERs). The secondary BIND DNS servers disabled recursion ( with "*recursion no;" *) in the global options. All the applications/systems do use secondary DNS servers for name resolution. Now there is a need to configure a forwarding zone in the "secondary DNS servers" to an external DNS server. In this scenario, in-order for the secondary server to forward the DNS query to an external DNS server, is it required to enable the recursion in the global options on the secondary servers? yes. Based on reference material, I did not see such a requirement. But my observation is the query is not getting forwarded ( tried to check using the packet trace) When recursion is enabled, the query is getting forwarded. The BIND version I am using is 9.11.2.x. -- 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. It's now safe to throw off your computer. ___ 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
forwarding zone setup from a BIND slave (without recursion?)
All, We have a set of BIND primary servers (MASTERs) and a set of secondary servers (slaves to the MASTERs). The secondary BIND DNS servers disabled recursion ( with "*recursion no;" *) in the global options. All the applications/systems do use secondary DNS servers for name resolution. Now there is a need to configure a forwarding zone in the "secondary DNS servers" to an external DNS server. In this scenario, in-order for the secondary server to forward the DNS query to an external DNS server, is it required to enable the recursion in the global options on the secondary servers? Based on reference material, I did not see such a requirement. But my observation is the query is not getting forwarded ( tried to check using the packet trace) When recursion is enabled, the query is getting forwarded. The BIND version I am using is 9.11.2.x. Appreciate your ideas and help. Thank you Kind Regards, Ravi Kota ___ 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: Authority and forwarding, but not recursion/iteration
Hammers and nails... On Tue, 16 Mar 2021, Marki wrote: On 3/13/2021 12:11 AM, Tony Finch wrote: Marki wrote: But if you need granular filtering, that could become a lot of views... Yes, I think RPZ is really designed to be a ban hammer [...] Standard DNS server software (not only Bind) Is RPZ "standard" now? I know that the US Govt is now calling it "PDNS"... does not provide for easy whitelist filtering, only blacklists seem to be "en vogue". Not true at all. There are large cesspools of compute which I block by default and selectively whitelist into with RPZ. This requires (and it should be SOP) two local RPZs, a whitelist followed by a blacklist. If it's in the whitelist it's shiny otherwise it gets filtered by the RPZ dedicated to replicating the coldest regions of interstellar space. The cesspools in particular are handled via CNAME chains. That seems to be SOP, too. So images.example.com is a CNAME to random.cesspool-example.com. In the second list there is a catchall for *.cesspool-example.com which rewrites it all NXDOMAIN. Because I like example.com, I put a rule in the first list to leave *.example.com alone. (This does a really good job with third party cookies before they even get to the browser.) In fact, this should be SOP: whenever you use cesspool compute or servers, CNAME it from your actual domain m'kay? Granted there are some people who cleverly use random.cesspool-example.com in their dynamically generated pages. So clever. Ooops, not so much. In fact, this blocks stuff I never even thought of blocking but am glad I did! There can also be issues with TTLs, where you had something in a compute cesspool blocked and then you created an exception for it, and it won't resolve until the TTL expires. I solve that locally by disabling local cache: all stub resolver queries (getaddrinfo() I'm looking at you!) get sent to the local recursive/caching resolver by disabling nscd or rewriting TTLs if necessary. For extra credit you can hunt nameservers, although that's perhaps better handled in the mail filtering pipeline, which is where it really seems to matter. -- Fred Morris ___ 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: Authority and forwarding, but not recursion/iteration
On 3/13/2021 12:11 AM, Tony Finch wrote: Marki wrote: But if you need granular filtering, that could become a lot of views... Yes, I think RPZ is really designed to be a ban hammer for dealing with abuse, rather than a general-purpose access control mechanism. If you need to get really fancy then you should look at dnsdist which can be programmed in Lua. Tony. Just posting this to give everyone my conclusions and how this turned out. Standard DNS server software (not only Bind) does not provide for easy whitelist filtering, only blacklists seem to be "en vogue". Like trusting nearly everyone, except, oh well, what did they teach in security class? Never mind, we're currently rolling out dnsdist. @Tony Your feedback has been very to the point, knowledgeable and fruitful. If you've got an Amazon wishlist (almost wrote whitelist lol) let me know :D ___ 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: Authority and forwarding, but not recursion/iteration
Marki wrote: > > But if you need granular filtering, that could become a lot of views... Yes, I think RPZ is really designed to be a ban hammer for dealing with abuse, rather than a general-purpose access control mechanism. If you need to get really fancy then you should look at dnsdist which can be programmed in Lua. Tony. -- f.anthony.n.finchhttps://dotat.at/ Fitzroy: Westerly 4 to 6 in south, otherwise 7 to severe gale 9. Rough in south, otherwise very rough or high. Showers, squally in north. Good, occasionally poor. ___ 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: Authority and forwarding, but not recursion/iteration
On 3/9/2021 10:21 PM, Tony Finch wrote: Marki wrote: I'm not sure about the flexibility of RPZ; it doesn't seem that I can have rules like "client 1.2.3.4 is allowed to look up example.com but client 1.2.3.5 is not". You can have multiple response-policy zones, which are matched in the order they are listed in the configuration. You could perhaps have a zone listed early that uses RPZ-CLIENT-IP triggers and a PASSTHRU policy for non-sandboxed clients, then have a zone containing QNAME triggers (with liberal use of wildcards) and PASSTHRU policy (again) for just the permitted internal names, and finally a catch-all zone (wildcard to match any qname) with an NXDOMAIN policy to deny external names for sandboxed clients. (You can equally well combine the first two into a single zone, depending on whether you want more single-purpose RPZs or fewer multi-purpose ones.) Probably the setup would be more straightforward if there was a view for sandboxed clients and one or more views for those that are not. Concerning the non-sandboxed (or less-sandboxed view), I still fail to see how RPZ would allow me to define conditionals like "Host 1.2.3.4 is allowed to resolve example.com" (and nothing else). AFAICS you can either trigger on the client ip and allow (or deny) all names, or trigger on the name to be resolved and allow (or deny) for all clients, but not a combination thereof. You could create a view that matches 1.2.3.4 and include an RPZ that allows to use example.com. But if you need granular filtering, that could become a lot of views... Marki ___ 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: Authority and forwarding, but not recursion/iteration
Marki wrote: > > Concerning static-stub: Using a (bogus) forwarder together with "forward > first" (default) seems to work (Note: using "forward only" gives SERVFAIL). > All outside requests get a SERVFAIL even with "forward first" but that's an > esthetic problem. Yes, SERVFAIL is ugly - I should have mentioned that. > I'm not sure about the flexibility of RPZ; it doesn't seem that I can > have rules like "client 1.2.3.4 is allowed to look up example.com but > client 1.2.3.5 is not". You can have multiple response-policy zones, which are matched in the order they are listed in the configuration. You could perhaps have a zone listed early that uses RPZ-CLIENT-IP triggers and a PASSTHRU policy for non-sandboxed clients, then have a zone containing QNAME triggers (with liberal use of wildcards) and PASSTHRU policy (again) for just the permitted internal names, and finally a catch-all zone (wildcard to match any qname) with an NXDOMAIN policy to deny external names for sandboxed clients. (You can equally well combine the first two into a single zone, depending on whether you want more single-purpose RPZs or fewer multi-purpose ones.) Tony. -- f.anthony.n.finchhttps://dotat.at/ Forties, Cromarty, Forth: South or southeast 5 to 7, increasing gale 8 or severe gale 9 for a time. Slight or moderate, becoming rough later, occasionally very rough except in Forth. Rain. Good, becoming moderate or poor for a time. ___ 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: Authority and forwarding, but not recursion/iteration
On 3/9/2021 6:03 PM, Tony Finch wrote:
Marki wrote:
I am seeking a combination of either a combined configuration on one, or a
config of several different DNS servers together to achieve the following:
* Some clients should be able to resolve authoritative local zones as well as
some forwarded zones.
* Other clients should be able to resolve all of that _plus_ be able to make
recursive queries to the internet (or use a global forwarder).
In my opinion, as a rule of thumb it's best to avoid per-zone forwarding
in BIND. (Microsoft DNS really encourages it, but be wary because it
doesn't mean the same thing there!)
It's helpful if you have a clear distinction between authoritative-only
nameservers on the one hand, and on the other hand recursive nameservers
that provide service to stub resolvers. It sounds like you want to provide
an internal-only sandbox to some recursive clients, but it's best to think
of it as a restricted recursive service, not a special kind of
authoritative service. Especially because stub clients expect to receive
fully-resolved answers, so if you point them at an authoritative-only
server you'll get obscure problems in cases like cross-zone CNAMEs.
[ The distinction is that auth-only servers expect to receive only RD=0
(recursion not desired) queries from recursive DNS servers and reply with
RA=0 (recursion not available), whereas recursive servers expect to
receive RD=1 (recursion desired) from stub resolvers and reply with RA=1
(recursion available). ]
When you need to tie authoritative zones together, use delegation records
pointing at your authoritative-only name servers. Then your recursive
servers can just follow delegations in the usual way without special
configuration. (If you are doing split DNS, this can get fiddly, which is
a good reason for keeping your split DNS as simple as possible.)
[ You can configure recursive servers to have their own authoritative
copies of your zones - it can be faster and more resilient - but you can
think of it as a shortcut or optimization, on top of the fundamental
auth/rec split. ]
Your question is now, how to provide a restricted recursive service?
The top-level setup is to have multiple views with match-clients clauses
to determine whether a client is in the sandbox view or not. Then the
question is how to configure the sandbox view.
I don't know of any particularly good ways in BIND :-) When you want
default-allow with a block list, then RPZ is ideal, but you are asking for
default-deny with an allow list.
You might be able to configure a dummy default forwarder, and tell BIND it
is bogus, something like this (which I have not tested!):
forwarders A.B.C.D;
server A.B.C.D {
bogus yes;
};
then have per-zone static-stub configuration for allowed zones, pointing
at working authoritative servers.
Alternatively it might be easier to make other software such as dnsdist do
what you want. Or, consider implementing the sandbox with firewalls at the
network level. (But are you sandboxing DNS because of worries about
data exfiltration?)
Tony.
You're right about the sandbox and exfiltration (C2 etc.). What can't go
out, can't hurt. We don't need public DNS resolution on most client
systems since all Internet access is filtered through an explicit proxy.
Thus, why not just turn it off instead of trying to protect it using
expensive appliances and whatnot.
Concerning static-stub: Using a (bogus) forwarder together with "forward
first" (default) seems to work (Note: using "forward only" gives
SERVFAIL). All outside requests get a SERVFAIL even with "forward first"
but that's an esthetic problem. Another approach might be to disable
forwarders altogether (make it fully recursive) and then use RPZ. This
would however mean that stubs/forwarded zones would need to be
whitelisted, which means one or two more lines of configuration (and a
nice reply from the server).
As you mentioned there would be other view(s) for clients that actually
need public DNS. Correctly firewalling means blocking everything unless
it is allowed (whitelisting principle). I'm not sure about the
flexibility of RPZ; it doesn't seem that I can have rules like "client
1.2.3.4 is allowed to look up example.com but client 1.2.3.5 is not".
Marki
___
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: Authority and forwarding, but not recursion/iteration
Marki wrote:
>
> I am seeking a combination of either a combined configuration on one, or a
> config of several different DNS servers together to achieve the following:
>
> * Some clients should be able to resolve authoritative local zones as well as
> some forwarded zones.
>
> * Other clients should be able to resolve all of that _plus_ be able to make
> recursive queries to the internet (or use a global forwarder).
In my opinion, as a rule of thumb it's best to avoid per-zone forwarding
in BIND. (Microsoft DNS really encourages it, but be wary because it
doesn't mean the same thing there!)
It's helpful if you have a clear distinction between authoritative-only
nameservers on the one hand, and on the other hand recursive nameservers
that provide service to stub resolvers. It sounds like you want to provide
an internal-only sandbox to some recursive clients, but it's best to think
of it as a restricted recursive service, not a special kind of
authoritative service. Especially because stub clients expect to receive
fully-resolved answers, so if you point them at an authoritative-only
server you'll get obscure problems in cases like cross-zone CNAMEs.
[ The distinction is that auth-only servers expect to receive only RD=0
(recursion not desired) queries from recursive DNS servers and reply with
RA=0 (recursion not available), whereas recursive servers expect to
receive RD=1 (recursion desired) from stub resolvers and reply with RA=1
(recursion available). ]
When you need to tie authoritative zones together, use delegation records
pointing at your authoritative-only name servers. Then your recursive
servers can just follow delegations in the usual way without special
configuration. (If you are doing split DNS, this can get fiddly, which is
a good reason for keeping your split DNS as simple as possible.)
[ You can configure recursive servers to have their own authoritative
copies of your zones - it can be faster and more resilient - but you can
think of it as a shortcut or optimization, on top of the fundamental
auth/rec split. ]
Your question is now, how to provide a restricted recursive service?
The top-level setup is to have multiple views with match-clients clauses
to determine whether a client is in the sandbox view or not. Then the
question is how to configure the sandbox view.
I don't know of any particularly good ways in BIND :-) When you want
default-allow with a block list, then RPZ is ideal, but you are asking for
default-deny with an allow list.
You might be able to configure a dummy default forwarder, and tell BIND it
is bogus, something like this (which I have not tested!):
forwarders A.B.C.D;
server A.B.C.D {
bogus yes;
};
then have per-zone static-stub configuration for allowed zones, pointing
at working authoritative servers.
Alternatively it might be easier to make other software such as dnsdist do
what you want. Or, consider implementing the sandbox with firewalls at the
network level. (But are you sandboxing DNS because of worries about
data exfiltration?)
Tony.
--
f.anthony.n.finchhttps://dotat.at/
Irish Sea: South or southwest 4 to 6, increasing 7 to severe gale 9 for a
time. Slight or moderate, becoming rough or very rough for a time. Rain.
Moderate occasionally poor.
___
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: Authority and forwarding, but not recursion/iteration
Where is it sending recursive queries if it owns the root? On Sun, Mar 7, 2021 at 3:06 AM Marki wrote: > I tried that. When you configure no global forwarders it's going to > recurse because recursion needs to be enabled for the individual forwarded > zones to work. You'd have to specify a fake global forwarder which looks > like a hack. > > > On March 7, 2021 10:09:49 AM GMT+01:00, Crist Clark < > cjc+bind-us...@pumpky.net> wrote: >> >> Two views. The view that does not do internet DNS claims authority for >> the root and does not global forward. The entire DNS is just the zones >> defined in the view, which can be authoritative or forwarded. The other >> view has the global forward-only to upstream resolvers. >> >> On Sat, Mar 6, 2021 at 3:34 PM Marki wrote: >> >>> I'm not sure: >>> >>> > Some clients should be able to resolve authoritative local zones as >>> well as some forwarded zones. >>> >>> And only that. "forward only;" doesn't cut it, in case you mean the >>> global option. That would still forward everything else somewhere else. The >>> requirement is to _only_ resolve local stuff for some clients. >>> On 3/6/2021 8:48 PM, Crist Clark wrote: >>> >>> forward only; >>> >>> On Fri, Mar 5, 2021 at 5:19 PM Marki wrote: >>> >>>> Hello, >>>> >>>> I am seeking a combination of either a combined configuration on one, >>>> or >>>> a config of several different DNS servers together to achieve the >>>> following: >>>> * Some clients should be able to resolve authoritative local zones as >>>> well as some forwarded zones. >>>> * Other clients should be able to resolve all of that _plus_ be able to >>>> make recursive queries to the internet (or use a global forwarder). >>>> All hosts use the same DNS servers, this should not be made about the >>>> clients but rather be configurable on the server. >>>> >>>> Now the problems are the following: >>>> * Since I need forwarders I can't turn off recursion. >>>> * Since I can't turn off recursion I can't prevent it to go and try to >>>> resolve from root DNS. >>>> >>>> How do I do one (local authority and forwarders) but not the other >>>> (iterative lookups on the Internet)? >>>> >>>> Thanks, >>>> >>>> Marki >>>> >>>> ___ >>>> 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 >>> >> ___ > 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: Authority and forwarding, but not recursion/iteration
I tried that. When you configure no global forwarders it's going to recurse because recursion needs to be enabled for the individual forwarded zones to work. You'd have to specify a fake global forwarder which looks like a hack. On March 7, 2021 10:09:49 AM GMT+01:00, Crist Clark wrote: >Two views. The view that does not do internet DNS claims authority for >the >root and does not global forward. The entire DNS is just the zones >defined >in the view, which can be authoritative or forwarded. The other view >has >the global forward-only to upstream resolvers. > >On Sat, Mar 6, 2021 at 3:34 PM Marki wrote: > >> I'm not sure: >> >> > Some clients should be able to resolve authoritative local zones as >well >> as some forwarded zones. >> >> And only that. "forward only;" doesn't cut it, in case you mean the >global >> option. That would still forward everything else somewhere else. The >> requirement is to _only_ resolve local stuff for some clients. >> On 3/6/2021 8:48 PM, Crist Clark wrote: >> >> forward only; >> >> On Fri, Mar 5, 2021 at 5:19 PM Marki >wrote: >> >>> Hello, >>> >>> I am seeking a combination of either a combined configuration on >one, or >>> a config of several different DNS servers together to achieve the >>> following: >>> * Some clients should be able to resolve authoritative local zones >as >>> well as some forwarded zones. >>> * Other clients should be able to resolve all of that _plus_ be able >to >>> make recursive queries to the internet (or use a global forwarder). >>> All hosts use the same DNS servers, this should not be made about >the >>> clients but rather be configurable on the server. >>> >>> Now the problems are the following: >>> * Since I need forwarders I can't turn off recursion. >>> * Since I can't turn off recursion I can't prevent it to go and try >to >>> resolve from root DNS. >>> >>> How do I do one (local authority and forwarders) but not the other >>> (iterative lookups on the Internet)? >>> >>> Thanks, >>> >>> Marki >>> >>> ___ >>> 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 >> ___ 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: Authority and forwarding, but not recursion/iteration
Two views. The view that does not do internet DNS claims authority for the root and does not global forward. The entire DNS is just the zones defined in the view, which can be authoritative or forwarded. The other view has the global forward-only to upstream resolvers. On Sat, Mar 6, 2021 at 3:34 PM Marki wrote: > I'm not sure: > > > Some clients should be able to resolve authoritative local zones as well > as some forwarded zones. > > And only that. "forward only;" doesn't cut it, in case you mean the global > option. That would still forward everything else somewhere else. The > requirement is to _only_ resolve local stuff for some clients. > On 3/6/2021 8:48 PM, Crist Clark wrote: > > forward only; > > On Fri, Mar 5, 2021 at 5:19 PM Marki wrote: > >> Hello, >> >> I am seeking a combination of either a combined configuration on one, or >> a config of several different DNS servers together to achieve the >> following: >> * Some clients should be able to resolve authoritative local zones as >> well as some forwarded zones. >> * Other clients should be able to resolve all of that _plus_ be able to >> make recursive queries to the internet (or use a global forwarder). >> All hosts use the same DNS servers, this should not be made about the >> clients but rather be configurable on the server. >> >> Now the problems are the following: >> * Since I need forwarders I can't turn off recursion. >> * Since I can't turn off recursion I can't prevent it to go and try to >> resolve from root DNS. >> >> How do I do one (local authority and forwarders) but not the other >> (iterative lookups on the Internet)? >> >> Thanks, >> >> Marki >> >> ___ >> 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 > ___ 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: Authority and forwarding, but not recursion/iteration
I'm not sure: > Some clients should be able to resolve authoritative local zones as well as some forwarded zones. And only that. "forward only;" doesn't cut it, in case you mean the global option. That would still forward everything else somewhere else. The requirement is to _only_ resolve local stuff for some clients. On 3/6/2021 8:48 PM, Crist Clark wrote: forward only; On Fri, Mar 5, 2021 at 5:19 PM Marki <mailto:bind-us...@lists.roth.lu>> wrote: Hello, I am seeking a combination of either a combined configuration on one, or a config of several different DNS servers together to achieve the following: * Some clients should be able to resolve authoritative local zones as well as some forwarded zones. * Other clients should be able to resolve all of that _plus_ be able to make recursive queries to the internet (or use a global forwarder). All hosts use the same DNS servers, this should not be made about the clients but rather be configurable on the server. Now the problems are the following: * Since I need forwarders I can't turn off recursion. * Since I can't turn off recursion I can't prevent it to go and try to resolve from root DNS. How do I do one (local authority and forwarders) but not the other (iterative lookups on the Internet)? Thanks, Marki ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users <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/ <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 <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: Authority and forwarding, but not recursion/iteration
forward only; On Fri, Mar 5, 2021 at 5:19 PM Marki wrote: > Hello, > > I am seeking a combination of either a combined configuration on one, or > a config of several different DNS servers together to achieve the > following: > * Some clients should be able to resolve authoritative local zones as > well as some forwarded zones. > * Other clients should be able to resolve all of that _plus_ be able to > make recursive queries to the internet (or use a global forwarder). > All hosts use the same DNS servers, this should not be made about the > clients but rather be configurable on the server. > > Now the problems are the following: > * Since I need forwarders I can't turn off recursion. > * Since I can't turn off recursion I can't prevent it to go and try to > resolve from root DNS. > > How do I do one (local authority and forwarders) but not the other > (iterative lookups on the Internet)? > > Thanks, > > Marki > > ___ > 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
Authority and forwarding, but not recursion/iteration
Hello, I am seeking a combination of either a combined configuration on one, or a config of several different DNS servers together to achieve the following: * Some clients should be able to resolve authoritative local zones as well as some forwarded zones. * Other clients should be able to resolve all of that _plus_ be able to make recursive queries to the internet (or use a global forwarder). All hosts use the same DNS servers, this should not be made about the clients but rather be configurable on the server. Now the problems are the following: * Since I need forwarders I can't turn off recursion. * Since I can't turn off recursion I can't prevent it to go and try to resolve from root DNS. How do I do one (local authority and forwarders) but not the other (iterative lookups on the Internet)? Thanks, Marki ___ 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: Bind 9.10 recursion issues
Why are you using forwarders? These cloudflare servers are not
authoritive for cat.com and don't seem to be open resolvers either.
Lyle Giese
LCR Computer Services, Inc.
On 12/4/20 12:48 PM, Wade Blackwell wrote:
Good morning from the West Coast,
It’s been a while since I’ve setup an authoritative
bind server from scratch so I may be missing something very basic.
First time in a docker container, besides the point but maybe it plays
(this looks like a configuration issue in Bind). I’m getting the
following errors when trying to resolve domains external to my own;
---snip---
17:30:04.843 REFUSED unexpected RCODE resolving './NS/IN':
172.64.32.142#53
04-Dec-2020 17:30:04.859 REFUSED unexpected RCODE resolving
'www.cat.com/A/IN <http://www.cat.com/A/IN>': 172.64.32.142#53
04-Dec-2020 17:30:04.865 REFUSED unexpected RCODE resolving './NS/IN':
172.64.33.136#53
04-Dec-2020 17:30:04.867 REFUSED unexpected RCODE resolving
'E.ROOT-SERVERS.NET//IN <http://E.ROOT-SERVERS.NET//IN>':
172.64.32.142#53
04-Dec-2020 17:30:04.867 REFUSED unexpected RCODE resolving
'G.ROOT-SERVERS.NET//IN <http://G.ROOT-SERVERS.NET//IN>':
172.64.32.142#53
04-Dec-2020 17:30:04.877 REFUSED unexpected RCODE resolving
'www.cat.com/A/IN <http://www.cat.com/A/IN>': 172.64.33.136#53
04-Dec-2020 17:30:04.883 REFUSED unexpected RCODE resolving './NS/IN':
108.162.192.142#53
04-Dec-2020 17:30:04.884 REFUSED unexpected RCODE resolving
'E.ROOT-SERVERS.NET//IN <http://E.ROOT-SERVERS.NET//IN>':
108.162.192.142#53
04-Dec-2020 17:30:04.889 REFUSED unexpected RCODE resolving
'G.ROOT-SERVERS.NET//IN <http://G.ROOT-SERVERS.NET//IN>':
108.162.192.142#53
04-Dec-2020 17:30:04.897 REFUSED unexpected RCODE resolving
'www.cat.com/A/IN <http://www.cat.com/A/IN>': 108.162.192.142#53
04-Dec-2020 17:30:04.906 REFUSED unexpected RCODE resolving
'E.ROOT-SERVERS.NET//IN <http://E.ROOT-SERVERS.NET//IN>':
172.64.33.136#53
04-Dec-2020 17:30:04.906 REFUSED unexpected RCODE resolving './NS/IN':
108.162.193.136#53
---end---
You’ll notice the above are Cloudflare resolvers (pete/roxy)
I get a DNSSEC related error when the same resolution is attempted on
the OpenDNS servers
---snip---
04-Dec-2020 17:30:05.084 validating ./DNSKEY: unable to find a DNSKEY
which verifies the DNSKEY RRset and also matches a trusted key for '.'
04-Dec-2020 17:30:05.085 no valid KEY resolving './DNSKEY/IN':
208.67.220.220#53
04-Dec-2020 17:30:05.108 validating ./DNSKEY: unable to find a DNSKEY
which verifies the DNSKEY RRset and also matches a trusted key for '.'
04-Dec-2020 17:30:05.108 no valid KEY resolving './DNSKEY/IN':
208.67.222.222#53
---end---
Named.conf has the correct sources for queries;
---snip---
acl permit {
172.30.0.0/16 <http://172.30.0.0/16>;
---end---
Named.conf.options has the correct forwarders, recursion and query
statements (ignore syntax, pulling partials);
---snip---
forwarders {
108.162.193.136;
172.64.33.136;
108.162.192.142;
172.64.32.142;
173.245.58.142;
208.67.220.220;
208.67.222.222;
};
allow-recursion {
172.30.0.0/16 <http://172.30.0.0/16>;
allow-query {
172.30.0.0/16 <http://172.30.0.0/16>;
---end---
What am I missing here (flame away…)?
-W
“Solo puedo explicártelo a ti. No puedo entenderlo por ti”
___
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
Bind 9.10 recursion issues
Good morning from the West Coast,
It’s been a while since I’ve setup an authoritative bind
server from scratch so I may be missing something very basic. First time in
a docker container, besides the point but maybe it plays (this looks like a
configuration issue in Bind). I’m getting the following errors when trying
to resolve domains external to my own;
---snip---
17:30:04.843 REFUSED unexpected RCODE resolving './NS/IN': 172.64.32.142#53
04-Dec-2020 17:30:04.859 REFUSED unexpected RCODE resolving '
www.cat.com/A/IN': 172.64.32.142#53
04-Dec-2020 17:30:04.865 REFUSED unexpected RCODE resolving './NS/IN':
172.64.33.136#53
04-Dec-2020 17:30:04.867 REFUSED unexpected RCODE resolving '
E.ROOT-SERVERS.NET//IN': 172.64.32.142#53
04-Dec-2020 17:30:04.867 REFUSED unexpected RCODE resolving '
G.ROOT-SERVERS.NET//IN': 172.64.32.142#53
04-Dec-2020 17:30:04.877 REFUSED unexpected RCODE resolving '
www.cat.com/A/IN': 172.64.33.136#53
04-Dec-2020 17:30:04.883 REFUSED unexpected RCODE resolving './NS/IN':
108.162.192.142#53
04-Dec-2020 17:30:04.884 REFUSED unexpected RCODE resolving '
E.ROOT-SERVERS.NET//IN': 108.162.192.142#53
04-Dec-2020 17:30:04.889 REFUSED unexpected RCODE resolving '
G.ROOT-SERVERS.NET//IN': 108.162.192.142#53
04-Dec-2020 17:30:04.897 REFUSED unexpected RCODE resolving '
www.cat.com/A/IN': 108.162.192.142#53
04-Dec-2020 17:30:04.906 REFUSED unexpected RCODE resolving '
E.ROOT-SERVERS.NET//IN': 172.64.33.136#53
04-Dec-2020 17:30:04.906 REFUSED unexpected RCODE resolving './NS/IN':
108.162.193.136#53
---end---
You’ll notice the above are Cloudflare resolvers (pete/roxy)
I get a DNSSEC related error when the same resolution is attempted on the
OpenDNS servers
---snip---
04-Dec-2020 17:30:05.084 validating ./DNSKEY: unable to find a DNSKEY which
verifies the DNSKEY RRset and also matches a trusted key for '.'
04-Dec-2020 17:30:05.085 no valid KEY resolving './DNSKEY/IN':
208.67.220.220#53
04-Dec-2020 17:30:05.108 validating ./DNSKEY: unable to find a DNSKEY which
verifies the DNSKEY RRset and also matches a trusted key for '.'
04-Dec-2020 17:30:05.108 no valid KEY resolving './DNSKEY/IN':
208.67.222.222#53
---end---
Named.conf has the correct sources for queries;
---snip---
acl permit {
172.30.0.0/16;
---end---
Named.conf.options has the correct forwarders, recursion and query
statements (ignore syntax, pulling partials);
---snip---
forwarders {
108.162.193.136;
172.64.33.136;
108.162.192.142;
172.64.32.142;
173.245.58.142;
208.67.220.220;
208.67.222.222;
};
allow-recursion {
172.30.0.0/16;
allow-query {
172.30.0.0/16;
---end---
What am I missing here (flame away…)?
-W
“Solo puedo explicártelo a ti. No puedo entenderlo por ti”
___
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: DNS security, amplification attacks and recursion
On Tue, 7 Jul 2020, Tony Finch wrote: Brett Delmage wrote: On Tue, 7 Jul 2020, Tony Finch wrote: minimal-any yes; Why only reduce and not eliminate? The reason is a bit subtle. If an ANY query comes via a recursive resolver, it is much better to give the resolver an answer so that it will put an entry in its cache... This is a very interesting and clear explanation. Thanks for taking the time to share this Tony. TIL :-) Brett ___ 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: DNS security, amplification attacks and recursion
Brett Delmage wrote: > On Tue, 7 Jul 2020, Tony Finch wrote: > > > > minimal-any yes; > > Why only reduce and not eliminate? The reason is a bit subtle. If an ANY query comes via a recursive resolver, it is much better to give the resolver an answer so that it will put an entry in its cache. The cache entry will stop more ANY queries from being sent from the resolver to the upstream auth server, as long as its TTL lasts. If the auth server does not answer, or sends a REFUSED error, the resolver is likely to retry, which increases worthless traffic rather than suppressing it, and the resolver may decide the auth server is lame which will cause knock-on problems for legitimate queries. There are some scenarios where reflection attacks go through multiple servers. If you can get cache entries into those servers then the attack traffic gets suppressed closer to its source. There have been quite a lot of attacks that work like this: * an ISP has a huge number of customers with crappy home routers, that can act as open recursive resolvers * an arsehole decides to use these crappy home routers in a reflection / amplification DDoS attack * the crappy home routers forward the attack queries to their ISP's recursive servers; these recursive servers are legitimate and well configured but suffer from bad client devices * the recursive servers resolve the queries against some third party authoritative servers If the recursive servers cache the responses, then the auth servers should not be much affected by the attack: most of the traffic is answered from the ISP caches, and maybe the home router caches if they have them. But if the auth servers don't answer, or send REFUSED errors, then the recursive servers are going to keep retrying queries, and thereby relay a very large proportion of the attack traffic to the auth servers. Sadness will follow. Note that RRL does not help in this scenario, because from the auth server's point of view the ISP resolvers are legitimate clients, which RRL can observe from their retry behaviour. RRL is designed for attacks where the spoofed queries go direct to the auth server, which is not happening in this case. When this happened to us (when my servers were the third party auth servers) the DDoS attack was hitting a very large number of ISPs, so our auth servers were getting ANY queries via huge numbers of recursive servers. Extra unfortunately, the ANY response was too big to fit in UDP, so all the resolvers were trying to query over TCP. And our auth servers did not have enough TCP capacity to handle the load. Much sadness. (It didn't take us offline because our off-site auth servers were differently configured and able to keep answering.) So I implemented minimal-any to stop it from happening again. Tony. -- f.anthony.n.finchhttp://dotat.at/ Fisher, German Bight: Westerly veering northwesterly 4 to 6, decreasing 3 later in south German Bight. Moderate, occasionally rough at first. Mainly fair. Mainly good. ___ 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: DNS security, amplification attacks and recursion
On 07 Jul 2020, at 12:06, Michael De Roover wrote: > On 7/7/20 4:06 PM, Tony Finch wrote: > >> max-udp-size 1420; >> https://dnsflagday.net/2020/ > Interesting, I wasn't aware of this campaign. I don't know if I'm > knowledgeable enough on UDP to be able to make educated decisions on this > myself but I look forward to its eventual release. The URL has a good explanation of this setting and it looks like 1420 is a more than adequate packet size. >From the page: An EDNS buffer size of 1232 bytes will avoid fragmentation on nearly all current networks. This is based on an MTU of 1280, which is required by the IPv6 specification, minus 48 bytes for the IPv6 and UDP headers. Sunce 1420 is still well under the MTU on most connections (usually 1500, sometimes 1492) and well above the required, I suspect this is fine as well. I've gone ahead and added to to my named.conf with a comment linking to Tony's message. -- "Are you pondering what I'm pondering?" "I think so, Mr. Brain, but if the sun'll come out tomorrow, what's it doing right now?" ___ 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: DNS security, amplification attacks and recursion
On Tue, 7 Jul 2020, Shumon Huque wrote: Cloudflare themselves now implement the "minimal any" behavior described in this spec: https://tools.ietf.org/html/rfc8482 cloudflare.com. 3789 IN HINFO "RFC8482" "" Gee, that's a pretty minimal answer! Thanks.___ 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: DNS security, amplification attacks and recursion
On Tue, Jul 7, 2020 at 2:21 PM Brett Delmage wrote: > On Tue, 7 Jul 2020, Tony Finch wrote: > > > Reduce the size of responses to ANY queries, which are a favourite tool > of > > amplification attacks. There's basically no downside to this one, in my > > opinion, but I'm biased because I implemented it. > > > > minimal-any yes; > > Why only reduce and not eliminate? > > Can ANY responses be disabled completely with an option? > > This article at cloudflare > https://blog.cloudflare.com/deprecating-dns-any-meta-query-type/ > states that they have deprecated it because it wasn't being used. They > should know! This was posted over 5 years ago, in 2015. > Cloudflare themselves now implement the "minimal any" behavior described in this spec: https://tools.ietf.org/html/rfc8482 Responding to ANY with NOTIMP, REFUSED, or unknown RCODEs, or not responding at all results in undesirable follow-on behaviour from DNS resolvers (mostly aggressive retries). Shumon. --- $ dig @ns1.cloudflare.com. cloudflare.com. ANY ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54526 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;cloudflare.com.IN ANY ;; ANSWER SECTION: cloudflare.com. 3789IN HINFO "RFC8482" "" ___ 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: DNS security, amplification attacks and recursion
On Tue, 7 Jul 2020, Tony Finch wrote: Reduce the size of responses to ANY queries, which are a favourite tool of amplification attacks. There's basically no downside to this one, in my opinion, but I'm biased because I implemented it. minimal-any yes; Why only reduce and not eliminate? Can ANY responses be disabled completely with an option? This article at cloudflare https://blog.cloudflare.com/deprecating-dns-any-meta-query-type/ states that they have deprecated it because it wasn't being used. They should know! This was posted over 5 years ago, in 2015. Brett ___ 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: DNS security, amplification attacks and recursion
On 7/7/20 4:06 PM, Tony Finch wrote:
An auth-only server can also be used for amplification attacks that use
its authoritative zones - these attacks don't have to use recursion.
There are a few ways to mitigate auth-only amplification attacks.
Response rate limiting is very effective. Start off by putting the
following in your options{} section, and look in the BIND ARM for other
directives you can put in the rate-limit{} section.
rate-limit {
responses-per-second 10;
};
That's a really useful option to have, I didn't know about this yet. It
seems like that could take care of the brunt of amplification attacks
already. Definitely going to add this in, thanks!
Set a maximum UDP packet size, to suppress fragmented packets. The DNS
flag day 2020 campaign will make this a standard setting. For a long time
I have used:
max-udp-size 1420;
https://dnsflagday.net/2020/
A downside of small UDP responses is more truncated packets and more
queries over TCP, but there are still more ways to reduce response size
which also reduce truncation.
Interesting, I wasn't aware of this campaign. I don't know if I'm
knowledgeable enough on UDP to be able to make educated decisions on
this myself but I look forward to its eventual release.
Reduce the size of responses to ANY queries, which are a favourite tool of
amplification attacks. There's basically no downside to this one, in my
opinion, but I'm biased because I implemented it.
minimal-any yes;
I've heard of these ANY queries being preferred for amplification
attacks as well, since the responses are often so large... I don't think
that there would be any downsides to this either, in fact I've never
actually seen a legitimate application use it... Probably best to lock
down indeed.
You can also reduce the size of other answers. In theory this option might
force resolvers to make more queries to get records that by default would
appear in the additional section, but I think in practice resolvers make
these queries anyway because of RFC 2181 trustworthiness logic, and
because applications (such as SMTP servers) find it easier to query
directly than use additional records. So on my auth servers I set:
minimal-responses yes;
Hmm, for the authoritative name servers this might be a good idea yeah..
Those are authoritative only (i.e. `recursion no`). So for clients
querying those, the NS records served in the additional section at least
should already be known to the client anyway... I mean that's why
they're there to begin with, so they must already know that information
from the DNS servers higher up the chain. And another query if needed,
saves traffic either way I suppose.
Thanks a lot for the detailed reply, I really appreciate it :)
--
Met vriendelijke groet / Best regards,
Michael De Roover
___
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: DNS security, amplification attacks and recursion
@lbutlr wrote:
>
> > rate-limit { responses-per-second 10; };
>
> Does that apply to local queries as well (for example, a mail server may
> easily make a whole lot of queries to 127.0.0.1, and rate limiting it
> would at the very least affect logging and could delay mail if the MTA
> cannot verify DNS.
I don't recommend using response rate limiting on recursive servers.
The principle behind RRL is that auth servers are queried by resolvers
with caches, and a correctly-functioning cache will not repeat the same
query very frequently, so it is reasonable to apply a rate limit on the
auth servers.
Recursive servers, on the other hand, are often queried by stub resolvers
without caches. The query rate is then entirely driven by the application
workload, and you can't apply a rate limit on the recursive server without
causing serious trouble for the application.
It can be especially bad because traditional cacheless stub resolvers are
not good at error recovery, and when RRL hits, their retry strategy is
likely to increase the query rate observed by the server, making things
worse.
If you are running an oldskool multi-purpose server that is recursive for
its own daemons but authoritative for others, then you can use the
`rate-limit { exempt-clients }` option so that RRL doesn't apply to
recursive clients. But I wouldn't recommend a setup like this. (My auth
servers have their /etc/resolv.conf pointing at my recursive service.)
> Do these setting also need to be applied to the secondary servers?
The settings I described are for public authoritative servers, i.e ones
that appear in NS records. These servers can be primary or secondary (but
are usually secondary).
Secondary servers don't necessarily appear in NS records, and if they
don't they are less likely to be exposed to this kind of attack.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Southeast Iceland: Westerly or southwesterly, 3 to 5, becoming variable 3 or
less later in north. Moderate. Showers. Good.
___
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: DNS security, amplification attacks and recursion
On 07 Jul 2020, at 08:06, Tony Finch wrote:
Excellent post, and a nice summary of some best practices.
I have a couple of questions.
> Response rate limiting is very effective. Start off by putting the
> following in your options{} section, and look in the BIND ARM for other
> directives you can put in the rate-limit{} section.
>
> rate-limit { responses-per-second 10; };
Does that apply to local queries as well (for example, a mail server may easily
make a whole lot of queries to 127.0.0.1, and rate limiting it would at the
very least affect logging and could delay mail if the MTA cannot verify DNS.
Do these setting also need to be applied to the secondary servers?
--
What's another word for Thesaurus?
___
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: DNS security, amplification attacks and recursion
Michael De Roover wrote:
>
> Said friend said to me that he tested my authoritative name servers and
> found them to be not vulnerable. [snip] They do not respond to recursive
> queries. It appears that the test of whether a server is "vulnerable" or
> not has to do with this. The command used to test this was apparently
> "dig +short test.openresolver.com TXT @your.name.server".
OK, that iss all right and correct, but there is (of course) a bit more to
this issue.
As you already know, the most basic thing to avoid is not being an open
recursive server. Out of the box, BIND has a recursion ACL that only
allows queries from directly connected networks, so you won't have this
problem without making an explicit configuration mistake. Normally for an
authoritative-only server, you should set `recursion no` to lock it down
more tightly.
An auth-only server can also be used for amplification attacks that use
its authoritative zones - these attacks don't have to use recursion.
There are a few ways to mitigate auth-only amplification attacks.
Response rate limiting is very effective. Start off by putting the
following in your options{} section, and look in the BIND ARM for other
directives you can put in the rate-limit{} section.
rate-limit {
responses-per-second 10;
};
Especially if you have DNSSEC signed zones then there are a few extra
things you can do to reduce the size of your response packets, which
reduces the attacker's amplification factor, and makes you less likely to
be abused.
Set a maximum UDP packet size, to suppress fragmented packets. The DNS
flag day 2020 campaign will make this a standard setting. For a long time
I have used:
max-udp-size 1420;
https://dnsflagday.net/2020/
A downside of small UDP responses is more truncated packets and more
queries over TCP, but there are still more ways to reduce response size
which also reduce truncation.
Reduce the size of responses to ANY queries, which are a favourite tool of
amplification attacks. There's basically no downside to this one, in my
opinion, but I'm biased because I implemented it.
minimal-any yes;
You can also reduce the size of other answers. In theory this option might
force resolvers to make more queries to get records that by default would
appear in the additional section, but I think in practice resolvers make
these queries anyway because of RFC 2181 trustworthiness logic, and
because applications (such as SMTP servers) find it easier to query
directly than use additional records. So on my auth servers I set:
minimal-responses yes;
If you are signing zones with DNSSEC, consider doing an algorithm
rollover to ECDSA p256 (algorithm 13) because this has much smaller
signatures than RSA. Algorithm rollovers are not particularly easy,
because you need a good grasp of the DNSSEC key timing parameters and how
and when to swap over your DS records. (There used to be even more
gotchas, so it is getting easier, honest!)
Finally, there's the built-in _bind CHAOS view. This has very strict
response rate limiting by default, but if you want to be super careful
you can set `version none` and `hostname none` to lock it down further.
(I don't bother with this.)
Here endeth the brain dump.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Mull of Galloway to Mull of Kintyre including the Firth of Clyde and North
Channel: Variable, 2 to 4. Moderate at first near the Mull of Kintyre,
otherwise smooth or slight. Showers. Mainly good.
___
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: DNS security, amplification attacks and recursion
On Tue, Jul 07, 2020 at 03:00:13PM +0200, Michael De Roover wrote a message of 46 lines which said: > The command used to test this was apparently "dig +short > test.openresolver.com TXT @your.name.server". ANY instead of TXT may be more efficient (specially with +dnssec), if the goal is to get the maximum amplification. Of course, if the server implements RFC 8482, ANY won't help. > Authoritative name servers may not need a huge DNS infrastructure > for a small-ish zone (say under 1k records), but recursors on the > scale of Google and Cloudflare in particular (not sure how popular > Quad9 is so far).. those use massive infrastructure including > anycast and everything! I'd consider it safe to assume that their > servers are at least on the order of 100Gbps cumulatively, if not > more. This is precisely what makes them dangerous. They are good reflectors (good from the point of view of the attacker). On the other hand, they typically implement various forms of rate-limiting, and they are monitored closely by knowledgeable professionals so, they may not be good reflectors after all. > If these would be vulnerable to amplification attacks just because > they allow recursion, They're not vulnerable, this attack works by reflection (just like the NTP attack you mentioned) so they are not the potential victims, they could be used as helpers. ___ 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
DNS security, amplification attacks and recursion
Hello, Recently I discussed with a friend of mine the idea of NTP and DNS in the context of denial of service attacks. In NTP this amplification attack is done with the monlist command (that should honestly never have been publicly available due to its purpose being pretty much entirely debugging-related). The DNS version was rather unclear to me however. Said friend said to me that he tested my authoritative name servers and found them to be not vulnerable. I don't run the latest and greatest of BIND at all, I mean it's Debian distribution packages we're talking about there... But they were set up to be exclusively authoritative. They do not respond to recursive queries. It appears that the test of whether a server is "vulnerable" or not has to do with this. The command used to test this was apparently "dig +short test.openresolver.com TXT @your.name.server". That's simply a recursive query of what appears to be an arbitrary record to me. This also meant that supposedly the recursive DNS servers from Google, Cloudflare and Quad9 were all considered vulnerable. I find this very hard to believe. Authoritative name servers may not need a huge DNS infrastructure for a small-ish zone (say under 1k records), but recursors on the scale of Google and Cloudflare in particular (not sure how popular Quad9 is so far).. those use massive infrastructure including anycast and everything! I'd consider it safe to assume that their servers are at least on the order of 100Gbps cumulatively, if not more. If these would be vulnerable to amplification attacks just because they allow recursion, wouldn't skids be jumping on this like there's no tomorrow? It doesn't make any sense to me. This seems to be not very well documented online (or more likely my search terms aren't right), so yeah... I wonder why the idea of recursion became associated with a vulnerable server in the first place. -- Met vriendelijke groet / Best regards, Michael De Roover ___ 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: How to disable recursion on ONE domain? (Bind-9.11.14)
Sorry, my bad. (Actually it doesn’t matter because it serves well as example
that static-stub configuration fails when the servers are unreachable and it
doesn’t recurse.)
But even with server-addresses it properly servfails when the static-stub
addresses are unreachable.
Perhaps it behaves differently when there’s already cached content?
I suggest you run test BIND instance with -d 99 to see what’s happening.
Ondřej
--
Ondřej Surý — ISC
> On 15 May 2020, at 18:22, Chris Palmer wrote:
>
> Hi Ondřej
>
> At first glance your suggestion looked like what I had done. But...
> I used:
>
> view "a" {
> match-clients { 172.16.n.n/24; }
> allow-recursion { any; };
> zone "x.y.zzz" {
>type static-stub;
>server-addresses {
> 10.n.n.n;
> 10.n.n.m;
>};
> };
> };
>
> If the 10.n.n.n addresses are not reachable, it still recurses and does a
> public query resulting in an NXDOMAIN. However, I don't know what I have done
> differently this time, but the NXDOMAIN is no longer being cached. Each
> attempt causes it to query upstream, and when I bring the VPN up it uses the
> 10.n.n.n server correctly. Which is acceptable, although I'm still unsure why
> it is recursing at all (or at least why I can't prevent it).
>
> Out of curiosity I then changed to what you suggested:
>
> view "a" {
> match-clients { 172.16.n.n/24; }
> allow-recursion { any; };
> zone "x.y.zzz" {
>type static-stub;
>server-names {
> "10.n.n.n";
> "10.n.n.m";
>};
> };
> };
>
> This ALWAYS gives a SERVFAIL though regardless of whether the 10.n.n.n
> addresses are reachable or not...
>
> So I have something that works, although it is sub-optimal when the VPN is
> down.
>
> Cheers, Chris
>
>> On 15/05/2020 14:26, Ondřej Surý wrote:
>> Hi Chris,
>> why don’t you just delegate the x.y.zzz to the server in the VPN?
>> Generally, the static-stub should work in this case, but your email doesn’t
>> have
>> enough details why it would not.
>> I properly get SERVFAILs with this minimal config:
>> zone "sury.org" {
>> type static-stub;
>> server-names {
>> "192.168.1.1";
>> };
>> };
>> and named -g reports:
>> 15-May-2020 15:25:00.015 network unreachable resolving '192.168.1.1/A/IN':
>> 2001:503:c27::2:30#53
>> 15-May-2020 15:25:00.015 network unreachable resolving
>> '192.168.1.1//IN': 2001:503:c27::2:30#53
>> Cheers,
>> Ondrej
>> --
>> Ondřej Surý
>> ond...@isc.org
>>>> On 15 May 2020, at 14:40, Chris Palmer wrote:
>>>
>>> Hi Ondřej
>>>
>>> That could work for eliminating the caching delay when the VPN comes up.
>>> I'd just have to get that into the VPN config so people didn't have to do
>>> it manually.
>>>
>>> Is there any way to stop the recursion for that domain happening in the
>>> first place though?
>>>
>>> Thanks, Chris
>>>
>>>
>>> On 15/05/2020 13:34, Ondřej Surý wrote:
>>>> Hi Chris,
>>>> when your vpn comes up, you need to issue:
>>>> rndc flushtree
>>>> command to the BIND 9 instance.
>>>> Ondrej
>>>> --
>>>> Ondřej Surý
>>>> ond...@isc.org
>>>>> On 15 May 2020, at 14:16, Chris Palmer via bind-users
>>>>> wrote:
>>>>>
>>>>> There is much discussion about recursion but I can't find anything that
>>>>> matches this use case...
>>>>>
>>>>> - In-house Bind-9.11.14 server, master for some local zones, recursion
>>>>> enabled; not accessible from external networks
>>>>> - Two views for in-house networks
>>>>> - Intermittent VPN access from in-house network to another private
>>>>> network that is master for DNS zone x.y.zzz; this network is not publicly
>>>>> reachable
>>>>> - Need queries from one of our views for x.y.zzz to be sent to the static
>>>>> address for the x.y.zzz server that is only reachable via the VPN
>>>>> - When the VPN is not connected, need the lookup on to fail/timeout
>>>>> rather than go through the recursion path
>>>>> - When the VPN is again connected need lookups to succeed without undue
>>>>> delay.
>>>>>
>>>>> Within the required view I have tried a zone with type forward
>>>>> (specifying forwarders and forward only)
re: How to disable recursion on ONE domain? (Bind-9.11.14)
Would adding the following to the zone config work?
forwarders {};
Regards,
Bob
___
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: How to disable recursion on ONE domain? (Bind-9.11.14)
On Fri, May 15, 2020 at 12:22 PM Chris Palmer via bind-users <
bind-users@lists.isc.org> wrote:
> Hi Ondřej
>
> At first glance your suggestion looked like what I had done. But...
> I used:
>
> view "a" {
>match-clients { 172.16.n.n/24; }
>allow-recursion { any; };
>zone "x.y.zzz" {
> type static-stub;
> server-addresses {
>10.n.n.n;
>10.n.n.m;
> };
>};
> };
>
> If the 10.n.n.n addresses are not reachable, it still recurses and does
> a public query resulting in an NXDOMAIN. However, I don't know what I
> have done differently this time, but the NXDOMAIN is no longer being
> cached. Each attempt causes it to query upstream, and when I bring the
> VPN up it uses the 10.n.n.n server correctly. Which is acceptable,
> although I'm still unsure why it is recursing at all (or at least why I
> can't prevent it).
>
> Out of curiosity I then changed to what you suggested:
>
> view "a" {
>match-clients { 172.16.n.n/24; }
>allow-recursion { any; };
>zone "x.y.zzz" {
> type static-stub;
> server-names {
>"10.n.n.n";
>"10.n.n.m";
> };
>};
> };
>
> This ALWAYS gives a SERVFAIL though regardless of whether the 10.n.n.n
> addresses are reachable or not...
>
"server-names" must be given a list of NAMES, not addresses. "10.n.n.n" is
probably not the right name, looks more like an address.
--
Bob Harold
>
> So I have something that works, although it is sub-optimal when the VPN
> is down.
>
> Cheers, Chris
>
> On 15/05/2020 14:26, Ondřej Surý wrote:
> > Hi Chris,
> >
> > why don’t you just delegate the x.y.zzz to the server in the VPN?
> >
> > Generally, the static-stub should work in this case, but your email
> doesn’t have
> > enough details why it would not.
> >
> > I properly get SERVFAILs with this minimal config:
> >
> > zone "sury.org" {
> >type static-stub;
> >server-names {
> > "192.168.1.1";
> >};
> > };
> >
> > and named -g reports:
> >
> > 15-May-2020 15:25:00.015 network unreachable resolving '192.168.1.1/A/IN':
> 2001:503:c27::2:30#53
> > 15-May-2020 15:25:00.015 network unreachable resolving '
> 192.168.1.1//IN': 2001:503:c27::2:30#53
> >
> > Cheers,
> > Ondrej
> > --
> > Ondřej Surý
> > ond...@isc.org
> >
> >> On 15 May 2020, at 14:40, Chris Palmer wrote:
> >>
> >> Hi Ondřej
> >>
> >> That could work for eliminating the caching delay when the VPN comes
> up. I'd just have to get that into the VPN config so people didn't have to
> do it manually.
> >>
> >> Is there any way to stop the recursion for that domain happening in the
> first place though?
> >>
> >> Thanks, Chris
> >>
> >>
> >> On 15/05/2020 13:34, Ondřej Surý wrote:
> >>> Hi Chris,
> >>> when your vpn comes up, you need to issue:
> >>> rndc flushtree
> >>> command to the BIND 9 instance.
> >>> Ondrej
> >>> --
> >>> Ondřej Surý
> >>> ond...@isc.org
> >>>> On 15 May 2020, at 14:16, Chris Palmer via bind-users <
> bind-users@lists.isc.org> wrote:
> >>>>
> >>>> There is much discussion about recursion but I can't find anything
> that matches this use case...
> >>>>
> >>>> - In-house Bind-9.11.14 server, master for some local zones,
> recursion enabled; not accessible from external networks
> >>>> - Two views for in-house networks
> >>>> - Intermittent VPN access from in-house network to another private
> network that is master for DNS zone x.y.zzz; this network is not publicly
> reachable
> >>>> - Need queries from one of our views for x.y.zzz to be sent to the
> static address for the x.y.zzz server that is only reachable via the VPN
> >>>> - When the VPN is not connected, need the lookup on to fail/timeout
> rather than go through the recursion path
> >>>> - When the VPN is again connected need lookups to succeed without
> undue delay.
> >>>>
> >>>> Within the required view I have tried a zone with type forward
> (specifying forwarders and forward only), and also a zone of type
> static-stub (specifying server-addresses). Both work fine when the VPN is
> up. Both have two problems though when the VPN is disconnected:
> >>>>(a) the queries are recursed and an NXDOMAIN response cached.
> >>>>(b) When the VPN comes back up the cached NXDOMAIN is served
> until it expires.
> >>>>
> >>>> I have been trying to force a SERVFAIL when the specified servers for
> that domain are unreachable, rather than recursing. And presumably that
> would then cause the queries to quickly flow to the required servers once
> they are reachable again. Is that possible, or is there another approach to
> this problem?
> >>>>
> >>>> Many thanks, Chris
>
>
___
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: How to disable recursion on ONE domain? (Bind-9.11.14)
Hi Ondřej
At first glance your suggestion looked like what I had done. But...
I used:
view "a" {
match-clients { 172.16.n.n/24; }
allow-recursion { any; };
zone "x.y.zzz" {
type static-stub;
server-addresses {
10.n.n.n;
10.n.n.m;
};
};
};
If the 10.n.n.n addresses are not reachable, it still recurses and does
a public query resulting in an NXDOMAIN. However, I don't know what I
have done differently this time, but the NXDOMAIN is no longer being
cached. Each attempt causes it to query upstream, and when I bring the
VPN up it uses the 10.n.n.n server correctly. Which is acceptable,
although I'm still unsure why it is recursing at all (or at least why I
can't prevent it).
Out of curiosity I then changed to what you suggested:
view "a" {
match-clients { 172.16.n.n/24; }
allow-recursion { any; };
zone "x.y.zzz" {
type static-stub;
server-names {
"10.n.n.n";
"10.n.n.m";
};
};
};
This ALWAYS gives a SERVFAIL though regardless of whether the 10.n.n.n
addresses are reachable or not...
So I have something that works, although it is sub-optimal when the VPN
is down.
Cheers, Chris
On 15/05/2020 14:26, Ondřej Surý wrote:
Hi Chris,
why don’t you just delegate the x.y.zzz to the server in the VPN?
Generally, the static-stub should work in this case, but your email doesn’t have
enough details why it would not.
I properly get SERVFAILs with this minimal config:
zone "sury.org" {
type static-stub;
server-names {
"192.168.1.1";
};
};
and named -g reports:
15-May-2020 15:25:00.015 network unreachable resolving '192.168.1.1/A/IN':
2001:503:c27::2:30#53
15-May-2020 15:25:00.015 network unreachable resolving '192.168.1.1//IN':
2001:503:c27::2:30#53
Cheers,
Ondrej
--
Ondřej Surý
ond...@isc.org
On 15 May 2020, at 14:40, Chris Palmer wrote:
Hi Ondřej
That could work for eliminating the caching delay when the VPN comes up. I'd
just have to get that into the VPN config so people didn't have to do it
manually.
Is there any way to stop the recursion for that domain happening in the first
place though?
Thanks, Chris
On 15/05/2020 13:34, Ondřej Surý wrote:
Hi Chris,
when your vpn comes up, you need to issue:
rndc flushtree
command to the BIND 9 instance.
Ondrej
--
Ondřej Surý
ond...@isc.org
On 15 May 2020, at 14:16, Chris Palmer via bind-users
wrote:
There is much discussion about recursion but I can't find anything that matches
this use case...
- In-house Bind-9.11.14 server, master for some local zones, recursion enabled;
not accessible from external networks
- Two views for in-house networks
- Intermittent VPN access from in-house network to another private network that
is master for DNS zone x.y.zzz; this network is not publicly reachable
- Need queries from one of our views for x.y.zzz to be sent to the static
address for the x.y.zzz server that is only reachable via the VPN
- When the VPN is not connected, need the lookup on to fail/timeout rather than
go through the recursion path
- When the VPN is again connected need lookups to succeed without undue delay.
Within the required view I have tried a zone with type forward (specifying
forwarders and forward only), and also a zone of type static-stub (specifying
server-addresses). Both work fine when the VPN is up. Both have two problems
though when the VPN is disconnected:
(a) the queries are recursed and an NXDOMAIN response cached.
(b) When the VPN comes back up the cached NXDOMAIN is served until it
expires.
I have been trying to force a SERVFAIL when the specified servers for that
domain are unreachable, rather than recursing. And presumably that would then
cause the queries to quickly flow to the required servers once they are
reachable again. Is that possible, or is there another approach to this problem?
Many thanks, Chris
___
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: How to disable recursion on ONE domain? (Bind-9.11.14)
Hi Chris,
why don’t you just delegate the x.y.zzz to the server in the VPN?
Generally, the static-stub should work in this case, but your email doesn’t have
enough details why it would not.
I properly get SERVFAILs with this minimal config:
zone "sury.org" {
type static-stub;
server-names {
"192.168.1.1";
};
};
and named -g reports:
15-May-2020 15:25:00.015 network unreachable resolving '192.168.1.1/A/IN':
2001:503:c27::2:30#53
15-May-2020 15:25:00.015 network unreachable resolving '192.168.1.1//IN':
2001:503:c27::2:30#53
Cheers,
Ondrej
--
Ondřej Surý
ond...@isc.org
> On 15 May 2020, at 14:40, Chris Palmer wrote:
>
> Hi Ondřej
>
> That could work for eliminating the caching delay when the VPN comes up. I'd
> just have to get that into the VPN config so people didn't have to do it
> manually.
>
> Is there any way to stop the recursion for that domain happening in the first
> place though?
>
> Thanks, Chris
>
>
> On 15/05/2020 13:34, Ondřej Surý wrote:
>> Hi Chris,
>> when your vpn comes up, you need to issue:
>> rndc flushtree
>> command to the BIND 9 instance.
>> Ondrej
>> --
>> Ondřej Surý
>> ond...@isc.org
>>> On 15 May 2020, at 14:16, Chris Palmer via bind-users
>>> wrote:
>>>
>>> There is much discussion about recursion but I can't find anything that
>>> matches this use case...
>>>
>>> - In-house Bind-9.11.14 server, master for some local zones, recursion
>>> enabled; not accessible from external networks
>>> - Two views for in-house networks
>>> - Intermittent VPN access from in-house network to another private network
>>> that is master for DNS zone x.y.zzz; this network is not publicly reachable
>>> - Need queries from one of our views for x.y.zzz to be sent to the static
>>> address for the x.y.zzz server that is only reachable via the VPN
>>> - When the VPN is not connected, need the lookup on to fail/timeout rather
>>> than go through the recursion path
>>> - When the VPN is again connected need lookups to succeed without undue
>>> delay.
>>>
>>> Within the required view I have tried a zone with type forward (specifying
>>> forwarders and forward only), and also a zone of type static-stub
>>> (specifying server-addresses). Both work fine when the VPN is up. Both have
>>> two problems though when the VPN is disconnected:
>>> (a) the queries are recursed and an NXDOMAIN response cached.
>>> (b) When the VPN comes back up the cached NXDOMAIN is served until it
>>> expires.
>>>
>>> I have been trying to force a SERVFAIL when the specified servers for that
>>> domain are unreachable, rather than recursing. And presumably that would
>>> then cause the queries to quickly flow to the required servers once they
>>> are reachable again. Is that possible, or is there another approach to this
>>> problem?
>>>
>>> Many thanks, Chris
>>> ___
>>> 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
signature.asc
Description: Message signed with OpenPGP
___
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: How to disable recursion on ONE domain? (Bind-9.11.14)
Hi Ondřej That could work for eliminating the caching delay when the VPN comes up. I'd just have to get that into the VPN config so people didn't have to do it manually. Is there any way to stop the recursion for that domain happening in the first place though? Thanks, Chris On 15/05/2020 13:34, Ondřej Surý wrote: Hi Chris, when your vpn comes up, you need to issue: rndc flushtree command to the BIND 9 instance. Ondrej -- Ondřej Surý ond...@isc.org On 15 May 2020, at 14:16, Chris Palmer via bind-users wrote: There is much discussion about recursion but I can't find anything that matches this use case... - In-house Bind-9.11.14 server, master for some local zones, recursion enabled; not accessible from external networks - Two views for in-house networks - Intermittent VPN access from in-house network to another private network that is master for DNS zone x.y.zzz; this network is not publicly reachable - Need queries from one of our views for x.y.zzz to be sent to the static address for the x.y.zzz server that is only reachable via the VPN - When the VPN is not connected, need the lookup on to fail/timeout rather than go through the recursion path - When the VPN is again connected need lookups to succeed without undue delay. Within the required view I have tried a zone with type forward (specifying forwarders and forward only), and also a zone of type static-stub (specifying server-addresses). Both work fine when the VPN is up. Both have two problems though when the VPN is disconnected: (a) the queries are recursed and an NXDOMAIN response cached. (b) When the VPN comes back up the cached NXDOMAIN is served until it expires. I have been trying to force a SERVFAIL when the specified servers for that domain are unreachable, rather than recursing. And presumably that would then cause the queries to quickly flow to the required servers once they are reachable again. Is that possible, or is there another approach to this problem? Many thanks, Chris ___ 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: How to disable recursion on ONE domain? (Bind-9.11.14)
Hi Chris, when your vpn comes up, you need to issue: rndc flushtree command to the BIND 9 instance. Ondrej -- Ondřej Surý ond...@isc.org > On 15 May 2020, at 14:16, Chris Palmer via bind-users > wrote: > > There is much discussion about recursion but I can't find anything that > matches this use case... > > - In-house Bind-9.11.14 server, master for some local zones, recursion > enabled; not accessible from external networks > - Two views for in-house networks > - Intermittent VPN access from in-house network to another private network > that is master for DNS zone x.y.zzz; this network is not publicly reachable > - Need queries from one of our views for x.y.zzz to be sent to the static > address for the x.y.zzz server that is only reachable via the VPN > - When the VPN is not connected, need the lookup on to fail/timeout rather > than go through the recursion path > - When the VPN is again connected need lookups to succeed without undue delay. > > Within the required view I have tried a zone with type forward (specifying > forwarders and forward only), and also a zone of type static-stub (specifying > server-addresses). Both work fine when the VPN is up. Both have two problems > though when the VPN is disconnected: > (a) the queries are recursed and an NXDOMAIN response cached. > (b) When the VPN comes back up the cached NXDOMAIN is served until it > expires. > > I have been trying to force a SERVFAIL when the specified servers for that > domain are unreachable, rather than recursing. And presumably that would then > cause the queries to quickly flow to the required servers once they are > reachable again. Is that possible, or is there another approach to this > problem? > > Many thanks, Chris > ___ > 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 signature.asc Description: Message signed with OpenPGP ___ 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
How to disable recursion on ONE domain? (Bind-9.11.14)
There is much discussion about recursion but I can't find anything that matches this use case... - In-house Bind-9.11.14 server, master for some local zones, recursion enabled; not accessible from external networks - Two views for in-house networks - Intermittent VPN access from in-house network to another private network that is master for DNS zone x.y.zzz; this network is not publicly reachable - Need queries from one of our views for x.y.zzz to be sent to the static address for the x.y.zzz server that is only reachable via the VPN - When the VPN is not connected, need the lookup on to fail/timeout rather than go through the recursion path - When the VPN is again connected need lookups to succeed without undue delay. Within the required view I have tried a zone with type forward (specifying forwarders and forward only), and also a zone of type static-stub (specifying server-addresses). Both work fine when the VPN is up. Both have two problems though when the VPN is disconnected: (a) the queries are recursed and an NXDOMAIN response cached. (b) When the VPN comes back up the cached NXDOMAIN is served until it expires. I have been trying to force a SERVFAIL when the specified servers for that domain are unreachable, rather than recursing. And presumably that would then cause the queries to quickly flow to the required servers once they are reachable again. Is that possible, or is there another approach to this problem? Many thanks, Chris ___ 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
ipv6, was: Re: Question About Recursion ...
On 2020-04-17 11:40, Tim Daneliuk wrote: On 4/17/20 10:17 AM, julien soula wrote: On Fri, Apr 17, 2020 at 09:56:21AM -0500, Tim Daneliuk wrote: On 4/17/20 9:50 AM, Bob Harold wrote: 'dig' should tell you what address it used, at the bottom of the output - what does it say? ;; Query time: 0 msec ;; SERVER: ::1#53(::1) ;; WHEN: Fri Apr 17 09:53:51 CDT 2020 ;; MSG SIZE rcvd: 83 Does the SERVER line indicate it's trying to get to the local instance via IPV6 or is this just standard notation? (This is an IPV4 only environment). "::1" is locahost in IPv6. It is not the same as 127.0.0.1 . A least, you should add this IP to trustedhosts to check if it works. Aha! That was it. What is curious to me is that bind uses this even in the absence of any IPV6 in the environment. Problem solved. Thanks all! What "absence" is this? You showed us that dig connected to ::1#53, yes, via ipv6. Not having external ipv6 routing is not the same as absence of ipv6. Your system DOES have ipv6 enabled. As others have pointed out, you either need to put ::1 in your ACL, or make a resolv.conf with "nameserver 127.0.0.1". Personally, I always disable the ipv6 module in the OS kernel if there is no connectivity. And Bob (I think it was) mentioned "named -4". Since ipv6 is the future, it's generally the default protocol in many OSs when it is enabled. That's why I suggest disabling it in your kernel, to avoid this and many other problems; not just with dig & named, but with other software as well. ___ 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: Question About Recursion In A Split Horizon Setup
On Fri, Apr 17, 2020 at 12:45 PM Tim Daneliuk wrote: > On 4/17/20 10:17 AM, julien soula wrote: > > On Fri, Apr 17, 2020 at 09:56:21AM -0500, Tim Daneliuk wrote: > >> On 4/17/20 9:50 AM, Bob Harold wrote: > >>> > >>> Agree, that's odd, and not what the man page says. Any chance that > there is some other DNS helper running, like resolved, nscd, dnsmasq, etc? > >> > >> Nope. This is vanilla FreeBSD with vanilla bind running. > >> > >>> 'dig' should tell you what address it used, at the bottom of the > output - what does it say? > >> > >> > >> > >> ;; Query time: 0 msec > >> ;; SERVER: ::1#53(::1) > >> ;; WHEN: Fri Apr 17 09:53:51 CDT 2020 > >> ;; MSG SIZE rcvd: 83 > >> > >> > >> Does the SERVER line indicate it's trying to get to the local instance > via > >> IPV6 or is this just standard notation? (This is an IPV4 only > environment). > > > > "::1" is locahost in IPv6. It is not the same as 127.0.0.1 . A least, > > you should add this IP to trustedhosts to check if it works. > > > > best regard, > > > > > Aha! That was it. What is curious to me is that bind uses this even in > the absence > of any IPV6 in the environment. > > Problem solved. Thanks all! > > > > -- > > > Tim Daneliuk tun...@tundraware.com > PGP Key: http://www.tundraware.com/PGP/ > > As a separate issue: Check the logs to see if BIND is trying to use IPv6 to resolve queries. Look for messages like: address not available resolving with some IPv6 address I have to start named with the "-4" option on my servers that do not yet have IPv6 connectivity. -- Bob Harold ___ 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: Question About Recursion In A Split Horizon Setup
On 17-Apr-20 10:56, Tim Daneliuk wrote: > On 4/17/20 9:50 AM, Bob Harold wrote: >> Agree, that's odd, and not what the man page says. Any chance that there is >> some other DNS helper running, like resolved, nscd, dnsmasq, etc? > Nope. This is vanilla FreeBSD with vanilla bind running. > >> 'dig' should tell you what address it used, at the bottom of the output - >> what does it say? > > > ;; Query time: 0 msec > ;; SERVER: ::1#53(::1) > ;; WHEN: Fri Apr 17 09:53:51 CDT 2020 > ;; MSG SIZE rcvd: 83 > > > Does the SERVER line indicate it's trying to get to the local instance via > IPV6 or is this just standard notation? (This is an IPV4 only environment). > > You seem to be selecting views based on IP address. If the host on which you are running dig is multi-homed, the OS may pick a source address other than what you intend. Use -b to explicitly bind to a particular interface. (Or, if you use TSIG to match views, -k) Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. signature.asc Description: OpenPGP digital signature ___ 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: Question About Recursion In A Split Horizon Setup
On 4/17/20 10:17 AM, julien soula wrote: > On Fri, Apr 17, 2020 at 09:56:21AM -0500, Tim Daneliuk wrote: >> On 4/17/20 9:50 AM, Bob Harold wrote: >>> >>> Agree, that's odd, and not what the man page says. Any chance that there >>> is some other DNS helper running, like resolved, nscd, dnsmasq, etc? >> >> Nope. This is vanilla FreeBSD with vanilla bind running. >> >>> 'dig' should tell you what address it used, at the bottom of the output - >>> what does it say? >> >> >> >> ;; Query time: 0 msec >> ;; SERVER: ::1#53(::1) >> ;; WHEN: Fri Apr 17 09:53:51 CDT 2020 >> ;; MSG SIZE rcvd: 83 >> >> >> Does the SERVER line indicate it's trying to get to the local instance via >> IPV6 or is this just standard notation? (This is an IPV4 only environment). > > "::1" is locahost in IPv6. It is not the same as 127.0.0.1 . A least, > you should add this IP to trustedhosts to check if it works. > > best regard, > Aha! That was it. What is curious to me is that bind uses this even in the absence of any IPV6 in the environment. Problem solved. Thanks all! -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ 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: Question About Recursion In A Split Horizon Setup
On Fri, Apr 17, 2020 at 09:56:21AM -0500, Tim Daneliuk wrote: > On 4/17/20 9:50 AM, Bob Harold wrote: > > > > Agree, that's odd, and not what the man page says. Any chance that there > > is some other DNS helper running, like resolved, nscd, dnsmasq, etc? > > Nope. This is vanilla FreeBSD with vanilla bind running. > > > 'dig' should tell you what address it used, at the bottom of the output - > > what does it say? > > > > ;; Query time: 0 msec > ;; SERVER: ::1#53(::1) > ;; WHEN: Fri Apr 17 09:53:51 CDT 2020 > ;; MSG SIZE rcvd: 83 > > > Does the SERVER line indicate it's trying to get to the local instance via > IPV6 or is this just standard notation? (This is an IPV4 only environment). "::1" is locahost in IPv6. It is not the same as 127.0.0.1 . A least, you should add this IP to trustedhosts to check if it works. best regard, -- Julien ___ 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: Question About Recursion In A Split Horizon Setup
On Fri, Apr 17, 2020 at 11:03 AM Konstantin Stefanov wrote: > On 17.04.2020 17:56, Tim Daneliuk wrote: > > On 4/17/20 9:50 AM, Bob Harold wrote: > >> > >> Agree, that's odd, and not what the man page says. Any chance that > there is some other DNS helper running, like resolved, nscd, dnsmasq, etc? > > > > Nope. This is vanilla FreeBSD with vanilla bind running. > Lately vanilla FreeBSD has unbound as caching and recursive DNS server. > Did you turn it off? > > > > >> 'dig' should tell you what address it used, at the bottom of the output > - what does it say? > > > > > > > > ;; Query time: 0 msec > > ;; SERVER: ::1#53(::1) > > ;; WHEN: Fri Apr 17 09:53:51 CDT 2020 > > ;; MSG SIZE rcvd: 83 > > > > > > Does the SERVER line indicate it's trying to get to the local instance > via > > IPV6 or is this just standard notation? (This is an IPV4 only > environment). > The server is using IPv6 locally, so you need to include "::1" in the "trustedhosts" and view match statements. Or just create /etc/resolv.conf with: nameserver 127.0.0.1 So the man page was right, just not specific. -- Bob Harold > > -- > Konstantin Stefanov > > ___ 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: Question About Recursion In A Split Horizon Setup
On 17.04.2020 17:56, Tim Daneliuk wrote: On 4/17/20 9:50 AM, Bob Harold wrote: Agree, that's odd, and not what the man page says. Any chance that there is some other DNS helper running, like resolved, nscd, dnsmasq, etc? Nope. This is vanilla FreeBSD with vanilla bind running. Lately vanilla FreeBSD has unbound as caching and recursive DNS server. Did you turn it off? 'dig' should tell you what address it used, at the bottom of the output - what does it say? ;; Query time: 0 msec ;; SERVER: ::1#53(::1) ;; WHEN: Fri Apr 17 09:53:51 CDT 2020 ;; MSG SIZE rcvd: 83 Does the SERVER line indicate it's trying to get to the local instance via IPV6 or is this just standard notation? (This is an IPV4 only environment). -- Konstantin Stefanov ___ 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: Question About Recursion In A Split Horizon Setup
On 4/17/20 9:50 AM, Bob Harold wrote: > > Agree, that's odd, and not what the man page says. Any chance that there is > some other DNS helper running, like resolved, nscd, dnsmasq, etc? Nope. This is vanilla FreeBSD with vanilla bind running. > 'dig' should tell you what address it used, at the bottom of the output - > what does it say? ;; Query time: 0 msec ;; SERVER: ::1#53(::1) ;; WHEN: Fri Apr 17 09:53:51 CDT 2020 ;; MSG SIZE rcvd: 83 Does the SERVER line indicate it's trying to get to the local instance via IPV6 or is this just standard notation? (This is an IPV4 only environment). -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ 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
