Re: Saurabh: Want to exclude the MX Record from my RPZ Configuration.

You can not accomplish that task using RPZ. It doesn't allow to substitute/block a specific record and bypass others. Vadim > On 06 Sep 2018, at 22:24, Saurabh Srivastava wrote: > > Dear Bind-Users, > > Greetings of the Day!!! > > I have stuck at one place in my DNS RPZ. > I want to exclude

Saurabh: Want to exclude the MX Record from my RPZ Configuration.

Dear Bind-Users, Greetings of the Day!!! I have stuck at one place in my DNS RPZ. I want to exclude the MX Record for any domain in my RPZ Configration. I only want to keep the A Record of any domain but want to exclude the MX Record of that domain. Can you please help me out to achieve this?

Re: How to avoid to listen on specific interfaces

Appreciate your help. That works. Zhe On 2018年09月07日 01:17, Sten Carlsen wrote: > In the end I had to look in the BIND ARM. > > As I read this, the solution should be: > options { > listen-on { ! 10.0.1.1; any;}; > }; > The first part tells bind to not listen to 10.0.1.1 and the second part

RE: [BIND] RE: KSK Rollover

The kicker was probably this line: Sep 6 15:44:40 ns3 audit: { write } for pid=15447 comm="named" name="named.secroots" dev="dm-0" ino=135707451 scontext=system_u:system_r:named_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file permissive=0 The SELinux context that BIND runs in on a

Re: [BIND] RE: KSK Rollover

This matter has been resolved with input from Evan. I was able to add a file path for secroots to the named.conf file and push the output file to a temp directory that was not permission restricted. secroots-file "/tmp/named.secroots" ; Ultimately when I ran "rndc secroots" it created the

Re: Frequent timeout

On Thu, Sep 6, 2018 at 5:56 PM John W. Blue wrote: > > So that file is full of nothing but queries and no responses which, sadly, is > useless. > > Run: > > tcpdump -s0 -n -i eth0 port domain -w /tmp/domaincapture.pcap > > You don't need all of the extra stuff because -s0 captures the full

RE: Frequent timeout

So that file is full of nothing but queries and no responses which, sadly, is useless. Run: tcpdump -s0 -n -i eth0 port domain -w /tmp/domaincapture.pcap You don't need all of the extra stuff because -s0 captures the full packet. John -Original Message- From: bind-users

RE: [BIND] RE: KSK Rollover

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2018-09-06 at 20:58 +, Brent Swingle wrote: > I left all of the permissions the same and I think they should be > lenient enough: > [root@ns3 named]# ls -lh named.secroots > -rw-rw-rw-. 1 named named 0 Sep 6 13:52 named.secroots Does

RE: [BIND] RE: KSK Rollover

I moved the file from /etc to /var/named and now I get an additional error line printed in /var/log/messages. Sep 6 15:44:40 ns3 named[15443]: received control channel command 'secroots' Sep 6 15:44:40 ns3 named[15443]: could not open secroots dump file 'named.secroots': permission denied Sep

Re: [BIND] RE: KSK Rollover

Hi Brent. In out CentOS box, the named.secroots file is written on /var/named/ You should check permissions there too. Hugo On 20:32 06/09, Brent Swingle wrote: > Evan, > > I ran the command and followed the directions to build out rndc as you have > suggested. However, I am not sure that

RE: KSK Rollover

Evan, I ran the command and followed the directions to build out rndc as you have suggested. However, I am not sure that it made much of a difference. I should have been a little clearer from the beginning. I had worked with rndc to issue other commands and had received what appeared to be

Re: Frequent timeout

On Thu, Sep 6, 2018 at 3:05 PM John W. Blue wrote: > > Alex, > > Have you uploaded this pcap with the SERVFAIL's? I didn't have time to look > at your first upload but can review this one. Thanks very much. I've uploaded the pcap file here. It's about ~100MB compressed, and represents about

RE: Frequent timeout

Alex, Have you uploaded this pcap with the SERVFAIL's? I didn't have time to look at your first upload but can review this one. John -Original Message- From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Alex Sent: Thursday, September 06, 2018 1:49 PM To:

Re: Frequent timeout

Hi, On Mon, Sep 3, 2018 at 12:45 PM Carl Byington wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On Sun, 2018-09-02 at 21:54 -0400, Alex wrote: > > Do you have any other ideas on how I can isolate this problem? > > Run tcpdump on the external ethernet connection. > > tcpdump

Re: KSK Rollover

On Thu, Sep 06, 2018 at 05:34:21PM +, Brent Swingle wrote: > This is the command that does not work and the output received: > [root@ns2 ~]# rndc secroots > rndc: 'secroots' failed: permission denied > [root@ns2 ~]# Have you set up your server to accept rndc commands? If not, run

Re: KSK Rollover

As I personally understand it you can ignore this notice if: a) you are not enforcing DNSSEC validation b) if you are running a version of BIND that supports automatic KSK updates. John Sent from Nine From: Brent Swingle Sent:

KSK Rollover

I recently received an email indicating that our DNS servers are not properly equipped for the planned KSK Rollover that is coming. It leads off with this line "On 11 October 2018, ICANN will change or "roll over" the DNSSEC key signing key (KSK) of the DNS root zone." Reading through the

Re: How to avoid to listen on specific interfaces

In the end I had to look in the BIND ARM. As I read this, the solution should be: options { listen-on { ! 10.0.1.1; any;}; }; The first part tells bind to not listen to 10.0.1.1 and the second part tells bind to listen on any other address. Having the Listen-on statement removes the default

Re: How to avoid to listen on specific interfaces

On 06/09/2018 14.33, He Zhe wrote: > > On 2018年09月06日 20:26, Sten Carlsen wrote: >> >> On 06/09/2018 12.36, He Zhe wrote: >>> Hi, >>> >>> How can I config to let named NOT listen on specific interfaces? Any >>> negation config in options like below? Currently it listens on all >>> interfaces

Re: How to avoid to listen on specific interfaces

On 2018年09月06日 20:26, Sten Carlsen wrote: > > > On 06/09/2018 12.36, He Zhe wrote: >> Hi, >> >> How can I config to let named NOT listen on specific interfaces? Any >> negation config in options like below? Currently it listens on all >> interfaces and compete with other DNS daemons in the

Re: How to avoid to listen on specific interfaces

On 06/09/2018 12.36, He Zhe wrote: > Hi, > > How can I config to let named NOT listen on specific interfaces? Any negation > config in options like below? Currently it listens on all interfaces and > compete with other DNS daemons in the same system. > > options { > listen-on { ! 10.0.1.1; };

How to avoid to listen on specific interfaces

Hi, How can I config to let named NOT listen on specific interfaces? Any negation config in options like below? Currently it listens on all interfaces and compete with other DNS daemons in the same system. options { listen-on { ! 10.0.1.1; }; }; Thanks, Zhe

Re: 'tsig-keygen' vs 'dnssec-keygen' - keysize

dnssec-keygen had -d which set the truncated bits in the .private file for HMACs. tsig-keygen could be extended to look for -bits with -a but yes I meant just edit the resulting algorithm name in the file. Mark > On 6 Sep 2018, at 4:49 pm, Browne, Stuart wrote: > >> >> -Original

RE: 'tsig-keygen' vs 'dnssec-keygen' - keysize

> -Original Message- > From: Evan Hunt [mailto:e...@isc.org] > Sent: Thursday, 6 September 2018 4:35 PM > To: Browne, Stuart > Cc: Mark Andrews; bind-users@lists.isc.org > Subject: Re: 'tsig-keygen' vs 'dnssec-keygen' - keysize > > > Is there no cryptographic difference between the

Re: 'tsig-keygen' vs 'dnssec-keygen' - keysize

On Thu, Sep 06, 2018 at 04:28:23AM +, Browne, Stuart via bind-users wrote: > Ok, then here goes me in my not-really-understanding HMAC properly. > > When using 'dnssec-keygen -a hmac-md5 -b 512 -n HOST some-name' (512 > being the max keysize lited in 'dnssec-keygen -h'), we end up with an 88