DNSKEY and RRSIG DNSKEY TTL values aren't changed after changing of zone's TTL
Hello. I'm using BIND 9.9.5. My steps: 1. Sign zone using one 1 ZSK and 2 KSK: a) adding "*auto-dnssec maintain;*" and "*inline-signing yes;*" directive into zone section of named.conf; b) setting publication and activation timestamps to current time in key files; c) *rndc reload*. 2. Change TTL value in the zone file ($TTL 86400 ==> $TTL 432000). 3. Increase serial number in SOA record by 1. 4. *rndc reload*. After that - DNSKEY and RRSIG DNSKEY records still have 86400 value in TTL (checked via *dig*). What could be the reason for such behavior? Kind regards, Aleks Ostapenko ___ 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: Delegation questions
Speaking as a European, at least for now, I suspect the forwarding mindset is more from the enterprise and security culture rather than being territorial. There's a viewpoint that says things are better if they are tightly controlled and predictable, so always using the same configured path for DNS lookups is The Right Thing To Do (and there may be test suites and monitoring to try to ensure that 99% of all transactions complete within so many milliseconds etc etc). Sam In article , Chris Buxton wrote: > Forwarding is more similar to how some other systems work. But it's not how > DNS naturally works. I think the biggest source of "forwarding = natural" is > perhaps from admins coming from other parts of IT, rather than any regional > difference. But I could be wrong. > > From a technical perspective, in addition to the performance factor that > Kevin described, there is the fact that forwarding is inherently brittle. (So > are stub zones, for different reasons.) So the more you forward, the harder > it becomes to troubleshoot the inevitable problems that will arise, because > you have more systems to check and more ways for things to go wrong. > > Regards, > Chris > > Sent from my iPhone > > > On Aug 12, 2016, at 5:11 PM, Darcy Kevin (FCA) > > wrote: > > > > True, strictly from a per-hop latency standpoint, there shouldn't be much > > difference between forwarding a packet or forwarding a DNS query. > > > > Having said that -- and I'm sure the BIND developers could elaborate > > further on this -- I know that there's big difference between processing > > *packets*, from, say, a routing standpoint, which customized ASIC-level > > hardware can do to the tune of millions per second, and processing > > *queries*, which are much higher-level constructs, with a lot more > > variation, more levels of parsing, disassembly, re-assembly, validation, > > etc. When you have multi-hop DNS forwarding, you're using up significant > > resources on multiple computing devices at once, in ways that don't > > necessarily lend themselves to optimization in hardware. It ends up being > > the opposite of parallelism, i.e. using the resources of multiple devices > > to accomplish something that could, with only configuration changes, be > > accomplished with the resources of only one device. > > > > At the risk of sounding xenophobic, there seems to be a mindset among > > certain cultures that forwarding is "natural", and, in contrast, having DNS > > instances talk to each other directly is somehow "artificial". I've had > > this conversation many times with many of my European counterparts over the > > years, and we just seem to view things differently. One could speculate on > > the difference in world view -- submission to higher authority, perhaps? > > Hierarchical social organization? I don't know -- I don't claim any > > expertise whatsoever in sociology, cognitive psychology, or related fields. > > But for me, and I think most people in my (North American) culture -- > > possibly because we tend more towards individualism and/or egalitarianism? > > -- having DNS instances talk *directly* to each other, as "equals" or > > "peers", is much more natural than one DNS instance relying upon another to > > handle all of its resolution needs (thus making the first instance > > subservient, in a sense, to the second), which then relies on another, and > > to another, and so on, in a daisy chain. > > > > Again, maybe it's just a different mindset/world-view. Or, perhaps I'm > > over-generalizing a cultural difference from a relatively-small sample of > > conversations. But, as I touched on in my second paragraph, there may be > > some objective reasons to eschew forwarding, particularly multi-hop > > forwarding. > > > >- Kevin > > > > > > -Original Message- > > From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of > > Willmann, Robert > > Sent: Friday, August 12, 2016 1:33 AM > > To: bind-users@lists.isc.org > > Subject: RE: Delegation questions > > > > Kevin Darcy wrote: > >> > >> In any case, multi-hop forwarding is always the least-preferred option. > > > > I wonder for which reason do you think this. > > > > Of course, any forwarding adds a additional hop and therefore additional > > delay and an additional possible point of failure. > > But this is true for any network-connection. > > > > So, what do you think are the DNS-specific downsides of forwarding? > > The only thing that comes to mind if I think about downsides of forwarding > > is that, if something goes wrong, the client only gets a generic SERVFAIL > > as errormessage instead of a specific explanation what exactly went wrong. > > > > Do you see other downsides to forwarding? > > > > > > Mit freundlichen GrüÃen > > Robert Willmann > > > > -- > > Commerzbank AG > > Group Information Technology > > GS-IT 8.2.3 Core Services > >
RE: Stub Zone Behavior?
Forwarding is a different beast from "stub" (recursive rather than iterative
resolution).
I'd look at "static-stub", if your NS list is overgrown with
useless/unreachable stuff. It's configured basically the same way as
forwarding, but without making the paradigm shift (and possible unforeseen
consequences) from iterative to recursive resolution.
http://jpmens.net/2011/01/25/binds-new-static-stub-zone-type/
https://lists.isc.org/pipermail/bind-users/2012-September/088719.html
If you only have a *few*, relatively-static set of unreachables, you might
consider listing just those ones as "bogus".
- Kevin
-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Ray Van
Dolson
Sent: Saturday, August 13, 2016 8:29 AM
To: bind-users@lists.isc.org
Subject: Stub Zone Behavior?
Have a resolver at a branch office with a view containing a stub zone as
follows:
zone "domain.com." IN {
type stub;
masters { 10.216.11.6; 10.58.4.1; 10.50.4.32; };
file "stub/domain.com";
forwarders {};
};
Other notes:
- "domain.com" is an Active Directory zone.
- Running bind-9.8.2-0.47.rc1.el6.x86_64 (RHEL6)
This setup seemed to work fine for many months, but within the last two or so
has randomly started returning no answers for only certain queries (well the
SOA stuff is returned) until I rndc flush on the system after which response
returns to normal for a period of time.
After trying a few things without success, I changed the zone type to forward
instead of stub (with the servers used as masters in the stub config as the
forwarders) and this has seemed to solved the problem.
As I understand it, stub zones work by pulling down SOA, NS and "glue"
for the NS from one of the masters into a local zone file and then queries to
the domain are answered by querying one of the authoritative servers defined in
the stub zone.
My working theory is that BIND will randomly choose one of the NS servers to
get an answer from, and since our NS list is very long with the servers
scattered across the globe, perhaps BIND chooses one which doesn't respond
quickly enough or at all (or maybe badly?) and then caches that negative or
absent response.
Probably in this case the forward type works just as well for our local clients
at the office (I believe answers for "forward" zones can also be cached
locally...), so am inclined to stand pat with this config but would still love
to understand what might have caused the original stub setup to fail.
Ray
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Disabling rate-limit?
I inherited a DNS server which is running BIND 9.8.x. There was a DNS incident where our customers complained that they saw query timeouts intermittently (Our customers run cassandra/hadoop applications and send same queries repeatedly). They also run nscd on their hosts but I was told all have same TTL value of 3600 indicating all names expire at the same time on thousands of client hosts). I tried to reproduce the issue by sending hostname.bind queries and I see logs similar to the one below: named[]: limit responses to for hostname.bind CH TXT named[]: *stop limiting responses to for hostname.bind CH TXT I reviewed /etc/named.conf and do not see 'rate-limit' configuration. I am confused because BIND ARM says rate-limit is disabled by default. But logs indicate otherwise. ( I did "grep rate /etc/*" and didn't see anything. There are no includes in named.conf) Please advice on how I can disable rate-limit on my DNS server. I did a strings on 'named' binary and see this: strings /usr/sbin/named | egrep -i rrl dns_rrl dns_rrl_init dns_rrl_view_destroy What else do I need to check to identify if RRL is enabled? Thanks Blr ___ 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: DNSKEY and RRSIG DNSKEY TTL values aren't changed after changing of zone's TTL
In message , =?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCe0YHRgtCw0L/QtdC90LrQvg==?= writes: > Hello. > > I'm using BIND 9.9.5. > My steps: > >1. Sign zone using one 1 ZSK and 2 KSK: a) adding "*auto-dnssec >maintain;*" and "*inline-signing yes;*" directive into zone section of >named.conf; b) setting publication and activation timestamps to current >time in key files; c) *rndc reload*. >2. Change TTL value in the zone file ($TTL 86400 ==> $TTL 432000). >3. Increase serial number in SOA record by 1. >4. *rndc reload*. > > After that - DNSKEY and RRSIG DNSKEY records still have 86400 value in TTL > (checked via *dig*). > What could be the reason for such behavior? > > > Kind regards, > Aleks Ostapenko Use "dnssec-settime -L ttl" Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: Disabling rate-limit?
On Mon, 15 Aug 2016, blrmaani wrote: I inherited a DNS server which is running BIND 9.8.x. There was a DNS incident where our customers complained that they saw query timeouts intermittently (Our customers run cassandra/hadoop applications and send same queries repeatedly). They also run nscd on their hosts but I was told all have same TTL value of 3600 indicating all names expire at the same time on thousands of client hosts). I tried to reproduce the issue by sending hostname.bind queries and I see logs similar to the one below: named[]: limit responses to for hostname.bind CH TXT named[]: *stop limiting responses to for hostname.bind CH TXT I reviewed /etc/named.conf and do not see 'rate-limit' configuration. I am confused because BIND ARM says rate-limit is disabled by default. But logs indicate otherwise. The built-in view for the "CH" class has response rate-limting (RRL) enabled by default. It's possible to override it, but it might not help you any. Basically, your test queries are sufficiently different than normal queries that your test methodology is probably invalid. Do you see RRL log messages for normal queries? If not, then RRL is probably not your trouble. Other things like insufficient UDP buffering, lacking CPU horsepower, or overwhelmed iptables connection tracking can also cause time-outs. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335- ___ 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: Disabling rate-limit?
Hi Blr, First things first: if your customers are sending queries, this is probably about their own recursive queries timing out, rather than incoming authoritative queries timing out. Something else you should check: are your customers receiving a delayed (say a few seconds) SERVFAIL response, or are they receiving no response at all? There's a different set of options in BIND for recursive rate limiting versus authoritative rate limiting. Recursive queries: * recursive-clients * clients-per-query * max-clients-per-query Running 'rndc status' is a good way to see how close you are to these limits; you'll see log messages like "no more recursive clients: quota reached" There's also a newer set of "recursive client rate-limiting" features available in newer (9.9 and 9.10) versions of BIND, but I'm pretty sure this doesn't apply to your case. Authoritative queries: https://kb.isc.org/article/AA-00994/0/Using-the-Response-Rate-Limiting-Feature-in-BIND-9.10.html IIRC, rate-limiting for authoritative queries (called "Response rate limiting" or "RRL") wasn't enabled by default until BIND 9.10.x, and required a specific build in BIND 9.9.x. It's not available in BIND 9.8.x. John On Mon, Aug 15, 2016 at 9:22 PM, blrmaani wrote: > I inherited a DNS server which is running BIND 9.8.x. There was a DNS > incident where our customers complained that they saw query timeouts > intermittently (Our customers run cassandra/hadoop applications and send same > queries repeatedly). They also run nscd on their hosts but I was told all > have same TTL value of 3600 indicating all names expire at the same time on > thousands of client hosts). > > I tried to reproduce the issue by sending hostname.bind queries and I see > logs similar to the one below: > > named[]: limit responses to for > hostname.bind CH TXT > named[]: *stop limiting responses to > for hostname.bind CH TXT > > > I reviewed /etc/named.conf and do not see 'rate-limit' configuration. I am > confused because BIND ARM says rate-limit is disabled by default. But logs > indicate otherwise. > > ( I did "grep rate /etc/*" and didn't see anything. There are no includes in > named.conf) > > Please advice on how I can disable rate-limit on my DNS server. > > > I did a strings on 'named' binary and see this: > > strings /usr/sbin/named | egrep -i rrl > dns_rrl > dns_rrl_init > dns_rrl_view_destroy > > What else do I need to check to identify if RRL is enabled? > > > Thanks > Blr > ___ > 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 -- John Miller Systems Engineer Brandeis University johnm...@brandeis.edu (781) 736-4619 ___ 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: Disabling rate-limit?
>From tcpdump, it appears that customers are receiving delayed response and are >too sensitive for timeouts. The queries they are sending are authoritative i.e the zone is on our nameserver. How do I trouble-shoot this issue? This is really intermittent and hard to reproduce.. thanks Blr On Monday, August 15, 2016 at 7:27:44 PM UTC-7, John Miller wrote: > Hi Blr, > > First things first: if your customers are sending queries, this is > probably about their own recursive queries timing out, rather than > incoming authoritative queries timing out. > > Something else you should check: are your customers receiving a > delayed (say a few seconds) SERVFAIL response, or are they receiving > no response at all? > > There's a different set of options in BIND for recursive rate limiting > versus authoritative rate limiting. > > Recursive queries: > > * recursive-clients > * clients-per-query > * max-clients-per-query > > Running 'rndc status' is a good way to see how close you are to these > limits; you'll see log messages like > > "no more recursive clients: quota reached" > > There's also a newer set of "recursive client rate-limiting" features > available in newer (9.9 and 9.10) versions of BIND, but I'm pretty > sure this doesn't apply to your case. > > Authoritative queries: > https://kb.isc.org/article/AA-00994/0/Using-the-Response-Rate-Limiting-Feature-in-BIND-9.10.html > IIRC, rate-limiting for authoritative queries (called "Response rate > limiting" or "RRL") wasn't enabled by default until BIND 9.10.x, and > required a specific build in BIND 9.9.x. It's not available in BIND > 9.8.x. > > John > > On Mon, Aug 15, 2016 at 9:22 PM, blrmaani wrote: > > I inherited a DNS server which is running BIND 9.8.x. There was a DNS > > incident where our customers complained that they saw query timeouts > > intermittently (Our customers run cassandra/hadoop applications and send > > same queries repeatedly). They also run nscd on their hosts but I was told > > all have same TTL value of 3600 indicating all names expire at the same > > time on thousands of client hosts). > > > > I tried to reproduce the issue by sending hostname.bind queries and I see > > logs similar to the one below: > > > > named[]: limit responses to for > > hostname.bind CH TXT > > named[]: *stop limiting responses to > > for hostname.bind CH TXT > > > > > > I reviewed /etc/named.conf and do not see 'rate-limit' configuration. I am > > confused because BIND ARM says rate-limit is disabled by default. But logs > > indicate otherwise. > > > > ( I did "grep rate /etc/*" and didn't see anything. There are no includes > > in named.conf) > > > > Please advice on how I can disable rate-limit on my DNS server. > > > > > > I did a strings on 'named' binary and see this: > > > > strings /usr/sbin/named | egrep -i rrl > > dns_rrl > > dns_rrl_init > > dns_rrl_view_destroy > > > > What else do I need to check to identify if RRL is enabled? > > > > > > Thanks > > Blr > > ___ > > 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 > > > > -- > John Miller > Systems Engineer > Brandeis University > johnm...@brandeis.edu > (781) 736-4619 ___ 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
