numerous nsec3 bad cache hits
On one of my servers I'm seeing numerous log entries of the following type: Oct 29 07:40:14 mx2 named[14747]: validating @0x7f3378be05b0: fema.net SOA: bad cache hit (fema.net/DNSKEY) Oct 29 07:40:15 mx2 named[14747]: validating @0x7f3378be05b0: 6o978dethbt4s0cg8sfb1jsts4ssimsc.fema.net NSEC3: bad cache hit (fema.net/DNSKEY) Oct 29 07:40:15 mx2 named[14747]: validating @0x7f3378be05b0: jkkfnbb4eep0h0ltjf1cisf4eo2lgnm5.fema.net NSEC3: bad cache hit (fema.net/DNSKEY) Oct 29 07:40:15 mx2 named[14747]: validating @0x7f3378be05b0: fema.net SOA: bad cache hit (fema.net/DNSKEY) Oct 29 07:40:15 mx2 named[14747]: validating @0x7f3378be05b0: 6o978dethbt4s0cg8sfb1jsts4ssimsc.fema.net NSEC3: bad cache hit (fema.net/DNSKEY) Oct 29 07:40:15 mx2 named[14747]: validating @0x7f3378be05b0: jkkfnbb4eep0h0ltjf1cisf4eo2lgnm5.fema.net NSEC3: bad cache hit (fema.net/DNSKEY) Oct 29 07:40:15 mx2 named[14747]: validating @0x7f3378be05b0: fema.net SOA: bad cache hit (fema.net/DNSKEY) Oct 29 07:40:20 mx2 named[14747]: validating @0x7f3378be05b0: fema.net SOA: bad cache hit (fema.net/DNSKEY) Oct 29 07:40:20 mx2 named[14747]: validating @0x7f3378be05b0: 6o978dethbt4s0cg8sfb1jsts4ssimsc.fema.net NSEC3: bad cache hit (fema.net/DNSKEY) Oct 29 07:40:20 mx2 named[14747]: validating @0x7f3378be05b0: fema.net SOA: bad cache hit (fema.net/DNSKEY) Oct 29 07:40:20 mx2 named[14747]: validating @0x7f3378be05b0: 6o978dethbt4s0cg8sfb1jsts4ssimsc.fema.net NSEC3: bad cache hit (fema.net/DNSKEY) I'm guessing this is some kind of brute force attack on BIND trying to take advantage of a broken dnssec configuration for fema.net? The problem is that the syslog is filled with these messages. Antonio Querubin e-mail: t...@lavanauts.org xmpp: antonioqueru...@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: A record of domain name must be name server ?
On Thu, 11 Sep 2014, Matus UHLAR - fantomas wrote: If you point www CNAME @, the 'www' will have both MX and NS records same as example.com. Which may e.g. cause rejectd on backup MX hosts, apparently not designed to receive mail for www.example.com. Actually no. All other RRs are supposed to be ignored (except for RRSIG, etc) once the CNAME exists. Ie. the MX and NS RRs exist only for example.com, but not www.example.com. Antonio Querubin e-mail: t...@lavanauts.org xmpp: antonioqueru...@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: Serial numbers for inline signing
Is there a way to keep the serial numbers synced between the primary and slaves for auto-maintained zones? Every once in a while the primary and slaves somehow get out of sync and the logs start generating error messages about the mis-match. The mis-match also gets noticed by various DNS sanity checkers. Antonio Querubin e-mail: t...@lavanauts.org xmpp: antonioqueru...@gmail.com On Dec 18, 2013, at 10:17 AM, Thomas Schulz sch...@adi.com wrote: I have a question about the serial number as modified by inline signing. I have a static zone, adi.com, that I am setting up for dnssec. I added inline-signing yes; key-directory dnssec; auto-dnssec maintain; to my named.conf file after generating the keys and then did a rndc restart. After that I did a rndc signing -nsec3param 1 0 10 aef7db3a adi.com to switch to nsec3. Checking the resulting serial number, I find that it is 2013120423. The serial number in the static zone file is 2013120400. Why did it bump it up to 23? I expected something like 02. I can’t tell you why you got an exact number, but the best rule about this is “don’t worry about the signed serial number”, as BIND will take care of it for you. As long as you continue to increment the static zone serial number as you always have, the serial in the signed zone will be maintained correctly. There are a number of things that are happening all the time with the signed zone that you are not aware of, for example, re-signing as signatures reach expiration, re-signing when you change from NSEC to NSEC3, etc. All of these will keep the signed serial number ‘bumping up’ even when your zone isn’t changing. AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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: dig and IPV6 server
On Mon, 26 Aug 2013, hugo hugoo wrote: C:\digdig @fe80::a6b1:e9ff:fe68:c8 www.google.be dig: couldn't get address for 'fe80::a6b1:e9ff:fe68:c8': address family not supported Try adding the interface to the link-local, eg.: dig @fe80::a6b1:e9ff:fe68:c8%eth0 www.google.be Antonio Querubin e-mail: t...@lavanauts.org xmpp: antonioqueru...@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
tools for searching/removing stale keys
Has anyone come up with scripts/tools for removing stale zone-signing keys but leaving key-signing keys which are in the same directory alone? Antonio Querubin e-mail/xmpp: t...@lava.net ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
need to disable dnssec for pseudo TLD zone
When I recently installed the root dnssec initial key on our DNS it broke
it's ability to accept responses for forwarded requests for a DNS block
list zone served by another system. Other queries aren't affected. The
config for the forwarded zone looks like:
zone dnsbl {
type forward;
forward only;
forwarders {
10.0.0.124;
};
};
The server at 10.0.0.124 is running rbldnsd. Queries to our main resolver
DNS for anything in the 'dnsbl' zone generate a SERVFAIL and BIND logs
messages similar to the following:
error (chase DS servers) resolving 'sbl.dnsbl/DS/IN': 10.0.0.124#53
If I disable the root initial key, the forwarded queries work again. I
think the problem is that our pseudo TLD 'dnsbl' isn't a signed zone or
something like that. The RRs for the zone are retrieved from various spam
BL repositories.
Is there a way to disable dnssec validation on a per-zone basis for
internal pseudo TLDs?
Antonio Querubin
808-545-5282 x3003
e-mail/xmpp: t...@lava.net
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
