error sending response: would block

[Paul B. Henson]

I recently updated a couple servers that were running OpenBSD 6.3 with
bind 9.11.3 to OpenBSD 6.4 and bind 9.11.4pl2. Since then, I'm been
getting a large number of "error sending response: would block" log
messages:

Nov 15 11:03:58 lisa named[79587]: client @0x6f2f02bc440
10.128.30.77#65198 (p64-keyvalueservice.icloud.com): view internal:
error sending response: would block
Nov 15 11:07:42 lisa named[79587]: client @0x6f325b7a440
10.128.0.19#1851 (alt1.gmail-smtp-in.l.google.com): view internal: error
sending response: would block

I reviewed the article at https://kb.isc.org/docs/aa-00717 ; but it's
not clear - is this just a warning message, and it tries again and
successfully responds to the client, or is this a hard error and the
client never gets a response?

I wasn't getting any errors before the upgrade, and I don't think the
load on these servers is anywhere near high enough to cause them to be
overloaded.

Any thoughts on what might be going on?

Thanks...

___
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: problem registering DS records with EDUCAUSE, sanity check please

[Paul B. Henson]

> From: Stephane Bortzmeyer
> Sent: Tuesday, July 15, 2014 12:43 AM
>
> You can also note that it is quite common to publish DS without any
> matching KSK. It is even documented in RFC 6781, section 4.2.4. For an
> actual example, see .UK  (the yellow
> path).

Interesting, my understanding was that if there was a dangling DS record in
the parent that did not match a published DNSKEY in the child a validating
client might consider the zone bogus and refuse to resolve it.

___
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: problem registering DS records with EDUCAUSE, sanity check please

[Paul B. Henson]

> From: Mark Andrews
> Sent: Monday, July 14, 2014 6:33 PM
>
> For a DS to *work* it needs to point to a key that signs the DNSKEY
> RRset.  Validators check that the signature exists.  Activating the
> key will add 1 signature to the zone.

Let me preface this reply by indicating that I am far from a dnssec expert
:), I researched it to some reasonable extent five odd years ago when we
converted our infrastructure to use it, but it's more than possible I
misunderstood something.

That said, I assume when you say to "work", you mean for that KSK to be part
of the trust path for a client to validate a given record. In which case,
it's not my intent at this time for that KSK to "work", only to publish it,
and have a valid DS record in place, such that it could work in the future.
When it's time to roll over, it will be activated and used for signing, and
clients will immediately be happy with it because the valid DS record is in
place. Until it's time for it to be activated, due to scheduled rollover or
emergency rollover due to key compromise, the secret key for that KSK could
theoretically sit in a locked safe far away from any networked system (not
that we actually do that, but it would be possible). If it were activated,
it would be in use; why would I want two active KSKs (unless, I suppose, I
was using the double signature method of rollover)? Keys have a publish time
separate from the activation time, your advice seems to be always make them
the same? Unless I misunderstood key rollover strategies and mechanisms,
there is nothing wrong with having a published key that is not actually
being used to sign anything yet.

> Not activating it increases the risk of shooting your self in the
> foot in the future which, presumable, EDUCAUSE is trying to prevent.
> If you were to disable the current key without first activating the
> new key and allowing the old DNSKEY RRset to clear caches you would
> end up with a broken secure delegation

Well, yes, if I were to do something stupid bad things would happen ;). I
could just stop publishing any DNSKEY records, leave dangling DS records in
the parent, and be completely broken. The publication and activation is
controlled by our fully automated (barring manual parent  DS record
maintenance) dnssec key rollover mechanism, so I'm not particularly worried
about shooting myself in the foot :).

I also don't think this is what educause is doing, as I haven't had any
trouble entering DS records for published but not activated KSK's in the
past, and I assume a change such as this would have come up in our existing
technical support interaction regarding what they might have changed about
the system since last year.

Thanks.

___
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: problem registering DS records with EDUCAUSE, sanity check please

[Paul B. Henson]

On Tue, Jul 15, 2014 at 10:19:10AM +1000, Mark Andrews wrote:

> The new key does not sign the DNSKEY RRset.
[...]
> Make sure the DNSKEY RRset is signed with the new key then try to
> add the DS record to the parent.

It's intentionally not being used for signing; it's published but not yet
activated. We've been doing pre-publish key rollover since we deployed
dnssec, I don't think there's any requirement that a DS record point to
a key actually in use for signing, just to one that exists in the zone?

Thanks...
___
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: problem registering DS records with EDUCAUSE, sanity check please

[Paul B. Henson]

> From: Stephane Bortzmeyer
> Sent: Monday, July 14, 2014 1:43 PM
>
> > So, I suspect a bug in EDUCAUSE.
> 
> Your DNSKEY set being a little over 1500 bytes, you may suspect a MTU
> issue.

Cool, thanks for double checking me and a potential problem to look at.
Makes me feel a little bit better that it won't be one of those issues where
you yell at somebody for weeks to fix their stuff and then it turns out you
did something wrong :).


___
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

problem registering DS records with EDUCAUSE, sanity check please

[Paul B. Henson]

We roll our KSK's for our edu domain annually in July, after which I need to
manually go to the EDUCAUSE management site to delete the old DS records for
the key no longer in use, and add the new DS records for the key just
published and scheduled to be used the following year.

This year, after deleting the old records, I have been unable to add the new
records, when I try to add the new records into their system, it tells me
"We were unable to locate the DNSSEC data you entered in the published zone
for this domain". From what I understand, they basically do a DNSKEY lookup
for the zone, and if you are trying to enter DS records for a key that
doesn't exist, they try to keep you from shooting yourself in the foot.
However, I'm reasonably sure I am entering the correct records for the new
key that is published and does exist.

After opening a trouble ticket, they indicate that they have received no
other complaints and as far as they know their system is working correctly.
While they continue to look into it, I was hoping to get a quick sanity
check to make sure I'm not doing something stupid :).

As of today, there are three DNSKEY KSK's being published in our zone,
csupomona.edu:

43200   DNSKEY  257 3 8 (

AwEAAdFxrkq3ckurcqLiyaoXUTgnbNYeNqPz

ux9X90Y4mxdgq+by/q7n+tAFL0D3mnR583f7

BFjRCWjNU5Txn2kkc3vCW7vy4ACzOw1svEXu

pA+VW4SxwkzIIlXDYqA0H9rwtuh02KXCLDNX

NMJE/gmjHUUavy99sK+fbZp/+wDIG6E/xEgi

a/AzeXlN5ooorNl5HqHYRCl3q0tAHSiXCDmV

gRc1mKKPfURILiaGiHMAt13duN+COtX0I3GJ

T1t54NJ6pUWzHo0G9l4XzKB+QDXrVSjIbw+I

3f2AQ2X2OtOyL+8ZnDK9WxoaJF2IwUsy4Gkw

etIyZrxbdOJegbuKQG9ocVs=

) ; KSK; alg = RSASHA256; key id =
7390

This is the old key, that was in use from 7/2013-7/2014, and will actually
be removed tomorrow.

43200   DNSKEY  257 3 8 (

AwEAAdGKMuliCXyKT1xnqZTCu0XJwJ45uDXi

/OWnYbIJox7TejDTS9j9mZqnzh/T+s8awm/q

JDJASSfK1Udi58I32kZr/O+hzyPR7IH7JT61

YWjPIlf3WslOS9hmsUEEWxvu8WdmLbyHaf+w

WFUMYiyvHcVcw1xPlURI0z6xP1vLl0/Oxy4q

NRTARjfcuj5MmdntmB7PHR3nK+Hm8NO1Yt1y

DnHTr2LBKGneJdwYUPaSXW+R8nUF98yrZghn

0LjzKo3Rp7QZ446dxN8OTjo+KDyxboP5+dO+

EnU7qRuYWfLjwomtI7S1sWQZbIkGhQsS2FIc

C9y3SL1LYWe8HtqBkozSED8=

) ; KSK; alg = RSASHA256; key id =
64507

This is the current key in use, originally published 7/2013, activated
7/2014, and scheduled to be used through 7/2015. This key has DS records in
the edu zone that I added last year:

csupomona.edu.  IN DS 64507 8 1
4736F7DB4A69FF2A97C7CAF3848EFD0BBC42AC1C
csupomona.edu.  IN DS 64507 8 2

85567D63F5AA85A9CE5303776F3DBBCFCB8C82F254E55EE4ECC4279A 04CC350A

43200   DNSKEY  257 3 8 (

AwEAAdSfxR9Es3kRy4G0elMdTaxzQ8zWw9ur

WU1Tq4kc21Ca0wsFZQCB1jU5XNXCiITwEiRb

oxO5nOgBHGqI0+Et39NUr7Oi252bsKowQbib

nd3Y6oeUfZvKyqgvNlSJqpLdC5SsHN2r9lHR

EpO3VpE+bZDdfMys8Lb3xtNqdzjRX8a4nz0z

H1JfrSQG92pP5YXhErsP//r7YCOQdwnuNsWm

ECWXDISDhlorYqRsHNmjFsnrCpbDkrp9J84I

tPcN7DXqDofxRqGxIZ+sx7GcXecCcyAEtHrM

1bZuhzwUjWiscfADWwNTfRrxRxPAgAAorXL4

/dYAx/8QfFINz2/w8Pblrs0=

) ; KSK; alg = RSASHA256; key id =
58561

And finally, the new key I just created, for which I'm trying to add DS
records. The dsset file created by dnssec-signzone says these records should
be:

csupomona.edu.  IN DS 58561 8 1
68893E21C919C85530F9033B4315F68D1248CDBC
csupomona.edu.  IN DS 58561 8 2
DDA5E90D66BB90E2D10881DE0974A3DF0A3C614A6D88C1BA28B19546 1E45C8C5

The same records are generated by dnssec-dsfromkey. Yet, when I try to
register these DS records with EDUCAUSE, their system claims they cannot
find a matching key in our published zone.

Does anybody see anything out of place? Fortunately, the key is not
scheduled to be used unti

Re: dnssec-signzone: warning: NSEC3 generation requested with no DNSKEY; ignoring

[Paul B. Henson]

On 4/25/2013 11:57 AM, Evan Hunt wrote:


The warning is spurious and has been fixed in 9.9.3.  It was incorrectly
checking to see whether there were any DNSKEY records in the zone *before*
loading them from the key files.  It should have been doing so afterward,
obviously.


Ah, okay, thanks for the info. It didn't look like anything was broken 
but it's nice to have a confirmation before rolling it out :).



___
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

dnssec-signzone: warning: NSEC3 generation requested with no DNSKEY; ignoring

[Paul B. Henson]

We're upgrading from bind 9.8 to 9.9, and there's a new warning from 
dnssec-signzone that's confusing me. We are using a locally developed 
mechanism for signing that predates the auto and in-line signing 
mechanisms currently available in bind, and run the command like this:


dnssec-signzone -d /path/to/dsset -K /path/to/keys -3 00 -f 
zone.signed -e +3024000 -j 1800 -o zone.edu -r /dev/urandom -S -T 12h 
/path/to/input


dnssec-signzone: warning: NSEC3 generation requested with no DNSKEY; 
ignoring

Fetching ZSK 59544/RSASHA256 from key repository.
Fetching ZSK 29076/RSASHA256 from key repository.
Fetching KSK 0/RSASHA256 from key repository.
Fetching KSK 38074/RSASHA256 from key repository.
Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 1 active, 1 stand-by, 0 revoked
  ZSKs: 1 active, 1 stand-by, 0 revoked

Despite the warning that appears to be saying it's ignoring NSEC3 
generation, the signed output includes NSEC3 data:


0   NSEC3PARAM 1 0 10 00
0   RRSIG   NSEC3PARAM 8 2 0 (
20130530022110 20130425022136 
59544 zone.edu.
MREyFqJcDGl7q1+iIb5/SPXZjloP7JkQQDyIDviqW5VdCHE7R+0yiuKGgPFBaxkx7b7C4qNd 
   5Ok+TP9Oh1yhjx5qKzQCEH9cN+v82+J34fStJBsGZPjejz7Sk9b2n71QMfrBwzyPP4Mczjsz

Cx+Rs1OPSWICqpNZteJ3vEece7Y= )

10800   RRSIG   NSEC3 8 3 10800 (
20130530020852 20130425022136 
59544 zone.edu.

C6CearljzIjr/oN9h05AAXmdfI2+TXlJE6qh
QsAa8t+4c2BRTr+XujmOHSA6wdTZCJpbF00t
k3ex9J4FGUqrvmrfgoMG/97i1LTtU4+zKGtH
iYZzns1mBx6+SvMat0MdIA5Oyf/BshTQKw9A
uArXwwrt4tZpI2oqjqaO++lNPSU= )

and it most certainly includes DNSKEY's:

43200   DNSKEY  256 3 8 (
AwEAAbdtXRiwmMRMktaixtDE5HafjiVncGJX
xniePMxmZui8XWZ/QYDdwCAa9q7os6chnZ0J
LA7jFhDpjx9dAJXL1DLgYGOKKxAgAtQeODS/
DDek96Phnc34eTui4zARMI5Xtg2izbV5qHZE
S6oAmhVOVtk7XCymL1WGyK5QM1QK8/h/
) ; ZSK; alg = RSASHA256; key id = 29076

What exactly is this warning supposed to mean?

Thanks…
___
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: managed-keys-zone ./IN: No DNSKEY RRSIGs found for '.': success

[Paul B. Henson]

On Wed, Nov 23, 2011 at 02:02:42PM -0800, Paul B. Henson wrote:
> Still seeing these... No ideas anybody :)?
> 
> Looks like they're always paired with an EDNS log line:
> 
> Nov 23 13:35:19 atlas named[28846]: success resolving './DNSKEY' (in
> '.'?) after disabling EDNS
> Nov 23 13:35:19 atlas named[28846]: managed-keys-zone ./IN/internal: No
> DNSKEY RRSIGs found for '.': success

For the archives, it turns out that we're evaluating a new packetshaper
on our border, specifically the Procera PL8720, and it was
misclassifying dns traffic as uTP (a newer UDP based bittorrent
protocol), and dropping some of it :(. After adding our dns servers to
an exception list so the unit was no longer managing their traffic the
problem stopped.


> On Tue, Nov 22, 2011 at 11:14:08AM -0800, Paul B. Henson wrote:
> > Yesterday I started getting messages like:
> > 
> > Nov 22 10:29:01 gemini named[28532]: managed-keys-zone ./IN: No DNSKEY
> > RRSIGs found for '.': success
> > 
> > Nov 22 10:53:44 titan named[15260]: managed-keys-zone ./IN/external: No
> > DNSKEY RRSIGs found for '.': success
> > Nov 22 10:53:54 titan named[15260]: managed-keys-zone ./IN/internal: No
> > DNSKEY RRSIGs found for '.': success
> > 
> > 
> > in my logs. Looks like they're showing up once per hour since they
> > started, the same message on all my servers, both recursive and
> > authorative. Didn't find anything useful searching for the message.
> > Everything still seems to be working fine. Other than upgrading from
> > 9.7.4 to 9.7.4_p1 last week nothing's changed on my side.
> > 
> > Any thoughts on what this means and why it just started out of the blue?
> 
> -- 
> Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
> Operating Systems and Network Analyst  |  hen...@csupomona.edu
> California State Polytechnic University  |  Pomona CA 91768
> _______
> 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

-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
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: managed-keys-zone ./IN: No DNSKEY RRSIGs found for '.': success

[Paul B. Henson]

Still seeing these... No ideas anybody :)?

Looks like they're always paired with an EDNS log line:

Nov 23 13:35:19 atlas named[28846]: success resolving './DNSKEY' (in
'.'?) after disabling EDNS
Nov 23 13:35:19 atlas named[28846]: managed-keys-zone ./IN/internal: No
DNSKEY RRSIGs found for '.': success


On Tue, Nov 22, 2011 at 11:14:08AM -0800, Paul B. Henson wrote:
> Yesterday I started getting messages like:
> 
> Nov 22 10:29:01 gemini named[28532]: managed-keys-zone ./IN: No DNSKEY
> RRSIGs found for '.': success
> 
> Nov 22 10:53:44 titan named[15260]: managed-keys-zone ./IN/external: No
> DNSKEY RRSIGs found for '.': success
> Nov 22 10:53:54 titan named[15260]: managed-keys-zone ./IN/internal: No
> DNSKEY RRSIGs found for '.': success
> 
> 
> in my logs. Looks like they're showing up once per hour since they
> started, the same message on all my servers, both recursive and
> authorative. Didn't find anything useful searching for the message.
> Everything still seems to be working fine. Other than upgrading from
> 9.7.4 to 9.7.4_p1 last week nothing's changed on my side.
> 
> Any thoughts on what this means and why it just started out of the blue?

-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
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

managed-keys-zone ./IN: No DNSKEY RRSIGs found for '.': success

[Paul B. Henson]

Yesterday I started getting messages like:

Nov 22 10:29:01 gemini named[28532]: managed-keys-zone ./IN: No DNSKEY
RRSIGs found for '.': success

Nov 22 10:53:44 titan named[15260]: managed-keys-zone ./IN/external: No
DNSKEY RRSIGs found for '.': success
Nov 22 10:53:54 titan named[15260]: managed-keys-zone ./IN/internal: No
DNSKEY RRSIGs found for '.': success


in my logs. Looks like they're showing up once per hour since they
started, the same message on all my servers, both recursive and
authorative. Didn't find anything useful searching for the message.
Everything still seems to be working fine. Other than upgrading from
9.7.4 to 9.7.4_p1 last week nothing's changed on my side.

Any thoughts on what this means and why it just started out of the blue?

Thanks...


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
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: dnssec config sanity check

[Paul B. Henson]

On 10/5/2011 10:25 AM, michoski wrote:


Your initial hope is what I missed comments on...


Me too; didn't get any "that's horribly broken because" or any "that
looks good" feedback, guess I'll just have to review it a couple more
times and hope for the best.


"It is recommended that the transition of a KSK from the published
state to the ready state (introduction time) lasts for 45 days (RFC
5011, Automated Updates of DNS Security (DNSSEC) Trust Anchors). If
the parent of the zone is signed, the recommended introduction time
(SPARTA) is one week. The recommended period during which a KSK is
retired before it is removed from the zone (retirement time) is four
weeks. For the ZSK, the recommended introduction time is four days
and the retirement time is two weeks."

What values are other folks using?


I'm not sure why such a long retirement time is recommended,
particularly for the ZSK which has no dependencies on getting a parent
zone to update anything.

For the KSK, you don't want to use it to sign anything until the parent
has published the DS record, any old cached copies of that set without
the new one have expired, you've published the DNSKEY record, and any
old cached copies of that set have expired. For my case, I am publishing
the KSK for an entire year before using it, so can't see any issues
there. You don't want to remove a KSK until the parent has removed the
corresponding DS record, cached copies have expired, and there are no
longer any signatures floating around signed by it. My TTL is only 12
hours, so keeping it around for two weeks after I stop using it seems
more than sufficient (and if for some reason there is an excessive delay
getting the parent to remove the DS record, I can extend the publication
further).

For the ZSK, you don't want to sign anything with it after publication
until you are sure there are no old cached copies of the set floating
around without it. I'm going to publish the ZSK one month in advance of
using it, so again don't see any issues. You don't want to remove it
while there are potentially any cached signatures floating around that
use it. Again with a TTL of 12 hours, two days seems like it should be a
sufficient interval to wait.

You don't want your signature lifetime to be too short, resulting in
expired signatures before new ones are generated. My signature lifetime
will be 35 days, with a forced signing at least once a month on the
first of the month, along with a fresh signing anytime the backend data
changes. So I don't see a scenario where my signatures would expire.

The only edge case I can see that might cause a failure is if my primary
server dies or there is an issue transferring the new zone to
secondaries towards the end of the month. Hypothetically, if the
underlying data doesn't change, and the zone was only signed on the
first of the month, and an issue arises say the last week of the month,
there is a case where it is possible my secondaries will have a copy of
the zone that hasn't expired yet, but which does not have valid
signatures. I'm willing to live with this possibility, as the likelihood
of such a failure is low, and the likelihood it would be resolved
quickly is high :).

I guess if I missed anything at some point maybe Stephane Bortzmeyer
will be contacting me to let me know my dnssec deployment is broken and
asking what tool I'm using ;)...


--
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
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: dnssec config sanity check

[Paul B. Henson]

On Wed, Oct 05, 2011 at 12:22:58AM -0700, Stephane Bortzmeyer wrote:
 
> Not true. For every problem reported by the tool, I contacted the
> managers of the domain, both to report they have an issue and to ask
> them what system they were using. So, I'm pretty confident that
> OpenDNSSEC had no such issue.

Sorry then, that detail wasn't laid out in the paper...

Prior to the implementation of key timing metadata and the ability for
dnssec-signzone to automatically select what keys to use in bind 9.7, I
could see how a third party tool to manage rollover for you could be
useful. With it, the amount of wrapper to make it work in a simple
scenario isn't that big. Assuming my selection of timings isn't broken,
I'm reasonably confident our dnssec rollovers will procede smoothly
without issues, and I'd rather use a little bit of custom local glue
that fits perfectly into our existing deployment rather than try to bend
a complicated tool to our will or change our deployment to match its
idea of how things should work.


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
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: dnssec config sanity check

[Paul B. Henson]

On 10/3/2011 11:45 PM, Stephane Bortzmeyer wrote:


Experience of DNSSEC deployment (see my paper at SATIN
<http://conferences.npl.co.uk/satin/papers/satin2011-Bortzmeyer.pdf>)
shows that custom programs have many timing bugs. Many things can go
wrong Why not using an existing program such as OpenDNSSEC ?


From a quick read of your paper, I see you discovered many rollover 
timing issues in the wild, but it doesn't look like those are correlated 
with any particular tool. Other than knowing a given domain had an 
issue, you have no idea what caused it, or what tool they may have been 
using, and it is only an assumption that the issue arose from a custom 
program... They could well have been using some existing programs such 
as OpenDNSsec which presumably aren't guaranteed bug free :).


We initially implemented this over a year ago, but were delayed in 
deployment when it turned out our ISP (who provides secondary services) 
was running an ancient version of bind that didn't do dnssec 8-/. I 
didn't find any good solutions available at the time.


Taking a look at OpenDNSsec, I don't think I'd use it even if we were 
starting today; it is way over engineered for our requirements. I'm not 
a big fan of XML configuration files, and I don't particularly want a 
signing daemon running 24x7. The current capability of bind to 
automatically select which keys to use based on their timing data, with 
a minimal wrapper around it, provides more than enough functionality to 
manage our relatively simple zones.


dnssec is fairly complicated, and the issue of timing can be complex, 
but once the variables are determined than the actual procedures of 
implementation are pretty simple. Generate keys with appropriate 
publication, activation, inactivation, and deletion timings, and then 
use them ;). My hope from my initial posting was to get a little peer 
review of the appropriateness of the timings I've selected...



--
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
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: dnssec config sanity check

[Paul B. Henson]

On 10/3/2011 6:31 PM, Mark Andrews wrote:


Don't ASSUME that the DS will be published in time. Build checks into
your proceedures from the beginning.  e.g.

Publish and activate July 1. Change DS records July 8. Check
that DS is published July 15 and set inactivate and deletion
dates if and only if new DS is published to August 1 and
September 1 respectively.  If the DS is not publish chase
up with parent and recheck the next day slipping inactivate
and deletion dates for a day for each day the DS publication
date is past July 15.


Other than the (regrettably still manual) update of the DS in the parent 
zone via the registrar, everything else is automated. I don't think 
we'll assume the registrar will do the right thing, but rather than 
waiting until verifying they have and then doing manual things, I think 
I'd rather have the automated process take care of things without 
intervention, and then only have to manually step in and tweak if the 
registrar doesn't update in a timely fashion. Call me optimistic :).


Why would I delay a week between publishing the new KSK and updating the 
DS records? With a TTL of only 12 hours, it seems a delay of no longer 
than that would be required (assuming the new zone was successfully 
transferred to all secondaries).


I initially assumed it wouldn't matter if there was a DS entry in the 
parent zone for a KSK that was no longer in use and not published, but 
it seems in that scenario a resolver might consider the zone bogus and 
fail it. From what I've read, it sounds like it shouldn't, but better 
safe than sorry. The update is removing a key no longer in use, and 
adding a key that won't be used for another year. The new DS entry for 
the new key won't really be needed until that year has passed unless a 
key compromise requires an early rollover. The old DS entry shouldn't 
need to be around for any more than the 12 hour TTL that clients might 
still have signatures from the old key in their caches. Operationally, 
I'll probably update the DS entries the day after the new key is 
generated, and with the current 1 day+ latency the registrars seem to be 
displaying, the DS cut over will happen probably 2-3 days after the key 
cutover. If the registrar hasn't updated within 14 days, I'll need to 
tweak the deletion date for the old key to prevent any broken resolvers 
from failing. The key actually being used has already existed in the 
parent zone for the last year, so verifying the current signatures 
shouldn't be an issue even if the registrar flakes out.


Thanks...

--
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
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

dnssec config sanity check

[Paul B. Henson]

We are getting ready to deploy dnssec, and I'd appreciate a quick sanity 
check on our configuration and key timings to make sure I didn't miss 
anything that would cause things to blow up ;).


Our zone data is maintained in a revision control repository; when 
changes are made there is a process that generates a bind format zone 
file from the data, checks it for syntax errors, compiles, and then 
signs it, at the end reloading the zone into bind with rndc.


Our zones are configured with a 1 hour refresh/5 minute retry/two week 
expiration for zone transfers and a default TTL of 12 hours.


We're using RSASHA256 for both KSK and ZSK, with a keysize of 2048 and 
1024 respectively.


The KSK's are rotated yearly on July 1 at midnight. New KSK's are 
created with a publish date set 1 year in the future, an inactive date 2 
years in the future, and a deletion date of 2 years and 14 days in the 
future. At any given time there are 2 or 3 KSK's being published: the 
key currently being used to sign the ZSK, the key that will be used to 
sign the ZSK starting at the next rotation period, and for 14 days after 
the rotation the key that was previously being used (this 14 day window 
is to ensure enough time to update the DS entries in the parent zones). 
The ZSK's are rotated monthly on the 1st at 12:02am. New ZSK's are 
created with a publish date set 1 month in the future, an inactive date 
2 months in the future, and a deletion date of 2 months and 2 days in 
the future. At any given time there are 2 or 3 ZSK's being published: 
the key currently being used to sign the zone, the key that will be used 
to sign the zone starting at the next rotation period, and for 2 days 
after the rotation the key that was previously being used.


dnssec-signzone is configured to automatically pull the appropriate keys 
from the key directory, and the zones are signed with NSEC3 with a 35 
day validity and 30 minute jitter. After the new keys are generated on 
the first of the month, all of the zones fiels are generated and signed.


The only issue I see is that if there are no updates to the zone in a 
given month (resulting in another signing with a 35 day validity from 
that date), and the master dies on the last day of the month, the slaves 
will have zones which would be good for two weeks based on SOA timings, 
but with signatures that will die off in as little as five days. I don't 
consider that very likely; there are typically updates at least every 
day or two, and if our master died I'm pretty sure we'd have it fixed 
within 24 hours.


Are there any timing issues or edge cases that I'm missing? Thanks in 
advance for any feedback...



--
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
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: "Key : Delaying activation to match the DNSKEY TTL."

[Paul B. Henson]

On 7/7/2011 12:37 PM, Evan Hunt wrote:


less than $dnskey_ttl seconds in the future.  If the activation time
were further away, it would not warn you.  If it were in the past, it
would use the key to sign the zone, and again it would not warn you.
There's only a window of $dnskey_ttl seconds in which you'd ever see
this.


Ah, ok, now it's making sense. On another review, the message wasn't
generated in the forced signing after the new keys were created, it came
from a run initiated by someone making an actual change that needed to
be deployed. This must be the first time since we rolled it out that a
change has been made within 12 hours (our default TTL) of a key
rollover, which is why I'd never seen it before.


And actually, in the case of dnssec-signzone, it's a pointless
message and should probably be suppressed.


Agreed :), would have saved me some confusion and unnecessary concern.
For now, I can just ignore it, thanks again for the clarification of
what was going on.

--
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
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: "Key : Delaying activation to match the DNSKEY TTL."

[Paul B. Henson]

On Wed, Jul 06, 2011 at 06:56:57PM -0700, Evan Hunt wrote:
 
> Apparently it thought this was the first time it was being published,
> anyway.  That information doesn't come from the publication date but
> from before-and-after comparison of the DNSKEY RRset.
> 
> If this message came from dnssec-signzone, I guess maybe you were
> signing the raw zone, rather than re-signing a zone that was already
> signed?

Yes; our zone data is stored in a subversion repository, when it
changes, a process generates a bind format zone file from the raw data,
feeds it through named-compilezone, then through dnssec-signzone,
and then finally copies it into place and reloads the zone via rndc
reload.

I only saw this message when the key first became active, I haven't seen
it since. However, based on your description, and given I'm always
signing a fresh zone rather than resigning one, it seems I'd always see
this message, as dnssec-signzone would never have an existing DNSKEY
RRset to compare to, and would always think the key was being published
for the first time? So there must be some consideration of the times set
in the key that affects this decision.

Is there any way to make dnssec-signzone not try to be smarter than it
should be? If I have a key that should be active, I want it used to
sign. Part of our key rolling process is forcing an update after new
keys are generated, to get them published and so that the last published
but not yet used keys are brought into play. If dnssec-signzone
doesn't use the keys that should be active, and there are no updates for
a month (which would result in another signing), I'll end up with
invalid signatures before the next scheduled key generation :(.


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
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: "Key : Delaying activation to match the DNSKEY TTL."

[Paul B. Henson]

On Tue, Jul 05, 2011 at 07:34:22PM -0700, Evan Hunt wrote:
 
> The key is being published now, and its activation date (i.e., when it
> will start to be used to sign records) is in the near future: less than
> the TTL of the DNSKEY record from now.
> 
> When the key starts signing, then someone could get an RRSIG generated by
> that key... but, if that same someone had a cached copy of the DNSKEY
> record from *before* the key was published, then validation could fail.
> 
> So, what it's telling you is that named won't start signing records with
> this key until after the old DNSKEY record is guaranteed to have expired
> out of all the resolver caches.

Hmm, thanks for the explanation. However, for this case, while the
activation date was in the near future, the *publish* date was far in
the past.

Per the log output from my update script (which runs dnssec-signzone
behind the scenes):

Jun 30 17:07:26 dns_update[8373]: warning: Key
csupomona.edu/RSASHA256/17755: Delaying activation to match the DNSKEY
TTL. (sign_zone)
Jun 30 17:07:26 dns_update[8373]: warning: Key
csupomona.edu/RSASHA256/1161: Delaying activation to match the DNSKEY
TTL. (sign_zone)

And the corresponding key timing info:

$ dnssec-settime -p all Kcsupomona.edu.+008+17755.key 
Created: Thu Jul  8 19:05:30 2010
Publish: Thu Jul  8 19:05:30 2010
Activate: Fri Jul  1 00:00:00 2011
Revoke: UNSET
Inactive: Sun Jul  1 00:00:00 2012
Delete: Tue Jul  3 00:00:00 2012

$ dnssec-settime -p all Kcsupomona.edu.+008+01161.key 
Created: Wed Jun  1 00:02:02 2011
Publish: Wed Jun  1 00:02:02 2011
Activate: Fri Jul  1 00:00:00 2011
Revoke: UNSET
Inactive: Mon Aug  1 00:00:00 2011
Delete: Wed Aug  3 00:00:00 2011

I was rolling both the ZSK and my KSK, the first should have been
published for the last month, the second for the last year?

Wait, how does dnssec-signzone know whether or not a key has been
published or not? I could have created a key 10 seconds ago and set a
publication date of last year, and what would distingish that from a key
actually created and published last year?


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
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

"Key : Delaying activation to match the DNSKEY TTL."

[Paul B. Henson]

I saw this message from dnssec-signzone around the time a previously
published key was due to be activated, and I'm not quite sure what it
means. Google is uncharacteristically silent about it ;).

If someone could offer an explanation of why the activation was delayed
and whether I should care it would be much appreciated, thanks...


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
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: bind 9.7.1 tries to automatically resign non-dynamic zones

[Paul B. Henson]

Didn't see any replies on this :(. I did send it on a Sunday and maybe it
slipped through the cracks, so I thought I'd try one more time and hope
somebody might have an idea what's going on :).

I opened a bug with ISC, but no response on that yet. I dug through the
source code some myself, the auto-dnssec option seems to control the
"refreshkeytime", whereas the automatic resigning behavior I'm seeing is
controlled by the "resigntime". That is initialized in zone.c by the
function sc_time_settoepoch, which if left to that value would not result
in automatic resigning. The function set_resigntime gets called during zone
loading, which fetches a time via dns_db_getsigningtime. I'm not sure where
that's getting a time from, but it results in the server wanting to resign
stuff 7 days before the signatures expire. It calls zone_resigninc, which
is resulting in the error messages and failures listed below. None of this
seems conditional on the zone in question being dynamic.

Anybody have any suggestions on how to make bind stop trying to
automatically resign a non-dynamic zone?

Thanks...


On Sun, 29 Aug 2010, Paul B. Henson wrote:

> We're prototyping dnssec with bind 9.7.1, and ran into a strange issue
> where it looks like bind is trying to automatically resign non-dynamic
> zones when the signatures are going to expire.
>
> Our zones are signed by an external process, and all bind is supposed to do
> is serve them 8-/. Zones are signed whenever contents change, or at least
> monthly to prevent the signatures from expiring. One of the zones hadn't
> been changed all month so far, and the signatures were only valid for 7
> more days, when suddenly these errors popped up in the logs:
>
> Aug 28 10:33:37 atlas named[4001]: dns_dnssec_findzonekeys2: error reading
> private key file calpolypomona.org/RSASHA256/19218: file not found
> Aug 28 10:33:37 atlas named[4001]: dns_dnssec_findzonekeys2: error reading
> private key file calpolypomona.org/RSASHA256/10476: file not found
> Aug 28 10:33:37 atlas named[4001]: dns_dnssec_findzonekeys2: error reading
> private key file calpolypomona.org/RSASHA256/60885: file not found
> Aug 28 10:33:37 atlas named[4001]: dns_dnssec_findzonekeys2: error reading
> private key file calpolypomona.org/RSASHA256/60649: file not found
> Aug 28 10:33:37 atlas named[4001]: dns_dnssec_findzonekeys2: error reading
> private key file calpolypomona.org/RSASHA256/18097: file not found
> Aug 28 10:33:37 atlas named[4001]:
> /var/lib/bind/cpp/calpolypomona.org_external.jnl: create: permission denied
> Aug 28 10:33:37 atlas named[4001]: zone calpolypomona.org/IN/external:
> zone_resigninc:dns_journal_open -> unexpected error
> Aug 28 10:33:37 atlas named[4001]: zone calpolypomona.org/IN/external:
> sending notifies (serial 2010080101)
> Aug 28 10:33:53 atlas named[4001]: dns_dnssec_findzonekeys2: error reading
> private key file calpolypomona.org/RSASHA256/19218: file not found
> Aug 28 10:33:53 atlas named[4001]: dns_dnssec_findzonekeys2: error reading
> private key file calpolypomona.org/RSASHA256/10476: file not found
> Aug 28 10:33:53 atlas named[4001]: dns_dnssec_findzonekeys2: error reading
> private key file calpolypomona.org/RSASHA256/60885: file not found
> Aug 28 10:33:53 atlas named[4001]: dns_dnssec_findzonekeys2: error reading
> private key file calpolypomona.org/RSASHA256/60649: file not found
> Aug 28 10:33:53 atlas named[4001]: dns_dnssec_findzonekeys2: error reading
> private key file calpolypomona.org/RSASHA256/18097: file not found
> Aug 28 10:33:53 atlas named[4001]:
> /var/lib/bind/cpp/calpolypomona.org_external.jnl: create: permission denied
> Aug 28 10:33:53 atlas named[4001]: zone calpolypomona.org/IN/external:
> zone_resigninc:dns_journal_open -> unexpected error
> Aug 28 10:33:53 atlas named[4001]: zone calpolypomona.org/IN/external:
> sending notifies (serial 2010080102)
> [...]
> Aug 28 10:35:14 atlas named[4001]: zone calpolypomona.org/IN/external:
> setting keywarntime to 1283664914 - 7 days
>
> It seems like it noticed there were only 7 days of signature validity left,
> and decided it would just go ahead and resign. The zones are *not* dynamic,
> the bind service account (as demonstrated by the permission denied errors)
> doesn't even have write permission on the directories in which the zone
> files are stored. The authoritative serial in the file on disk is
> 2010080100, yet it started bumping the serial on the zone in memory higher
> (and passing that on to the secondaries, which would have broken any actual
> updates that might have been performed).
>
> From reviewing the manual, this behavior should only occur if the zones are
> dynamic, *and* auto-dnssec in enabled, nei

bind 9.7.1 tries to automatically resign non-dynamic zones

[Paul B. Henson]

We're prototyping dnssec with bind 9.7.1, and ran into a strange issue
where it looks like bind is trying to automatically resign non-dynamic
zones when the signatures are going to expire.

Our zones are signed by an external process, and all bind is supposed to do
is serve them 8-/. Zones are signed whenever contents change, or at least
monthly to prevent the signatures from expiring. One of the zones hadn't
been changed all month so far, and the signatures were only valid for 7
more days, when suddenly these errors popped up in the logs:

Aug 28 10:33:37 atlas named[4001]: dns_dnssec_findzonekeys2: error reading
private key file calpolypomona.org/RSASHA256/19218: file not found
Aug 28 10:33:37 atlas named[4001]: dns_dnssec_findzonekeys2: error reading
private key file calpolypomona.org/RSASHA256/10476: file not found
Aug 28 10:33:37 atlas named[4001]: dns_dnssec_findzonekeys2: error reading
private key file calpolypomona.org/RSASHA256/60885: file not found
Aug 28 10:33:37 atlas named[4001]: dns_dnssec_findzonekeys2: error reading
private key file calpolypomona.org/RSASHA256/60649: file not found
Aug 28 10:33:37 atlas named[4001]: dns_dnssec_findzonekeys2: error reading
private key file calpolypomona.org/RSASHA256/18097: file not found
Aug 28 10:33:37 atlas named[4001]:
/var/lib/bind/cpp/calpolypomona.org_external.jnl: create: permission denied
Aug 28 10:33:37 atlas named[4001]: zone calpolypomona.org/IN/external:
zone_resigninc:dns_journal_open -> unexpected error
Aug 28 10:33:37 atlas named[4001]: zone calpolypomona.org/IN/external:
sending notifies (serial 2010080101)
Aug 28 10:33:53 atlas named[4001]: dns_dnssec_findzonekeys2: error reading
private key file calpolypomona.org/RSASHA256/19218: file not found
Aug 28 10:33:53 atlas named[4001]: dns_dnssec_findzonekeys2: error reading
private key file calpolypomona.org/RSASHA256/10476: file not found
Aug 28 10:33:53 atlas named[4001]: dns_dnssec_findzonekeys2: error reading
private key file calpolypomona.org/RSASHA256/60885: file not found
Aug 28 10:33:53 atlas named[4001]: dns_dnssec_findzonekeys2: error reading
private key file calpolypomona.org/RSASHA256/60649: file not found
Aug 28 10:33:53 atlas named[4001]: dns_dnssec_findzonekeys2: error reading
private key file calpolypomona.org/RSASHA256/18097: file not found
Aug 28 10:33:53 atlas named[4001]:
/var/lib/bind/cpp/calpolypomona.org_external.jnl: create: permission denied
Aug 28 10:33:53 atlas named[4001]: zone calpolypomona.org/IN/external:
zone_resigninc:dns_journal_open -> unexpected error
Aug 28 10:33:53 atlas named[4001]: zone calpolypomona.org/IN/external:
sending notifies (serial 2010080102)
[...]
Aug 28 10:35:14 atlas named[4001]: zone calpolypomona.org/IN/external:
setting keywarntime to 1283664914 - 7 days

It seems like it noticed there were only 7 days of signature validity left,
and decided it would just go ahead and resign. The zones are *not* dynamic,
the bind service account (as demonstrated by the permission denied errors)
doesn't even have write permission on the directories in which the zone
files are stored. The authoritative serial in the file on disk is
2010080100, yet it started bumping the serial on the zone in memory higher
(and passing that on to the secondaries, which would have broken any actual
updates that might have been performed).

>From reviewing the manual, this behavior should only occur if the zones are
dynamic, *and* auto-dnssec in enabled, neither is true.

Bug?

Thanks...


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec-keygen & dnssec-signzone "smart signing" vs time zones

[Paul B. Henson]

On Wed, 28 Apr 2010, Mark Andrews wrote:

> Would something like this be better? Do you need a UTC after the
> timestamp.
[...]
> ; Created: 20100429025050 (Thu Apr 29 12:50:50 2010)

Even though it's just a comment, it would be nice for it not to be
ambiguous. As a comment, the raw value isn't very parsable, the descriptive
version itself would probably be fine if it was either always in UTC and
included a UTC suffix to make it obvious, or if relativized to the
localtime included that timezone as a suffix.

> Note: now + delta is timezone agnostic.

Yes, but I was tentively planning on rotating zone keys once a month, and
to simplify that making the 1st of the month the cutoff. It's easy to say
"the 1st of next month" in an absolute fashion, but in a delta fashion
you'd need to worry about how many days each month has. There's probably a
better implentation anyway, we're still in the early prototyping phase.

> From dnssec-signzone
[...]
>2530144500 denotes 14:45:00 UTC on May 30th, 2000.

Perhaps this same example/clarification could be added to the man pages for
dnssec-keygen and dnssec-settime under the "TIMING OPTIONS" section? That's
the documentation I was reviewing while looking into this.

Thanks...


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec-keygen & dnssec-signzone "smart signing" vs time zones

[Paul B. Henson]

On Wed, 28 Apr 2010, Mark Andrews wrote:

> The .private timestamps are in UTC and that is what is used for key
> management.  The .key values are just comments.  You should be able to
> work out my current offset from UTC.
>
> % grep Created Kl.+005+59421.*
> Kl.+005+59421.key:; Created: Thu Apr 29 11:10:24 2010
> Kl.+005+59421.private:Created: 20100429011024

Ah, ok, that makes more sense, thanks.

It might help prevent confusion if the documentation was more clear on time
handling; I might have missed it but I didn't see anything explaining time
was stored in UTC, or that times provided on the command line were
considered to be in UTC. That last bit isn't very intuitive, typically when
time is specified like that it's relative to your time zone. I guess I'll
need to convert the time I want relative to my time zone to UTC and pass
that on the command line instead.


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

dnssec-keygen & dnssec-signzone "smart signing" vs time zones

[Paul B. Henson]

I've been testing dnssec-keygen and the "smart signing" mode of
dnssec-signzone and have run into some timezone confusion; I'm not sure if
it's expected behavior or a bug. I searched around a bit and didn't find
anything relevant, apologies in advance if I missed a FAQ.

If I create a new key leaving the various time metadata options with the
default of "now":

$ date
Wed Apr 28 17:20:00 PDT 2010
$ dnssec-keygen -a RSASHA256 -3 -b 1024 -n ZONE -r /dev/urandom test.domain

$ cat Ktest.domain.+008+57078.key
; This is a zone-signing key, keyid 57078, for test.domain.
; Created: Wed Apr 28 17:20:54 2010
; Publish: Wed Apr 28 17:20:54 2010
; Activate: Wed Apr 28 17:20:54 2010

The metadata times match my current time.

OTOH, if I explicitly specify times for the metadata:

$ date
Wed Apr 28 17:23:15 PDT 2010

$ dnssec-keygen -a RSASHA256 -3 -b 1024 -n ZONE -r /dev/urandom -P now -A 
2010050100 -D 2010060100 test.domain

$ cat Ktest.domain.+008+53670.key
; This is a zone-signing key, keyid 53670, for test.domain.
; Created: Wed Apr 28 17:23:16 2010
; Publish: Wed Apr 28 17:23:16 2010
; Activate: Fri Apr 30 17:00:00 2010
; Delete: Mon May 31 17:00:00 2010

The times are off by 7 hours; rather than 05/01/2010 00:00:00 and
06/01/2010 00:00:00, they're 04/30/2010 17:00:00 and 05/31/2010 17:00:00.

Probably not coincidentally, my timezone is currently UTC-7.

It seems like when an explicit time is specified, it's considered UTC, and
converted to the local time zone before being stored?

The only documentation I found about the time format was "Dates can be
expressed in the format MMDD or MMDDHHMMSS", there was no mention
of timezones.

This is rather confusing. I would understand if time metadata was always
stored as UTC, which would allow key files to be migrated to servers at
various locations whichout changing the relative meaning of the times.
However, storing times based on the local time zone yet parsing times as
UTC doesn't appear very useful. You get both the problem of the time
metadata being relative and dnssec-signzone doing different things
depending on where it's run, and the headache of not being able to specify
times based on your local timezone 8-/.

Am I missing something?

Thanks for any insight...


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: split view dns, with a shared dynamic zone?

[Paul B. Henson]

On Mon, 5 Jan 2009, Adam Tkac wrote:

> Btw setup with slave zone in second view is described in FAQ as well:
> - https://www.isc.org/faq/bind
> - Configuration and Setup Questions -> "How do I share a dynamic zone
> between multiple views?"

Cool, thanks for the pointer. I searched with google and on the mailing
list archives, but never ran across the FAQ. I had tried something similar,
but the slave would do a zone transfer the first time the slave zone
existed, it would never update. I did not have an also-notify option on the
master though, maybe that would fix that problem. I will give it another
try.


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: split view dns, with a shared dynamic zone?

[Paul B. Henson]

On Tue, 30 Dec 2008, [iso-2022-jp] JINMEI Tatuya /  wrote:

> So, you at least need to fix one on-memory zone image that can be
> dynamically updated.  You'll then have to configure the other view where
> the "shared" zone is a secondary of the real dynamic zone in the other
> view, or a forward zone for which all queries to be forwarded to the real
> zone.  (I've not tried this configuration by myself, so I'm not 100% sure
> if this can implement what you need).

It's making my brain hurt ;), but I kind of see what you're suggesting. A
single server both master and secondary for the same zone in different
views. That should work for the "both the same" part. Then if I configure
the secondary zone to forward updates to the primary zone both views would
be the same and clients in either view could update. I guess the primary
zone would have to be in the view in which the IP of the actual server
resides, so the forwarded update from the server to itself ( 8-/, will that
even work?) hits the primary.

I think it's kind of a deficiency of bind not to support this type of
configuration more cleanly. It would be nice if you could have both split
view zones and standalone zones on the same server. Perhaps a feature
request :)?

Thanks for the suggestion, I'll play with it and see what happens.


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: split view dns, with a shared dynamic zone?

[Paul B. Henson]

On Tue, 30 Dec 2008, [iso-2022-jp] JINMEI Tatuya /  wrote:

> Is your goal something like this?
>
> - the server has an authority for a zone, e.g., "example.com".
> - example.com is defined for both the internal and external views, and
>   these views share the content of the example.com zone.
> - any clients can make an update to example.com, whether their IP
>   address is internal or external.

Yes, that is *exactly* what I want to do. Basically, I want that particular
zone to function as it would if I didn't have bind configured with zones
at all. Is there any way to accomplish that? I've reviewed the
configuration documentation and searched but haven't found anything
helpful.

Thanks...


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

split view dns, with a shared dynamic zone?

[Paul B. Henson]

I currently have a split view dns configuration, with a view for internal
ips and a separate view for external ips. There are some names which need
to resolve the same for both views. I have implemented this in the past by
having common data in a separate file that was included by the zone files
in each view, which has worked out fine for static zones.

However, now I want to implement a dynamic zone. The data in this zone
should be the same for both the external and internal views, and I'm just
not seeing a way to accomplish that.

I tried configuring a zone in both views pointing to the same underlying
file, which didn't work out, as updates from different view sources weren't
seen in the other view, and presumably the file/journal was getting
stomped on by competing updates from each view.

Is there any way to configure a dynamic zone which is shared between both
views, where an update from a box with an "internal" ip is seen by a query
from a box with an "external" ip, and vice versa? Short of setting up a
completely different DNS server and delegating the zone to it (which I'd
rather not do, I'd really like to keep this on the same master/slaves as
everything else) I can't think of a way to implement this.

Thanks for any suggestions...


-- 
Paul B. Henson  |  (909) 979-6361  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  hen...@csupomona.edu
California State Polytechnic University  |  Pomona CA 91768
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users