That is correct, as I have not setup the TSIG keys yet.
Also, I am still a bit confused on how this code should be implemented in
my conf file. In the example you posted that refers back to the link, where
would I place it in the context of my views on the master? Do I only need
that one stanza on
>
>
> view "insideview" {
>
> match-clients {
>
> internal-key;
>
> !external-key;
>
> internal;
>
> };
>
> server 25.25.25.25 {
>
> keys { internal-key };
>
>
I have successfully setup TSIG keys for "views" using a DNS master/server
pair. Zone transfers are working as expected between the 2 servers for each
view. Before we go live into production with this I need some clarification
on a couple things. Our prod servers are also allowing zone transfers to
I have successfully setup TSIG keys for "views" using a DNS master/server
pair. Zone transfers are working as expected between the 2 servers for each
view. Before we go live into production with this I need some clarification
on a couple things. Our prod servers are also allowing zone transfers to
n Thu, Aug 25, 2016 at 5:14 PM, project722 wrote:
> I have successfully setup TSIG keys for "views" using a DNS master/server
> pair. Zone transfers are working as expected between the 2 servers for each
> view. Before we go live into production with this I need some clarification
> on
___
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
Thanks Bob, that is exactly what I ended up doing. And its working great
now. You are also right about the view selection.
On Fri, Aug 26, 2016 at 3:43 PM, Bob Harold wrote:
>
> On Thu, Aug 25, 2016 at 6:25 PM, project722 wrote:
>
>> Actually, I got to thinking
Lets say my domain is foxtrot.com and we have SPF records for the SMTP
servers on foxtrot.com. Now lets say I have decided I want to allow
alphazulu.com to send mail as foxtrot.I know how to add alphazulu.com to
the SPF but If I wanted to also use DomainKeys or DKIM to authenticate
alphazulu.com wo
lsewhere in your
> infrastructure.
>
> I hope at least some of this makes sense, but if not, ask. DKIM and DMARC
> are fiddly, and a lot of the DKIM advice out there isn't entirely complete
> now that DMARC is on the scene and DMARC builds on top of DKIM and SPF.
>
>
> On
SPF in soft fail, DKIM
> in relaxed mode and DMARC in reporting mode only for the first 15-30 days
> and see how your traffic looks and who is sending on your behalf. Once you
> have a comfortable baseline, start to tighten up your policies.
>
>
>
>
> On Mon, Aug 29, 2016
the headers?
On Mon, Aug 29, 2016 at 9:34 AM, Mike Ragusa wrote:
> Glad to help! If you need a low cost DMARC reporting service, I would
> recommend www.dmarcian.com
>
> On Mon, Aug 29, 2016 at 10:33 AM project722 wrote:
>
>> Thanks guys - very helpful information indeed.
&g
Harold wrote:
>
> On Thu, Aug 25, 2016 at 12:56 PM, project722 wrote:
>
>> I have successfully setup TSIG keys for "views" using a DNS master/server
>> pair. Zone transfers are working as expected between the 2 servers for each
>> view. Before we go live into p
Thanks Bob, I will look into this. Do you know if the forwarders feature is
supported in Bind 9.8.2?
On Wed, Sep 7, 2016 at 9:38 AM, Bob Harold wrote:
>
> On Tue, Sep 6, 2016 at 5:23 PM, project722 wrote:
>
>> I'm interested in the "view forwarding" method. I
2016 at 11:37 AM, project722 wrote:
>
>> Thanks Bob, I will look into this. Do you know if the forwarders feature
>> is supported in Bind 9.8.2?
>>
>>
> Yes, forwarders is an old and stable feature.
>
> ("in-view" is new and experimental)
>
> --
&
that view the line:
>empty-zones-enable no;
>
> --
> Bob Harold
>
>
> On Thu, Sep 8, 2016 at 9:41 AM, Bob Harold wrote:
>
>>
>> On Thu, Sep 8, 2016 at 9:13 AM, project722 wrote:
>>
>>> Bob, in our prod environment, we are allowing 127.0.0.
21f:afff:fedd:6a26/64
Any help is greatly appreciated.
On Thu, Sep 8, 2016 at 11:33 AM, project722 wrote:
> I am not seeing that but thanks for the heads up. I will keep an eye on
> it.
>
> On Thu, Sep 8, 2016 at 10:14 AM, Bob Harold wrote:
>
>> I changed the subject
I have an interesting problem. I started noticing that when I do a dig
+trace against one of the domains we are authoritative for, we get errors
from our nameservers for "Bad Referral" and you can see where it forwarded
the request back up the namespace tree instead of giving the answer.
Unfortunat
ember 2016 at 11:12, project722 wrote:
>
>> I have an interesting problem. I started noticing that when I do a dig
>> +trace against one of the domains we are authoritative for, we get errors
>> from our nameservers for "Bad Referral" and you can see where it forwarded
&g
Is there a way to mitigate these vulnerabilities outside of updating BIND?
We use RHEL and have to wait on the official patch they provide. Our Bind
version is 9.8.2 for RHEL 6 and 9.9.4 for RHEL 7.
On Thu, Jan 12, 2017 at 9:37 AM, G.W. Haywood
wrote:
> Hello again,
>
> On Thu, 12 Jan 2017, Andr
Hey guys,
We received an email today about one of our recursive DNS servers that did
not support the new KSK for DNSSEC.
On 11 October 2018, ICANN will change or "roll over" the DNSSEC key
signing key (KSK) of the DNS root zone. Based on information from your
netw
's the difference here and with the scenario above in #1? My
concern is that our customers will get servfails when they try to access
sites like this one.
On Thu, Aug 23, 2018 at 6:33 AM Tony Finch wrote:
> project722 wrote:
> >
> > In my named.conf I changed:
> &
Thanks Tony! This was very helpful.
On Thu, Aug 23, 2018 at 8:01 AM Tony Finch wrote:
> project722 wrote:
> >
> > 1) I am still seeing the "no valid signature found" messages in my
> > bind.log.
>
> > ;; validating ncentral.teklinks.com/A: no valid
or do I need to point
named.conf to it? Do I even need this file at all?
On Thu, Aug 23, 2018 at 9:43 AM project722 wrote:
> Thanks Tony! This was very helpful.
>
> On Thu, Aug 23, 2018 at 8:01 AM Tony Finch wrote:
>
>> project722 wrote:
>> >
>> > 1) I am stil
I've got two recursive dns servers running ISC 9.11 and 9.12. We are using
RPZ and I have a whitelist/blacklist exception zone file on both servers. I
need the ability to change it only on one server and have it propogate to
the other servers. My config is working, but I'm getting some delays that
eindl Harald
wrote:
>
>
> Am 21.09.18 um 16:05 schrieb project722:
> > Then, on the "slave", it takes about 15 minutes for the file to actaully
> > update with the new info from the time of the xfer-in. I've tried adding
> > NS records for the slave in the
the regular zone file yet. Is that a correct assumption?
On Fri, Sep 21, 2018 at 12:05 PM Tony Finch wrote:
> project722 wrote:
>
> > But the slave still takes @15 minutes for the new data to get populated
> > in the file.
>
> Use `dig axfr` or `named-compilezone -j` to
anged. (for now)
On Fri, Sep 21, 2018 at 1:28 PM Tony Finch wrote:
> project722 wrote:
>
> > Sounds like to me you are saying that the server would return the updated
> > data, because its in the journal file, regardless of whether its made it
> > into the regular zone fil
Yes, I seem to be learning that the hard way:) My shop is still on Bind
9.8.2 (Red Hat) on our authoritative servers. These new features in 9.11
are nice!
On Fri, Sep 21, 2018 at 4:29 PM Reindl Harald
wrote:
>
> Am 21.09.18 um 20:01 schrieb project722:
> > Are you saying do a zo
28 matches
Mail list logo
