what is the localnet with netmask 255.255.255.255?

2013-06-20 Thread Rolf Haynberg
Hi Bind-Users and Devs, We are running servers which have an IP netmask of 255.255.255.255 and on which we had configured BIND to "allow-recursion { localnets; };". In this setting I would expect that only requests from the localhost allow recursion as there is no localnet. However, BIND allow

AW: what is the localnet with netmask 255.255.255.255?

2013-06-20 Thread Rolf Haynberg
Sorry, I forgot to mention that the Servers were running "Windows Server 2008". Linux does not seem to be affected. Von: bind-users-bounces+rolf.haynberg=1und1...@lists.isc.org [mailto:bind-users-bounces+rolf.haynberg=1und1...@lists.isc.org] Im Auftrag von Rolf Haynberg Gesendet: Donnerstag, 20

long SPF txt record

2013-06-20 Thread Koehler, Charles
Our email group wants to change the current SPF txt record and replace it with one that is 274 characters. How can I put it in so that it works correctly? Thanks --cwk == Charles Koehler Network Operations - IT Infrastructure UCSF 500 Parnassus Ave P7-14 San Francisc

Re: long SPF txt record

2013-06-20 Thread 风河
You may take a look at google's setting as samples. It's just grouping, I.e, gmail's SPF: $ idig gmail.com txt gmail.com. 300 IN TXT "v=spf1 redirect=_spf.google.com" $ idig _spf.google.com txt _spf.google.com.300 IN TXT "v=spf1 include:_netblocks.

Re: long SPF txt record

2013-06-20 Thread Lawrence K. Chen, P.Eng.
3.1.3. Multiple Strings in a Single DNS record As defined in RFC 1035 sections 3.3.14 and 3.3, a single text DNS record (either TXT or SPF RR types) can be composed of more than one string. If a published record contains multiple strings, then the record MUST be treated as if those strings are

Re: long SPF txt record

2013-06-20 Thread David Miller
On 6/20/2013 1:13 PM, Koehler, Charles wrote: > Our email group wants to change the current SPF txt record and replace it > with one that is 274 characters. > > How can I put it in so that it works correctly? > > Thanks > --cwk >From RFC 4408 ( http://www.ietf.org/rfc/rfc4408.txt ) 3.1.3. M

THANKS! RE: long SPF txt record

2013-06-20 Thread Koehler, Charles
My thanks to everyone who responded. --cwk :-) -Original Message- From: bind-users-bounces+charles.koehler=ucsf@lists.isc.org [mailto:bind-users-bounces+charles.koehler=ucsf@lists.isc.org] On Behalf Of David Miller Sent: Thursday, June 20, 2013 10:26 AM To: bind-users@lists.isc.o

RE: SPF record with include:

2013-06-20 Thread Julie Xu
Hi Steven, Jason, Ged and Bind expert Thanks for the reply. It is great help. However, I need ask more. For this include clause to be added in, I have also need to add DKIM records. we do not use it currently, which means the mx part do not use, but include part will use it. Could I get advi

Secondary DNS question...

2013-06-20 Thread SH Development
Our secondary DNS machine went down (and unnoticed for 24 hours). Today, we had multiple people calling about email that hadn't come in, and trouble with outgoing emails not going out. Our primary DNS was up the whole time. So my question is, why would my secondary being down, and only my prim

DDoS or Hijacking? Some tips for you delete poisoned cache

2013-06-20 Thread ISC Support Engineering Staff
https://www.isc.org/blogs/hijacking-dns-error-ddos-what-happened-and-what-you-can-do/ >From ISC Support Engineering staff ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-user

Re: Secondary DNS question...

2013-06-20 Thread John Miller
Hi Jeff, You've pointed out two separate problems (incoming e-mail not coming in & outgoing e-mail not going out), so some more details about your environment would probably be useful here: - are you combining both authoritative and recursive DNS on the same servers? - Are you using different MXe

Re: Secondary DNS question...

2013-06-20 Thread SH Development
I agree that the incoming and outgoing are different issues. I just mention it because I dealt with issues on both fronts today. The few claims that I had about email not being delivered were proved false by reviewing the logs that showed they had actually been delivered. So I don't think tha