dnssec bad cache hit error for bind9.16.13

2021-04-01 Thread Sakuma, Koshiro
Hello Team;

I've just finished setup for bind9.16.13 from scratch (source).  But I got
error when I checked with bind function with "dig" command.   The error I
got was as below.

1. dig result;
; <<>> DiG 9.11.20-RedHat-9.11.20-5.el8_3.1 <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: *SERVFAIL,* id: 17070
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

2. named.log
There are many bad cache hit logs.
dnssec: view internal:   validating nikkei225jp.com/SOA: bad cache hit
(com/DS)

I tried to dig out for this issue, I found one thing that disable
dnssec-validation option.
After changing, the issue had been fixed.  However, I'm wondering if I can
disable this option for security reason.  Or there is another solution??

Thank you for your support!

Regards,
___
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: replication time for dynamic records from primary to secondary servers

2021-04-01 Thread Cuttler, Brian R (HEALTH) via bind-users
Tony,

I don't think the issue I'm having is related to notify message not being 
reacted to nor zone transfer requests not being sent to answered.

What I think I'm seeing is DHCP updating the DNS primary, which works 
correctly, but I don't believe it updates the SOA serial number nor sends a 
notify message.

When you add a record to a zone, either by # nsupdate or via the transaction (I 
assume nsupdate protocol) between DHCP and DNS primary does something else need 
to be configured in order to get that incremental change sent to the secondary? 
Something that does not normally need to be set?

The issue is not that frequently noticed. The typical problem that crossed by 
desk looks like this.
 - Someone put a new printer online, it gets an IP from DHCP and asks DHCP to 
register its "name" with DNS which DHCP does on behalf of our printers
   and desktop computers (we do not allow the end points to create DHCP 
records).
 - I don't believe this updates the SOA serial number nor generates a Notify 
message, thought at could be a deficiency in the config.
 - At some point the secondary gets all of the updated records from the primary 
but in that interval the print server is updated to create a new print
   queue and if it queries the DNS secondary the printer name may fail to 
resolve.

The answers we have employed are 1) be patient 2) remove the deficient zones 
files from the DNS secondary and restart the DNS secondary.

Should the incremental update from the DHCP server cause DNS to update the SN 
and send a notify message?
Is there some other mechanism to update the secondary?

Thanks,
Brian

-Original Message-
From: Tony Finch  On Behalf Of Tony Finch
Sent: Wednesday, March 31, 2021 11:43 AM
To: Cuttler, Brian R (HEALTH) 
Cc: bind-users@lists.isc.org
Subject: Re: replication time for dynamic records from primary to secondary 
servers

ATTENTION: This email came from an external source. Do not open attachments or 
click on links from unknown senders or unexpected emails.


Cuttler, Brian R (HEALTH) via bind-users  wrote:
>
> We are seeing a delay in the primary DNS server updating the secondary
> and would like to shorten that interval.

This is probably due to NOTIFY messages not working. NOTIFY is the
mechanism that allows primary servers to tell secondaries to get the
latest version of a zone promptly. I wrote some notes on debugging slow
zone transfers a couple of weeks ago:

https://protect2.fireeye.com/v1/url?k=9a160f3f-c58d367e-9a14f60a-000babda0106-d930663ddef913a2=1=067dcc81-1082-4e21-a672-c998f736beca=https%3A%2F%2Flists.isc.org%2Fpipermail%2Fbind-users%2F2021-March%2F104278.html

Tony.
--
f.anthony.n.finch
https://protect2.fireeye.com/v1/url?k=4efddec9-1166e788-4eff27fc-000babda0106-90e4f91c3445cf30=1=067dcc81-1082-4e21-a672-c998f736beca=https%3A%2F%2Fdotat.at%2F
Fair Isle: North 5 or 6, decreasing 3 or 4, then backing northwest 4
or 5 later. Moderate or rough, becoming slight or moderate. Mainly
fair. Good.

___
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