Stop of logging of No Valid Signature Found

[Robert Moskowitz]

Yes, I know lots of places don't have DNSSEC signed zones. **I** have
not done mine yet, but I turned on DNSSEC checking on my server and I am
getting all too many messages like:

validating @0xb4247b50: 117.in-addr.arpa NSEC: no valid signature
found: 1 Time(s)
validating @0xb4247b50: 117.in-addr.arpa SOA: no valid signature
found: 1 Time(s)


How can I stop the logging of only " no valid signature found"? So I
can watch for more meaningful events and not so quickly grow
/var/log/messages?

[Casey Deccio]

On Mon, Feb 25, 2013 at 5:09 AM, Robert Moskowitz <r...@htt-consult.com> wrote:

Yes, I know lots of places don't have DNSSEC signed zones.  **I** have not done mine yet, but I turned on DNSSEC checking on my server and I am getting all too many messages like:

      validating @0xb4247b50: 117.in-addr.arpa NSEC: no valid signature found: 1 Time(s)
      validating @0xb4247b50: 117.in-addr.arpa SOA: no valid signature found: 1 Time(s)

Yes, but 117.in-addr.arpa *is* signed [1], so if you're not getting signatures, that's problematic.
 

How can I stop the logging of only " no valid signature found"?  So I can watch for more meaningful events and not so quickly grow /var/log/messages?

Logging can be tuned on a per-category (e.g., DNSSEC) basis, including the location to which log messages are sent (e.g., file, syslog, etc.).  See the section on logging in the BIND 9 Configuration Reference for more information on how to do this [2].

Casey

[1]  http://dnsviz.net/d/117.in-addr.arpa/USuy_w/dnssec/
[2]  http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch06.html

[Robert Moskowitz]

On 02/25/2013 02:00 PM, Casey Deccio wrote:

On Mon, Feb 25, 2013 at 5:09 AM, Robert Moskowitz <r...@htt-consult.com> wrote:

Yes, I know lots of places don't have DNSSEC signed zones.  **I** have not done mine yet, but I turned on DNSSEC checking on my server and I am getting all too many messages like:

      validating @0xb4247b50: 117.in-addr.arpa NSEC: no valid signature found: 1 Time(s)
      validating @0xb4247b50: 117.in-addr.arpa SOA: no valid signature found: 1 Time(s)

Yes, but 117.in-addr.arpa *is* signed [1], so if you're not getting signatures, that's problematic.

So that is not good.  This is over port 53, right?  I have that open for udp and tcp.  My general options section has:

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

    /* Path to ISC DLV key */
    bindkeys-file "/etc/named.iscdlv.key";

    managed-keys-directory "/var/named/dynamic";

How can I stop the logging of only " no valid signature found"?  So I can watch for more meaningful events and not so quickly grow /var/log/messages?

Logging can be tuned on a per-category (e.g., DNSSEC) basis, including the location to which log messages are sent (e.g., file, syslog, etc.).  See the section on logging in the BIND 9 Configuration Reference for more information on how to do this [2].

thanks I will read this AFTER I find out why I am not getting the signature.  Perhaps I should check to see if I am getting any sigs?  How might I do that?

[Robert Moskowitz]

Well I am not getting this sig authenticated.  Per offlist instructions I did (and got no aa flag):

dig +dnssec 117.in-addr.arpa ptr

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.6 <<>> +dnssec 117.in-addr.arpa ptr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34757
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;117.in-addr.arpa.        IN    PTR

;; AUTHORITY SECTION:
117.in-addr.arpa.    10800    IN    SOA    ns1.apnic.net. read-txt-record-of-zone-first-dns-admin.apnic.net. 3006077576 7200 1800 604800 172800
117.in-addr.arpa.    10800    IN    RRSIG    SOA 5 3 172800 20130327180149 20130225170149 31261 117.in-addr.arpa. bC/xkWAsZ9+NdEMshdBQKqE4Xkdvjnwtqquvbl2142Og64XkgplTlrB8 gMgCGxeorXpzvPJDsCfhlpXWsq2ck+qSSvOEJeOEt88BBumMAO1Bc46k klXmQ4+eckbnWEwrpk4nkG+3K8lbAgZZjSPiVpbu4klfRyZ+T45EnZx0 oJc=
117.in-addr.arpa.    10800    IN    RRSIG    NSEC 5 3 172800 20130327180149 20130225170149 31261 117.in-addr.arpa. LIxMYOMIW8eTRACvq02vqMrhSk7tX8Az2gahOJ5jYCUvGDzsTtcm7ub+ qyWADcklsVi3hiWHnSzAPTIrO6WIrxj/wZl/5m5QTOK38Ml4ut0FFkK+ 4qujylUJ8+3mmPbTbTIe6gdB8Lv/6pV2rZy1pDm1TxhGykwG82v+1R2E +88=
117.in-addr.arpa.    10800    IN    NSEC    0.117.in-addr.arpa. NS SOA TXT RRSIG NSEC DNSKEY

;; Query time: 207 msec
;; SERVER: 208.83.67.148#53(208.83.67.148)
;; WHEN: Mon Feb 25 15:16:54 2013
;; MSG SIZE  rcvd: 527

[Robert Moskowitz]

On 02/25/2013 03:25 PM, Robert Moskowitz wrote:

On 02/25/2013 02:33 PM, Robert Moskowitz wrote:

On 02/25/2013 02:00 PM, Casey Deccio wrote:

On Mon, Feb 25, 2013 at 5:09 AM, Robert Moskowitz <r...@htt-consult.com> wrote:

Yes, I know lots of places don't have DNSSEC signed zones.  **I** have not done mine yet, but I turned on DNSSEC checking on my server and I am getting all too many messages like:

      validating @0xb4247b50: 117.in-addr.arpa NSEC: no valid signature found: 1 Time(s)
      validating @0xb4247b50: 117.in-addr.arpa SOA: no valid signature found: 1 Time(s)

Yes, but 117.in-addr.arpa *is* signed [1], so if you're not getting signatures, that's problematic.

So that is not good.  This is over port 53, right?  I have that open for udp and tcp.  My general options section has:

    dnssec-enable yes;
    dnssec-validation yes;

digging back in the archive here, I find out this should be

    dnssec-validation auto;

And now I don't have all those false no valid sig messages and I can look for the NEXT problem.

[Mark Andrews]

In message <512C09F5...@htt-consult.com>, Robert Moskowitz writes:
> On 02/25/2013 03:25 PM, Robert Moskowitz wrote:
> >
> > On 02/25/2013 02:33 PM, Robert Moskowitz wrote:
> >>
> >> On 02/25/2013 02:00 PM, Casey Deccio wrote:
> >>> On Mon, Feb 25, 2013 at 5:09 AM, Robert Moskowitz
> >>> <r...@htt-consult.com <mailto:r...@htt-consult.com>> wrote:
> >>>
> >>> Yes, I know lots of places don't have DNSSEC signed zones.
> >>> **I** have not done mine yet, but I turned on DNSSEC checking
> >>> on my server and I am getting all too many messages like:
> >>>
> >>> validating @0xb4247b50: 117.in-addr.arpa NSEC: no valid
> >>> signature found: 1 Time(s)
> >>> validating @0xb4247b50: 117.in-addr.arpa SOA: no valid
> >>> signature found: 1 Time(s)
> >>>
> >>>
> >>> Yes, but 117.in-addr.arpa *is* signed [1], so if you're not getting
> >>> signatures, that's problematic.
> >>
> >> So that is not good. This is over port 53, right? I have that open
> >> for udp and tcp. My general options section has:
> >>
> >> dnssec-enable yes;
> >> dnssec-validation yes;
>
> digging back in the archive here, I find out this should be
>
> dnssec-validation auto;

Actually it can be either. It's all a matter of how you want to
setup your trust anchors. For private root zones it is absolutely
the wrong thing to do.

> And now I don't have all those false no valid sig messages and I can
> look for the NEXT problem.
>
> >> dnssec-lookaside auto;
> >>
> >> /* Path to ISC DLV key */
> >> bindkeys-file "/etc/named.iscdlv.key";
> >>
> >> managed-keys-directory "/var/named/dynamic";
> >>
> >>
>
>

> --------------040909030006030801080707
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
>
> <html>
> <head>
> <meta content="text/html; charset=ISO-8859-1"
> http-equiv="Content-Type">
> </head>
> <body bgcolor="#FFFFFF" text="#000000">
> <br>
> <div class="moz-cite-prefix">On 02/25/2013 03:25 PM, Robert
> Moskowitz wrote:<br>
> </div>
> <blockquote cite="mid:512BC8D6...@htt-consult.com" type="cite">
> <meta http-equiv="Context-Type" content="text/html;
> charset=ISO-8859-1">
> <br>
> <div class="moz-cite-prefix">On 02/25/2013 02:33 PM, Robert
> Moskowitz wrote:<br>
> </div>
> <blockquote cite="mid:512BBC82...@htt-consult.com"
> type="cite"> <br>
> <div class="moz-cite-prefix">On 02/25/2013 02:00 PM, Casey
> Deccio wrote:<br>
> </div>
> <blockquote
> cite="mid:CAEKtLiSLdsWZ8odu6LR+R=-O4sYuSAQVqfna...@mail.gmail.com"
> type="cite"> On Mon, Feb 25, 2013 at 5:09 AM, Robert Moskowitz
> <span dir="ltr">&lt;<a moz-do-not-send="true"
> href="mailto:r...@htt-consult.com" target="_blank">rgm@htt-consu
> lt.com</a>&gt;</span>
> wrote:<br>
> <div class="gmail_quote">
> <blockquote class="gmail_quote"> Yes, I know lots of places
> don't have DNSSEC signed zones. &nbsp;**I** have not done mine

> yet, but I turned on DNSSEC checking on my server and I am

> getting all too many messages like:<br>
> <br>
> &nbsp; &nbsp; &nbsp; validating @0xb4247b50: 117.in-addr.arpa N
> SEC: no
> valid signature found: 1 Time(s)<br>
> &nbsp; &nbsp; &nbsp; validating @0xb4247b50: 117.in-addr.arpa S
> OA: no
> valid signature found: 1 Time(s)<br>
> </blockquote>
> <div><br>

> Yes, but 117.in-addr.arpa *is* signed [1], so if you're

> not getting signatures, that's problematic.<br>
> </div>
> </div>
> </blockquote>
> <br>
> So that is not good.&nbsp; This is over port 53, right?&nbsp; I have
> that
> open for udp and tcp.&nbsp; My general options section has:<br>
> <br>
> &nbsp;&nbsp;&nbsp; dnssec-enable yes;<br>
> &nbsp;&nbsp;&nbsp; dnssec-validation yes;<br>
> </blockquote>
> </blockquote>
> <br>
> digging back in the archive here, I find out this should be<br>
> <br>
> &nbsp;&nbsp;&nbsp; dnssec-validation auto;<br>
> <br>

> And now I don't have all those false no valid sig messages and I can

> look for the NEXT problem.<br>
> <br>
> <blockquote cite="mid:512BC8D6...@htt-consult.com" type="cite">
> <blockquote cite="mid:512BBC82...@htt-consult.com"
> type="cite"> &nbsp;&nbsp;&nbsp; dnssec-lookaside auto;<br>
> <br>
> &nbsp;&nbsp;&nbsp; /* Path to ISC DLV key */<br>
> &nbsp;&nbsp;&nbsp; bindkeys-file "/etc/named.iscdlv.key";<br>
> <br>
> &nbsp;&nbsp;&nbsp; managed-keys-directory "/var/named/dynamic";<br>
> <br>
> <br>
> </blockquote>
> </blockquote>
> <br>
> </body>
> </html>
>
> --------------040909030006030801080707--
>
> --===============3835226412723589147==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> --===============3835226412723589147==--
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

[Robert Moskowitz]

I got this from some old messages from you on the subject of "no valid
signature".

Perhaps tieing into my using the builtin root hints rather than
explicitly including a root.hint stub?

Like the other person, once I changed from 'yes' to 'auto' I stopped
logging these messages so I ASSuME that now all those zones are being
validated.

No private root zones here. At least that I know of!

[Mark Andrews]

In message <512C1009...@htt-consult.com>, Robert Moskowitz writes:
> >>>> dnssec-enable yes;
> >>>> dnssec-validation yes;
> >> digging back in the archive here, I find out this should be
> >>
> >> dnssec-validation auto;
> > Actually it can be either. It's all a matter of how you want to
> > setup your trust anchors. For private root zones it is absolutely
> > the wrong thing to do.
>
> I got this from some old messages from you on the subject of "no valid
> signature".
>
> Perhaps tieing into my using the builtin root hints rather than
> explicitly including a root.hint stub?
>
> Like the other person, once I changed from 'yes' to 'auto' I stopped
> logging these messages so I ASSuME that now all those zones are being
> validated.
>
> No private root zones here. At least that I know of!

dnssec-validation auto; adds a implicit managed-keys clause for the
root. If you just do dnssec-validation yes; you need to add a
explict trusted-keys / managed-keys clause.

managed-keys {
. initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=";
};

If you have islands of trust you will need to have managed/trusted
keys for them. It is also a good idea to have managed/trusted keys
for your internal zones so you are not dependent on external zones
for internal lookups when your internet connection goes down.

Mark

[Robert Moskowitz]

On 02/25/2013 08:38 PM, Mark Andrews wrote:
> In message <512C1009...@htt-consult.com>, Robert Moskowitz writes:
>>>>>> dnssec-enable yes;
>>>>>> dnssec-validation yes;
>>>> digging back in the archive here, I find out this should be
>>>>
>>>> dnssec-validation auto;
>>> Actually it can be either. It's all a matter of how you want to
>>> setup your trust anchors. For private root zones it is absolutely
>>> the wrong thing to do.
>> I got this from some old messages from you on the subject of "no valid
>> signature".
>>
>> Perhaps tieing into my using the builtin root hints rather than
>> explicitly including a root.hint stub?
>>
>> Like the other person, once I changed from 'yes' to 'auto' I stopped
>> logging these messages so I ASSuME that now all those zones are being
>> validated.
>>
>> No private root zones here. At least that I know of!
> dnssec-validation auto; adds a implicit managed-keys clause for the
> root. If you just do dnssec-validation yes; you need to add a
> explict trusted-keys / managed-keys clause.
>
> managed-keys {
> . initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=";
> };

Yes, I wondered about this as I have the include:

bindkeys-file "/etc/named.iscdlv.key";

which contains:

managed-keys {
# ISC DLV: See https://www.isc.org/solutions/dlv for details.
# NOTE: This key is activated by setting "dnssec-lookaside auto;"
# in named.conf.
dlv.isc.org. initial-key 257 3 5
"BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2
brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+
1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5
ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk
Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM
QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt
TDN0YUuWrBNh";

# ROOT KEY: See https://data.iana.org/root-anchors/root-anchors.xml
# for current trust anchor information.
# NOTE: This key is activated by setting "dnssec-validation auto;"
# in named.conf.

. initial-key 257 3 8
"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
QxA+Uk1ihz0=";
};

So why did this not work?

> If you have islands of trust you will need to have managed/trusted
> keys for them. It is also a good idea to have managed/trusted keys
> for your internal zones so you are not dependent on external zones
> for internal lookups when your internet connection goes down.

I know I need to tackle my internal view. After I put up the new
server, I built a test server for only a few internal systems to use. I
will work on my internal view there, and then bring that over to my main
server.

One step at a time. Or maybe two or three?

[Mark Andrews]

Because it is only processed in the "auto" cases and only the approritate
trusted keys are extracted.

bindkeys-file "/etc/named.iscdlv.key";

is not the same as

include "/etc/named.iscdlv.key";

> > If you have islands of trust you will need to have managed/trusted
> > keys for them. It is also a good idea to have managed/trusted keys
> > for your internal zones so you are not dependent on external zones
> > for internal lookups when your internet connection goes down.
>
> I know I need to tackle my internal view. After I put up the new
> server, I built a test server for only a few internal systems to use. I
> will work on my internal view there, and then bring that over to my main
> server.
>
> One step at a time. Or maybe two or three?

[Robert Moskowitz]

Oops. That's what I get for copying the DNSSEC 'stuff' from the default
named.conf supplied by RHEL/Centos which looks like it is for a caching
server.

So should I change this to an include and put dnssec-validation back to yes?

[Chris Buxton]

On Feb 25, 2013, at 8:25 PM, Robert Moskowitz wrote:
> So should I change this to an include and put dnssec-validation back to yes?

No. "dnssec-validation auto;" is correct for 90% of cases. An Internet validating resolver should almost certainly use this. Mark is simply being precise and complete in his explanation.

Chris Buxton
BlueCat Networks