Re: configuration error in lists.isc.org

[Reindl Harald]

Am 07.08.2015 um 01:25 schrieb Heiko Richter:

Whenever I post something to the list (I'm not using SMTP, I'm using a
usenet server to post to comp.protocols.dns.bind), my postmaster
address receives DMARC notifications from list members that have
employed this wonderful protocol on their servers, telling me my
message had been rejected for violating my SPF policy.

My SPF record doesn't include lists.ist.org, of course and it never
will. Furthermore it ends with "-all" so all my messages to the list
are being rejected by list members who have spf aware servers.

Just wanted to let you all know about it as I can imagine I'm not the
only person who has outgoing SPF.

And the worst thing: If you have a record ending with "~all" your
messages will be accepted but probably end up in a spam report
container slowly eating away the good anti-spam-reputation your server
has.

So ISC: please fix your list servers, let them rewrite the From headers!


please try to understand the topic before blaming!
http://wiki.list.org/DEV/DMARC

* SPF is about envelopes and *never* from-headers
* the envelope is @lists.isc.org

the problem is the list-footer breaking DKIM

> I'm not using SMTP, I'm using a usenet server
> to post to comp.protocols.dns.bind

well, and where is your DKIM signature at all when you are talking about 
DMARC - just look at the source code of your own mail?




signature.asc
Description: OpenPGP digital 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

tsig zone sharing between zones check + scream

[Lawrence K. Chen, P.Eng.]

Gjust noticed that about 12 hours ago, the business office person 
finally update our KSK with registrar. (where window was last month.)


Well, apparently history must repeat

3 years ago, we rolled over from RSASHA256 to RSASHA256... but the person 
that did all the interaction with registrarswhere the criteria is that 
they be in position to pay as needed (which did used to be dns 
administrator/department manager/etcbut when they left the new manager he 
didn't want us to continue to have that responsibility...but would've taken 
it...anyhoo)  They selected algorithm type as RSASHA1-NSEC3...


Which caused a bit of an outage, especially since they went on vacation right 
after having left it to the last minute. we had a 60 day rollover 
window)...original I had gone around end of fiscal year, but decided to shift 
it...



Well, this timestill going RSASHA256 to RSASHA256 (I had done the 
roll from RSASHA1-NSEC to RSASHA256 before it was possible to register do 
such things with registrar...so only DLV was involvedthough I did run 
into a problem since I had a DS record in my zone, etc. the mismatch doing 
one than the other apparently was the wrong way to go...or soemething.)


So this time...RSASHA1 (#5) got selected.

--

So about tsig sharing a zone

Is something like this right? (ignoring any typos ;)

==

  key "external" {
  algorithm hmac-sha1;
  secret "";
  }

  key "internal" }
  algorith hmac-sha1;
  secret "";
  }

  options {
notify explicit;
allow-trasnfer { none; };
  }

  acl k-state { 129.130/16; 10.130/16; 10.131/16; 10.132/16; ... 10.139/16; 
172.21/16; 192.168.x.0/24; 10.0.0.0/24; };


  acl internal { !key external; key internal; k-state; };
  acl external { !key internal; key external; any; };

  view "internal" {
  match-clients { internal; };

  allow-transfer { key internal; };

  zone "ksu.edu" {
 type master;
 file "pri/ksu.campus.signed";
 allow-transfer { key internal; int-secs; };
 also-notify { 129.130.x.x; 129.130.x.y; 129.130.x.z; };
  }
  zone "ads.ksu.edu" {
 type slave;
 file "sec/zone.ads.ksu.edu";
 masters { 127.0.0.1 key external;
   129.130.y.y;
   129.130.y.z;
 };
 multi-master yes;
 also-notify { 127.0.0.1 key external };
  };
   };

   view "external" {
   match-clients { external; };

   allow-transfer { key external; };

   zone "ksu.edu" {
   type master;
   file "pri/ksu.edu.signed";
   also notify { 129.130.139.150 key external;
 129.130.139.151 key external;
 129.130.254.21 key external;
   };
   };
   zone "ads.ksu.edu" {
   type slave;
   file "ext/zone.ads.ksu.edu";
   masters { 127.0.0.1 key internal; };
   also notify { 129.130.139.150 key external;
 129.130.139.151 key external;
 129.130.254.21 key external;
   };
  };
  };

==

I think that's what I'm thinkingthough been so long since I too break 
from monitor that I can barely see now


--
Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator
   with LOPSA Professional Recognition.
For: Enterprise Server Technologies (EST) -- & SafeZone Ally

___
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: [OT] Re: configuration error in lists.isc.org

[Matus UHLAR - fantomas]

On Aug 6, 2015, at 4:25 PM, Heiko Richter mailto:em...@heikorichter.name>> wrote:

Whenever I post something to the list (I'm not using SMTP, I'm
using a usenet server to post to comp.protocols.dns.bind), my
postmaster address receives DMARC notifications from list members
that have employed this wonderful protocol on their servers,
telling me my message had been rejected for violating my SPF
policy.

My SPF record doesn't include lists.ist.org
, of course and it never will. Furthermore
it ends with "-all" so all my messages to the list are being
rejected by list members who have spf aware servers.


SPF must only check envelope address, not header From: address
- it was never designed to do the latter.

On 07.08.15 02:54, Heiko Richter wrote:

Just found another solution, that will help with any DMARC-aware
server that knows Sender-ID. I just published:
heikorichter.name.  60  IN  TXT "spf2.0/pra ?all"

This will force DMARC to check only the envelope sender, which is
changed by lists.isc.org as /dev/rob0 pointed out earlier


How did your SenderID record look before?

Note that it's the SenderID specification that is horribly broken (btw, just
because of mailing lists) and further any protocol that uses it (does
DMARC?)

Blaming the ISC mailserver for not changing header address is blaming it for
doing something (all?) list servers did years before microsoft came with the
braindead SenderID specification that broke this behaviour.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"One World. One Web. One Program." - Microsoft promotional advertisement
"Ein Volk, ein Reich, ein Fuhrer!" - Adolf Hitler
___
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: configuration error in lists.isc.org

[Lawrence K. Chen, P.Eng.]

On 2015-08-06 19:00, /dev/rob0 wrote:



My SPF record doesn't include lists.ist.org, of course and it never
will. Furthermore it ends with "-all" so all my messages to the
list are being rejected by list members who have spf aware servers.


No, GNU Mailman (which is the software behind lists.isc.org) does the
right thing, setting a proper *envelope* sender address in the ISC
domain.  Proper filtering would go on the envelope sender.



Hmm, I had thought look, but I see that nowwhich seemed that it should be 
the ideal way to go People here have gotten angry when something changes 
headers on them.  Office 365 rewrite From lines...and its not a fixed 
wayas it breaks my mail filters every now and then.  The rewriting had 
angered users here, since for some of us what we put with our email address 
in the from is important or consistent (its what I sent my from to when I 
first started here, not sure what people would think if I changed it  
Though there'll be a point where I might want to stop paying for right right 
to use it...




Just wanted to let you all know about it as I can imagine I'm not
the only person who has outgoing SPF.

And the worst thing: If you have a record ending with "~all" your
messages will be accepted but probably end up in a spam report
container slowly eating away the good anti-spam-reputation your
server has.


Unfortunately a lot of sites do silly things, so there may be a bit
of truth in that.  But it's not a reason to join in on doing silly
things.



In looking through the received headers I see that there's no SPF for 
lists.isc.org


We used to have ~all for our SPF, but eventually we went with -all, and that 
has caused some weird rejections for people.


Like a research needs to email expenses some .gov address, which is just a 
forwarder to the real person's addressbut the mailer for that address, 
doesn't see their forwarder as an allowed address for us, so its bounced the 
bounced the emails back.


I don't see why I need to list the .gov as ours...when the people that run it 
don't trust it.  But, various reasons didn't seem to calm the person down.. 
went over our heads but never heard about the issue again.


OTOH, we have caved on adding systems that aren't 'ours'...though how much of 
Office365 is actually 'ours'but I think we currently have a couple 
includes for mass emailing solutions or our survey system (normally we push 
for them to use a subomain, our old in-house survey system was on its own 
subdomain, which the new one can use, but its more flexible on what users can 
useit then comes down to whether there's a SPF rule in their way or not.



So ISC: please fix your list servers, let them rewrite the From
headers!


Seems to me this is the Listserv way though we haven't yet upgraded to 
that version of Listserv.  Otherwise I had thought about using mimedefang to 
rewrite the envelope so that our old Listserv could continue...current is 16 
ours is 14really need to get it upgraded for other reasons...and though 
they were going to finally go live while I had been away, but now it might be 
not be until next year?  Suspect there's something between our generating 
class lists automation while our mainframe is gone the the automation, a 
collection of nearly 150 ReXX scripts...lives on.  And, it does things that 
Listserv is not supposed allow ...like prevent users from unsubscribing from 
a list...though that's basically processes notification that somebody has 
unsubscribed, and send commands to resubscribe them


While Mimedefang can also rewrite Fron/To/Subject, etc I'm person don't like 
such things


Especially the rewriting because it thinks the email is spam (or I am and 
changes it so the email can't be replied to, etc.)


Though the frequency of complaints over this seems to have dropped off 
here...though  its summer and most people haven't noticed yet that the new 
listserv did not go live on June 1st.



--
Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator
   with LOPSA Professional Recognition.
For: Enterprise Server Technologies (EST) -- & SafeZone Ally
___
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: do not stupidly delete ZSK files

[Lawrence K. Chen, P.Eng.]

On 2015-08-06 19:26, Heiko Richter wrote:


Though back then I was still building bind 32-bit, and the hardware
as much slower.  A full signing was more than 10x longer than our
current hardwarewhich can get it done in just under a minute.
(usually)  The need for speed is some people expect DNS changes to
be near instantaneous.


So either you have very slow servers, or a really big zone, if it
takes a whole minute to sign it.

Just use inline-signing and the changes will be instantanious. As soon
as nsupdate delivers a change to the master server, it will sign it
automatically and send out notifies. Doesn't even take a second, as
only the changes need to be signed, not the whole zone.



Its big and probably full of a lot of stuff that isn't needed anymore, etc.  
Though there something weird about the zones too.


our ksu.edu zone will have more entries than the k-state.edu one, even though 
by policy they should be the same, though I just fixed up delegated subdomain 
that is only doing .ksu.edu form (the also don't list us as secondaries or 
allow us to do transfers anymore...which they're supposed to according to 
policy (and to ensure external resolutionespecially if all their 
129.130.x.y addresses become 10.42.x.y or something.  Internally we're 
probably running out of open blocks of IPv4, especially for anything that 
wants /27 or bigger (such as a /21)  It caused problems the first chunk from 
a reclaimed block was used.  The reclaimed block used to be our guest 
wireless network (which is now a number of are was a growing number of blocks 
in 10.x.x.x space)  The switch to WPA2 Enterprise versus open guest, made it 
too tempting to take easy way to get online.  So it was required that campus 
resources block access from guest networks.  There was no notification that 
the old guest network wasn't anymore...and its been years now.


But, often hear that it should would be nice if I filled these various 
network blocks with generated forward/reversesI'm rarely in the loop for 
what and where the blocks are.


Anyways...the odd thing I was going with ksu.edu vs k-state.edu...the size of 
the raw second zones end up fairly close in size so would expect a huge 
difference in viewing the zones.


but, the named-compilezone to convert k-state.edu back into text took a few 
seconds, while it took minutes to do ksu.edu.same machine, etc.Wonder 
why, and wonder to what extent I should investigate.


But, our master server, is Sun Fire X4170 M2 (dual Xeon E5620's)its bored 
and a waste most of the time...until a full signing needs to get done.  
Though it isn't as fun to watch when I was using a T5120 (64 threads)load 
average would break 100 and set all kinds of monitoring alerts  but it 
chugged along finethough the apps (and their admins) in other containers 
on it weren't as happy.


Years ago, loads exceeding 100 were often fatal and messy, since they used to 
be caused by problems between ZFS and our old SAN (9985)as much as they 
didn't want us to, turning of zil was often the fix to make it not happen 
anymore.  The problem went away after we switched to new SAN (which isnt so 
new anymore...as its end is nearing.


I've thought about looking for a solution that I can throw our zone configs 
enough that would just work, but I largely haven't had time to do that.  Or I 
was hoping to get more backing on enforcing good behavior in my zones. (stop 
the vanity of wanting 10.x.x.x servers at same level as your subdomain with 
public.)  Not sure how preprocesssing zone files to generate internal / 
external (/ guest / dr) versions translates into a free ready to go solution 
:)


I commented out the the latter two as the first never did what they wanted, 
and I heard that the official DR plan was something that got written up back 
in 2000 and and then shelved to be revisited when there's funding  So 
once we got we got secondaries outside of our netblock (we vanished complete 
a few times when our Internet connection breaks, and the last major quite a 
number of sites plus our email were externally hosted


During recent DNS outage, i couldn't send replies to co-workersour 
Office365 tenant said i was an invalid sender :..(  It also apparently 
knocked me off of jabber and stopped having my deskphone forward to my 
cellphoneor for me to get sms notications of voicemail.


But, FreeNode contined to workbefore jabber we had a private channel that 
we hung out in (while its been a long time since we ran a node, we still have 
well maybe not, since the co-workers that had those friends have all left 
nowwhich is probably why ownership of the channel hasn't transferred to 
me)





For those I do have a script that can run after and ssh into all
my caching servers have flush


You don't need to manually sync your servers. Just aktivate NOTIFY and
your master will inform all slaves of any zone changes. If you also
activate IXF

Re: do not stupidly delete ZSK files

[Casey Deccio]

On Thu, Aug 6, 2015 at 7:55 PM, Lawrence K. Chen, P.Eng. 
wrote:

> Ok, so way back thenthey were running servers that didn't support
> NSEC3 RRs and it had nothing to do with what algorithm we were using5
> for RSASHA1 or 7 for RSASHA1-NSEC3-SHA1.
>

DNSSEC introduces: new records (and types) into a zone; new protocol
requirements on servers; and a variety of crypto algorithms.  As far as the
new records are concerned, they are transferred between authoritative
servers (primaries and secondaries) like other records in the zone--even
servers that aren't fully DNSSEC aware should be able to handle this.  With
regard to protocol requirements, even if an authoritative server has the
appropriate DNSSEC records, it must know how to serve them in response to
queries.  This includes serving the RRSIGs with RRsets, serving NSEC or
NSEC3 for authenticated denial of existence (negative responses and
wildcards), serving DS records from the parent zone, etc.  However, some of
these protocol requirements have been incremental (e.g, NSEC3), which is
why algorithms 6 and 7 were introduced--same algorithms as 3 and 5, new
protocol requirements for servers.  So... while algorithms don't
necessarily need to be understood by the authoritative servers (because
they're not doing the validating), protocol requirements do.

In short: the DNSSEC records were probably being transferred correctly, and
the secondaries probably supported DNSSEC but not NSEC3, but the algorithms
themselves didn't matter to the authoritative server.

Casey
___
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: do not stupidly delete ZSK files

[Heiko Richter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 07.08.2015 um 03:36 schrieb Carl Byington:
> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
> 
> On Fri, 2015-08-07 at 02:46 +0200, Heiko Richter wrote:
>> Sadly automated KSK rollover isn't supported by most registrars,
> 
> Yes, but I only need one registrar to support it :)
> 
> I have python code that uses the gkg.net API to do automated KSK 
> generation and rollover, including publishing the new (and deleting
> the old) KSKs at the registrar.
> 
> 
> 
> 

sadly my registrar supports that only for customers with a volume of
at lease 1000 domains
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBAgAGBQJVxBOeAAoJECKEz6pWghImb2AP/j0GOjdi7uq4qU7fGRZ4zmSw
1mC3s83M90xTD4j0Bf9m5ZzVRnN5vLW/7A9PsJxKeXfMI3RXhHKVWG1jHXWMLY9r
s1urBB0U0Elw78TP6IgV60caPhx7KWDywwh3rWwE/nZi1JikcGPRcl76wPtu/AOI
XsQdE5Cbw/GA6KV/5hWhP9VSrUuxrGyf6fXJtJyau2K2RaMV4zIz0AN1bt14mPFC
4vSZmxk2FlHLsKON7XiSOIQ0GRkbo2rY7YYN7mKDCkkyoCs3vsNanj+RKswgWbND
PhQ7C+Q0cUEqFPkSB6JGUtES9FfP+VtIApmzLS6MJQeacClU5CAUlObtGb3uj9vD
TnjePRd71W8PK+AYBNWxpO84LqFCNoDhQtz9nKjntJrYM5fTUi30GTKSHkQHJef9
2kjyxrnGfLhMuxMQgcQc0C2k9eEI3bdJU9PaUvYSesyRhoY5qQLXmIQhhjdGA2z0
taZKiHi/FlumppNGP0xK1DIMMLH30oW2H3AlJhSIlxwiD1drp15StecoBNP7W87/
Wfz4hGao6//0QX+CK4T/F/UHBHQOcbc+bTwXQGhQFszYz+F9FrUFEZcdZIkR5jq6
OpEkct+DAGaGviBRmE8L45M+oxC1LY6U9mjOyinN8Z22vELw26zxl0EnVTrR387G
+p3keqtDrFYFPvJKuh0+
=X9U2
-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: do not stupidly delete ZSK files

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 2015-08-07 at 02:46 +0200, Heiko Richter wrote:
> Sadly automated KSK rollover isn't supported by most registrars,

Yes, but I only need one registrar to support it :)

I have python code that uses the gkg.net API to do automated KSK
generation and rollover, including publishing the new (and deleting the
old) KSKs at the registrar.


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

iEYEARECAAYFAlXEC4AACgkQL6j7milTFsGvtwCfS3Cw9yjJHghwn2QT2dBkbDYR
pM0An1kUDFCFlkhoYc0BUfQN3oLvwaL1
=NpH7
-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: [OT] Re: configuration error in lists.isc.org

[Heiko Richter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 07.08.2015 um 02:03 schrieb Charles Swiger:
> On Aug 6, 2015, at 4:25 PM, Heiko Richter  > wrote:
>> Whenever I post something to the list (I'm not using SMTP, I'm
>> using a usenet server to post to comp.protocols.dns.bind), my
>> postmaster address receives DMARC notifications from list members
>> that have employed this wonderful protocol on their servers,
>> telling me my message had been rejected for violating my SPF
>> policy.
>> 
>> My SPF record doesn't include lists.ist.org
>> , of course and it never will. Furthermore
>> it ends with "-all" so all my messages to the list are being
>> rejected by list members who have spf aware servers.
> 
> DMARC makes assumptions which do not play nicely with mailing
> lists-- in particular, a mailing list is always going to want to
> use a bounce address within it's own domain to notice failing
> delivery-- so SPF usually isn't going to match.
> 
> The choices I see are to either list the mailservers of the mailing
> lists you participate on in your SPF records, convince the folks
> receiving your mail to whitelist the ISC mailing servers from SPF /
> DMARC checks, and/or change your SPF policy from -all to something
> less strict.

Changing to ~all will indeed solve the problem at the mta-level. But
it will make filters like spamassassin create false-positives and
probably dump the mails into user's spam-folders. This will poisen the
bayes filter and - depending on what the users do with their spam -
you run the risk of getting reported to RBLs, so not a good idea.

> 
> Otherwise, accept that the choices you've made mean the messages
> you send will frequently bounce.
> 
>> So ISC: please fix your list servers, let them rewrite the From
>> headers!
> 
> How would this help?  Changing the From header breaks your domain's
> DKIM signing; are you asking them to take ownership of your
> messages and then DKIM sign them on behalf of isc.org
> ?  That breaks normal email replies.

OK, didn't think about DKIM, changing the From header won't work either.

> 
> Even the DMARC FAQ is honest enough to note that every alternative
> has major cons:
> 
> 
> https://dmarc.org/wiki/FAQ#I_operate_a_mailing_list_and_I_want_to_interoperate_with_DMARC.2C_what_should_I_do.3F
>
>  Regards, -- -Chuck
> 

Just found another solution, that will help with any DMARC-aware
server that knows Sender-ID. I just published:
heikorichter.name.  60  IN  TXT "spf2.0/pra ?all"

This will force DMARC to check only the envelope sender, which is
changed by lists.isc.org as /dev/rob0 pointed out earlier

Heiko
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBAgAGBQJVxAG2AAoJECKEz6pWghImYnIP/2WHWKQEkRetRAl8uB92Dnqz
e/i0tCJcEI5o2JMvuPiykRNB6Mb04z+TPTyP2FmXFe33zCs8CWp9pV1dcn0A1nbp
voZ7zZ7p2nQr0vR9Tj5XDjHN3bucI97VMUYVWiRK+9Pw7+vjdhMKW5dn2M/qveJY
/95IJX2NKLu6ZUsL5eyZIdhQb+3wJ+EfkcwdGOGLlhZ9EihqozRe1qgplcVJDJUs
owo0hgRrbL+s/h7Dz3VOk1g0SYk4EYb/xcc2I558CKhu8VmcfXA8DIXIsGOuvTzV
5RJumYvp7JCwinPoNDcMiy3Db8AXw2mTbF1Q3oWxt1CmF7LITHV9ltVuU2nH22Lq
WGkk2ErMgHwaRONXybfUNlsA5s6njVOIx3RcNyb4qOEsgoOvWG7bxhnj7XOCP84p
ZwFyNHvamT/PVqQKBybDwec1Urdw+VWf11byzto+E/+wJt0ELH1yD4uqigxy3DXP
9qOzOjKFDNNt2WqRHdf+O9HPSCsQXAMjTEXReUg6OFWox19UEAbEYx4i3Vx+SeUP
RsG9a6kG2vWlf6A6i20XZYHiYLH+lI1OT5x706QyA3GY0vWlkvUgxCHPf3JiX77c
tFtrp0tyX/PRCvn2demNNr7fTteuGcRPjFuzhezaoZBVgKkuJ0E5kWwsDYgDMfMi
YIeqlm0uIYCOTn0Fs4p5
=/b+D
-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: do not stupidly delete ZSK files

[Heiko Richter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 07.08.2015 um 02:35 schrieb Dave Warren:
> On 2015-08-06 17:26, Heiko Richter wrote:
>> Root is signed with RSASHA256 at the moment. There is no sence in
>> having a more secure algorithm because anybody who can't crack that
>> algorithm may just attack the weakest link in the chain above you.
> 
> This only holds while assuming similar key rotation schemes, I believe?
> If the roots are signed with RSASHA256 and rotate every 3 months, while
> you sign, set it and forget it, you're vulnerable to anyone that can
> crack RSASHA256 over any period of time.
> 
> Probably a theoretical difference, if it becomes feasible for someone to
> crack RSASHA256 in any reasonable level of time, it would be equally
> feasible to invest in 2x-8x the hardware and start breaking roots in
> under 3 months.
> 

That's why you sould employ automated rollover.

For example my ZSKs are changed automatically every month. As the system
does this automatically I cannot forget to do it.

It's also not hard to implement that, just run a monthly conjob of
dnssec-keygen that dumps new keys into the key-directory of every domain
and make proper use of -P -A -I and -D switches.

Sadly automated KSK rollover isn't supported by most registrars, but my
master server send me an email-reminder, whenever a KSK keyfile gets too
old because I forgot the rollover
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBAgAGBQJVw//aAAoJECKEz6pWghImtNMQAIh4hGzydUs3zT8IWiSfKP6o
rtMb2USayknmy1Z7Uy+hAM7yL9tC+1Qw8e6PqNOVZMGhtADqYvQLyKeXmK/ZHiMF
l5i2erDNqgjpk34dICrE+lmvmzuQ8cNqL15qqut+tR8rPQJc4TDb2iuyInU7h1yB
JNP2W/hoadnBTVwrvUEsXN+G7AknDushcUpTzzblRQvvt4UPSjD/Ict9tpw2HL2S
JrHhwtjeBhuu6IIc0kzQQwyUQi8lgPWSS+5FqlHlkJQ/texB039wxJPmdEqhQgXM
GB0ZVsIcNdRZB8eWC/TBt4AQcOKqQFudqMKhDEsTIXDcrExU3F9+Stnwgcfo6VMv
5ScIpgneiE1GgAXozULfDY7coJDlB5h3JcpRd3nPgSpWTl9VpdjHWPeTNzlXNMLu
q4VlQRAbCi73hs3L+G0Dy1MW9FQCS5WJ0PZfE8xu53O5D80qpjAEX7+C8wgZd8bg
y/OlgZ2hpt0i/7QfIH9fWvGFs3+VgwL2OjkfP3ZdY7k+cpoS5hsyZaRZ+Wf2FpjQ
Ze3xx3hf/rb0GyRfSh+8eAjlRlYQbEFPTKBpeViDizqHQ+n8GDt+ug4OSuR2K7GJ
eF77ImC6sgfUaLD2+VKoiq5XgdBbF5fg1sPOeKlFVZZJqoIFX8Po7L36nbNbuh+k
d4BUpas//FA5QJgGr3IW
=lcpn
-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: do not stupidly delete ZSK files

[Dave Warren]

On 2015-08-06 17:26, Heiko Richter wrote:

Root is signed with RSASHA256 at the moment. There is no sence in
having a more secure algorithm because anybody who can't crack that
algorithm may just attack the weakest link in the chain above you.


This only holds while assuming similar key rotation schemes, I believe? 
If the roots are signed with RSASHA256 and rotate every 3 months, while 
you sign, set it and forget it, you're vulnerable to anyone that can 
crack RSASHA256 over any period of time.


Probably a theoretical difference, if it becomes feasible for someone to 
crack RSASHA256 in any reasonable level of time, it would be equally 
feasible to invest in 2x-8x the hardware and start breaking roots in 
under 3 months.


--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren


___
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: do not stupidly delete ZSK files

[Heiko Richter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 07.08.2015 um 01:55 schrieb Lawrence K. Chen, P.Eng.:
> 
> 
> On 2015-08-06 17:54, Heiko Richter wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>> 
>> Am 07.08.2015 um 00:23 schrieb Lawrence K. Chen, P.Eng.:
>>> 
>>> 
>>> On 2015-07-31 06:33, Tony Finch wrote:
> Most zones have four authoritative nameservers, only one
> of which I manage. Of the three I don't manage, I'm pretty
> sure at least two have no DNSSEC-specific configuration --
> a hint that any DNSSEC records they serve come from this
> hidden primary.
 
 The DNSSEC records come from the zone data like any other 
 records. You don't need any special DNSSEC configuration to
 act as a secondary for a signed zone - it just works.
 
>>> 
>>> Is that the case now?  I recall when I was initial deploying 
>>> DNSSEC, DLV required that all my nameservers respond the same.
>>> 
>>> We use NSEC3 on our zones, but at the time our network
>>> operator's nameservers didn't support NSEC3, so were absent
>>> from their responses. Had to delay until they upgraded their
>>> servers (something about needing to upgrade from 5 to 6 first),
>>> before we could go DNSSEC.
>>> 
>>> At first I was just going to turn off NSEC3, but our CISO
>>> decided we had to have it.  Though until earlier this year we
>>> used a constant 4 digit salt. (ascii for KS ;)  Now I have it
>>> generating a new random 16 digit salt, adapted from example
>>> from some paper I had read (and each signing generates its
>>> own salt...
>>> 
>>> Even though it is apparently still possible to walk a NSEC3
>>> domain, I think it was to more to hide any embarrassment cruft
>>> in our zone file. No idea when somebody will decide to finally
>>> clean things up. Other than that recollection, I haven't looked
>>> into what possible issues we could run into if the capabilities
>>> of our outside managed secondaries didn't match the appliance.
>>> 
>>> Like what if those secondaries only supported up to RSASHA256,
>>> but appliance with crypo accelerator prefers RSASHA512 (or
>>> perhaps some GOST ... or ECDA/SHA384, which aren't in my named
>>> builds...still using 0.9.8zlatest - avoids figuring what else
>>> depended on itaside from clamav on our virus filters.)
>>> Actually, I wonder if a transition to RSASHA512 on my
>>> nameservers wouldn't be bad my bind builds are 64-bit.
>>> 
>> 
>> The secondaries don't have to support any encryption algorithms
>> as they will not use them. These encryption algorithms are used
>> to create the RRSIG records (a process running only on the
>> master) and to verify them (a process running only on
>> dnssec-enabled recursive servers).
>> 
>> Whenever you update your zone with nsupdate or you run 'rndc
>> sign' on your zone the master creates the signatures and saves
>> them in RRSIG records. Then it sends out notifys to all
>> secondaries, which will re-transfer the zone from the master.
>> From that point on the only thing your servers have to do, is
>> hand out records from the existing zone.
>> 
>> The only thing your servers have to support are the record types.
>> So if your server is still living in the stone age and doesn't
>> know about the existence of DNSKEY, RRSIG and NSEC3 resource
>> records, it will probably have problems to handle your zone.
>> 
>> But if such a server still exists nowadays, not having dnssec
>> will be the least of it's worries as has missed decades of
>> security updates...
> 
> Ok, so way back thenthey were running servers that didn't
> support NSEC3 RRs and it had nothing to do with what algorithm we
> were using5 for RSASHA1 or 7 for RSASHA1-NSEC3-SHA1.
> 
> It did stump when the move to RSASHA256 was made that there was a 
> selection with NSEC3 in the name.  Though not as freaked out 
> managementsome how my manager was able to calm them down...

Modern keys are all NSEC3-aware. Everything that came after RSASHA1
has NSEC3-support. It is automatically enabled as soon as you publish
NSEC3-parameters in your zone.

> 
> I don't recall if there was a conscious decision to go SHA256 or
> SHA512, except that from messages I had seen most people were doing
> SHA256.

You always have to look at the complete trust-chain from root to you.
The trust of your records can only be as high as the weekest algorithm
used in the entire chain allows.

Root is signed with RSASHA256 at the moment. There is no sence in
having a more secure algorithm because anybody who can't crack that
algorithm may just attack the weakest link in the chain above you.

Also you have to keep in mind that resolvers have to be able to verify
your signatures. I used ECDSA in the beginning, but then notices that
by far not every dnssec-enabled resolver is able to verify those
signatures, so I changed back to RSASHA256 as this is the minimum any
resolver needs to know in order to verify root.

> Though back then I was still building bind 32-bit, and th

[OT] Re: configuration error in lists.isc.org

[Charles Swiger]

On Aug 6, 2015, at 4:25 PM, Heiko Richter  wrote:
> Whenever I post something to the list (I'm not using SMTP, I'm using a
> usenet server to post to comp.protocols.dns.bind), my postmaster
> address receives DMARC notifications from list members that have
> employed this wonderful protocol on their servers, telling me my
> message had been rejected for violating my SPF policy.
> 
> My SPF record doesn't include lists.ist.org , of 
> course and it never
> will. Furthermore it ends with "-all" so all my messages to the list
> are being rejected by list members who have spf aware servers.

DMARC makes assumptions which do not play nicely with mailing lists--
in particular, a mailing list is always going to want to use a bounce
address within it's own domain to notice failing delivery-- so SPF
usually isn't going to match.

The choices I see are to either list the mailservers of the mailing lists
you participate on in your SPF records, convince the folks receiving your
mail to whitelist the ISC mailing servers from SPF / DMARC checks, and/or
change your SPF policy from -all to something less strict.

Otherwise, accept that the choices you've made mean the messages you send
will frequently bounce.

> So ISC: please fix your list servers, let them rewrite the From headers!

How would this help?  Changing the From header breaks your domain's DKIM 
signing;
are you asking them to take ownership of your messages and then DKIM sign
them on behalf of isc.org?  That breaks normal email replies.

Even the DMARC FAQ is honest enough to note that every alternative has major 
cons:

  
https://dmarc.org/wiki/FAQ#I_operate_a_mailing_list_and_I_want_to_interoperate_with_DMARC.2C_what_should_I_do.3F

Regards,
-- 
-Chuck

___
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: configuration error in lists.isc.org

[/dev/rob0]

On Fri, Aug 07, 2015 at 01:25:37AM +0200, Heiko Richter wrote:
> Nothing concerning Bind, but still relevant to all list users:
> 
> Just wanted to let you all know about a configuration error on
> lists.isc.org. It doesn't rewrite any email headers, only reflects
> incoming messages to all list members which leads to problems in
> SPF-checks.

Just like pretty much every list server in existence, ever since the 
idea of participatory mailing lists began.

> Whenever I post something to the list (I'm not using SMTP, I'm 
> using a usenet server to post to comp.protocols.dns.bind), my 
> postmaster address receives DMARC notifications from list members 
> that have employed this wonderful protocol on their servers, 
> telling me my message had been rejected for violating my SPF 
> policy.

Something which the wonderful folks who thought up DMARC apparently 
failed to consider.  (Somewhat like a FUSSP in that in order to work 
correctly, millions of sites globally will have to change the way 
they do things.)

> My SPF record doesn't include lists.ist.org, of course and it never 
> will. Furthermore it ends with "-all" so all my messages to the 
> list are being rejected by list members who have spf aware servers.

No, GNU Mailman (which is the software behind lists.isc.org) does the 
right thing, setting a proper *envelope* sender address in the ISC 
domain.  Proper filtering would go on the envelope sender.

> Just wanted to let you all know about it as I can imagine I'm not 
> the only person who has outgoing SPF.
> 
> And the worst thing: If you have a record ending with "~all" your
> messages will be accepted but probably end up in a spam report
> container slowly eating away the good anti-spam-reputation your
> server has.

Unfortunately a lot of sites do silly things, so there may be a bit 
of truth in that.  But it's not a reason to join in on doing silly 
things.

> So ISC: please fix your list servers, let them rewrite the From 
> headers!

I am strongly opposed to this.  DMARC was another half-baked idea 
which should not be influencing such wide-ranging changes.  Do note 
that lists.isc.org long predates DMARC.

Furthermore, it's not fixing the server, it's breaking it.  Users 
want to see the sender's address.  Some of them use it for such 
things as killfiling.

But thank you for bringing this issue up.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
___
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: do not stupidly delete ZSK files

[Lawrence K. Chen, P.Eng.]

On 2015-08-06 17:54, Heiko Richter wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 07.08.2015 um 00:23 schrieb Lawrence K. Chen, P.Eng.:



On 2015-07-31 06:33, Tony Finch wrote:

Most zones have four authoritative nameservers, only one of
which I manage. Of the three I don't manage, I'm pretty sure at
least two have no DNSSEC-specific configuration -- a hint that
any DNSSEC records they serve come from this hidden primary.


The DNSSEC records come from the zone data like any other
records. You don't need any special DNSSEC configuration to act
as a secondary for a signed zone - it just works.



Is that the case now?  I recall when I was initial deploying
DNSSEC, DLV required that all my nameservers respond the same.

We use NSEC3 on our zones, but at the time our network operator's
nameservers didn't support NSEC3, so were absent from their
responses. Had to delay until they upgraded their servers
(something about needing to upgrade from 5 to 6 first), before we
could go DNSSEC.

At first I was just going to turn off NSEC3, but our CISO decided
we had to have it.  Though until earlier this year we used a
constant 4 digit salt. (ascii for KS ;)  Now I have it generating a
new random 16 digit salt, adapted from example from some paper I
had read (and each signing generates its own salt...

Even though it is apparently still possible to walk a NSEC3 domain,
I think it was to more to hide any embarrassment cruft in our zone
file. No idea when somebody will decide to finally clean things
up. Other than that recollection, I haven't looked into what
possible issues we could run into if the capabilities of our
outside managed secondaries didn't match the appliance.

Like what if those secondaries only supported up to RSASHA256, but
appliance with crypo accelerator prefers RSASHA512 (or perhaps some
GOST ... or ECDA/SHA384, which aren't in my named builds...still
using 0.9.8zlatest - avoids figuring what else depended on
itaside from clamav on our virus filters.)  Actually, I wonder
if a transition to RSASHA512 on my nameservers wouldn't be bad
my bind builds are 64-bit.



The secondaries don't have to support any encryption algorithms as
they will not use them. These encryption algorithms are used to create
the RRSIG records (a process running only on the master) and to verify
them (a process running only on dnssec-enabled recursive servers).

Whenever you update your zone with nsupdate or you run 'rndc sign' on
your zone the master creates the signatures and saves them in RRSIG
records. Then it sends out notifys to all secondaries, which will
re-transfer the zone from the master. From that point on the only
thing your servers have to do, is hand out records from the existing zone.

The only thing your servers have to support are the record types. So
if your server is still living in the stone age and doesn't know about
the existence of DNSKEY, RRSIG and NSEC3 resource records, it will
probably have problems to handle your zone.

But if such a server still exists nowadays, not having dnssec will be
the least of it's worries as has missed decades of security updates...


Ok, so way back thenthey were running servers that didn't support NSEC3 
RRs and it had nothing to do with what algorithm we were using5 for 
RSASHA1 or 7 for RSASHA1-NSEC3-SHA1.


It did stump when the move to RSASHA256 was made that there was a selection 
with NSEC3 in the name.  Though not as freaked out managementsome how my 
manager was able to calm them down...


I don't recall if there was a conscious decision to go SHA256 or SHA512, 
except that from messages I had seen most people were doing SHA256.  Though 
back then I was still building bind 32-bit, and the hardware as much slower.  
A full signing was more than 10x longer than our current hardwarewhich 
can get it done in just under a minute. (usually)  The need for speed is some 
people expect DNS changes to be near instantaneous.


For those I do have a script that can run after and ssh into all my caching 
servers have flush


Now if only I could figure out how to do that to the rest of the world to 
satisfy those other requests.


Recently saw in incidenta department that has full control of their 
subdomain made a typo on an entry with TTL 86400.  They had fixed the typo, 
but the world still wasn't seeing the correction.  Asked us if we could lower 
the TTL for it, to maybe 300.


Hmmm... no.

--
Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator
   with LOPSA Professional Recognition.
For: Enterprise Server Technologies (EST) -- & SafeZone Ally

___
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

configuration error in lists.isc.org

[Heiko Richter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi!

Nothing concerning Bind, but still relevant to all list users:

Just wanted to let you all know about a configuration error on
lists.isc.org. It doesn't rewrite any email headers, only reflects
incoming messages to all list members which leads to problems in
SPF-checks.

Whenever I post something to the list (I'm not using SMTP, I'm using a
usenet server to post to comp.protocols.dns.bind), my postmaster
address receives DMARC notifications from list members that have
employed this wonderful protocol on their servers, telling me my
message had been rejected for violating my SPF policy.

My SPF record doesn't include lists.ist.org, of course and it never
will. Furthermore it ends with "-all" so all my messages to the list
are being rejected by list members who have spf aware servers.

Just wanted to let you all know about it as I can imagine I'm not the
only person who has outgoing SPF.

And the worst thing: If you have a record ending with "~all" your
messages will be accepted but probably end up in a spam report
container slowly eating away the good anti-spam-reputation your server
has.

So ISC: please fix your list servers, let them rewrite the From headers!

Yours,
Heiko Richter
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBAgAGBQJVw+zvAAoJECKEz6pWghImwr4P+wb6hzvJTFK3WYOIpoj5Vw0B
CEV4vhkj0vKYaAvui6rwJAtUkcM8C8IvbdhxdM4TiM6Av7wCBi+uhbF8+khZnlJ4
n0RnLcYQTtEpUawTkLz2BXxePkkkoB7/s3/TWEBUSnuW32oLLJgY1/qczazP1jQ3
1hCXhrKYojrUu0bCBgt30PiZCmYIh0MIg9gT2zudSkKdy/AhIIqCoB29SCtIVKYa
Yka0Jv3LD+ligZte7CUgdvoRRPFn1i/cOloZKl9hGRUAbQJgDtXgzYhyqSj6kJyB
utpYDjbsKNxeec3D64ZFQWRAIjpgD+n2JqaJvnbMibrgdmcoIREcJcgGcmYv7rCJ
BHhJx36p2PHdCaiRro/HbGKs3GhjcnUYi6GVOlI2NGa56zv6y1yh25sp3D3PHWfW
8jWtfij6+nTdckCndyIe78n1X85uyBRUYs4g2Uk/9Jd3Ki1hypnqnViiolPlOajZ
FF7K0BrTuNFNYdPrbuwGpzXhYBR70wT0SyNb23uqYtn+MqqvZspS43VbkJCghbdh
GJ5CmbApUR6IitjJp5TNUaAkqJRbUlZ3Drs9ggLQU9naUFTzoA6vW6sxLTF7WERo
cz8D1D6gO97PrmCyDjOqp7csviD8LyaE6q7kdTYT/1azF9RWTaSj8MEL1EC+EVwR
r9eWsswM+R33CyzY1Ffa
=QZUO
-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: do not stupidly delete ZSK files

[Heiko Richter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 07.08.2015 um 00:23 schrieb Lawrence K. Chen, P.Eng.:
> 
> 
> On 2015-07-31 06:33, Tony Finch wrote:
>>> Most zones have four authoritative nameservers, only one of
>>> which I manage. Of the three I don't manage, I'm pretty sure at
>>> least two have no DNSSEC-specific configuration -- a hint that
>>> any DNSSEC records they serve come from this hidden primary.
>> 
>> The DNSSEC records come from the zone data like any other
>> records. You don't need any special DNSSEC configuration to act
>> as a secondary for a signed zone - it just works.
>> 
> 
> Is that the case now?  I recall when I was initial deploying
> DNSSEC, DLV required that all my nameservers respond the same.
> 
> We use NSEC3 on our zones, but at the time our network operator's 
> nameservers didn't support NSEC3, so were absent from their
> responses. Had to delay until they upgraded their servers
> (something about needing to upgrade from 5 to 6 first), before we
> could go DNSSEC.
> 
> At first I was just going to turn off NSEC3, but our CISO decided
> we had to have it.  Though until earlier this year we used a
> constant 4 digit salt. (ascii for KS ;)  Now I have it generating a
> new random 16 digit salt, adapted from example from some paper I
> had read (and each signing generates its own salt...
> 
> Even though it is apparently still possible to walk a NSEC3 domain,
> I think it was to more to hide any embarrassment cruft in our zone
> file. No idea when somebody will decide to finally clean things
> up. Other than that recollection, I haven't looked into what
> possible issues we could run into if the capabilities of our
> outside managed secondaries didn't match the appliance.
> 
> Like what if those secondaries only supported up to RSASHA256, but 
> appliance with crypo accelerator prefers RSASHA512 (or perhaps some
> GOST ... or ECDA/SHA384, which aren't in my named builds...still
> using 0.9.8zlatest - avoids figuring what else depended on
> itaside from clamav on our virus filters.)  Actually, I wonder
> if a transition to RSASHA512 on my nameservers wouldn't be bad
> my bind builds are 64-bit.
> 

The secondaries don't have to support any encryption algorithms as
they will not use them. These encryption algorithms are used to create
the RRSIG records (a process running only on the master) and to verify
them (a process running only on dnssec-enabled recursive servers).

Whenever you update your zone with nsupdate or you run 'rndc sign' on
your zone the master creates the signatures and saves them in RRSIG
records. Then it sends out notifys to all secondaries, which will
re-transfer the zone from the master. From that point on the only
thing your servers have to do, is hand out records from the existing zone.

The only thing your servers have to support are the record types. So
if your server is still living in the stone age and doesn't know about
the existence of DNSKEY, RRSIG and NSEC3 resource records, it will
probably have problems to handle your zone.

But if such a server still exists nowadays, not having dnssec will be
the least of it's worries as has missed decades of security updates...
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBAgAGBQJVw+WJAAoJECKEz6pWghImuowP/j7lLD/8+VbHxvNY7P3O+9jQ
+r8tA80mkf9JJ5MdLejOm50eZuTShulSVuIYqdlfttXxkVb51dI16ej6fLzJj3Ed
qKeO8EBU/LJKaOosUuDxZyrPbrw8iPRXeERFF44z16NfGtMsvP4BROyDRZD4EJnD
O1dxDmBBT2+hz9NJ69PtRmbxTjXYds/w4gXr1Jb9qp41a0l9PwgPnGbaYtHdi2be
0py05poIJKYk2z+qxBHYc/uKAzlIvLFhk63GWRZjYaPJNoWAW50vDXy6+vMGEIiq
Fb3jpXYyxYxRV/TOF7L8Cehgy0Bvz1jk/JUoWfXEt5ZfVLq+XITaIZxYe2i2Rdd0
6j51X3c8CVBfpEWNoMqo/YiDhQ++D51glN+oRMlBMdpZHmVVsWpZyTOttXfUTeuB
ZmIM6ntNb6t6ofJBwF4ihrnm0Z4l21d4wbe/nETbCzoPkct9T0QsN9D9wYD8rkFf
ksU6H+N0SZvX8Y+DS9D0cJ5WfZnP9PM5syt47YKVr9yLMQGRZbb31S6c3u/Myhq5
qiIjUZETSVxoCEz3iZnmdbY4bE+u73jHe7yt+akW1mpnwfiiyyxjZNYKws/otT62
8ge/XIZoaVd5AzM2o2Ew7bYu75dM2fTjltVdKOGz4tLbtMcr/ydXQYz7FcoM2jxU
8tgxPfOQtUknMtA7IoZ9
=1Xlf
-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

New BIND betas are available: 9.9.8b1 and 9.10.3b1

[Michael McNally]

New development versions of BIND are available.  Release notes can be
found at:

 BIND 9.9.8b1:
   ftp://ftp.isc.org/isc/bind9/9.9.8b1/RELEASE-NOTES.bind-9.9.8b1.html

 BIND 9.10.3b1:
   ftp://ftp.isc.org/isc/bind9/9.10.3b1/RELEASE-NOTES.bind-9.10.3b1.html


Along with minor features such as new options for dig, both versions
contain a set of new features, previously offered only in the BIND 9
Subscription Version and the BIND 9 Experimental Branch, intended to
help operators reduce resource consumption and server load by adding
new quotas to limit the queries that are sent by recursive resolvers
to authoritative servers which are experiencing denial-of-service
attacks.

These anti-DDoS features are available through an optional compilation
flag; see the release notes for further details.
___
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: do not stupidly delete ZSK files

[Lawrence K. Chen, P.Eng.]

On 2015-07-31 06:33, Tony Finch wrote:

Most zones have four authoritative nameservers, only one of which I
manage. Of the three I don't manage, I'm pretty sure at least two have
no DNSSEC-specific configuration -- a hint that any DNSSEC records they
serve come from this hidden primary.


The DNSSEC records come from the zone data like any other records. You
don't need any special DNSSEC configuration to act as a secondary for a
signed zone - it just works.



Is that the case now?  I recall when I was initial deploying DNSSEC, DLV 
required that all my nameservers respond the same.


We use NSEC3 on our zones, but at the time our network operator's nameservers 
didn't support NSEC3, so were absent from their responses.  Had to delay 
until they upgraded their servers (something about needing to upgrade from 5 
to 6 first), before we could go DNSSEC.


At first I was just going to turn off NSEC3, but our CISO decided we had to 
have it.  Though until earlier this year we used a constant 4 digit salt. 
(ascii for KS ;)  Now I have it generating a new random 16 digit salt, 
adapted from example from some paper I had read (and each signing 
generates its own salt...


Even though it is apparently still possible to walk a NSEC3 domain, I think 
it was to more to hide any embarrassment cruft in our zone file.  No idea 
when somebody will decide to finally clean things up.
Other than that recollection, I haven't looked into what possible issues we 
could run into if the capabilities of our outside managed secondaries didn't 
match the appliance.


Like what if those secondaries only supported up to RSASHA256, but appliance 
with crypo accelerator prefers RSASHA512 (or perhaps some GOST ... or 
ECDA/SHA384, which aren't in my named builds...still using 0.9.8zlatest - 
avoids figuring what else depended on itaside from clamav on our virus 
filters.)  Actually, I wonder if a transition to RSASHA512 on my nameservers 
wouldn't be bad my bind builds are 64-bit.


--
Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator
   with LOPSA Professional Recognition.
For: Enterprise Server Technologies (EST) -- & SafeZone Ally
___
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: Question on "--with-libxml2" option while compiling on Sparc Solaris 10 and the Configuration Summary output.

[Lawrence K. Chen, P.Eng.]

 The 9.10.2P3 build shows that '--enable-full-report' was set, while 9.9.7P2
doesn't have this configure option set.

In the configure script it has libxml2 in the block that is only printed if
'--enable-full-report' is set.
On 2015-08-06 14:29, Bhangui, Sandeep - BLS CTR wrote: 

> Hello 
> 
> This is what I get in the summary after I run configure on BIND 9.10.2P3 
> source code when I use the "--with-libxml2" option for compiling . As we can 
> see the summary says that the option has been enabled. 
> 
> Configuration summary: 
> 
>  
> 
> Optional features enabled: 
> 
> Multiprocessing support (--enable-threads) 
> 
> Mutex lock type: adaptive 
> 
> GSS-API (--with-gssapi) 
> 
> Source Identity Token support (--enable-sit) 
> 
> Algorithm: aes 
> 
> IPv6 support (--enable-ipv6) 
> 
> OpenSSL cryptography/DNSSEC (--with-openssl) 
> 
> XML STATISTICS (--WITH-LIBXML2) 
> 
> Allow 'fixed' rrset-order (--enable-fixed-rrset) 
> 
> Print backtrace on crash (--enable-backtrace) 
> 
> Use symbol table for backtrace, named only (--enable-symtable) 
> 
> Dynamically loadable zone (DLZ) drivers: 
> 
> None 
> 
> Features disabled or unavailable on this platform: 
> 
> Large-system tuning (--with-tuning) 
> 
> GeoIP access control (--with-geoip) 
> 
> PKCS#11/Cryptoki support (--with-pkcs11) 
> 
> Native PKCS#11/Cryptoki support (--enable-native-pkcs11) 
> 
> GOST algorithm support (--with-gost) 
> 
> ECDSA algorithm support (--with-ecdsa) 
> 
> Use libseccomp system call filtering (--enable-seccomp) 
> 
> Use GNU libtool (--with-libtool) 
> 
> Automated Testing Framework (--with-atf) 
> 
> Python tools (--with-python) 
> 
> JSON statistics (--with-libjson) 
> 
> The complied 9.10.2P3 named binary shows that it is compiled with " 
> -with-libxml2" 
> 
> ./named -V 
> 
> BIND 9.10.2-P3  built by make with 
> '--build=sparc-sun-solaris2.10' '--host=sparc-sun-solaris2.10' 
> '--with-openssl' '--WITH-LIBXML2' '--disable-openssl-version-check' 
> '--enable-ipv6' '--enable-fixed-rrset' '--enable-threads' '--enable-sit' 
> '--enable-largefile' '--enable-full-report' 
> '--prefix=/usr/local/named-jail9.10.2P3' 
> '--bindir=/usr/local/named-jail9.10.2P3/usr/bin' 
> '--sbindir=/usr/local/named-jail9.10.2P3/usr/sbin' 
> '--libexecdir=/usr/local/named-jail9.10.2P3/usr/libexec' 
> '--sysconfdir=/usr/local/named-jail9.10.2P3/etc' 
> '--sharedstatedir=/usr/local/named-jail9.10.2P3/usr/shared' 
> '--localstatedir=/usr/local/named-jail9.10.2P3/var' 
> '--libdir=/usr/local/named-jail9.10.2P3/usr/lib' 
> '--includedir=/usr/local/named-jail9.10.2P3/usr/include' 
> '--mandir=/usr/local/named-jail9.10.2P3/usr/man' 
> 'build_alias=sparc-sun-solaris2.10' 'host_alias=sparc-sun-solaris2.10' 
> 
> compiled by GCC 3.4.3 (csl-sol210-3_4-branch+sol_rpath) 
> 
> compiled with OpenSSL version: OpenSSL 0.9.7d 17 Mar 2004 (+ security fixes 
> for: CVE-2005-2969 CVE-2006-2937 CVE-2006-2940 CVE-2006-3738 CVE-2006-4339 
> CVE-2006-4343 CVE-2006-7250 CVE-2007-5135 CVE-2007-3108 CVE-2008-5077 
> CVE-2008-7270 CVE-2009-0590 CVE-2009-2409 CVE-2009-3555 CVE-2010-4180 
> CVE-2011-4576 CVE-2011-4619 CVE-2012-0884 CVE-2012-1165 CVE-2012-2110 
> CVE-2012-2131 CVE-2012-2333 CVE-2013-0166 CVE-2013-0169 CVE-2014-0224 
> CVE-2014-3508 CVE-2014-3511 CVE-2014-3566 CVE-2014-3567 CVE-2014-3568 
> CVE-2014-3569 CVE-2014-3570 CVE-2014-8275 CVE-2015-0204 CVE-2015-0286 
> CVE-2015-0287 CVE-2015-0288 CVE-2015-0289 CVE-2015-0292 CVE-2015-0293 
> CVE-2015-1789 CVE-2015-1790 CVE-2015-4000) 
> 
> linked to OpenSSL version: OpenSSL 0.9.7d 17 Mar 2004 (+ security fixes for: 
> CVE-2005-2969 CVE-2006-2937 CVE-2006-2940 CVE-2006-3738 CVE-2006-4339 
> CVE-2006-4343 CVE-2006-7250 CVE-2007-5135 CVE-2007-3108 CVE-2008-5077 
> CVE-2008-7270 CVE-2009-0590 CVE-2009-2409 CVE-2009-3555 CVE-2010-4180 
> CVE-2011-4576 CVE-2011-4619 CVE-2012-0884 CVE-2012-1165 CVE-2012-2110 
> CVE-2012-2131 CVE-2012-2333 CVE-2013-0166 CVE-2013-0169 CVE-2014-0224 
> CVE-2014-3508 CVE-2014-3511 CVE-2014-3566 CVE-2014-3567 CVE-2014-3568 
> CVE-2014-3569 CVE-2014-3570 CVE-2014-8275 CVE-2015-0204 CVE-2015-0286 
> CVE-2015-0287 CVE-2015-0288 CVE-2015-0289 CVE-2015-0292 CVE-2015-0293 
> CVE-2015-1789 CVE-2015-1790 CVE-2015-4000) 
> 
> compiled with libxml2 version: 2.6.23 
> 
> linked to libxml2 version: 20623 
> 
> It seems to me that above both output for Bind9.10.2P3 seem to be correct and 
> in sync. 
> 
> This is what I get when in summary when I run configure with the same options 
> on source code for BIND9.9.7P2. As we can see the summary DOES NOT say that 
> the option “—WITH-LIBXML2” is enabled even though I have it in the configure. 
> 
> Is that normal or do I have an issue here? 
> 
> Should I not see XML statistics enabled in the summary below for BIND9.9.7P2? 
> 
>  
> 
> Configuration summary: 
> 
> ---

Question on "--with-libxml2" option while compiling on Sparc Solaris 10 and the Configuration Summary output.

[Bhangui, Sandeep - BLS CTR]

Hello


This is what I get in the summary after I run configure  on BIND 9.10.2P3 
source code when I use the "-with-libxml2" option for compiling .  As we can 
see the summary  says that the option has been enabled.

Configuration summary:

Optional features enabled:
Multiprocessing support (--enable-threads)
Mutex lock type: adaptive
GSS-API (--with-gssapi)
Source Identity Token support (--enable-sit)
Algorithm: aes
IPv6 support (--enable-ipv6)
OpenSSL cryptography/DNSSEC (--with-openssl)
XML statistics (--with-libxml2)
Allow 'fixed' rrset-order (--enable-fixed-rrset)
Print backtrace on crash (--enable-backtrace)
Use symbol table for backtrace, named only (--enable-symtable)
Dynamically loadable zone (DLZ) drivers:
None

Features disabled or unavailable on this platform:
Large-system tuning (--with-tuning)
GeoIP access control (--with-geoip)
PKCS#11/Cryptoki support (--with-pkcs11)
Native PKCS#11/Cryptoki support (--enable-native-pkcs11)
GOST algorithm support (--with-gost)
ECDSA algorithm support (--with-ecdsa)
Use libseccomp system call filtering (--enable-seccomp)
Use GNU libtool (--with-libtool)
Automated Testing Framework (--with-atf)
Python tools (--with-python)
JSON statistics (--with-libjson)


The complied 9.10.2P3 named binary shows that it is compiled with " 
-with-libxml2"

./named -V
BIND 9.10.2-P3  built by make with '--build=sparc-sun-solaris2.10' 
'--host=sparc-sun-solaris2.10' '--with-openssl' '--with-libxml2' 
'--disable-openssl-version-check' '--enable-ipv6' '--enable-fixed-rrset' 
'--enable-threads' '--enable-sit' '--enable-largefile' '--enable-full-report' 
'--prefix=/usr/local/named-jail9.10.2P3' 
'--bindir=/usr/local/named-jail9.10.2P3/usr/bin' 
'--sbindir=/usr/local/named-jail9.10.2P3/usr/sbin' 
'--libexecdir=/usr/local/named-jail9.10.2P3/usr/libexec' 
'--sysconfdir=/usr/local/named-jail9.10.2P3/etc' 
'--sharedstatedir=/usr/local/named-jail9.10.2P3/usr/shared' 
'--localstatedir=/usr/local/named-jail9.10.2P3/var' 
'--libdir=/usr/local/named-jail9.10.2P3/usr/lib' 
'--includedir=/usr/local/named-jail9.10.2P3/usr/include' 
'--mandir=/usr/local/named-jail9.10.2P3/usr/man' 
'build_alias=sparc-sun-solaris2.10' 'host_alias=sparc-sun-solaris2.10'
compiled by GCC 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
compiled with OpenSSL version: OpenSSL 0.9.7d 17 Mar 2004 (+ security fixes 
for: CVE-2005-2969 CVE-2006-2937 CVE-2006-2940 CVE-2006-3738 CVE-2006-4339 
CVE-2006-4343 CVE-2006-7250 CVE-2007-5135 CVE-2007-3108 CVE-2008-5077 
CVE-2008-7270 CVE-2009-0590 CVE-2009-2409 CVE-2009-3555 CVE-2010-4180 
CVE-2011-4576 CVE-2011-4619 CVE-2012-0884 CVE-2012-1165 CVE-2012-2110 
CVE-2012-2131 CVE-2012-2333 CVE-2013-0166 CVE-2013-0169 CVE-2014-0224 
CVE-2014-3508 CVE-2014-3511 CVE-2014-3566 CVE-2014-3567 CVE-2014-3568 
CVE-2014-3569 CVE-2014-3570 CVE-2014-8275 CVE-2015-0204 CVE-2015-0286 
CVE-2015-0287 CVE-2015-0288 CVE-2015-0289 CVE-2015-0292 CVE-2015-0293 
CVE-2015-1789 CVE-2015-1790 CVE-2015-4000)
linked to OpenSSL version: OpenSSL 0.9.7d 17 Mar 2004 (+ security fixes for: 
CVE-2005-2969 CVE-2006-2937 CVE-2006-2940 CVE-2006-3738 CVE-2006-4339 
CVE-2006-4343 CVE-2006-7250 CVE-2007-5135 CVE-2007-3108 CVE-2008-5077 
CVE-2008-7270 CVE-2009-0590 CVE-2009-2409 CVE-2009-3555 CVE-2010-4180 
CVE-2011-4576 CVE-2011-4619 CVE-2012-0884 CVE-2012-1165 CVE-2012-2110 
CVE-2012-2131 CVE-2012-2333 CVE-2013-0166 CVE-2013-0169 CVE-2014-0224 
CVE-2014-3508 CVE-2014-3511 CVE-2014-3566 CVE-2014-3567 CVE-2014-3568 
CVE-2014-3569 CVE-2014-3570 CVE-2014-8275 CVE-2015-0204 CVE-2015-0286 
CVE-2015-0287 CVE-2015-0288 CVE-2015-0289 CVE-2015-0292 CVE-2015-0293 
CVE-2015-1789 CVE-2015-1790 CVE-2015-4000)
compiled with libxml2 version: 2.6.23
linked to libxml2 version: 20623


It seems to me that above both output for Bind9.10.2P3 seem to be correct and 
in sync.

This is what I get when in summary when I run configure with the same options 
on source code for Bind9.9.7P2. As we can see the summary does not say that the 
option "-with-libxml2" is enabled even though I have it in the configure.

Is that normal or do I have an issue here?

Should I not see XML statistics enabled in the summary below for BIND9.9.7P2?


Configuration summary:

Optional features enabled:
Multiprocessing support (--enable-threads)
Response Rate Limiting (--enable-rrl)
GSS-API (--with-gssapi)
Allow 'fixed' rrset-order (--enable-fixed-rrset)
Print backtrace on crash (--enable-backtrace)
Use symbol table for backtrace, named only (--enable-symtable)
Dynamically loadable zone (DLZ) drivers:
None

Features disabled or unavailable on this platform:
PKCS#11/Cryptoki support (--with-pkcs11)
New statistics (-

Re: expired KSK, other domains failed to resolve?

[Casey Deccio]

On Thu, Aug 6, 2015 at 4:16 AM, Lawrence K. Chen, P.Eng. 
wrote:

> So, in running some testsI found that "dig +trace kstatesports.com"
> would get to ns-1.ksu.edu show couple NSEC3 records and stop.
>

$ dig +short kstatesports.com ns
ns-2.ksu.edu.
ns-3.ksu.edu.
ns-1.ksu.edu.

Because the kstatesports.com name servers are in the edu zone, they are
considered "out of bailiwick".  A resolver must resolve those names in
order to learn the addresses of the servers it must communicate with for
kstatesports.com queries.  Thus, kstatesports.com depends on ns-{1,2,3}.
ksu.edu resolving (and validating) properly.

Cheers,
Casey
___
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: Negation in view match-clients ACL doesn't work?

[Cathy Almond]

On 04/08/2015 21:29, Darcy Kevin (FCA) wrote:
> The short answer is that that is how address-match-lists work: a non-negated 
> match allows access, a negated match denies access, and if there is *no* 
> match, access is denied. The only real reason to use a negated match, 
> therefore, is when what you're negating is a subset of something later in the 
> address-match-list.
> 
> You do realize, I hope, that you could just change the order of the views and 
> then you wouldn't need any form of negation (earlier one matches 127.0.0.1, 
> later one matches "any").
> 
>   - Kevin
> 
> -Original Message-
> From: bind-users-boun...@lists.isc.org 
> [mailto:bind-users-boun...@lists.isc.org] On Behalf Of MURTARI, JOHN
> Sent: Tuesday, August 04, 2015 4:19 PM
> To: bind-users@lists.isc.org
> Subject: Negation in view match-clients ACL doesn't work?
> 
> Folks,
> 
>   This has been a real mystery and haven't been able to find a good 
> explanation for the behavior. For a simple example I have two views setup and 
> I want to differentiate access based on queries originating from 127.0.0.1.
> 
>   In my FIRST ATTEMPT I just negated the IP address, but that didn't 
> work.  The first view never matched.   In the SECOND ATTEMPT I simply added 
> "any" AFTER the negation  and that worked?
>   
>   I read the ARM, can someone explain?  Many Thanks!
> 
> FIRST ATTEMPT:  Fails - no clients can see external_zones.
> 
> view "default-test" {
>  match-clients { ! 127.0.0.1; };  // thought this would match anyone but 
> 127.0.0.1
> 
>  zone "." {
> type hint;
> file "db.cache";
>  };
>  zone "0.0.127.in-addr.arpa" {
> type master;
> file "db.127.0.0.0";
>  };
> 
>  include "external_zones.txt";
> };
> 
> view "default" {
>  match-clients { any; };
> 
>  zone "." {
> type hint;
> file "db.cache";
>  };
>  zone "0.0.127.in-addr.arpa" {
> type master;
> file "db.127.0.0.0";
>  };
> 
>  include "internal_zones.txt";  
> };
> 
> SECOND ATTEMPT: Succeeds, only external clients can see external_zones.
> 
> view "default-test" {
>  match-clients { ! 127.0.0.1;  any; };  // Why must I add any?
> ..
> 
Although it's dealing with a different question, this KB article might
help a bit with understanding ACLs:

https://kb.isc.org/article/AA-00723

___
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

expired KSK, other domains failed to resolve?

[Lawrence K. Chen, P.Eng.]

I wish I had the foresight to same the dig traces

But, on Tuesday we had a strange DNS outage.

I have 3 outside facing authoritative-only nameservers named ns-1.ksu.edu, 
ns-2.ksu.edu, ns-3.ksu.edu, which are all slaves off our hidden master 
server.


that in addition to being the authority for ksu.edu, is the authority for 
many other zonessuch as kstatesports.com.


Our KSK rollover was the month of July, but the business office person that 
has access to our registrars did't update to our new KSK. by the 31st. (the 
actual inactivation was August 2nd at 1am...should've been August 1st, but 
the script had failed to run automatically for previous KSK rollover, but got 
it to run the following day...though it again didn't work for this KSK 
rollover...)


However I noticed that the zone file on my slaves had a July 28th timestamp.  
which is odd, because the routine resiging had run in the morning of the 31st 
(Friday mornings by cron)


So, in running some testsI found that "dig +trace kstatesports.com" would 
get to ns-1.ksu.edu show couple NSEC3 records and stop.


I then tried "dig +trace +nodnssec kstatesports.com" and it resolved.

Ohwonder why I hadn't tried doing dig after I got things temporarily 
working again.


I see now that I got two NSEC3 records, and their corresponding RRSIG 
records.


So, what's the reason for needing those NSEC3's in getting to 
kstatesports.com?  And, what was the cause for no RRSIG's.  Is the timing 
part of the signing or was it past its half life to stop these other domains, 
but not resolutions in from the ksu.edu zone


--

Only our .edu domains are signed.  Though in the future we might start 
signing everythingexcept our reverse IP space.  Who knew that ARIN was 
going to disallow role accounts from making changes, where we only have role 
accounts as contacts for our IP space. (was probably before I knew of such 
things, like their take over of things...)


Like while I'm the only individual contact for a former employer's IP space, 
but they require proof of the company's existance and that I'm part of the 
companybefore they can process my request to release the IP space.  But 
the company went out business in early 2001.  Some company in Japan seems to 
be squatting on our old domain (I recall our business manager suddenly 
finding that we had to pay to keep our domain.  But, seems to be I didn't 
hear about ARIN wanting money for IP space just before my first LISA (2007), 
where I found person from ARIN surround by admins 
discussing,asking,screaming,etc.  about them want to suddenly charge lots of 
money for their (pre-ARIN) assignments, etc.  Or perhaps it was my second 
LISA in 2008...  Hmm, probably 2007 when there was lots of news that ipv4 was 
about to run out where we finally did last month?  Wonder how long before 
I'll get around to doing IPv6..at home...


I actually tried to release it twice, somehow I forgot why they wouldn't let 
me the first time.  They also won't let me remove the company info without 
some kind of impossible proof...from the company to allow it.  Wasn't until 
their request for proof the companies existence that I remembered that I had 
run into the problem before.


--
Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator
   with LOPSA Professional Recognition.
For: Enterprise Server Technologies (EST) -- & SafeZone Ally
___
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

Unable to generate DNSSEC keys stored in HSM

[Catalin Leanca]

Hello,

I have BIND 9.10 compiled with native PKCS#11 support and Thales nShield 
Connect HSM.
The problem is with dnssec-keyfromlabel that is unable to generate key 
pair from HSM.

First, the keys were generated in HSM using OpenDNSSEC.

The keys are correctly listed by following command:
$ sudo /usr/local/bind9.10.2/sbin/pkcs11-list -s 761406613
slot 761406613
Enter Pin:
object[0]: handle 1122 class 3 label[32] 
'9af889382e25222b32eb59f67c95cb53' id[16] 0x9af889382e25222b...
object[1]: handle 1123 class 3 label[32] 
'1095a767cb4e3ac8f5cdcb8d4a108e34' id[16] 0x1095a767cb4e3ac8...


When trying to execute the following command i get the error:
$ sudo /usr/local/bind9.10.2/sbin/dnssec-keyfromlabel -l 
"pkcs11:object=9af889382e25222b32eb59f67c95cb53;pin-source=/etc/pass" -a 
8 -P now -A now example.com 
dnssec-keyfromlabel: fatal: failed to get key example.com/RSASHA256 
: not found


Any ideas on how to solve this ?


Regards,

Catalin L.
___
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