Re: "rndc sign", "auto-dnssec maintain" and TYPE65534 record "stickyness"?
On 26/11/12 14:47, Phil Mayers wrote:
> All,
>
> Up front, I should note that this was on a hidden master server which
> was running 9.7.0 (since updated). So it may not work this way on
> current versions of bind.
>
> We (well, I) had a little accident recently when rolling a ZSK. We use
> "auto-dnssec maintain" like so:
>
> zone "blah" {
> file "zones/blah/zone";
> auto-dnssec maintain;
> key-directory "zones/blah";
> allow-update { ... };
> type master;
> };
>
> The zones are initially signed offline using "dnssec-signzone" using the
> "-j" option so that incremental re-signing is evenly spread over time.
>
> My normal system for doing a ZSK rollover is as follows:
>
> cd /var/named/data/zones/blah
> dnssec-keygen ...
> dnssec-settime -P now -A none K
>
> ...then wait until the new DNSKEY has propagated, and:
>
> dnssec-settime -A now K && dnssec-settime -I now K
>
> ...then wait 30 days until bind has incrementally re-signed the entire
> zone and the old key is not in use + TTLs, then:
>
> dnssec-settime -D now K
>
>
> Unfortunately this time, I made a mistake. After swapping the active
> keys, I foolishly ran:
>
> rndc sign THEZONE
>
> Somehow the notion had occurred that this would make it load the new
> keys, despite me knowing this is not the case. Instead, this immediately
> signed every record in the zone with the new key, which doubled the size
> of the zone and blew away any signing jitter I had.
>
> [Obviously what I wanted was "rndc loadkeys"]
>
>
> After recovering by reverting the active/inactive keys and running "rndc
> sign" again, two problems emerged:
>
> 1. Despite the old key having a create/publish/active time in the past,
> and no other times, bind stopped incremental re-signing, which I only
> noticed close to the disaster point. It would sign new records added via
> DDNS, but not regenerate signatures. The daemon had been completely
> restarted, so it wasn't a stuck internal state - it must have been an
> attribute of the zone. I assume it had stopped signing because it was
> waiting on the next item...
>
> 2. When I tried to resume the process a few days later using the same
> "new" key, the "full resign" started again, straight away, despite me
> not having made the error of doing "rndc sign".
>
>
> I assume both problems are related, and were caused by the TYPE65534
> records, plural, which persisted in the zone after the original mistake:
>
> TYPE65534 \# 5 ( 0512870001 ) => old key id# 4743
> TYPE65534 \# 5 ( 05B98E ) => new key id# 47502
>
> My question is this: how could I have avoided the two problems that
> occurred the *second* time I tried this?
>
> Presumably I needed to make the zone completely forget about the new key
> ID, which would have removed the relevant TYPE65534 record - but would
> that have re-started the incremental re-signing with the old key?
>
> Cheers,
> Phil
Hi Phil,
It's tricky to answer your questions since this was on BIND 9.7.0 which
has been substantially updated between 9.7.0 and 9.7.7 (the CHANGES log
of 9.7.7 might give you some clues). But also of particular relevance
to this would be the change in how automatic resigning is done when
there's a key rollover. It was blogged about here:
https://www.isc.org/community/blog/201006/bind-972-and-and-automatic-dnssec-signing
Hope this helps.
Cathy
___
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: Performance tuning
"Adamiec, Lawrence" wrote on 11/26/2012 01:12:48 PM: > To the best of my knowledge, there are no problems with our DNS. We > only host 25 domains. > > The report must also address these two specific questions: > > 1. Why does www.kentlaw.iit.edu load quicker than kentlaw.iit.edu in > any browser? Are you sure this is a DNS issue? Test it by adding both to /etc/hosts (or Windows equal). Reboot and flush all caches between tests. > 2. What happens if we remove the forwarders option from named.conf? Depends why you have the forwarders. . > I can't duplicate the issue in Q1 and I'm trying to determine a way > of testing Q2. Oh the joys of intermittent problems. Are you sure the issues reported as Q1 are real? Have the web site folks been involved in discussions or are they just blaming DNS without testing anything? If possible sneak host file entries onto a handful of user machines and see if they still complain. Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ 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
truncated responses vs. minimal-responses?
Hello, last few weeks I have seen many discussions over UDP truncating and using "minimal-responses yes;" to prevent BIDN from doing that. I've read article stating that nameserver should avoid truncating packets even by skipping additional and authority sections in its responses, which should mean that using minimal-responses would not help. However, I've seen a few mails mentioning that a query can get truncated when the authority section is too big and advices to turn minimal-responses on. Reading the 9.9.2 docs and even looking at the sources (I am not a C coder) did not help me with this. Can anyone enlight me in this? Thank you. -- 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. - Holmes, what kind of school did you study to be a detective? - Elementary, Watson. -- Daffy Duck & Porky Pig ___ 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: truncated responses vs. minimal-responses?
-Original Message- From: Matus UHLAR - fantomas Date: Tuesday, November 27, 2012 12:28 PM To: "bind-users@lists.isc.org" Subject: truncated responses vs. minimal-responses? >Hello, > >last few weeks I have seen many discussions over UDP truncating and using >"minimal-responses yes;" to prevent BIDN from doing that. > >I've read article stating that nameserver should avoid truncating packets >even by skipping additional and authority sections in its responses, which >should mean that using minimal-responses would not help. > >However, I've seen a few mails mentioning that a query can get truncated >when the authority section is too big and advices to turn >minimal-responses >on. > >Reading the 9.9.2 docs and even looking at the sources (I am not a C >coder) >did not help me with this. It seems it should help... less bits in the packet relating to additional and authority should leave room for other data. That said, I think the better way (when possible) is to adjust RRs not to return "too much data" (e.g. NS, A, etc. not returning more than ~8 hosts -- which in turn could be multicast, load balanced, etc to get the desired scale). Akamai, for example, defaults to limiting up to 8 "RDATAs" per RR (or however you'd describe that). If you add 20 As for a name you'll rotate through 8 at a time. You can request more at your own risk...they assume you'll ensure the larger answer will fit in a UDP packet and not cause TCP responses which cripple performance. ___ 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: Performance tuning
Hi, My original post was about writing a report to optimize our DNS servers and the report needed to address two questions. Based on the answers I received, I will write our servers are already optimized and no further tuning is needed. Now about the two specific questions for the report. Q1 -- I don't believe the problem is DNS related. However, I have not been able to recreate the trouble so I don't know if there is any problem. As other list members have posted, they didn't have any problems with the pages rendering either. As far as asking me about the web sites staff, well, I am the technical contact for our web sites. Our Public Affairs department handles content related issues and I take of all server related things. I will double check the web server, but it shouldn't be using any rewrites for the main page. And I don't know who is complaining about the pages. This question came from my boss. Q2 -- The forwarders statement was added to our config file about six years ago. Some users complained they could not reach two or three specific web sites outside our domain. At that time, one of our network staff members told me his nslookup for the sites were timing out. I was instructed to insert the forwarder statement with the main campus servers acting as the forwarder. The time outs stopped and people stopped complaining. I don't know that adding the forwarder statement actually fixed any trouble but nslookups did not time out, people stopped complaining, and my boss was happy. (I know dig is better). Unfortunately, I don't remember which sites people were complaining about. Larry On Tue, Nov 27, 2012 at 8:11 AM, wrote: > "Adamiec, Lawrence" wrote on 11/26/2012 > 01:12:48 PM: > > > > To the best of my knowledge, there are no problems with our DNS. We > > only host 25 domains. > > > > The report must also address these two specific questions: > > > > 1. Why does www.kentlaw.iit.edu load quicker than kentlaw.iit.edu in > > any browser? > > Are you sure this is a DNS issue? Test it by adding both to /etc/hosts > (or Windows equal). Reboot and flush all caches between tests. > > > 2. What happens if we remove the forwarders option from named.conf? > > Depends why you have the forwarders. > . > > I can't duplicate the issue in Q1 and I'm trying to determine a way > > of testing Q2. > > Oh the joys of intermittent problems. Are you sure the issues reported as > Q1 are real? Have the web site folks been involved in discussions or are > they just blaming DNS without testing anything? > > If possible sneak host file entries onto a handful of user machines and > see if they still complain. > > > > > > Confidentiality Notice: > This electronic message and any attachments may contain confidential or > privileged information, and is intended only for the individual or entity > identified above as the addressee. If you are not the addressee (or the > employee or agent responsible to deliver it to the addressee), or if this > message has been addressed to you in error, you are hereby notified that > you may not copy, forward, disclose or use any part of this message or any > attachments. Please notify the sender immediately by return e-mail or > telephone and delete this message from your system. > ___ 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: "rndc sign", "auto-dnssec maintain" and TYPE65534 record "stickyness"?
On 27/11/12 09:13, Cathy Almond wrote: It's tricky to answer your questions since this was on BIND 9.7.0 which has been substantially updated between 9.7.0 and 9.7.7 (the CHANGES log of 9.7.7 might give you some clues). But also of particular relevance to this would be the change in how automatic resigning is done when there's a key rollover. It was blogged about here: https://www.isc.org/community/blog/201006/bind-972-and-and-automatic-dnssec-signing Hope this helps. Thanks - that's a very helpful and relevant document. It sounds like what I ran into was actually the *expected* behaviour for that version. That being the case, I'm puzzled why it didn't happen with previous two ZSK rollover I did. However, given there have been extensive changes, I'll just re-test on the bench and write it off to experience. Cheers, Phil ___ 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
