date:20180906

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

2018-09-06 Thread Vadim Pavlov via bind-users

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 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?
> Means, in configuration, is it possible to exclude the MX Record of any 
> domain?
> Please hep me out in this regard.
> 
> Thanks,
> Saurabh 
> Thanks & Regards,
> 
> Saurabh
> Email: jp.saur...@gmail.com    
> ___
> 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

___
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

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

2018-09-06 Thread Saurabh Srivastava

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?
Means, in configuration, is it possible to exclude the MX Record of any
domain?
Please hep me out in this regard.

Thanks,
Saurabh
Thanks & Regards,

Saurabh
Email: jp.saur...@gmail.com
___
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

Re: How to avoid to listen on specific interfaces

2018-09-06 Thread He Zhe

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 tells 
> bind to listen on any other address.
> Having the Listen-on statement removes the default listen for all addresses.
>
>
> On 06/09/2018 15.24, He Zhe wrote:
>> On 2018年09月06日 21:06, Sten Carlsen wrote:
>>> 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 and compete with other DNS daemons in the same system.
>>
>> options {
>> listen-on { ! 10.0.1.1; };
>> };
> You may try to let it specifically listen to all interfaces except the 
> one you want excluded.
 Thanks for your hint.

 But the "all" here is hard for me to determine beforehand. Many potential 
 different things would use named but some specific one just want to use 
 their own DNS services. So I'm looking for the NOT operation.
>>> I would assume that there is a limited and fairly fixed number of actual 
>>> NICs in the host.
>>>
>>> example:
>>> eth0 -> internal network 192.168.43.17
>>> eth1 -> external network 123.45.6.7
>>> eth0:7 -> VLAN for location 1  192.168.23.45
>>>
>>> Listen_on { 192.168.43.17; 192.168.23.45; }  eth1 is missing and should not 
>>> be listened to.
>> Thanks for the example.
>>
>> The IPs in my case cannot be determined in advance. They might be configured 
>> and then changed to any values. I could fall back to create a script to 
>> detect the changes and modify named's config and restart the named service. 
>> But that sounds not so good. I hope named can ignore some specific IP and/or 
>> interfaces while handles the rest.
>>
>> Zhe
>>
 Zhe

>> Thanks,
>> Zhe
>> ___
>> 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
> ___
> 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
>

___
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

RE: [BIND] RE: KSK Rollover

2018-09-06 Thread Browne, Stuart via bind-users

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 red hat system doesn't have access 
to write to a file of etc_t. After moving the file to /var/named somewhere, a 
restorecon should have reset it to something like var_named_t or 
var_named_cache_t which it would have had access to write to.

>From the line, 'permissive=0' so it suggests a SELinux-enforcing environment.
Stuart

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Brent 
Swingle
Sent: Friday, 7 September 2018 12:05 PM
To: bind-users@lists.isc.org
Subject: 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 output file here:

/tmp/systemd-private-b2ebff459df9471e8bf444e2d2b1116e-named.service-HX1NF5/tmp/named.secroots


The data in the file seems to be as desired if I understand the KSK Rollover 
test correctly, I should see 20326 which pertains to the new key:

[root@ns3 tmp]# cat named.secroots
06-Sep-2018 18:47:16.190

Start view internal-in

./RSASHA256/20326 ; managed
./RSASHA256/19036 ; managed
dlv.isc.org/RSASHA1/19297 ; managed

Start view external-in

./RSASHA256/20326 ; managed
./RSASHA256/19036 ; managed
dlv.isc.org/RSASHA1/19297 ; managed

Start view external-chaos

dumpsecroots failed: not found




I did not fully try Carl's input below but I believe it would have worked as 
well.  I had performed a "chmod 770 /var/named" but I did not follow it up with 
the SELinux modification.  The last error I had was SELinux barking so I'd 
anticipate his suggestion was the correct one.

Does the 'named' user have write access to /var/named? The default
redhat setup has /var/named as 0750, with /var/named/data as 0770. Also,
the default redhat selinux config prevents named writing to /var/named.

chmod 770 /var/named
setsebool -P named_write_master_zones=true
rndc secroots




Thanks everyone for assisting with this matter.
___
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

Re: [BIND] RE: KSK Rollover

2018-09-06 Thread Brent Swingle

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 output file here:

/tmp/systemd-private-b2ebff459df9471e8bf444e2d2b1116e-named.service-HX1NF5/tmp/named.secroots

The data in the file seems to be as desired if I understand the KSK Rollover
test correctly, I should see 20326 which pertains to the new key:

[root@ns3 tmp]# cat named.secroots
06-Sep-2018 18:47:16.190

Start view internal-in

./RSASHA256/20326 ; managed
./RSASHA256/19036 ; managed
dlv.isc.org/RSASHA1/19297 ; managed

Start view external-in

./RSASHA256/20326 ; managed
./RSASHA256/19036 ; managed
dlv.isc.org/RSASHA1/19297 ; managed

Start view external-chaos

dumpsecroots failed: not found

I did not fully try Carl's input below but I believe it would have worked as
well. I had performed a "chmod 770 /var/named" but I did not follow it up with
the SELinux modification. The last error I had was SELinux barking so I'd
anticipate his suggestion was the correct one.

Does the 'named' user have write access to /var/named? The default
redhat setup has /var/named as 0750, with /var/named/data as 0770. Also,
the default redhat selinux config prevents named writing to /var/named.

chmod 770 /var/named
setsebool -P named_write_master_zones=true
rndc secroots

Thanks everyone for assisting with this matter.
___
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

Re: Frequent timeout

2018-09-06 Thread Alex

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 packet.

This is the command I ran to produce the pcap file I sent:

# tcpdump -s0 -vv -i eth0 -nn -w domain-capture-eth0-090518.pcap udp
dst port domain

I have a few other pcap files here. Can you tell me the query you ran
in wireshark to search for the SERVFAIL packets? Perhaps I can find
them here. I have another that I just realized was running for quite a
while and has grown to 1.5GB until I just stopped it. I also have
another that was run with "-i any", but it's also quite large.

I'd otherwise probably have to wait until tomorrow to run it again, as
it appears to happen during periods of high traffic.

I should also mention that, while eth0 is the physical device, there
is a bridge set up to support virtual machines (none of which were
active). Hopefully that's not the reason! (real IP obscured).

br0: flags=4163  mtu 1500
inet 68.195.XXX.45  netmask 255.255.255.248  broadcast 68.195.XXX.47
inet6 fe80::16da:e9ff:fe97:ab71  prefixlen 64  scopeid 0x20
inet6 ::16da:e9ff:fe97:ab71  prefixlen 64  scopeid 0x0
ether 14:da:e9:97:ab:71  txqueuelen 1000  (Ethernet)
RX packets 54953236  bytes 45182800578 (42.0 GiB)
RX errors 0  dropped 231612  overruns 0  frame 0
TX packets 68345276  bytes 33687959055 (31.3 GiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163  mtu 1500
inet6 fe80::16da:e9ff:fe97:ab71  prefixlen 64  scopeid 0x20
ether 14:da:e9:97:ab:71  txqueuelen 1000  (Ethernet)
RX packets 61078845  bytes 46596159121 (43.3 GiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 68733541  bytes 34028363069 (31.6 GiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
device interrupt 16  memory 0xdf20-df22

Thanks,
Alex


>
> John
>
> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Alex
> Sent: Thursday, September 06, 2018 2:54 PM
> To: bind-users@lists.isc.org
> Subject: 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 4hrs of data, I believe.
> https://drive.google.com/file/d/1KUpDoQ2zuz5ITeKuO0BhlK7JvWSUAG3B/view?usp=sharing
>
> Thanks,
> Alex
> ___
> 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
___
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

RE: Frequent timeout

2018-09-06 Thread John W. Blue

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 [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Alex
Sent: Thursday, September 06, 2018 2:54 PM
To: bind-users@lists.isc.org
Subject: 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 4hrs of data, I believe.
https://drive.google.com/file/d/1KUpDoQ2zuz5ITeKuO0BhlK7JvWSUAG3B/view?usp=sharing

Thanks,
Alex
___
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

RE: [BIND] RE: KSK Rollover

2018-09-06 Thread Carl Byington

-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 the 'named' user have write access to /var/named? The default
redhat setup has /var/named as 0750, with /var/named/data as 0770. Also,
the default redhat selinux config prevents named writing to /var/named.

chmod 770 /var/named
setsebool -P named_write_master_zones=true
rndc secroots


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAluRnR8ACgkQL6j7milTFsF2FgCfSt7RIVrO8lK8izQlNn9TadPp
F58Anj81TEmtg34Cpjhh3DqMWEQFUCxA
=NwIr
-END PGP SIGNATURE-


___
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

RE: [BIND] RE: KSK Rollover

2018-09-06 Thread Brent Swingle

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  6 15:44:40 ns3 named[15443]: dumpsecroots failed: permission denied
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


This error also appears in the audit.log file and a search is pointing to 
SELinux as the hangup.  Any pointers on dealing with SELinux would be 
appreciated.

type=AVC msg=audit(1536266680.663:75671): avc:  denied  { 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


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




-Original Message-
From: Hugo Salgado-Hernández [mailto:hsalg...@nic.cl] 
Sent: Thursday, September 06, 2018 3:39 PM
To: Brent Swingle 
Cc: Evan Hunt ; bind-users@lists.isc.org
Subject: 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 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 valid responses 
> as if rndc was functional.  I had somewhat assumed that rndc was baked in 
> behind the scenes and ready to go.  Either way I it has a rndc.conf and is 
> specified in named.conf at this point.
> 
> I have two of these servers that are identical from an SW perspective.  As a 
> test, I issued "rndc secroots" on the server that I have modified to 
> configure rndc and observed the following lines appear in the 
> /var/log/messages file.  When I issued "rndc secroots" from the non-modified 
> file I get the same 3 lines.  It acts like the process is running but it is 
> unable to write output to the named.secroots file.
> 
> Sep  6 14:33:13 ns2 named[31189]: received control channel command 'secroots'
> Sep  6 14:33:13 ns2 named[31189]: could not open secroots dump file 
> 'named.secroots': permission denied Sep  6 14:33:13 ns2 named[31189]: 
> dumpsecroots failed: permission denied
> 
> 
> As a test, I manually created named.secroots with weakened permissions to see 
> if that made a difference but it still won't print output to it.
> [root@ns3 etc]# ls -lh named.secroots
> -rw-rw-rw-. 1 named named 0 Sep  6 13:52 named.secroots
> 
> 
> 
> -Original Message-
> From: Evan Hunt [mailto:e...@isc.org]
> Sent: Thursday, September 06, 2018 1:22 PM
> To: Brent Swingle 
> Cc: bind-users@lists.isc.org
> Subject: 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 "rndc-confgen" and follow the directions.
> 
> --
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
> 
> ___
> 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
> 
___
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

Re: [BIND] RE: KSK Rollover

2018-09-06 Thread Hugo Salgado-Hernández

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 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 valid responses 
> as if rndc was functional.  I had somewhat assumed that rndc was baked in 
> behind the scenes and ready to go.  Either way I it has a rndc.conf and is 
> specified in named.conf at this point.
> 
> I have two of these servers that are identical from an SW perspective.  As a 
> test, I issued "rndc secroots" on the server that I have modified to 
> configure rndc and observed the following lines appear in the 
> /var/log/messages file.  When I issued "rndc secroots" from the non-modified 
> file I get the same 3 lines.  It acts like the process is running but it is 
> unable to write output to the named.secroots file.
> 
> Sep  6 14:33:13 ns2 named[31189]: received control channel command 'secroots'
> Sep  6 14:33:13 ns2 named[31189]: could not open secroots dump file 
> 'named.secroots': permission denied 
> Sep  6 14:33:13 ns2 named[31189]: dumpsecroots failed: permission denied
> 
> 
> As a test, I manually created named.secroots with weakened permissions to see 
> if that made a difference but it still won't print output to it.
> [root@ns3 etc]# ls -lh named.secroots
> -rw-rw-rw-. 1 named named 0 Sep  6 13:52 named.secroots
> 
> 
> 
> -Original Message-
> From: Evan Hunt [mailto:e...@isc.org] 
> Sent: Thursday, September 06, 2018 1:22 PM
> To: Brent Swingle 
> Cc: bind-users@lists.isc.org
> Subject: 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 "rndc-confgen" and follow the directions.
> 
> -- 
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
> 
> ___
> 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
> 


signature.asc
Description: PGP signature
___
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

RE: KSK Rollover

2018-09-06 Thread Brent Swingle

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 valid responses as if rndc 
was functional.  I had somewhat assumed that rndc was baked in behind the 
scenes and ready to go.  Either way I it has a rndc.conf and is specified in 
named.conf at this point.

I have two of these servers that are identical from an SW perspective.  As a 
test, I issued "rndc secroots" on the server that I have modified to configure 
rndc and observed the following lines appear in the /var/log/messages file.  
When I issued "rndc secroots" from the non-modified file I get the same 3 
lines.  It acts like the process is running but it is unable to write output to 
the named.secroots file.

Sep  6 14:33:13 ns2 named[31189]: received control channel command 'secroots'
Sep  6 14:33:13 ns2 named[31189]: could not open secroots dump file 
'named.secroots': permission denied 
Sep  6 14:33:13 ns2 named[31189]: dumpsecroots failed: permission denied

As a test, I manually created named.secroots with weakened permissions to see 
if that made a difference but it still won't print output to it.
[root@ns3 etc]# ls -lh named.secroots
-rw-rw-rw-. 1 named named 0 Sep  6 13:52 named.secroots

-Original Message-
From: Evan Hunt [mailto:e...@isc.org] 
Sent: Thursday, September 06, 2018 1:22 PM
To: Brent Swingle 
Cc: bind-users@lists.isc.org
Subject: 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 "rndc-confgen" and follow the directions.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

___
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

Re: Frequent timeout

2018-09-06 Thread Alex

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 4hrs of data, I believe.
https://drive.google.com/file/d/1KUpDoQ2zuz5ITeKuO0BhlK7JvWSUAG3B/view?usp=sharing

Thanks,
Alex



>
> 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: c...@byington.org; bind-users@lists.isc.org
> Subject: 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 -s0 -vv -i %s -nn -w /tmp/outputfile udp dst port domain
>
> I've captured some packets that I believe include the packets relating to the 
> SERVFAIL errors I've been receiving. Now I have to figure out how to go 
> through them.
>
> In the meantime, I've configured /etc/resolv.conf to send queries to a remote 
> system of ours, and the errors have (mostly) stopped.
>
> I also notice some traces take an abnormal amount of time. Ping times to 
> google.com are less than 20ms, but this trace shows reaching the root servers 
> takes 104ms:
>
> # dig +trace +nodnssec google.com
>
> ; <<>> DiG 9.11.4-P1-RedHat-9.11.4-5.P1.fc28 <<>> +trace +nodnssec google.com 
> ;; global options: +cmd
> .   3451IN  NS  g.root-servers.net.
> .   3451IN  NS  k.root-servers.net.
> .   3451IN  NS  j.root-servers.net.
> .   3451IN  NS  c.root-servers.net.
> .   3451IN  NS  i.root-servers.net.
> .   3451IN  NS  e.root-servers.net.
> .   3451IN  NS  m.root-servers.net.
> .   3451IN  NS  l.root-servers.net.
> .   3451IN  NS  a.root-servers.net.
> .   3451IN  NS  h.root-servers.net.
> .   3451IN  NS  b.root-servers.net.
> .   3451IN  NS  d.root-servers.net.
> .   3451IN  NS  f.root-servers.net.
> ;; Received 839 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms
>
> com.172800  IN  NS  h.gtld-servers.net.
> com.172800  IN  NS  g.gtld-servers.net.
> com.172800  IN  NS  b.gtld-servers.net.
> com.172800  IN  NS  j.gtld-servers.net.
> com.172800  IN  NS  f.gtld-servers.net.
> com.172800  IN  NS  m.gtld-servers.net.
> com.172800  IN  NS  c.gtld-servers.net.
> com.172800  IN  NS  d.gtld-servers.net.
> com.172800  IN  NS  k.gtld-servers.net.
> com.172800  IN  NS  i.gtld-servers.net.
> com.172800  IN  NS  l.gtld-servers.net.
> com.172800  IN  NS  a.gtld-servers.net.
> com.172800  IN  NS  e.gtld-servers.net.
> ;; Received 835 bytes from 202.12.27.33#53(m.root-servers.net) in 104 ms
>
> google.com. 172800  IN  NS  ns2.google.com.
> google.com. 172800  IN  NS  ns1.google.com.
> google.com. 172800  IN  NS  ns3.google.com.
> google.com. 172800  IN  NS  ns4.google.com.
> ;; Received 287 bytes from 192.33.14.30#53(b.gtld-servers.net) in 44 ms
>
> ;; expected opt record in response
> google.com. 300 IN  A   172.217.10.14
> ;; Received 44 bytes from 216.239.36.10#53(ns3.google.com) in 29 ms
>
> Running the same trace again showed 129ms.
>
> I also located this warning:
> 06-Sep-2018 12:03:33.304 client: warning: client @0x7f502c1d3d50
> 127.0.0.1#60968 (cmail20.com.multi.surbl.org): recursive-clients soft limit 
> exceeded (901/900/1000), aborting oldest query
>
> I've increased recursive-clients to 2500 but the SERVFAIL errors continue.
>
> There are also a ton of lame-server entries, many of which are related to one 
> RBL or another, as part of my postscreen config:
> 06-Sep-2018 13:16:50.686 lame-servers: info: connection refused resolving 
> '48.167.85.209.zz.countries.nerd.dk/A/IN': 195.182.36.121#53
> 06-Sep-2018 13:16:50.706 lame-servers: info: connection refused resolving 
> '48.167.85.209.bb.barracudacentral.org/A/IN':
> 64.235.154.72#53
> 06-Sep-2018 13:16:51.308 lame-servers: info: connection refused resolving

RE: Frequent timeout

2018-09-06 Thread John W. Blue

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: c...@byington.org; bind-users@lists.isc.org
Subject: 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 -s0 -vv -i %s -nn -w /tmp/outputfile udp dst port domain

I've captured some packets that I believe include the packets relating to the 
SERVFAIL errors I've been receiving. Now I have to figure out how to go through 
them.

In the meantime, I've configured /etc/resolv.conf to send queries to a remote 
system of ours, and the errors have (mostly) stopped.

I also notice some traces take an abnormal amount of time. Ping times to 
google.com are less than 20ms, but this trace shows reaching the root servers 
takes 104ms:

# dig +trace +nodnssec google.com

; <<>> DiG 9.11.4-P1-RedHat-9.11.4-5.P1.fc28 <<>> +trace +nodnssec google.com 
;; global options: +cmd
.   3451IN  NS  g.root-servers.net.
.   3451IN  NS  k.root-servers.net.
.   3451IN  NS  j.root-servers.net.
.   3451IN  NS  c.root-servers.net.
.   3451IN  NS  i.root-servers.net.
.   3451IN  NS  e.root-servers.net.
.   3451IN  NS  m.root-servers.net.
.   3451IN  NS  l.root-servers.net.
.   3451IN  NS  a.root-servers.net.
.   3451IN  NS  h.root-servers.net.
.   3451IN  NS  b.root-servers.net.
.   3451IN  NS  d.root-servers.net.
.   3451IN  NS  f.root-servers.net.
;; Received 839 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

com.172800  IN  NS  h.gtld-servers.net.
com.172800  IN  NS  g.gtld-servers.net.
com.172800  IN  NS  b.gtld-servers.net.
com.172800  IN  NS  j.gtld-servers.net.
com.172800  IN  NS  f.gtld-servers.net.
com.172800  IN  NS  m.gtld-servers.net.
com.172800  IN  NS  c.gtld-servers.net.
com.172800  IN  NS  d.gtld-servers.net.
com.172800  IN  NS  k.gtld-servers.net.
com.172800  IN  NS  i.gtld-servers.net.
com.172800  IN  NS  l.gtld-servers.net.
com.172800  IN  NS  a.gtld-servers.net.
com.172800  IN  NS  e.gtld-servers.net.
;; Received 835 bytes from 202.12.27.33#53(m.root-servers.net) in 104 ms

google.com. 172800  IN  NS  ns2.google.com.
google.com. 172800  IN  NS  ns1.google.com.
google.com. 172800  IN  NS  ns3.google.com.
google.com. 172800  IN  NS  ns4.google.com.
;; Received 287 bytes from 192.33.14.30#53(b.gtld-servers.net) in 44 ms

;; expected opt record in response
google.com. 300 IN  A   172.217.10.14
;; Received 44 bytes from 216.239.36.10#53(ns3.google.com) in 29 ms

Running the same trace again showed 129ms.

I also located this warning:
06-Sep-2018 12:03:33.304 client: warning: client @0x7f502c1d3d50
127.0.0.1#60968 (cmail20.com.multi.surbl.org): recursive-clients soft limit 
exceeded (901/900/1000), aborting oldest query

I've increased recursive-clients to 2500 but the SERVFAIL errors continue.

There are also a ton of lame-server entries, many of which are related to one 
RBL or another, as part of my postscreen config:
06-Sep-2018 13:16:50.686 lame-servers: info: connection refused resolving 
'48.167.85.209.zz.countries.nerd.dk/A/IN': 195.182.36.121#53
06-Sep-2018 13:16:50.706 lame-servers: info: connection refused resolving 
'48.167.85.209.bb.barracudacentral.org/A/IN':
64.235.154.72#53
06-Sep-2018 13:16:51.308 lame-servers: info: connection refused resolving 
'48.167.85.209.bl.blocklist.de/A/IN': 185.21.103.31#53
06-Sep-2018 13:16:54.798 lame-servers: info: connection refused resolving 
'e51dd24f684d212a7da1119b23603b0f.generic.ixhash.net/A/IN':
178.254.39.16#53
06-Sep-2018 13:16:54.799 lame-servers: info: connection refused resolving 
'f4d997d8949e6dbd30f6a418ad364589.generic.ixhash.net/A/IN':
178.254.39.16#53
06-Sep-2018 13:16:55.762 lame-servers: info: connection refused resolving 
'2.164.177.209.bb.barracudac

Re: Frequent timeout

2018-09-06 Thread Alex

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 -s0 -vv -i %s -nn -w /tmp/outputfile udp dst port domain

I've captured some packets that I believe include the packets relating
to the SERVFAIL errors I've been receiving. Now I have to figure out
how to go through them.

In the meantime, I've configured /etc/resolv.conf to send queries to a
remote system of ours, and the errors have (mostly) stopped.

I also notice some traces take an abnormal amount of time. Ping times
to google.com are less than 20ms, but this trace shows reaching the
root servers takes 104ms:

# dig +trace +nodnssec google.com

; <<>> DiG 9.11.4-P1-RedHat-9.11.4-5.P1.fc28 <<>> +trace +nodnssec google.com
;; global options: +cmd
.   3451IN  NS  g.root-servers.net.
.   3451IN  NS  k.root-servers.net.
.   3451IN  NS  j.root-servers.net.
.   3451IN  NS  c.root-servers.net.
.   3451IN  NS  i.root-servers.net.
.   3451IN  NS  e.root-servers.net.
.   3451IN  NS  m.root-servers.net.
.   3451IN  NS  l.root-servers.net.
.   3451IN  NS  a.root-servers.net.
.   3451IN  NS  h.root-servers.net.
.   3451IN  NS  b.root-servers.net.
.   3451IN  NS  d.root-servers.net.
.   3451IN  NS  f.root-servers.net.
;; Received 839 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

com.172800  IN  NS  h.gtld-servers.net.
com.172800  IN  NS  g.gtld-servers.net.
com.172800  IN  NS  b.gtld-servers.net.
com.172800  IN  NS  j.gtld-servers.net.
com.172800  IN  NS  f.gtld-servers.net.
com.172800  IN  NS  m.gtld-servers.net.
com.172800  IN  NS  c.gtld-servers.net.
com.172800  IN  NS  d.gtld-servers.net.
com.172800  IN  NS  k.gtld-servers.net.
com.172800  IN  NS  i.gtld-servers.net.
com.172800  IN  NS  l.gtld-servers.net.
com.172800  IN  NS  a.gtld-servers.net.
com.172800  IN  NS  e.gtld-servers.net.
;; Received 835 bytes from 202.12.27.33#53(m.root-servers.net) in 104 ms

google.com. 172800  IN  NS  ns2.google.com.
google.com. 172800  IN  NS  ns1.google.com.
google.com. 172800  IN  NS  ns3.google.com.
google.com. 172800  IN  NS  ns4.google.com.
;; Received 287 bytes from 192.33.14.30#53(b.gtld-servers.net) in 44 ms

;; expected opt record in response
google.com. 300 IN  A   172.217.10.14
;; Received 44 bytes from 216.239.36.10#53(ns3.google.com) in 29 ms

Running the same trace again showed 129ms.

I also located this warning:
06-Sep-2018 12:03:33.304 client: warning: client @0x7f502c1d3d50
127.0.0.1#60968 (cmail20.com.multi.surbl.org): recursive-clients soft
limit exceeded (901/900/1000), aborting oldest query

I've increased recursive-clients to 2500 but the SERVFAIL errors continue.

There are also a ton of lame-server entries, many of which are related
to one RBL or another, as part of my postscreen config:
06-Sep-2018 13:16:50.686 lame-servers: info: connection refused
resolving '48.167.85.209.zz.countries.nerd.dk/A/IN': 195.182.36.121#53
06-Sep-2018 13:16:50.706 lame-servers: info: connection refused
resolving '48.167.85.209.bb.barracudacentral.org/A/IN':
64.235.154.72#53
06-Sep-2018 13:16:51.308 lame-servers: info: connection refused
resolving '48.167.85.209.bl.blocklist.de/A/IN': 185.21.103.31#53
06-Sep-2018 13:16:54.798 lame-servers: info: connection refused
resolving 'e51dd24f684d212a7da1119b23603b0f.generic.ixhash.net/A/IN':
178.254.39.16#53
06-Sep-2018 13:16:54.799 lame-servers: info: connection refused
resolving 'f4d997d8949e6dbd30f6a418ad364589.generic.ixhash.net/A/IN':
178.254.39.16#53
06-Sep-2018 13:16:55.762 lame-servers: info: connection refused
resolving '2.164.177.209.bb.barracudacentral.org/A/IN':
64.235.145.15#53
06-Sep-2018 13:16:55.845 lame-servers: info: connection refused
resolving '2.164.177.209.bb.barracudacentral.org/A/IN':
64.235.154.72#53

What would be a cause of such a significant delay in reaching the root servers?

Thanks,
Alex
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users

Re: KSK Rollover

2018-09-06 Thread Evan Hunt

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 "rndc-confgen" and follow the directions.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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

Re: KSK Rollover

2018-09-06 Thread John W. Blue

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: Thursday, September 6, 2018 12:36 PM
To: bind-users@lists.isc.org
Subject: 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 email there are links on how to check our server setup and 
make adjustments.  My specific question to the group is in regards to one of 
the steps outlined for checking the current configuration.

This is the link that outlines the server test steps:
https://www.icann.org/dns-resolvers-checking-current-trust-anchors

This is the command that does not work and the output received:
[root@ns2 ~]# rndc secroots
rndc: 'secroots' failed: permission denied
[root@ns2 ~]#

This are the versions that I am running:
[root@ns2 ~]# named -v
BIND 9.10.2-P4-RedHat-9.10.2-5.P4.fc22


Might anyone be able to tell me what adjustment I would need to make in order 
for this command to work properly so I can look at the output file and verify 
my config?

Thanks,
___
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

KSK Rollover

2018-09-06 Thread Brent Swingle

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 email there are links on how to check our server setup and 
make adjustments.  My specific question to the group is in regards to one of 
the steps outlined for checking the current configuration.

This is the link that outlines the server test steps:
https://www.icann.org/dns-resolvers-checking-current-trust-anchors

This is the command that does not work and the output received:
[root@ns2 ~]# rndc secroots
rndc: 'secroots' failed: permission denied
[root@ns2 ~]#

This are the versions that I am running:
[root@ns2 ~]# named -v
BIND 9.10.2-P4-RedHat-9.10.2-5.P4.fc22


Might anyone be able to tell me what adjustment I would need to make in order 
for this command to work properly so I can look at the output file and verify 
my config?

Thanks,
___
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

Re: How to avoid to listen on specific interfaces

2018-09-06 Thread Sten Carlsen

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 listen for all addresses.


On 06/09/2018 15.24, He Zhe wrote:
>
> On 2018年09月06日 21:06, Sten Carlsen wrote:
>>
>> 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 and compete with other DNS daemons in the same system.
>
> options {
> listen-on { ! 10.0.1.1; };
> };
 You may try to let it specifically listen to all interfaces except the one 
 you want excluded.
>>> Thanks for your hint.
>>>
>>> But the "all" here is hard for me to determine beforehand. Many potential 
>>> different things would use named but some specific one just want to use 
>>> their own DNS services. So I'm looking for the NOT operation.
>> I would assume that there is a limited and fairly fixed number of actual 
>> NICs in the host.
>>
>> example:
>> eth0 -> internal network 192.168.43.17
>> eth1 -> external network 123.45.6.7
>> eth0:7 -> VLAN for location 1  192.168.23.45
>>
>> Listen_on { 192.168.43.17; 192.168.23.45; }  eth1 is missing and should not 
>> be listened to.
> Thanks for the example.
>
> The IPs in my case cannot be determined in advance. They might be configured 
> and then changed to any values. I could fall back to create a script to 
> detect the changes and modify named's config and restart the named service. 
> But that sounds not so good. I hope named can ignore some specific IP and/or 
> interfaces while handles the rest.
>
> Zhe
>
>>> Zhe
>>>
> Thanks,
> Zhe
> ___
> 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
 ___
 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

___
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

Re: How to avoid to listen on specific interfaces

2018-09-06 Thread He Zhe



On 2018年09月06日 21:06, Sten Carlsen wrote:
>
>
> 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 and compete with other DNS daemons in the same system.

 options {
 listen-on { ! 10.0.1.1; };
 };
>>> You may try to let it specifically listen to all interfaces except the one 
>>> you want excluded.
>> Thanks for your hint.
>>
>> But the "all" here is hard for me to determine beforehand. Many potential 
>> different things would use named but some specific one just want to use 
>> their own DNS services. So I'm looking for the NOT operation.
> I would assume that there is a limited and fairly fixed number of actual NICs 
> in the host.
>
> example:
> eth0 -> internal network 192.168.43.17
> eth1 -> external network 123.45.6.7
> eth0:7 -> VLAN for location 1  192.168.23.45
>
> Listen_on { 192.168.43.17; 192.168.23.45; }  eth1 is missing and should not 
> be listened to.

Thanks for the example.

The IPs in my case cannot be determined in advance. They might be configured 
and then changed to any values. I could fall back to create a script to detect 
the changes and modify named's config and restart the named service. But that 
sounds not so good. I hope named can ignore some specific IP and/or interfaces 
while handles the rest.

Zhe

>
>> Zhe
>>
 Thanks,
 Zhe
 ___
 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
>>> ___
>>> 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
>

___
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

Re: How to avoid to listen on specific interfaces

2018-09-06 Thread Sten Carlsen



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 and compete with other DNS daemons in the same system.
>>>
>>> options {
>>> listen-on { ! 10.0.1.1; };
>>> };
>> You may try to let it specifically listen to all interfaces except the one 
>> you want excluded.
> Thanks for your hint.
>
> But the "all" here is hard for me to determine beforehand. Many potential 
> different things would use named but some specific one just want to use their 
> own DNS services. So I'm looking for the NOT operation.
I would assume that there is a limited and fairly fixed number of actual
NICs in the host.

example:
eth0 -> internal network 192.168.43.17
eth1 -> external network 123.45.6.7
eth0:7 -> VLAN for location 1  192.168.23.45

Listen_on { 192.168.43.17; 192.168.23.45; }  eth1 is missing and should
not be listened to.

>
> Zhe
>
>>> Thanks,
>>> Zhe
>>> ___
>>> 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
>>
>>
>> ___
>> 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

___
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

Re: How to avoid to listen on specific interfaces

2018-09-06 Thread He Zhe



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 same system.
>>
>> options {
>> listen-on { ! 10.0.1.1; };
>> };
> You may try to let it specifically listen to all interfaces except the one 
> you want excluded.

Thanks for your hint.

But the "all" here is hard for me to determine beforehand. Many potential 
different things would use named but some specific one just want to use their 
own DNS services. So I'm looking for the NOT operation.

Zhe

>> Thanks,
>> Zhe
>> ___
>> 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
>
>
>
> ___
> 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

___
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

Re: How to avoid to listen on specific interfaces

2018-09-06 Thread Sten Carlsen



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; };
> };
You may try to let it specifically listen to all interfaces except the
one you want excluded.
>
> Thanks,
> Zhe
> ___
> 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

___
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

How to avoid to listen on specific interfaces

2018-09-06 Thread He Zhe

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
___
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

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

2018-09-06 Thread Mark Andrews



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 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 short/long output?
>> 
>> As I understand it (though I haven't studied this in a while and may be
>> fuzzy), the HMAC algorithm shortens keys that are longer than the block
>> size before it uses them, so it's true, long keys aren't necessary or
>> particularly helpful.
>> 
>>> Incidentally using bind-9.11 I was unable to use the truncation method
>>> you mentioned below (not that I really want to). Is it a 9.12 onwards
>>> thing?
>> 
>> No, but Mark's comment may have been confusing.  You can set up keys
>> that way in named.conf ("algorithm hmac-md5-96;" or whatever). At first
>> I thought he was talking about tsig-keygen; perhaps you read it the same
>> way I did?
>> 
>> --
>> Evan Hunt -- e...@isc.org
>> Internet Systems Consortium, Inc.
> 
> Yes, I did read it the same way as you Evan.
> 
> Thanks for the clarification on the HMAC usage.
> 
> Stuart

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
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

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

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

Re: How to avoid to listen on specific interfaces

RE: [BIND] RE: KSK Rollover

Re: [BIND] RE: KSK Rollover

Re: Frequent timeout

RE: Frequent timeout

RE: [BIND] RE: KSK Rollover

RE: [BIND] RE: KSK Rollover

Re: [BIND] RE: KSK Rollover

RE: KSK Rollover

Re: Frequent timeout

RE: Frequent timeout

Re: Frequent timeout

Re: KSK Rollover

Re: KSK Rollover

KSK Rollover

Re: How to avoid to listen on specific interfaces

Re: How to avoid to listen on specific interfaces

Re: How to avoid to listen on specific interfaces

Re: How to avoid to listen on specific interfaces

Re: How to avoid to listen on specific interfaces

How to avoid to listen on specific interfaces

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

24 matches

Site Navigation

Mail list logo

Footer information