date:20201218

issue with domain forwarding

2020-12-18 Thread Frank


   Hi,

 I am using bind-9.16.5.   I am having an issue with domain/zone 
forwarding.

Global forwarding works fine. When I configure domain forwarding no request
for dns info goes out from the machine. I did a tcpdump to verify this.
 For bind-9.13.2 the domain forwarding works properly.

   Here is my config:

I am using the default settings for the dnssec config. I tried setting 
them to off

and there is no change.

//dnssec-enable yes;
//dnssec-validation auto;
//dnssec-lookaside auto;


zone "ve2cii.com" {
    type forward;
    forward only;
    forwarders {
    108.161.165.156;
       };

--
sysadm  cronomagic.com
e-mail  ve2...@canasoft.net

POWERED BY LINUX

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

issue with domain forwarding

2020-12-18 Thread Frank






   Here is my entire config:

My machine IP  =   66.159.32.31   2606:af00:1::3



 key "rndc-key" {
    algorithm hmac-md5;
    secret "y4xt0wQJOiOiZmVaWSMgnQ==";
 };

 controls {
    inet 127.0.0.1 port 953
    allow { 127.0.0.1; } keys { "rndc-key"; };
 };

acl local {
    127.0.0.1;
    66.159.32.31;
    ::1;
    2606:af00::/32;
};

options {
    directory "/var/named";
    pid-file "/var/run/named.pid";
    allow-recursion { local; };
    listen-on-v6 { any; };
};

logging {
  category lame-servers { null; };
  category edns-disabled { null; };
  category resolver { null; };
  channel security_log {
  print-time yes;
  file "/var/log/bind_security" versions 20 size 5m;};
  category security { security_log; };
  channel default {
  print-time yes;
  file "/var/log/named_log" versions 20 size 5m;};
  category default { default; };
};


zone "." {
  type hint;
  file "/var/named/etc/named.root";
};

zone "0.0.127.in-addr.arpa" {
  type master;
  notify no;
  file "127.0.0.rev.cmg";
};

zone "ve2cii.com" {
    type forward;
    forward only;
    forwarders {
    108.161.165.156;
    };
};



 I am using bind-9.16.5.   I am having an issue with domain/zone 
forwarding.

Global forwarding works fine. When I configure domain forwarding no request
for dns info goes out from the machine. I did a tcpdump to verify this.
 For bind-9.13.2 the domain forwarding works properly.

   Here is my config:

I am using the default settings for the dnssec config. I tried setting 
them to off

and there is no change.

//dnssec-enable yes;
//dnssec-validation auto;
//dnssec-lookaside auto;


zone "ve2cii.com" {
    type forward;
    forward only;
    forwarders {
    108.161.165.156;
       };

--
sysadm  cronomagic.com
e-mail  ve2...@canasoft.net

POWERED BY LINUX

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Forwarded lookup failing on no valid RRSIG

2020-12-18 Thread Nicolas Bock

Hi Mark,

Thanks so much for the reply. I ran this command and am
getting the following:

$ dig +dnssec ds com @10.0.0.3

; <<>> DiG 9.10.6 <<>> +dnssec ds com @10.0.0.3
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36260
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;com. IN DS

;; ANSWER SECTION:
com. 63779 IN DS 30909 8 2 
E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766

;; Query time: 307 msec
;; SERVER: 10.0.0.3#53(10.0.0.3)
;; WHEN: Fri Dec 18 11:26:28 CST 2020
;; MSG SIZE rcvd: 80

In other words, the forwarder returns a Delegation Signer
record but not an RRset Signature record. Presumably that
means that that the forwarder is not validating the zone?

Thanks,

Nick

On Thu, Dec 17 2020, Mark Andrews wrote:

> DNSSEC requires that forwarders support DNSSEC.  Check that the forwarders 
> return
> DNSSEC records when they are queried.  The forwarders should also be 
> validating to
> filter spoofed responses from the internet.  You should be getting a answer 
> like
> this if the forwarders are validating.
>
> [beetle:~] marka% dig +dnssec ds com
>
> ; <<>> DiG 9.15.4 <<>> +dnssec ds com
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31284
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ; COOKIE: 5cf268bbbafd31a901005fdc081a24542baf0ffea0bb (good)
> ;; QUESTION SECTION:
> ;com. IN  DS
>
> ;; ANSWER SECTION:
> com.  40483   IN  DS  30909 8 2 
> E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
> com.  40483   IN  RRSIG   DS 8 1 86400 2020122917 
> 2020121616 26116 . 
> cgPgcSi6cq++komd2l+PzrCsawleAikedcwcGk5PbNr1onkXZGNypJoF 
> 7QQJ4GjMf4b7t+bO5f8szmo0cd2bz+DD0DMXoqUSFvEH4gOX9naoHcm0 
> 90MS5Wfdeg43gNDSot/U74RJS1CS50U3SreFd2ZFIik9MlCHrSFLf/9V 
> 7EqTJrs3xz9d/EG34O6qjaEqdw4GW40d3sA6kDGtSC+I9t4rttSEeasZ 
> FnkZWLCOvzOLfYQlCVqaWpYCnvNdoQUPsbmDCEJf22tanPUft59hPRMu 
> HmJAOKj77vy+kQWXaBcBo//NUX2asBLus8S7sJ9BDxpGUAsS9o+TdRlq YkIHBA==
>
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Fri Dec 18 12:38:34 AEDT 2020
> ;; MSG SIZE  rcvd: 395
>
> [beetle:~] marka% 
>
>
>> On 18 Dec 2020, at 11:36, Nicolas Bock  wrote:
>> 
>> Hi,
>> 
>> When I configure my named to forward to our corporate DNS
>> servers (10.0.0.2 and 10.0.0.3), I end up getting error
>> messages such as
>> 
>>   Dec 17 20:58:06 dns-server named[843946]: fetch: www.canonical.com/A
>>   Dec 17 20:58:06 dns-server named[843946]: fetch: com/DS
>>   Dec 17 20:58:06 dns-server named[843946]: delete_node(): 
>> 0x7fa7e331e010 www.canonical.com (bucket 15)
>>   Dec 17 20:58:06 dns-server named[843946]: delete_node(): 
>> 0x7fa7e331b080 com (bucket 2)
>>   Dec 17 20:58:06 dns-server named[843946]: no valid RRSIG resolving 
>> 'com/DS/IN': 10.0.0.2#53
>>   Dec 17 20:58:06 dns-server named[843946]: delete_node(): 
>> 0x7fa7e331b080 com (bucket 2)
>>   Dec 17 20:58:06 dns-server named[843946]: no valid RRSIG resolving 
>> 'com/DS/IN': 10.0.0.3#53
>>   Dec 17 20:58:06 dns-server named[843946]: delete_node(): 
>> 0x7fa7e331b080 com (bucket 2)
>>   Dec 17 20:58:06 dns-server named[843946]: no valid DS resolving 
>> 'www.canonical.com/A/IN': 10.0.0.2#53
>>   Dec 17 20:58:06 dns-server named[843946]: delete_node(): 
>> 0x7fa7e331e010 www.canonical.com (bucket 15)
>>   Dec 17 20:58:06 dns-server named[843946]: validating 
>> www.canonical.com/A: bad cache hit (com/DS)
>>   Dec 17 20:58:06 dns-server named[843946]: delete_node(): 
>> 0x7fa7e331e010 www.canonical.com (bucket 15)
>>   Dec 17 20:58:06 dns-server named[843946]: broken trust chain resolving 
>> 'www.canonical.com/A/IN': 10.0.0.3#53
>> 
>> I don't quite understand why. Are 10.0.0.{2,3} incorrectly
>> set up for DNSSEC? It looks like DNSSEC is already breaking
>> for com. How can I trace what the root cause is?
>> 
>> Thanks!
>> 
>> Nick
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>> unsubscribe from this list
>> 
>> ISC funds the development of this software with paid support subscriptions. 
>> Contact us at https://www.isc.org/contact/ for more information.
>> 
>> 
>> 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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-u

BIND through COPR after CentOS

2020-12-18 Thread John Thurston

We have been using the ISC COPR packages for BIND on CentOS. With the 
demise of CentOS, we (along with a few other people on the planet) need 
to consider where we will move our applications.


We have been completely happy with the packages provided by ISC through 
COPR. Does anyone want to offer up other linux distributions on which 
they have had unqualified success with these same packages?



--
--
Do things because you should, not just because you can.

John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND through COPR after CentOS

2020-12-18 Thread Victoria Risk

> On Dec 18, 2020, at 10:15 AM, John Thurston  wrote:
> 
> We have been using the ISC COPR packages for BIND on CentOS. With the demise 
> of CentOS, we (along with a few other people on the planet) need to consider 
> where we will move our applications.
> 
> We have been completely happy with the packages provided by ISC through COPR. 
> Does anyone want to offer up other linux distributions on which they have had 
> unqualified success with these same packages?

I have been worrying about whether we would see BIND users shift away from 
CentOS, although I think it is too soon to declare CentOS ‘dead’. 

This might be a good time to remind people that we also publish packages for 
Debian (https://packages.debian.org/source/sid/bind9) and Ubuntu 
(https://launchpad.net/~isc). We also maintain a Docker image 
(https://hub.docker.com/r/internetsystemsconsortium/bind9). 

Vicky

Victoria Risk
Product Manager
Internet Systems Consortium
vi...@isc.org

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND through COPR after CentOS

2020-12-18 Thread Ondřej Surý

I would add that the Debian packages are at:

* 9.11 https://bind.debian.net/bind-esv/
* 9.16 https://bind.debian.net/bind/
* 9.17 https://bind.debian.net/bind-dev/

Ondřej 
--
Ondřej Surý — ISC (He/Him)

> On 18. 12. 2020, at 19:24, Victoria Risk  wrote:
> 
> 
> 
>> On Dec 18, 2020, at 10:15 AM, John Thurston  wrote:
>> 
>> We have been using the ISC COPR packages for BIND on CentOS. With the demise 
>> of CentOS, we (along with a few other people on the planet) need to consider 
>> where we will move our applications.
>> 
>> We have been completely happy with the packages provided by ISC through 
>> COPR. Does anyone want to offer up other linux distributions on which they 
>> have had unqualified success with these same packages?
> 
> 
> 
> I have been worrying about whether we would see BIND users shift away from 
> CentOS, although I think it is too soon to declare CentOS ‘dead’. 
> 
> This might be a good time to remind people that we also publish packages for 
> Debian (https://packages.debian.org/source/sid/bind9) and Ubuntu 
> (https://launchpad.net/~isc). We also maintain a Docker image 
> (https://hub.docker.com/r/internetsystemsconsortium/bind9). 
> 
> Vicky
> 
> 
> Victoria Risk
> Product Manager
> Internet Systems Consortium
> vi...@isc.org
> 
> 
> 
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> 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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND through COPR after CentOS

2020-12-18 Thread Leroy Tennison

We have been using isc's bind (and dhcp for that matter) which comes with 
Ubuntu LTS versions and have had good success.  Right now we're on Ubuntu 16.04 
LTS but that's about to change since the 16.04 revision goes EOL in April.  I 
should mention that our implementation isn't terribly sophisticated and not 
large scale but it has worked.  The only other qualification is that the 
version which comes with the distribution isn't the latest by any means.


From: bind-users  on behalf of Ondřej Surý 

Sent: Friday, December 18, 2020 12:31 PM
To: Victoria Risk 
Cc: John Thurston ; bind-users@lists.isc.org 

Subject: [EXTERNAL] Re: BIND through COPR after CentOS


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


I would add that the Debian packages are at:

* 9.11 
https://bind.debian.net/bind-esv/
* 9.16 
https://bind.debian.net/bind/
* 9.17 
https://bind.debian.net/bind-dev/

Ondřej
--
Ondřej Surý — ISC (He/Him)


Harriscomputer

Leroy Tennison
Network Information/Cyber Security Specialist
E: le...@datavoiceint.com
P:


[cid:Data-Voice-International-LOGO_aa3d1c6e-5cfb-451f-ba2c-af8059e69609.PNG]


2220 Bush Dr
McKinney, Texas
75070
www.datavoiceint.com


This message has been sent on behalf of a company that is part of the Harris 
Operating Group of Constellation Software Inc.

If you prefer not to be contacted by Harris Operating Group please notify 
us.



This message is intended exclusively for the individual or entity to which it 
is addressed. This communication may contain information that is proprietary, 
privileged or confidential or otherwise legally exempt from disclosure. If you 
are not the named addressee, you are not authorized to read, print, retain, 
copy or disseminate this message or any part of it. If you have received this 
message in error, please notify the sender immediately by e-mail and delete all 
copies of the message.





On 18. 12. 2020, at 19:24, Victoria Risk  wrote:



On Dec 18, 2020, at 10:15 AM, John Thurston 
mailto:john.thurs...@alaska.gov>> wrote:

We have been using the ISC COPR packages for BIND on CentOS. With the demise of 
CentOS, we (along with a few other people on the planet) need to consider where 
we will move our applications.

We have been completely happy with the packages provided by ISC through COPR. 
Does anyone want to offer up other linux distributions on which they have had 
unqualified success with these same packages?


I have been worrying about whether we would see BIND users shift away from 
CentOS, although I think it is too soon to declare CentOS ‘dead’.

This might be a good time to remind people that we also publish packages for 
Debian (https://packages.debian.org/source/sid/bind9) and Ubuntu 
(https://launchpad.net/~isc). We also maintain a Docker image 
(https://hub.docker.com/r/internetsystemsconsortium/bind9).

Vicky


Victoria Risk
Product Manager
Internet Systems Consortium
vi...@isc.org





___
Please visit 
https://lists.isc.org/mailman/listinfo/bind-users
 to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at 
https://www.isc.org/contact/
 for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND through COPR after CentOS

2020-12-18 Thread Nicolas Bock

On Fri, Dec 18 2020, John Thurston wrote:

> We have been using the ISC COPR packages for BIND on CentOS. With the 
> demise of CentOS, we (along with a few other people on the planet) need 
> to consider where we will move our applications.
>
> We have been completely happy with the packages provided by ISC through 
> COPR. Does anyone want to offer up other linux distributions on which 
> they have had unqualified success with these same packages?

ISC also offers the bind9 package for Ubuntu [1]. I don't
know if that would satisfy your requirements, but it might
be an option.

Best,

Nick

[1] https://launchpad.net/~isc/+archive/ubuntu/bind
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND through COPR after CentOS

2020-12-18 Thread Bruce Johnson

I’m evaluating Oracle Linux to replace CentOS right now for other uses, which 
Oracle pinky-swears will always be free (beer and speech); it’s essentially 
another RHEL clone, with some additional stuff for oracle in the repo. I think 
it’ll end up replacing our CentOS 8 upgrade of ours.

Available Packages
Name : bind
Epoch: 32
Version  : 9.11.20
Release  : 5.el8
Architecture : src
Size : 8.1 M
Source   : None
Repository   : ol8_baseos_latest
Summary  : The Berkeley Internet Name Domain (BIND) DNS (Domain Name 
System) server
URL  : http://www.isc.org/products/BIND/
License  : MPLv2.0
Description  : BIND (Berkeley Internet Name Domain) is an implementation of the 
DNS
 : (Domain Name System) protocols. BIND includes a DNS server 
(named),
 : which resolves host names to IP addresses; a resolver library
 : (routines for applications to use when interfacing with DNS); and
 : tools for verifying that the DNS server is operating properly.


On Dec 18, 2020, at 11:15 AM, John Thurston 
mailto:john.thurs...@alaska.gov>> wrote:

We have been using the ISC COPR packages for BIND on CentOS. With the demise of 
CentOS, we (along with a few other people on the planet) need to consider where 
we will move our applications.

We have been completely happy with the packages provided by ISC through COPR. 
Does anyone want to offer up other linux distributions on which they have had 
unqualified success with these same packages?


--
--
Do things because you should, not just because you can.

John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND through COPR after CentOS

2020-12-18 Thread Leroy Tennison

I should have also mentioned that switching from an rpm world to a deb world 
(CentOS to Ubuntu) does come with it's learning curve.  Some utilities are 
different, networking configuration in particular is located in different 
places, then there's the whole package management system.  Not an enormous 
change but significant.


From: bind-users  on behalf of Bruce Johnson 

Sent: Friday, December 18, 2020 1:12 PM
To: John Thurston 
Cc: bind-users@lists.isc.org 
Subject: [EXTERNAL] Re: BIND through COPR after CentOS


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


I’m evaluating Oracle Linux to replace CentOS right now for other uses, which 
Oracle pinky-swears will always be free (beer and speech); it’s essentially 
another RHEL clone, with some additional stuff for oracle in the repo. I think 
it’ll end up replacing our CentOS 8 upgrade of ours.

Available Packages
Name : bind
Epoch: 32
Version  : 9.11.20
Release  : 5.el8
Architecture : src
Size : 8.1 M
Source   : None
Repository   : ol8_baseos_latest
Summary  : The Berkeley Internet Name Domain (BIND) DNS (Domain Name 
System) server
URL  : 
http://www.isc.org/products/BIND/
License  : MPLv2.0
Description  : BIND (Berkeley Internet Name Domain) is an implementation of the 
DNS
 : (Domain Name System) protocols. BIND includes a DNS server 
(named),
 : which resolves host names to IP addresses; a resolver library
 : (routines for applications to use when interfacing with DNS); and
 : tools for verifying that the DNS server is operating properly.



Harriscomputer

Leroy Tennison
Network Information/Cyber Security Specialist
E: le...@datavoiceint.com
P:


[cid:Data-Voice-International-LOGO_aa3d1c6e-5cfb-451f-ba2c-af8059e69609.PNG]


2220 Bush Dr
McKinney, Texas
75070
www.datavoiceint.com


This message has been sent on behalf of a company that is part of the Harris 
Operating Group of Constellation Software Inc.

If you prefer not to be contacted by Harris Operating Group please notify 
us.



This message is intended exclusively for the individual or entity to which it 
is addressed. This communication may contain information that is proprietary, 
privileged or confidential or otherwise legally exempt from disclosure. If you 
are not the named addressee, you are not authorized to read, print, retain, 
copy or disseminate this message or any part of it. If you have received this 
message in error, please notify the sender immediately by e-mail and delete all 
copies of the message.





On Dec 18, 2020, at 11:15 AM, John Thurston 
mailto:john.thurs...@alaska.gov>> wrote:

We have been using the ISC COPR packages for BIND on CentOS. With the demise of 
CentOS, we (along with a few other people on the planet) need to consider where 
we will move our applications.

We have been completely happy with the packages provided by ISC through COPR. 
Does anyone want to offer up other linux distributions on which they have had 
unqualified success with these same packages?


--
--
Do things because you should, not just because you can.

John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska
___
Please visit 
https://lists.isc.org/mailman/listinfo/bind-users
 to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at 
https://www.isc.org/contact/
 for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs

___
Please visit https://lists.isc.org/mailman/listinf

Re: Forwarded lookup failing on no valid RRSIG

2020-12-18 Thread @lbutlr

On 18 Dec 2020, at 10:56, Nicolas Bock  wrote:
> ;; ANSWER SECTION:
> com. 63779 IN DS 30909 8 2 
> E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766

> In other words, the forwarder returns a Delegation Signer
> record but not an RRset Signature record. Presumably that
> means that that the forwarder is not validating the zone?

This is what I get when checking against my bind server.

;; ANSWER SECTION:
com.43195   IN  DS  30909 8 2 
E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com.43195   IN  RRSIG   DS 8 1 86400 2020123005 
2020121704 26116 . y2okmC5beWCbF84ZmlSM1ALT6Rd3xw9t41MEv6d8ITX8F8PV2Y/RDHvo 
81ZlZK5sNsJFGXsTGyI+u5MrpSzlrD+6QXrE/h5Bt+YIvPI18DK4r5vk 
4676uoPTnU+Lg/3CJOV73BkLhmZ4B50jV5vwnDXHobX8stKtuUyIA5hE 
Uvh1a5znj3mQRrmCXjuQ+Sb5DOORAymJdLlo3RzXs2LurDnnxml4DlnT 
b1BG/tXjOsK/H/QLH7jkPg/9OBQqB7eROkZO+qMQFkkMxmMXFvnR9Mxx 
mDcftsZ7d+/JiYflQh+PHEh3ncnOlLD2+O/FV5Qe9vugmGVybTuf7INt /TiF7g==

-- 
Steak and suspicious-organ pie

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Forwarded lookup failing on no valid RRSIG

2020-12-18 Thread Mark Andrews

Correct it is not validating. Additionally it isn’t even DNSSES aware. It will 
need to be updated for you to validate through it. 

-- 
Mark Andrews

> On 19 Dec 2020, at 05:07, Nicolas Bock  wrote:
> 
> Hi Mark,
> 
> Thanks so much for the reply. I ran this command and am
> getting the following:
> 
> $ dig +dnssec ds com @10.0.0.3
> 
> ; <<>> DiG 9.10.6 <<>> +dnssec ds com @10.0.0.3
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36260
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;com. IN DS
> 
> ;; ANSWER SECTION:
> com. 63779 IN DS 30909 8 2 
> E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
> 
> ;; Query time: 307 msec
> ;; SERVER: 10.0.0.3#53(10.0.0.3)
> ;; WHEN: Fri Dec 18 11:26:28 CST 2020
> ;; MSG SIZE rcvd: 80
> 
> In other words, the forwarder returns a Delegation Signer
> record but not an RRset Signature record. Presumably that
> means that that the forwarder is not validating the zone?
> 
> Thanks,
> 
> Nick
> 
>> On Thu, Dec 17 2020, Mark Andrews wrote:
>> 
>> DNSSEC requires that forwarders support DNSSEC.  Check that the forwarders 
>> return
>> DNSSEC records when they are queried.  The forwarders should also be 
>> validating to
>> filter spoofed responses from the internet.  You should be getting a answer 
>> like
>> this if the forwarders are validating.
>> 
>> [beetle:~] marka% dig +dnssec ds com
>> 
>> ; <<>> DiG 9.15.4 <<>> +dnssec ds com
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31284
>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>> 
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags: do; udp: 4096
>> ; COOKIE: 5cf268bbbafd31a901005fdc081a24542baf0ffea0bb (good)
>> ;; QUESTION SECTION:
>> ;com.INDS
>> 
>> ;; ANSWER SECTION:
>> com.40483INDS30909 8 2 
>> E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
>> com.40483INRRSIGDS 8 1 86400 2020122917 
>> 2020121616 26116 . 
>> cgPgcSi6cq++komd2l+PzrCsawleAikedcwcGk5PbNr1onkXZGNypJoF 
>> 7QQJ4GjMf4b7t+bO5f8szmo0cd2bz+DD0DMXoqUSFvEH4gOX9naoHcm0 
>> 90MS5Wfdeg43gNDSot/U74RJS1CS50U3SreFd2ZFIik9MlCHrSFLf/9V 
>> 7EqTJrs3xz9d/EG34O6qjaEqdw4GW40d3sA6kDGtSC+I9t4rttSEeasZ 
>> FnkZWLCOvzOLfYQlCVqaWpYCnvNdoQUPsbmDCEJf22tanPUft59hPRMu 
>> HmJAOKj77vy+kQWXaBcBo//NUX2asBLus8S7sJ9BDxpGUAsS9o+TdRlq YkIHBA==
>> 
>> ;; Query time: 0 msec
>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>> ;; WHEN: Fri Dec 18 12:38:34 AEDT 2020
>> ;; MSG SIZE  rcvd: 395
>> 
>> [beetle:~] marka% 
>> 
>> 
 On 18 Dec 2020, at 11:36, Nicolas Bock  wrote:
>>> 
>>> Hi,
>>> 
>>> When I configure my named to forward to our corporate DNS
>>> servers (10.0.0.2 and 10.0.0.3), I end up getting error
>>> messages such as
>>> 
>>>  Dec 17 20:58:06 dns-server named[843946]: fetch: www.canonical.com/A
>>>  Dec 17 20:58:06 dns-server named[843946]: fetch: com/DS
>>>  Dec 17 20:58:06 dns-server named[843946]: delete_node(): 
>>> 0x7fa7e331e010 www.canonical.com (bucket 15)
>>>  Dec 17 20:58:06 dns-server named[843946]: delete_node(): 
>>> 0x7fa7e331b080 com (bucket 2)
>>>  Dec 17 20:58:06 dns-server named[843946]: no valid RRSIG resolving 
>>> 'com/DS/IN': 10.0.0.2#53
>>>  Dec 17 20:58:06 dns-server named[843946]: delete_node(): 
>>> 0x7fa7e331b080 com (bucket 2)
>>>  Dec 17 20:58:06 dns-server named[843946]: no valid RRSIG resolving 
>>> 'com/DS/IN': 10.0.0.3#53
>>>  Dec 17 20:58:06 dns-server named[843946]: delete_node(): 
>>> 0x7fa7e331b080 com (bucket 2)
>>>  Dec 17 20:58:06 dns-server named[843946]: no valid DS resolving 
>>> 'www.canonical.com/A/IN': 10.0.0.2#53
>>>  Dec 17 20:58:06 dns-server named[843946]: delete_node(): 
>>> 0x7fa7e331e010 www.canonical.com (bucket 15)
>>>  Dec 17 20:58:06 dns-server named[843946]: validating 
>>> www.canonical.com/A: bad cache hit (com/DS)
>>>  Dec 17 20:58:06 dns-server named[843946]: delete_node(): 
>>> 0x7fa7e331e010 www.canonical.com (bucket 15)
>>>  Dec 17 20:58:06 dns-server named[843946]: broken trust chain resolving 
>>> 'www.canonical.com/A/IN': 10.0.0.3#53
>>> 
>>> I don't quite understand why. Are 10.0.0.{2,3} incorrectly
>>> set up for DNSSEC? It looks like DNSSEC is already breaking
>>> for com. How can I trace what the root cause is?
>>> 
>>> Thanks!
>>> 
>>> Nick
>>> ___
>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>>> unsubscribe from this list
>>> 
>>> ISC funds the development of this software with paid support subscriptions. 
>>> Contact us at https://www.isc.org/contact/ for more information.
>>> 
>>> 
>>> bind-users mailing list
>>> bind-users@lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users
> 

___

Re: Forwarded lookup failing on no valid RRSIG

2020-12-18 Thread Nicolas Bock

Thanks Mark. Am I correct then that I need to either convince the
administrator of that DNS to enable DNSSEC or configure my DNS with
`dnssec-validation = no`?

Thanks,

Nick


On Fri, Dec 18, 2020 at 3:07 PM Mark Andrews  wrote:

> Correct it is not validating. Additionally it isn’t even DNSSES aware. It
> will need to be updated for you to validate through it.
>
> --
> Mark Andrews
>
> > On 19 Dec 2020, at 05:07, Nicolas Bock 
> wrote:
> >
> > Hi Mark,
> >
> > Thanks so much for the reply. I ran this command and am
> > getting the following:
> >
> > $ dig +dnssec ds com @10.0.0.3
> >
> > ; <<>> DiG 9.10.6 <<>> +dnssec ds com @10.0.0.3
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36260
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ;; QUESTION SECTION:
> > ;com. IN DS
> >
> > ;; ANSWER SECTION:
> > com. 63779 IN DS 30909 8 2
> E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
> >
> > ;; Query time: 307 msec
> > ;; SERVER: 10.0.0.3#53(10.0.0.3)
> > ;; WHEN: Fri Dec 18 11:26:28 CST 2020
> > ;; MSG SIZE rcvd: 80
> >
> > In other words, the forwarder returns a Delegation Signer
> > record but not an RRset Signature record. Presumably that
> > means that that the forwarder is not validating the zone?
> >
> > Thanks,
> >
> > Nick
> >
> >> On Thu, Dec 17 2020, Mark Andrews wrote:
> >>
> >> DNSSEC requires that forwarders support DNSSEC.  Check that the
> forwarders return
> >> DNSSEC records when they are queried.  The forwarders should also be
> validating to
> >> filter spoofed responses from the internet.  You should be getting a
> answer like
> >> this if the forwarders are validating.
> >>
> >> [beetle:~] marka% dig +dnssec ds com
> >>
> >> ; <<>> DiG 9.15.4 <<>> +dnssec ds com
> >> ;; global options: +cmd
> >> ;; Got answer:
> >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31284
> >> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
> >>
> >> ;; OPT PSEUDOSECTION:
> >> ; EDNS: version: 0, flags: do; udp: 4096
> >> ; COOKIE: 5cf268bbbafd31a901005fdc081a24542baf0ffea0bb (good)
> >> ;; QUESTION SECTION:
> >> ;com.INDS
> >>
> >> ;; ANSWER SECTION:
> >> com.40483INDS30909 8 2
> E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
> >> com.40483INRRSIGDS 8 1 86400 2020122917
> 2020121616 26116 .
> cgPgcSi6cq++komd2l+PzrCsawleAikedcwcGk5PbNr1onkXZGNypJoF
> 7QQJ4GjMf4b7t+bO5f8szmo0cd2bz+DD0DMXoqUSFvEH4gOX9naoHcm0
> 90MS5Wfdeg43gNDSot/U74RJS1CS50U3SreFd2ZFIik9MlCHrSFLf/9V
> 7EqTJrs3xz9d/EG34O6qjaEqdw4GW40d3sA6kDGtSC+I9t4rttSEeasZ
> FnkZWLCOvzOLfYQlCVqaWpYCnvNdoQUPsbmDCEJf22tanPUft59hPRMu
> HmJAOKj77vy+kQWXaBcBo//NUX2asBLus8S7sJ9BDxpGUAsS9o+TdRlq YkIHBA==
> >>
> >> ;; Query time: 0 msec
> >> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> >> ;; WHEN: Fri Dec 18 12:38:34 AEDT 2020
> >> ;; MSG SIZE  rcvd: 395
> >>
> >> [beetle:~] marka%
> >>
> >>
>  On 18 Dec 2020, at 11:36, Nicolas Bock 
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> When I configure my named to forward to our corporate DNS
> >>> servers (10.0.0.2 and 10.0.0.3), I end up getting error
> >>> messages such as
> >>>
> >>>  Dec 17 20:58:06 dns-server named[843946]: fetch:
> www.canonical.com/A
> >>>  Dec 17 20:58:06 dns-server named[843946]: fetch: com/DS
> >>>  Dec 17 20:58:06 dns-server named[843946]: delete_node():
> 0x7fa7e331e010 www.canonical.com (bucket 15)
> >>>  Dec 17 20:58:06 dns-server named[843946]: delete_node():
> 0x7fa7e331b080 com (bucket 2)
> >>>  Dec 17 20:58:06 dns-server named[843946]: no valid RRSIG
> resolving 'com/DS/IN': 10.0.0.2#53
> >>>  Dec 17 20:58:06 dns-server named[843946]: delete_node():
> 0x7fa7e331b080 com (bucket 2)
> >>>  Dec 17 20:58:06 dns-server named[843946]: no valid RRSIG
> resolving 'com/DS/IN': 10.0.0.3#53
> >>>  Dec 17 20:58:06 dns-server named[843946]: delete_node():
> 0x7fa7e331b080 com (bucket 2)
> >>>  Dec 17 20:58:06 dns-server named[843946]: no valid DS resolving '
> www.canonical.com/A/IN': 10.0.0.2#53
> >>>  Dec 17 20:58:06 dns-server named[843946]: delete_node():
> 0x7fa7e331e010 www.canonical.com (bucket 15)
> >>>  Dec 17 20:58:06 dns-server named[843946]: validating
> www.canonical.com/A: bad cache hit (com/DS)
> >>>  Dec 17 20:58:06 dns-server named[843946]: delete_node():
> 0x7fa7e331e010 www.canonical.com (bucket 15)
> >>>  Dec 17 20:58:06 dns-server named[843946]: broken trust chain
> resolving 'www.canonical.com/A/IN': 10.0.0.3#53
> >>>
> >>> I don't quite understand why. Are 10.0.0.{2,3} incorrectly
> >>> set up for DNSSEC? It looks like DNSSEC is already breaking
> >>> for com. How can I trace what the root cause is?
> >>>
> >>> Thanks!
> >>>
> >>> Nick
> >>> ___
> >>> Please visit https://lists.isc.org/mailman/listinfo

Re: BIND through COPR after CentOS

2020-12-18 Thread G.W. Haywood via bind-users


Hi there,

On Fri, 18 Dec 2020, Leroy Tennison wrote:


... switching from an rpm world to a deb world
... Not an enormous change but significant.


Indeed.  I'd suggest that if it's just about BIND, it's easier to grab
the source and build it.  That way you don't ever have to wait for the
package maintainer (not that you'll usually have to wait long), you do
get to make your own decisions, and there'll be fewer nasty surprises.

This has been my routine for more than a decade - I just did it this
evening on our primary.  The secondaries are somebody else's problem.

$ wget https://downloads.isc.org/isc/bind9/9.11.26/bind-9.11.26.tar.gz
$ tar xzvf bind-9.11.26.tar.gz
$ cd bind-9.11.26/
$ ./configure --enable-ipv6 --prefix=/usr/local --sysconfdir=/etc 
--with-openssl ...
$ make
# make install
# kill $(pidof /usr/local/sbin/named) ; sleep 2 ; /usr/local/sbin/named -u named

I don't think 'apt-get update/upgrade' would have been any quicker.

You might want to check signatures etc., but it is an 'https' download
link.  If you have a lot of machines and no Puppet, you can of course
make your own package in a few minutes.

You'll want to subscribe to the announce@ list.  If there's no CVE, I
usually wait for a couple of days after the announcement...

--

73,
Ged.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

bind refusing update

2020-12-18 Thread Dan Egli

I'm really stumped as to what's going on. I'm trying to get dhcpd to 
automatically update name records for my internal network. This is NOT 
going to the public internet by any means. It's just an internal 
network. But every time either I or dhcpd try to add a record, named 
refuses to allow it. I'm getting a message in the log that says refused 
due to allow-query:


19-Dec-2020 06:49:19.299 update-security: error: client @0x7fa61cd0 
10.0.2.15#49948: update 'eglifamily.name/IN' denied due to allow-query


What's causing this, and how do I fix it? I'm including my named.conf 
and dhcpd.con files below. Can anyone help me?


dhcpd.conf:
default-lease-time 300;
max-lease-time 43200;

ddns-update-style interim;

authoritative;
log-facility local1;


allow booting;

subnet 10.0.2.0 netmask 255.255.255.0 {
# no services at all! That's the llnk from the ISP. Don't touch it!
}


subnet 192.168.10.0 netmask 255.255.255.0 {
    range 192.168.10.128 192.168.10.254;
    if exists user-class and option user-class = "iPXE" {
    filename "pxelinux.efi";
    } else {
    filename "pxelinux.0";
    }
    next-server 192.168.10.3;
    option domain-name-servers 192.168.10.2, 8.8.8.8;
    option domain-name "eglifamily.name";
    option routers 192.168.10.1;

}

host fixed-1 {
    hardware ethernet 08:00:27:D5:AA:3C;
    fixed-address 192.168.10.64;
    option host-name "ethereum-1";
    ddns-hostname "ethereum-1.eglifamily.name";
}

named.conf:
/*
 * Refer to the named.conf(5) and named(8) man pages, and the documentation
 * in /usr/share/doc/bind-* for more details.
 * Online versions of the documentation can be found here:
 * https://kb.isc.org/article/AA-01031
 *
 * If you are going to set up an authoritative server, make sure you
 * understand the hairy details of how DNS works. Even with simple 
mistakes,
 * you can break connectivity for affected parties, or cause huge 
amounts of

 * useless Internet traffic.
 */

acl "xfer" {
    /* Deny transfers by default except for the listed hosts.
 * If we have other name servers, place them here.
 */
    none;
};

/*
 * You might put in here some ips which are allowed to use the cache or
 * recursive queries
 */
acl "trusted" {
    192.168.10.0/24;
    127.0.0.0/8;
    ::1/128;
};

acl "myself" {
    127.0.0.0/24;
    ::1/128;
};

options {
    directory "/var/bind";
    pid-file "/run/named/named.pid";

    /* https://www.isc.org/solutions/dlv >=bind-9.7.x only */
    //bindkeys-file "/etc/bind/bind.keys";
    tkey-gssapi-keytab "/var/lib/samba/bind-dns/dns.keytab";
    minimal-responses yes;


    listen-on-v6 { none; };  // for now
    listen-on { 192.168.10.2; 127.0.0.1; };

    allow-query {
    /*
 * Accept queries from our "trusted" ACL.  We will
 * allow anyone to query our master zones below.
 * This prevents us from becoming a free DNS server
 * to the masses.
 */
    trusted;
    };

    allow-query-cache {
    /* Use the cache for the "trusted" ACL. */
    trusted;
    };

    allow-recursion {
    /* Only trusted addresses are allowed to use recursion. */
    trusted;
    };

    allow-transfer {
    /* Zone tranfers are denied by default. */
    none;
    };

    allow-update {
    myself;
    };

    /*
    * If you've got a DNS server around at your upstream provider, 
enter its
    * IP address here, and enable the line below. This will make 
you benefit

    * from its cache, thus reduce overall DNS traffic in the Internet.
    *
    * Uncomment the following lines to turn on DNS forwarding, and 
change

    *  and/or update the forwarding ip address(es):
    */
/*
    forward first;
    forwarders {
    //  123.123.123.123;    // Your ISP NS
    //  124.124.124.124;    // Your ISP NS
    //  4.2.2.1;    // Level3 Public DNS
    //  4.2.2.2;    // Level3 Public DNS
    8.8.8.8;    // Google Open DNS
    8.8.4.4;    // Google Open DNS
    };

*/

//  dnssec-enable yes;
//  named-checkconf says above line is bad
    //dnssec-validation yes;

    /*
 * As of bind 9.8.0:
 * "If the root key provided has expired,
 * named will log the expiration and validation will not work."
 */
    dnssec-validation auto;

    /* if you have problems and are behind a firewall: */
    //query-source address * port 53;
};


logging {
    channel default_log {
    file "/var/log/named/named.log" versions 5 size 50M;
    print-time yes;
    print-severity yes;

Re: bind refusing update [never mind]

2020-12-18 Thread Dan Egli

I guess sometimes you just need to look at it in a differnet way. I 
never noticed it was using the 10.0.2.15 IP to try to update. That's 
going to be blocked because I don't have the outside world enabled for 
this server. So let me go ask on the DHCP list why it's insisting on 
using that interface.


On 12/18/2020 11:59 PM, Dan Egli wrote:
I'm really stumped as to what's going on. I'm trying to get dhcpd to 
automatically update name records for my internal network. This is NOT 
going to the public internet by any means. It's just an internal 
network. But every time either I or dhcpd try to add a record, named 
refuses to allow it. I'm getting a message in the log that says 
refused due to allow-query:


19-Dec-2020 06:49:19.299 update-security: error: client 
@0x7fa61cd0 10.0.2.15#49948: update 'eglifamily.name/IN' denied 
due to allow-query


What's causing this, and how do I fix it? I'm including my named.conf 
and dhcpd.con files below. Can anyone help me?


dhcpd.conf:
default-lease-time 300;
max-lease-time 43200;

ddns-update-style interim;

authoritative;
log-facility local1;


allow booting;

subnet 10.0.2.0 netmask 255.255.255.0 {
# no services at all! That's the llnk from the ISP. Don't touch it!
}


subnet 192.168.10.0 netmask 255.255.255.0 {
    range 192.168.10.128 192.168.10.254;
    if exists user-class and option user-class = "iPXE" {
    filename "pxelinux.efi";
    } else {
    filename "pxelinux.0";
    }
    next-server 192.168.10.3;
    option domain-name-servers 192.168.10.2, 8.8.8.8;
    option domain-name "eglifamily.name";
    option routers 192.168.10.1;

}

host fixed-1 {
    hardware ethernet 08:00:27:D5:AA:3C;
    fixed-address 192.168.10.64;
    option host-name "ethereum-1";
    ddns-hostname "ethereum-1.eglifamily.name";
}

named.conf:
/*
 * Refer to the named.conf(5) and named(8) man pages, and the 
documentation

 * in /usr/share/doc/bind-* for more details.
 * Online versions of the documentation can be found here:
 * https://kb.isc.org/article/AA-01031
 *
 * If you are going to set up an authoritative server, make sure you
 * understand the hairy details of how DNS works. Even with simple 
mistakes,
 * you can break connectivity for affected parties, or cause huge 
amounts of

 * useless Internet traffic.
 */

acl "xfer" {
    /* Deny transfers by default except for the listed hosts.
 * If we have other name servers, place them here.
 */
    none;
};

/*
 * You might put in here some ips which are allowed to use the cache or
 * recursive queries
 */
acl "trusted" {
    192.168.10.0/24;
    127.0.0.0/8;
    ::1/128;
};

acl "myself" {
    127.0.0.0/24;
    ::1/128;
};

options {
    directory "/var/bind";
    pid-file "/run/named/named.pid";

    /* https://www.isc.org/solutions/dlv >=bind-9.7.x only */
    //bindkeys-file "/etc/bind/bind.keys";
    tkey-gssapi-keytab "/var/lib/samba/bind-dns/dns.keytab";
    minimal-responses yes;


    listen-on-v6 { none; };  // for now
    listen-on { 192.168.10.2; 127.0.0.1; };

    allow-query {
    /*
 * Accept queries from our "trusted" ACL.  We will
 * allow anyone to query our master zones below.
 * This prevents us from becoming a free DNS server
 * to the masses.
 */
    trusted;
    };

    allow-query-cache {
    /* Use the cache for the "trusted" ACL. */
    trusted;
    };

    allow-recursion {
    /* Only trusted addresses are allowed to use 
recursion. */

    trusted;
    };

    allow-transfer {
    /* Zone tranfers are denied by default. */
    none;
    };

    allow-update {
    myself;
    };

    /*
    * If you've got a DNS server around at your upstream provider, 
enter its
    * IP address here, and enable the line below. This will make 
you benefit
    * from its cache, thus reduce overall DNS traffic in the 
Internet.

    *
    * Uncomment the following lines to turn on DNS forwarding, and 
change

    *  and/or update the forwarding ip address(es):
    */
/*
    forward first;
    forwarders {
    //  123.123.123.123;    // Your ISP NS
    //  124.124.124.124;    // Your ISP NS
    //  4.2.2.1;    // Level3 Public DNS
    //  4.2.2.2;    // Level3 Public DNS
    8.8.8.8;    // Google Open DNS
    8.8.4.4;    // Google Open DNS
    };

*/

//  dnssec-enable yes;
//  named-checkconf says above line is bad
    //dnssec-validation yes;

    /*
 * As of bind 9.8.0:
 * "If the root key provided has expired,
 * named will log the expiration and validation will

issue with domain forwarding

issue with domain forwarding

Re: Forwarded lookup failing on no valid RRSIG

BIND through COPR after CentOS

Re: BIND through COPR after CentOS

Re: BIND through COPR after CentOS

Re: BIND through COPR after CentOS

Re: BIND through COPR after CentOS

Re: BIND through COPR after CentOS

Re: BIND through COPR after CentOS

Re: Forwarded lookup failing on no valid RRSIG

Re: Forwarded lookup failing on no valid RRSIG

Re: Forwarded lookup failing on no valid RRSIG

Re: BIND through COPR after CentOS

bind refusing update

Re: bind refusing update [never mind]

16 matches

Site Navigation

Mail list logo

Footer information