Am 17.03.2016 um 14:53 schrieb Thomas Schulz:
This is not a BIND question but I hope people here will know the answer.
We are switching service providers and I understand that many email SPAM
prevention systems insist on the reverse DNS matching the forward DNS.
If I have two A records for our
Thomas Schulz wrote:
> We are switching service providers and I understand that many email SPAM
> prevention systems insist on the reverse DNS matching the forward DNS.
> If I have two A records for our mail server and the reverse record matches
> one of them, will that be good enough. Or will th
On Fri, Mar 18, 2016 at 10:04:05AM -0400, Thomas Schulz wrote:
> I turns out that it is harder than I thought to allow incomming
> connections from both providers at the same time, so I may not do
> that after all.
Multiple route tables (and rules to choose the appropriate table) are
fairly easy
Mark.
I owe you a virtual beer.. You were right! Thank you
Sorry I am still a n00b at this at times
On Thu, Mar 17, 2016 at 5:24 PM, Majid Mir
wrote:
> I think I Know why it worked on the old server.. it is because there is an
> existing Makefile already.. I am going to rename the existing mak
On 2016-03-18 01:46, Ron wrote:
On Fri, Mar 18, 2016 at 12:12 AM, G.W. Haywood
mailto:b...@jubileegroup.co.uk>> wrote:
Hi there,
On Thu, 17 Mar 2016, Ron wrote:
... in this case it's a supplier who is unable to keeps his
DNS servers
working, and we just want
Another question I have is, how exactly does BIND determine whether the IP
address is valid when setting listen-on or various source options? Although
ifconfig does not show the address, "ip addr" does show it and it is
reachable.
-Original Message-
From: Tony Finch [mailto:d...@dotat.at]
By “upstream” I assume you’re talking about forwarders. If your forwarders are
flakey, have you ever considered simply *not*forwarding*? That would seem to be
a better, structural solution to your problem, than holding DNS data beyond its
cache-expiration time (a really BAD idea).
Using DNS records beyond the owner-published TTL is risky business. You can’t
even know if the same legal entity is providing the content or services
previously published at that address/endpoint, and this uncertainty raises
security and/or liability concerns.
So, they’re not the least bit embarrassed by their abject inability to provide
reliable authoritative nameservice, eh?
In my experience, partners who have egg on their faces because they’ve recently
caused major outages, tend to be more willing than usual to co-operate on ways
to prevent furthe
9 matches
Mail list logo
