Seems that bind by default allows recursion and it''s not a good idea.
I''m struggling a bit on a couple of systems. These two systems run
sendmail and are nameservers. I have sendmail set to do domain lookups
and bounce if the domain does not exist.
My struggle has been to turn recursion off in bind while allowing
sendmail to do these lookups. I''ve been trying to do this by setting up
allow-recursion in the options section of named.conf. Using something like
allow-recursion {192.1.1.0/24; 192.34.2.6; };
The IPs have been changed to protect the innocent......
Bind is happy with the entry.. sendmail is not and starts bouncing email.
Does anybody have this working and have any hints? I''ve googled and
tested for hours....
Best,
John Hinton
Try adding localhost if you are using the localhost for resolving. So it may
look like
allow-recursion { localhost; 192.1.1.0/24; 192.34.2.6; };
Alternatively, try changing /etc/resolv.conf to a nameserver provided by the
data center you are at.
-----Original Message-----
From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf
Of John Hinton
Sent: 26 March 2006 04:57
To: CentOS mailing list
Subject: [CentOS] Bind Recursion and Sendmail
<snip>
allow-recursion {192.1.1.0/24; 192.34.2.6; };
On Sat, 2006-03-25 at 14:57, John Hinton wrote:> Seems that bind by default allows recursion and it''s not a good idea.It''s a good idea if you expect it to resolve addresses for you. It may not be a good idea for the registered public servers where you expect outside queries for your domains only.> I''m struggling a bit on a couple of systems. These two systems run > sendmail and are nameservers. I have sendmail set to do domain lookups > and bounce if the domain does not exist. > > My struggle has been to turn recursion off in bind while allowing > sendmail to do these lookups. I''ve been trying to do this by setting up > allow-recursion in the options section of named.conf. Using something like > > allow-recursion {192.1.1.0/24; 192.34.2.6; }; > > The IPs have been changed to protect the innocent...... > > Bind is happy with the entry.. sendmail is not and starts bouncing email. > > Does anybody have this working and have any hints? I''ve googled and > tested for hours....If you insist on having recursion off on the public servers configured as primary and secondaries for your domains (and it doesn''t make sense elsewhere), the easy fix is to run other DNS servers configured normally to do your own lookups and use the /etc/resolv.conf entries on your sendmail servers to use them - as you''ll need to do for everything else that wants a DNS server. Your own lookups are controlled entirely by the resolv.conf entries and can be on other machines whether or not you run an instance of named on the local machine. -- Les Mikesell lesmikesell@gmail.com
On 3/25/06, Les Mikesell <lesmikesell@gmail.com> wrote:> If you insist on having recursion off on the public servers > configured as primary and secondaries for your domains (and > it doesn''t make sense elsewhere), the easy fix is to run other > DNS servers configured normally to do your own lookups and use > the /etc/resolv.conf entries on your sendmail servers to use > them - as you''ll need to do for everything else that wants a > DNS server. Your own lookups are controlled entirely by the > resolv.conf entries and can be on other machines whether or not > you run an instance of named on the local machine.Recommended reading -> http://www.cymru.com/Documents/secure-bind-template.html -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety'''' Benjamin Franklin 1775
Les Mikesell wrote:>On Sat, 2006-03-25 at 14:57, John Hinton wrote: > > >>Seems that bind by default allows recursion and it''s not a good idea. >> >> > >It''s a good idea if you expect it to resolve addresses for you. It >may not be a good idea for the registered public servers where >you expect outside queries for your domains only. > > > >>I''m struggling a bit on a couple of systems. These two systems run >>sendmail and are nameservers. I have sendmail set to do domain lookups >>and bounce if the domain does not exist. >> >>My struggle has been to turn recursion off in bind while allowing >>sendmail to do these lookups. I''ve been trying to do this by setting up >>allow-recursion in the options section of named.conf. Using something like >> >>allow-recursion {192.1.1.0/24; 192.34.2.6; }; >> >>The IPs have been changed to protect the innocent...... >> >>Bind is happy with the entry.. sendmail is not and starts bouncing email. >> >>Does anybody have this working and have any hints? I''ve googled and >>tested for hours.... >> >> > >If you insist on having recursion off on the public servers >configured as primary and secondaries for your domains (and >it doesn''t make sense elsewhere), the easy fix is to run other >DNS servers configured normally to do your own lookups and use >the /etc/resolv.conf entries on your sendmail servers to use >them - as you''ll need to do for everything else that wants a >DNS server. Your own lookups are controlled entirely by the >resolv.conf entries and can be on other machines whether or not >you run an instance of named on the local machine. > > >At the suggestion of some notes on DNSReport.com, I tried turning recursion off and when I did, it broke sendmail. All of my upstream DNS'' have recursion turned on, and from what I gather about the mess there is a chance of dns poisoning with recursion on. Sam
Sam Drinkard wrote:> At the suggestion of some notes on DNSReport.com, I tried turning > recursion off and when I did, it broke sendmail. All of my upstream > DNS'' have recursion turned on, and from what I gather about the mess > there is a chance of dns poisoning with recursion on.You can turn recursion off only on name servers that will answer queries from other name servers. You can not turn recursion off on name servers that answer queries from clients. The resolver library is not supposed to perform recursion itself. That''s the job of name server. That''s why it broke your Sendmail. The resolver libraries are usually too dumb to perform recursive lookups them self, and might be even prevented to do so by firewalls. Also, it would be waste of your network bandwidth since you''d loose effects of caching that name servers are performing. Said that, on name servers that are supposed to answer queries from clients, you should be able to allow recursion only for specific clients. If you have a valid reason to do so. That basically means name server will not be particularly useful to clients not on the list. This might be a good idea if you have only one name server, serving both internal network and Internet (not such a good idea, IMO). Question for OP, what''s the content of /etc/resolv.conf? Do you have "nameserver 127.0.0.1" inthere by any chance? That would explain why it hasn''t worked, since 127.0.0.1 was not on the list of hosts allowed to do recursive lookups.
Aleksandar Milivojevic wrote:> > Question for OP, what''s the content of /etc/resolv.conf? Do you have > "nameserver 127.0.0.1" inthere by any chance? That would explain why > it hasn''t worked, since 127.0.0.1 was not on the list of hosts allowed > to do recursive lookups. >Ahh yes... I have resolv.conf set to nameserver 127.0.0.1 and it''s own IP, and also have included secondary and tertiary nameserver entries... my three nameservers. So, at this point I''m planning to use allow-recursion { localhost; 127.0.0.1; <ip of local class C>; <ip of 1st remote nameserver>; <ip of second remote nameserver>; }; in the options section of named.conf. Will do this later tonight.. in the morning.. and see if mail continues to flow. Unless someone can come up with a really good reason for not doing this. Apparently, there is the potential for someone on no more than a dialup, to completely fill as much as a T-1 with DNS requests if recursion is left on. This really is about equal to a bug.. although it clearly is not... but for sure should be considered a security issue. For others coming into the middle of this... this would be for registered nameservers only as I understand it. Best, John Hinton
John Hinton wrote:> allow-recursion { localhost; 127.0.0.1; <ip of local class C>; <ip of > 1st remote nameserver>; <ip of second remote nameserver>; };Remove localhost. 127.0.0.1 is localhost.
Aleksandar Milivojevic wrote:> Sam Drinkard wrote: > >> At the suggestion of some notes on DNSReport.com, I tried turning >> recursion off and when I did, it broke sendmail. All of my upstream >> DNS'' have recursion turned on, and from what I gather about the mess >> there is a chance of dns poisoning with recursion on. > > > You can turn recursion off only on name servers that will answer > queries from other name servers. You can not turn recursion off on > name servers that answer queries from clients. > > The resolver library is not supposed to perform recursion itself. > That''s the job of name server. That''s why it broke your Sendmail. > The resolver libraries are usually too dumb to perform recursive > lookups them self, and might be even prevented to do so by firewalls. > Also, it would be waste of your network bandwidth since you''d loose > effects of caching that name servers are performing. > > Said that, on name servers that are supposed to answer queries from > clients, you should be able to allow recursion only for specific > clients. If you have a valid reason to do so. That basically means > name server will not be particularly useful to clients not on the > list. This might be a good idea if you have only one name server, > serving both internal network and Internet (not such a good idea, IMO). > > Question for OP, what''s the content of /etc/resolv.conf? Do you have > "nameserver 127.0.0.1" inthere by any chance? That would explain why > it hasn''t worked, since 127.0.0.1 was not on the list of hosts allowed > to do recursive lookups. > > _______________________________________________ > CentOS mailing list > CentOS@centos.org > http://lists.centos.org/mailman/listinfo/centos > >Alexsandar, Thank you for the info. That does make sense now that I think of it. I guess I tend to believe everything I read from certain places without question, and that sometimes turns out to bite me in the rear-end :-) Sam