key dir massive
Hi, I recently upgraded from 9.16 to latest version and changed a zone, ran verisign test and it said all good, so changed my zones from auto maintain dnssec to dnssec policy default, what a nightmare, most our zones vanished few hours later for a day, and it create new keys for everything, this bug i saw was fixed many versions ago, should it not see my have keys and re-use them (keys were made a year ago on current at the time v9.11, we upgrade to 9.16 in July and no issue till these option name change rubbish. I was warned by colleagues not to do this as they too say migration nightmares, but I am my own person and now I regret not listening their advise. Now I think is under control, once identifying the current key set, is it safe to manually delete all the others keys privates and states, except the current one, and will any of that DS change again? -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: consolidating Reverse Zones
I have looked twice, there is no whitespace in the zone file.
If I change the conf file to present as a /16 it works fine, but we dont
have the /16 so we cant use it this way in production.
OK, we could, but that would be wrong because we are claiming dns of other
parts of /16 we have no rights to.
Either way it seems bind can not simply do it the way I had expected it to,
flabergasted by that.
On Fri, Oct 22, 2021 at 10:43 AM Mark Andrews wrote:
>
>
> > On 21 Oct 2021, at 18:33, Edwardo Garcia wrote:
> >
> > Hai all,
> >
> > We have been given task of doing some migrations within new merger.
> > One of these is we have a number of reverse zones, a /19 in fact, they
> are mostly GENERATE'd for regions with fixed gw and a few other local
> custom PTRs
> >
> > I have played roughly with a fictitious in-addr.arpa (I play with cgnat
> range since it will not affect or interfere with anyone whilst we play
> around)
> >
> > In our examples I have tried
> > zone "8-15.110.100.in-addr.arpa" {
> > type master;
> > file "cgnat.rev";
> > notify no;
> > };
> > I also tried 8/21.110.100... and it always complain
> > loading from master file cgnat.rev failed: unknown class/type
>
> Remove the white space from the front on the record on this indicated line.
>
> “ 151.10 PTR blue.stop.” is not the same as "151.10 PTR blue.stop.”
>
> Leading white space is “take the name from the previous record”.
>
> > The zone file has usual header, and PTR entry are only
> > 151.10 PTR blue.stop.
> > (even tried 10.151)
> >
> > I guess bind can not consolidate like this and we have to put up with a
> million /24 zone files ? I was thinking because we can do classless dele
> with smaller than /24, it would work on bigger :)
> >
> > ___
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> >
> > ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
> >
> >
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
>
> --
> 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
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: consolidating Reverse Zones
Wow, looks a right mess to be honest, might just have to leave it as is, less aggravation. Hard to understand why in 2021 almost 2022, we can't do something so simple in dns On Thu, Oct 21, 2021 at 9:49 PM Tony Finch wrote: > Edwardo Garcia wrote: > > > > I guess bind can not consolidate like this and we have to put up with a > > million /24 zone files ? I was thinking because we can do classless dele > > with smaller than /24, it would work on bigger :) > > It is possible! The basic idea (very briefly) is: > > With classless reverse DNS for prefixes longer than /24, you need a CNAME > in the /24 zone pointing at each address in the classless zone. > > For shorter prefixes, you need a DNAME in the /16 zone pointing at each > /24 in the classless zone. > > There are some documents explaining how we use this trick in production > at https://www.dns.cam.ac.uk/domains/reverse/ with links to the less > Cambridge-specific explanations in the last two paragraphs of that page, > viz: > > https://www.dns.cam.ac.uk/domains/reverse/technical.html > > https://tools.ietf.org/html/draft-fanf-dnsop-rfc2317bis > > Tony. > -- > f.anthony.n.finchhttps://dotat.at/ > Lundy, Fastnet: Northwest 4 or 5, occasionally 6 in Lundy. Rough or > very rough, becoming moderate or rough, then moderate later. Showers. > Good, occasionally moderate. > > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
consolidating Reverse Zones
Hai all,
We have been given task of doing some migrations within new merger.
One of these is we have a number of reverse zones, a /19 in fact, they are
mostly GENERATE'd for regions with fixed gw and a few other local custom
PTRs
I have played roughly with a fictitious in-addr.arpa (I play with cgnat
range since it will not affect or interfere with anyone whilst we play
around)
In our examples I have tried
zone "8-15.110.100.in-addr.arpa" {
type master;
file "cgnat.rev";
notify no;
};
I also tried 8/21.110.100... and it always complain
loading from master file cgnat.rev failed: unknown class/type
The zone file has usual header, and PTR entry are only
151.10 PTR blue.stop.
(even tried 10.151)
I guess bind can not consolidate like this and we have to put up with a
million /24 zone files ? I was thinking because we can do classless dele
with smaller than /24, it would work on bigger :)
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: strange dnssec question
Thank you, I'll report back the result
On Wed, Aug 18, 2021 at 10:49 AM Mark Andrews wrote:
>
> > On 18 Aug 2021, at 10:23, Edwardo Garcia wrote:
> >
> > Hola Mark,
> >
> > Thank you, so to be clear, what is mean to delegate zone, the black
> zone? I am not dns expert unfortunately
>
> Yes, create a seperate zone for black.example.net.
>
> In example.net you add NS records for black.example.net. They can use the
> same nameservers as for example.net.
>
> black.example.net. NS some.name.server.
> black.example.net. NS some-other.name.server
>
> you will end up with 2 zone clauses. Apart from the obvious name
> differences
> you won’t add the instructions to sign black.example.net to its stanza.
>
> zone example.net {
> type primary;
> file “example.net.db”;
> ...
> };
>
> zone black.example.net {
> type primary;
> file “black.example.net.db”;
> ...
> };
>
> The top of black.example.net.db has an SOA record and the same NS records
> as you put in the parent zone for it. The two sets of NS records are
> supposed to be the same.
>
> Mark
>
> > On Wed, Aug 18, 2021 at 6:23 AM Mark Andrews wrote:
> > Delegate the zone. Do NOT add a DS for it.
> >
> > --
> > Mark Andrews
> >
> >> On 17 Aug 2021, at 23:47, Edwardo Garcia wrote:
> >>
> >>
> >> Hola
> >>
> >> We have dnssec working for long time but need now to have a subdomain
> excluded, we are going to be use it to replace an internal blacklist, we
> have 14 smtp servers and it is cumbersome to keep in sync.
> >>
> >> So we have example.net signed,
> >> but we want black.example.net, and of course all addresses under, eg:
> 4.3.2.1.black.example.net to work, at present of course this presents
> SERVFAIL because dnssec, obvious "black" needs to be in example.net zone,
> nd its dns is ns999 whichwork when dnssec disabled but this is not optimum
> >>
> >> looking for suggestion or guidance to how we fix this please? Ir this
> is not possible?
> >>
> >> ___
> >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> >>
> >> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
> >>
> >>
> >> bind-users mailing list
> >> bind-users@lists.isc.org
> >> https://lists.isc.org/mailman/listinfo/bind-users
>
> --
> 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
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: strange dnssec question
Hola Mark, Thank you, so to be clear, what is mean to delegate zone, the black zone? I am not dns expert unfortunately On Wed, Aug 18, 2021 at 6:23 AM Mark Andrews wrote: > Delegate the zone. Do NOT add a DS for it. > > -- > Mark Andrews > > On 17 Aug 2021, at 23:47, Edwardo Garcia wrote: > > > Hola > > We have dnssec working for long time but need now to have a subdomain > excluded, we are going to be use it to replace an internal blacklist, we > have 14 smtp servers and it is cumbersome to keep in sync. > > So we have example.net signed, > but we want black.example.net, and of course all addresses under, eg: > 4.3.2.1.black.example.net to work, at present of course this presents > SERVFAIL because dnssec, obvious "black" needs to be in example.net zone, > nd its dns is ns999 whichwork when dnssec disabled but this is not optimum > > looking for suggestion or guidance to how we fix this please? Ir this is > not possible? > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > > 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 ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
strange dnssec question
Hola We have dnssec working for long time but need now to have a subdomain excluded, we are going to be use it to replace an internal blacklist, we have 14 smtp servers and it is cumbersome to keep in sync. So we have example.net signed, but we want black.example.net, and of course all addresses under, eg: 4.3.2.1.black.example.net to work, at present of course this presents SERVFAIL because dnssec, obvious "black" needs to be in example.net zone, nd its dns is ns999 whichwork when dnssec disabled but this is not optimum looking for suggestion or guidance to how we fix this please? Ir this is not possible? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC upgrade
Thank you! I have now corrected our ancient internal wiki so we now have learned how it goes Very much appreciate your patience and help, now I can start my weekend :-> On Sat, May 1, 2021 at 10:31 PM Tony Finch wrote: > Edwardo Garcia wrote: > > > > So you mean to say when it print out > > > > IN DS 45701 13 1 5422E9... > > IN DS 45701 13 2 qwertyE9... > > > > we never needed 45701 13 1 5422E9 only 45701 13 2 qwertyE9 ? > > Exactly, yes! > > > and we only need run > > > > dig @ns0 dnskey guiltyparty.net | dnssec-dsfromkey -2 -f - > guiltyparty.net > > > > and enter in just that one entry? 45701 13 2 qwertyE to the DS in > domain > > reg? > > Correct! > > > and we have been upload both all this years was wrong ? > > Well, not wrong, but unnecessary. The tools generally encouraged everyone > to publish both SHA1 and SHA2 DS records even though just SHA2 has been > enough for more than 10 years and SHA1 has had known weaknesses for even > longer. > > > hrmm, now I start to understand why not many use DNSSEC so confusing to > > those who not do this every day, or so many instructions around nobody > > knows what works > > > > But we getting there :-> > > Yes, slowly... > > Tony. > -- > f.anthony.n.finchhttps://dotat.at/ > Shannon, Rockall: Variable 4 or less, becoming southwest 3 to 5 later. > Slight, occasionally moderate in Rockall and at first in Shannon. > Showers. Good. > > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC upgrade
OKi, I assume that was same as dig @ns0 dnskey guiltyparty.net | dnssec-dsfromkey -f - guiltyparty.net Which is in our internals wiki for all these years (predate my employment 2012 ) So you mean to say when it print out IN DS 45701 13 1 5422E9... IN DS 45701 13 2 qwertyE9... we never needed 45701 13 1 5422E9 only 45701 13 2 qwertyE9 ? and we only need run dig @ns0 dnskey guiltyparty.net | dnssec-dsfromkey -2 -f - guiltyparty.net and enter in just that one entry? 45701 13 2 qwertyE to the DS in domain reg? and we have been upload both all this years was wrong ? way we been do it is instruction from wiki in full, more or less which I guess worked back in the day, dnssec-keygen -r /dev/urandom -a rsasha1 -b 1024 -K keys/ -n ZONE foo.net dnssec-keygen -r /dev/urandom -a rsasha1 -b 4096 -K keys/ -n ZONE -f KSK foo.net add into zone file $INCLUDE keys/Kfoo.net.+005+6341.key $INCLUDE keys/Kfoo.net.+005+9847.key dnssec-signzone -a -e +9590400 -K keys/ -N INCREMENT foo.net rndc stuff then get DS and add both info registrar from dig (like above) foo.net. IN DS 1234 5 1 . foo.net. IN DS 1234 5 2 . which stretch memory back to 2012 domain registrasr wanted both hrmm, now I start to understand why not many use DNSSEC so confusing to those who not do this every day, or so many instructions around nobody knows what works But we getting there :-> On Sat, May 1, 2021 at 8:25 PM Tony Finch wrote: > Edwardo Garcia wrote: > > > One thing I note, all check say everything is good, but when using > dnsviz, > > it says secure, shows the ecd... but also puts up warnings that I am > using > > alg 13 but digest 1 (sha1), which is not allowed, > > I guess the "digest 1" is referring to your DS records. In my guide I > said, get the DS record for the new algorithm like this: > > dnssec-dsfromkey -2 Kbotolph.cam.ac.uk.+013+Y > > The -2 option forces SHA-2 and avoids the deprecated SHA-1 hash. > > Old versions of BIND by default print both SHA1 and SHA2 DS records, and > it's relatively common for zones to have both kinds of DS record in their > delegation. > > SHA1 DS records are now discouraged so it's best to replace them with > SHA2, or just delete them if you have both kinds of DS record. > > Tony. > -- > f.anthony.n.finchhttps://dotat.at/ > harness technological change to human advantage > > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC upgrade
One thing I note, all check say everything is good, but when using dnsviz, it says secure, shows the ecd... but also puts up warnings that I am using alg 13 but digest 1 (sha1), which is not allowed, I never use the setting when create keys as the guide says not needed, if this a problem with them or maybe the .com and .net zones having longer TTL than ours (4 hours), confused, but I am happy enough since verisignlabs says all green ticks On Sat, May 1, 2021 at 4:15 AM Tony Finch wrote: > Edwardo Garcia wrote: > > > > One question however it talk about longest TTL, does this mean also root > > TLD zones (.com, .net) which from memory are 48 hours, so before we > delete > > old keys we need wait 48 hours, even though our zone TTL was 24 ? > > When you are waiting after adding and signing with the new keys and before > swapping the DS records, it's only the longest TTL in your own zone that > matters. In my notes I call this the "child TTL" because the root and TLD > etc. don't matter. > > https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html > > When you're waiting for the DS TTL it's only the TTL of that particular > record that matters. (It's in the parent zone so I called it the parent > TTL.) To be sure you are getting the right number you will need something > like: > > dig +ttlunits example.com ds @$(dig +short com ns | head -1) > > i.e. pick one of the nameservers of the parent zone and ask it for your > zone's DS record, so you don't get mislead by decremented cached TTLs. > Note the DS TTL is often not the same as the parent NS or glue TTL. > > > Thank you, wow much much easy than I hoped for :-) > > I'm happy it helped! > > Tony. > -- > f.anthony.n.finchhttps://dotat.at/ > Biscay: North, backing northwest later, 2 to 4, occasionally 5 later > in east. Slight. Showers. Good. > > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC upgrade
Halo Tony, Thank you, wow ecdsa-p256-sha256 produce keys 1/10th the size of rsa, strange how this better but we have made change as from your howto, thank you, now 24 hour and all seems ok from what we tell, and the test site says all good. One question however it talk about longest TTL, does this mean also root TLD zones (.com, .net) which from memory are 48 hours, so before we delete old keys we need wait 48 hours, even though our zone TTL was 24 ? Thank you, wow much much easy than I hoped for :-) On Wed, Apr 28, 2021 at 12:08 PM Tony Finch wrote: > Edwardo Garcia wrote: > > > > Many year ago we set up DNSSEC, our key were generated with sha1 as was > > recommended way back all them years. We too are not DNSSEC guru, so some > > answer may be simple > > Well, you are going to do an algorithm rollover, which is one of the more > tricky things you can do with DNSSEC. So, plan to do some testing, a trial > run, with a spare zone that you can break without worrying. > > If you like to understand things by getting an idea of the wider context > then there are a couple of RFCs on the general subject of key rollovers. > The parts that are most relevant are the algorithm rollover section in RFC > 6781 and the double-KSK section in RFC 7583. > > https://tools.ietf.org/html/rfc6781 > https://tools.ietf.org/html/rfc7583 > > DNSSEC has got easier since those RFCs were written, so you might as well > just skip to the howto bits below :-) It turns out, I wrote most of this > reply over a year ago... > > > Also we use ZSK -b 1024 and KSK -b 4096 > > even modern google from apnic show example ZSK of only 1024? is this > still > > secure? > > The current recommendation for DNSSEC algorithms is: > > * you already know you want to choose something based on sha256 - it's > secure enough, so there's no need for bigger hashes > > * ecdsa-p256-sha256 (13) is the best choice, because it is widely > supported and produces small signatures > > * if you must use RSA, use 2048 bit keys for both zsk and ksk. 1024 bits > is not secure; 2048 has a roughly comparable security level to sha256 > (112ish bits vs 128 bits); 4096 is big and slow and probably not worth > the cost > > * I would like to be able to deploy ed25519 (a better elliptic curve > than p256) but it is not yet supported well enough > > > Is best practise for doing this, replacing the keys completely, more or > > less like start fresh again? > > > > We do use inline signing and automatic maintain. > > I did a wholesale algorithm rollover from RSASHA1 to p256 around the end > of 2019 and I wrote an algorithm rollover guide for colleagues in other > parts of our university who run their own DNS. It's basically three steps > with lots of waiting in between: > > https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html > > The "Semi-automated DS updates" section probably isn't relevant to you, > and the "Future" section has been made obsolete by dnssec-policy. But the > rest of it should guide you through the essentials. > > (Also, the RIPE NCC does now support CDS records.) > > And use these DNS checking services to verify that it is working as > expected: > > https://dnsviz.net/ > > https://zonemaster.net/ > > Tony. > -- > f.anthony.n.finchhttps://dotat.at/ > Rattray Head to Berwick upon Tweed: North or northeast 4 or 5, > occasionally 3 later. Slight or moderate. Showers. Good. > > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DNSSEC upgrade
Halo all, Many year ago we set up DNSSEC, our key were generated with sha1 as was recommended way back all them years. We too are not DNSSEC guru, so some answer may be simple Now we want to upsecure this to sha256. Also we use ZSK -b 1024 and KSK -b 4096 even modern google from apnic show example ZSK of only 1024? is this still secure? Is best practise for doing this, replacing the keys completely, more or less like start fresh again? We do use inline signing and automatic maintain. I see 9.16 make it easy by not needing do anything but set policy, but we are stuck on 9.14 for time being. I am ok with wiping DS, keys everything and start fresh if that is easiest, unless there is another simple way? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dns cache issue
OK, so this happen again, with link congestion.
bind is caching the results as tested with no congestion, 78ms down to
1ms... BUT the issue with bind remain and logs show nothing wrong
congested link lookup , tried in instant succession with a second or less
between:
google.com (like any other host I try) timeout no servers can be reached
lookup internal zone I added to bind, replies with 7ms
retry google and few other sites again, all timeout no servers can be
reached
(google may only have 5min TTL but other domains i'm testing, including
mail provider etc, is 1 day.
ping to DNS box is quick
ping to other boxes is quick too
disconnect windows updating pc, and google et al respond with 1ms so it
obviously is in the bloody cache but because bind cant do something with
internet in a timely manor it just spits dummy
Why bind do this if it should already know the answer, it should give
answer, since it holds the record, just as it knows the internal test zone.
this all cause mail to fail, web browsing to fail, boss not happy.
On Fri, Jan 11, 2019 at 9:27 AM Edwardo Garcia wrote:
> Kevin,
> I though lan saturation too, but I can ssh into bind server immediately, I
> also, from my other pc did a lookup on local authoritative zone rpz.lan, so
> my bind replying right away or within 1 second during congestion, could it
> be dnssec the problem, I did not disable that to test, it really is like it
> is not caching any external results so maybe it needs to go out and do all
> lookups again to make sure signature valid? I really don't know. I'm now
> guessing.
>
> I will try your suggestion of logging again, and as for link local, yes,
> couple of years ago we saw problems
>
> ed
>
> On Fri, Jan 11, 2019 at 1:17 AM Kevin Darcy
> wrote:
>
>> Offhand, sounds like your LAN is saturated so the queries might not be
>> getting to BIND in the first place. Or the replies aren't getting back.
>> It's unlikely that QoS is going to help this, you indicated that QoS was on
>> your "router", and that is typical -- usually QoS is found on WAN links.
>> (Although, on the other hand, you mentioned VoIP, and VoIP sometimes
>> requires applying QoS at the LAN level too).
>>
>> You currently have query logging turned off. If it's not too
>> resource-intensive, you might want to consider turning that on, to verify
>> whether the queries are getting to BIND. Or, run a packet capture on the
>> BIND side. Packet capture on the BIND device should also help to identify
>> any issues talking upstream (e.g. to TLD servers or auth servers for
>> domains like google.com). Packet capture on the *client* side would
>> probably be necessary for definitive proof of whether replies are being
>> dropped by the LAN (compare what the server sent side-by-side with what the
>> client saw).
>>
>> I was intrigued by "server fe80::/16 { bogus yes; }; " in your config.
>> Have you had issues with IPv6 link-local addresses being associated with
>> delegated nameservers? I haven't noticed this, but then again, I haven't
>> been looking for that particular misconfiguration specifically...
>>
>>
>> - Kevin
>>
>>
>>
>> On Thu, Jan 10, 2019 at 12:06 AM Edwardo Garcia
>> wrote:
>>
>>> With new windows update last day, we notice something strange, our local
>>> DNS cache server timeout on lookups.
>>>
>>> For example lookup google.com, 1 minute later fails timeout looking up,
>>> but since it has already looked it up it should have returned answer from
>>> cache yes? google has a 5min TTL, my cache doesnt cacher it for even 1ns
>>> it seems
>>>
>>> QoS on router gives DNS (udp and tcp)and VoIP highest priority,
>>> everything else is default QoS must be working because if I do
>>> host www.google.com $externalDNSserver I get an answer pretty much
>>> right away, immediately try again on our local dns server it times out
>>> cant connect to any servers.
>>> this contrinues on, if I drop the LAN port on switch the windows update
>>> machine uses, it resolves google.com again, bring back up that port,
>>> it times out again.
>>>
>>> this only happens on congestion, with our cable link maxed out.
>>>
>>> (never thought i'd see the day when a windows pc would take out an
>>> entire network)
>>>
>>> Below is my named.conf I have to be missing something ?
>>>
>>> BIND 9.11.2-P1
>>> running on Linux i686 3.16.58 #1 SMP Sat Sep 29 11:06:24 AEST 2018
>>> built by make with defaults
>>>
>>> acl "trusted&q
Re: dns cache issue
Kevin,
I though lan saturation too, but I can ssh into bind server immediately, I
also, from my other pc did a lookup on local authoritative zone rpz.lan, so
my bind replying right away or within 1 second during congestion, could it
be dnssec the problem, I did not disable that to test, it really is like it
is not caching any external results so maybe it needs to go out and do all
lookups again to make sure signature valid? I really don't know. I'm now
guessing.
I will try your suggestion of logging again, and as for link local, yes,
couple of years ago we saw problems
ed
On Fri, Jan 11, 2019 at 1:17 AM Kevin Darcy
wrote:
> Offhand, sounds like your LAN is saturated so the queries might not be
> getting to BIND in the first place. Or the replies aren't getting back.
> It's unlikely that QoS is going to help this, you indicated that QoS was on
> your "router", and that is typical -- usually QoS is found on WAN links.
> (Although, on the other hand, you mentioned VoIP, and VoIP sometimes
> requires applying QoS at the LAN level too).
>
> You currently have query logging turned off. If it's not too
> resource-intensive, you might want to consider turning that on, to verify
> whether the queries are getting to BIND. Or, run a packet capture on the
> BIND side. Packet capture on the BIND device should also help to identify
> any issues talking upstream (e.g. to TLD servers or auth servers for
> domains like google.com). Packet capture on the *client* side would
> probably be necessary for definitive proof of whether replies are being
> dropped by the LAN (compare what the server sent side-by-side with what the
> client saw).
>
> I was intrigued by "server fe80::/16 { bogus yes; }; " in your config.
> Have you had issues with IPv6 link-local addresses being associated with
> delegated nameservers? I haven't noticed this, but then again, I haven't
> been looking for that particular misconfiguration specifically...
>
>
> - Kevin
>
>
>
> On Thu, Jan 10, 2019 at 12:06 AM Edwardo Garcia
> wrote:
>
>> With new windows update last day, we notice something strange, our local
>> DNS cache server timeout on lookups.
>>
>> For example lookup google.com, 1 minute later fails timeout looking up,
>> but since it has already looked it up it should have returned answer from
>> cache yes? google has a 5min TTL, my cache doesnt cacher it for even 1ns
>> it seems
>>
>> QoS on router gives DNS (udp and tcp)and VoIP highest priority,
>> everything else is default QoS must be working because if I do
>> host www.google.com $externalDNSserver I get an answer pretty much
>> right away, immediately try again on our local dns server it times out
>> cant connect to any servers.
>> this contrinues on, if I drop the LAN port on switch the windows update
>> machine uses, it resolves google.com again, bring back up that port, it
>> times out again.
>>
>> this only happens on congestion, with our cable link maxed out.
>>
>> (never thought i'd see the day when a windows pc would take out an entire
>> network)
>>
>> Below is my named.conf I have to be missing something ?
>>
>> BIND 9.11.2-P1
>> running on Linux i686 3.16.58 #1 SMP Sat Sep 29 11:06:24 AEST 2018
>> built by make with defaults
>>
>> acl "trusted" { localhost; 198.162.100.0/24; };
>> acl "sysop" { localhost; 192.168.100.6; };
>>
>> options {
>> directory "/var/named";
>> allow-query { trusted; };
>> allow-query-cache { trusted; };
>> allow-transfer { sysop; };
>> transfer-format many-answers;
>> masterfile-format text;
>> interface-interval 0;
>> response-policy {zone "rpz.lan"; };
>> dnssec-enable yes;
>> dnssec-validation auto;
>> empty-zones-enable yes;
>> };
>>
>> server fe80::/16 { bogus yes; };
>>
>> logging {
>> category lame-servers { null; };
>> category edns-disabled { null; };
>> category client { null; };
>> category dnssec { null; };
>> //channel log_queries { file "/var/named/query.log";
>> print-category yes; };
>> //category queries { log_queries; };
>> channel log-rpz { file "/var/log/rpz.log" versions 10 25m;
>> severity info; };
>> category rpz { log-rpz; };
>> };
>>
>> zone "." {
>> type hint;
>> file "root.cache";
>>
>> zone "rpz.lan" {
>> type master;
dns cache issue
With new windows update last day, we notice something strange, our local
DNS cache server timeout on lookups.
For example lookup google.com, 1 minute later fails timeout looking up, but
since it has already looked it up it should have returned answer from cache
yes? google has a 5min TTL, my cache doesnt cacher it for even 1ns it seems
QoS on router gives DNS (udp and tcp)and VoIP highest priority, everything
else is default QoS must be working because if I do
host www.google.com $externalDNSserver I get an answer pretty much right
away, immediately try again on our local dns server it times out cant
connect to any servers.
this contrinues on, if I drop the LAN port on switch the windows update
machine uses, it resolves google.com again, bring back up that port, it
times out again.
this only happens on congestion, with our cable link maxed out.
(never thought i'd see the day when a windows pc would take out an entire
network)
Below is my named.conf I have to be missing something ?
BIND 9.11.2-P1
running on Linux i686 3.16.58 #1 SMP Sat Sep 29 11:06:24 AEST 2018
built by make with defaults
acl "trusted" { localhost; 198.162.100.0/24; };
acl "sysop" { localhost; 192.168.100.6; };
options {
directory "/var/named";
allow-query { trusted; };
allow-query-cache { trusted; };
allow-transfer { sysop; };
transfer-format many-answers;
masterfile-format text;
interface-interval 0;
response-policy {zone "rpz.lan"; };
dnssec-enable yes;
dnssec-validation auto;
empty-zones-enable yes;
};
server fe80::/16 { bogus yes; };
logging {
category lame-servers { null; };
category edns-disabled { null; };
category client { null; };
category dnssec { null; };
//channel log_queries { file "/var/named/query.log";
print-category yes; };
//category queries { log_queries; };
channel log-rpz { file "/var/log/rpz.log" versions 10 25m; severity
info; };
category rpz { log-rpz; };
};
zone "." {
type hint;
file "root.cache";
zone "rpz.lan" {
type master;
file "rpz.lan";
allow-query { trusted; };
allow-update {none;};
notify no;
};
zone "akamai.net" {
type forward;
forward first;
forwarders { xx; xx; };
};
___
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 (re)signing and journaling
Ok, thanks.
On Fri, Dec 14, 2018 at 11:16 AM Mark Andrews wrote:
> inline-signing is optional. It all depends on how you want to maintain
> the zone.
>
> I prefer doing all the changed over nsupdate. Not editing the master file
> by hand
> removes a set of operator errors.
>
> Mark
>
> > On 14 Dec 2018, at 12:07 pm, Edwardo Garcia wrote:
> >
> > Yes, I did.
> >key-directory "keys/";
> >inline-signing yes; <- is this not required ?
> > auto-dnssec maintain;
> >
> >
> > On Fri, Dec 14, 2018 at 11:05 AM Mark Andrews wrote:
> > Sounds like you added inline-signing yes;
> >
> > > On 14 Dec 2018, at 12:02 pm, Edwardo Garcia
> wrote:
> > >
> > > I have answered my own Question, yes it does, thank you! (after
> removing the .signed in named,conf, else auto signing does
> .signed.signed :-)
> > >
> > > Thank you Mark!
> > >
> > > On Fri, Dec 14, 2018 at 10:50 AM Edwardo Garcia
> wrote:
> > > That seems simpler than what we once tried, OK we add that now. Thanks.
> > >
> > > And if we need to modify the zone file itself to make a change, rndc
> reload will do all this or do we need to
> > > dnssec-signzone -a -e +secondshere -K keys/ -N INCREMENT xxx.com
> freeze/thaw? etc like for new zone?
> > >
> > > On Fri, Dec 14, 2018 at 10:42 AM Mark Andrews wrote:
> > > auto-dnssec maintain;
> > >
> > > > On 14 Dec 2018, at 11:39 am, Edwardo Garcia
> wrote:
> > > >
> > > >
> > > > zone ".com" {
> > > > type master;
> > > > allow-transfer { sysops; slaves; };
> > > > file "xx.signed";
> > > > allow-query { any; };
> > > > allow-update { key "corp"; };
> > > > };
> > > >
> > > > This is what we use now, so by dynamic update we are doing yes?
> > > >
> > > > And now we need just have named do automatic (re)signing?
> > > > Last time we tried, we kept killing our domain so google fail us,
> do you know of a valid reference URL that is clear? that would be good?
> > > > Thanks
> > > >
> > > > On Fri, Dec 14, 2018 at 10:24 AM Mark Andrews wrote:
> > > > The best way is to configure you zone for dynamic updates and let
> named
> > > > automatically resign the zone as needed.
> > > >
> > > > > On 14 Dec 2018, at 11:13 am, Edwardo Garcia
> wrote:
> > > > >
> > > > > Hi,
> > > > > What is the best practice for signing/re-singing zones with
> journal?
> > > > >
> > > > > We manually resign our domain, and use journaling, resigning is a
> PIA.
> > > > > if we forget to thaw, the zone bails and stays unloaded because
> journal roll forward error, which bring the question why? since resolution
> to this is stop named, remove journal file and restart, could named and
> rndc not be smarter in these instance? or at very least, reload zone from
> file so at least it does not take unsuspecting peoples off air.
> > > > >
> > > > > So, way we (try to remember to) do is:
> > > > > (modify zonefile if need)
> > > > > rndc freeze
> > > > > dnssec-signzone -options
> > > > > rndc thaw
> > > > >
> > > > > or is better way? it is the freeze/thaw we keep forgetting :-!
> > > > >
> > > > > ___
> > > > > 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
> > > >
> > > > --
> > > > Mark Andrews, ISC
> > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > > > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> > > >
> > >
> > > --
> > > Mark Andrews, ISC
> > > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> > >
> >
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> >
>
> --
> 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: dnssec (re)signing and journaling
Yes, I did.
key-directory "keys/";
inline-signing yes; <- is this not required ?
auto-dnssec maintain;
On Fri, Dec 14, 2018 at 11:05 AM Mark Andrews wrote:
> Sounds like you added inline-signing yes;
>
> > On 14 Dec 2018, at 12:02 pm, Edwardo Garcia wrote:
> >
> > I have answered my own Question, yes it does, thank you! (after removing
> the .signed in named,conf, else auto signing does .signed.signed
> :-)
> >
> > Thank you Mark!
> >
> > On Fri, Dec 14, 2018 at 10:50 AM Edwardo Garcia
> wrote:
> > That seems simpler than what we once tried, OK we add that now. Thanks.
> >
> > And if we need to modify the zone file itself to make a change, rndc
> reload will do all this or do we need to
> > dnssec-signzone -a -e +secondshere -K keys/ -N INCREMENT xxx.com
> freeze/thaw? etc like for new zone?
> >
> > On Fri, Dec 14, 2018 at 10:42 AM Mark Andrews wrote:
> > auto-dnssec maintain;
> >
> > > On 14 Dec 2018, at 11:39 am, Edwardo Garcia
> wrote:
> > >
> > >
> > > zone ".com" {
> > > type master;
> > > allow-transfer { sysops; slaves; };
> > > file "xx.signed";
> > > allow-query { any; };
> > > allow-update { key "corp"; };
> > > };
> > >
> > > This is what we use now, so by dynamic update we are doing yes?
> > >
> > > And now we need just have named do automatic (re)signing?
> > > Last time we tried, we kept killing our domain so google fail us, do
> you know of a valid reference URL that is clear? that would be good?
> > > Thanks
> > >
> > > On Fri, Dec 14, 2018 at 10:24 AM Mark Andrews wrote:
> > > The best way is to configure you zone for dynamic updates and let named
> > > automatically resign the zone as needed.
> > >
> > > > On 14 Dec 2018, at 11:13 am, Edwardo Garcia
> wrote:
> > > >
> > > > Hi,
> > > > What is the best practice for signing/re-singing zones with journal?
> > > >
> > > > We manually resign our domain, and use journaling, resigning is a
> PIA.
> > > > if we forget to thaw, the zone bails and stays unloaded because
> journal roll forward error, which bring the question why? since resolution
> to this is stop named, remove journal file and restart, could named and
> rndc not be smarter in these instance? or at very least, reload zone from
> file so at least it does not take unsuspecting peoples off air.
> > > >
> > > > So, way we (try to remember to) do is:
> > > > (modify zonefile if need)
> > > > rndc freeze
> > > > dnssec-signzone -options
> > > > rndc thaw
> > > >
> > > > or is better way? it is the freeze/thaw we keep forgetting :-!
> > > >
> > > > ___
> > > > 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
> > >
> > > --
> > > Mark Andrews, ISC
> > > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> > >
> >
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> >
>
> --
> 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: dnssec (re)signing and journaling
I have answered my own Question, yes it does, thank you! (after removing
the .signed in named,conf, else auto signing does .signed.signed
:-)
Thank you Mark!
On Fri, Dec 14, 2018 at 10:50 AM Edwardo Garcia wrote:
> That seems simpler than what we once tried, OK we add that now. Thanks.
>
> And if we need to modify the zone file itself to make a change, rndc
> reload will do all this or do we need to
> dnssec-signzone -a -e +secondshere -K keys/ -N INCREMENT xxx.com
> freeze/thaw? etc like for new zone?
>
> On Fri, Dec 14, 2018 at 10:42 AM Mark Andrews wrote:
>
>> auto-dnssec maintain;
>>
>> > On 14 Dec 2018, at 11:39 am, Edwardo Garcia wrote:
>> >
>> >
>> > zone ".com" {
>> > type master;
>> > allow-transfer { sysops; slaves; };
>> > file "xx.signed";
>> > allow-query { any; };
>> > allow-update { key "corp"; };
>> > };
>> >
>> > This is what we use now, so by dynamic update we are doing yes?
>> >
>> > And now we need just have named do automatic (re)signing?
>> > Last time we tried, we kept killing our domain so google fail us, do
>> you know of a valid reference URL that is clear? that would be good?
>> > Thanks
>> >
>> > On Fri, Dec 14, 2018 at 10:24 AM Mark Andrews wrote:
>> > The best way is to configure you zone for dynamic updates and let named
>> > automatically resign the zone as needed.
>> >
>> > > On 14 Dec 2018, at 11:13 am, Edwardo Garcia
>> wrote:
>> > >
>> > > Hi,
>> > > What is the best practice for signing/re-singing zones with journal?
>> > >
>> > > We manually resign our domain, and use journaling, resigning is a
>> PIA.
>> > > if we forget to thaw, the zone bails and stays unloaded because
>> journal roll forward error, which bring the question why? since resolution
>> to this is stop named, remove journal file and restart, could named and
>> rndc not be smarter in these instance? or at very least, reload zone from
>> file so at least it does not take unsuspecting peoples off air.
>> > >
>> > > So, way we (try to remember to) do is:
>> > > (modify zonefile if need)
>> > > rndc freeze
>> > > dnssec-signzone -options
>> > > rndc thaw
>> > >
>> > > or is better way? it is the freeze/thaw we keep forgetting :-!
>> > >
>> > > ___
>> > > 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
>> >
>> > --
>> > Mark Andrews, ISC
>> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>> >
>>
>> --
>> 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: dnssec (re)signing and journaling
That seems simpler than what we once tried, OK we add that now. Thanks.
And if we need to modify the zone file itself to make a change, rndc reload
will do all this or do we need to
dnssec-signzone -a -e +secondshere -K keys/ -N INCREMENT xxx.com
freeze/thaw? etc like for new zone?
On Fri, Dec 14, 2018 at 10:42 AM Mark Andrews wrote:
> auto-dnssec maintain;
>
> > On 14 Dec 2018, at 11:39 am, Edwardo Garcia wrote:
> >
> >
> > zone ".com" {
> > type master;
> > allow-transfer { sysops; slaves; };
> > file "xx.signed";
> > allow-query { any; };
> > allow-update { key "corp"; };
> > };
> >
> > This is what we use now, so by dynamic update we are doing yes?
> >
> > And now we need just have named do automatic (re)signing?
> > Last time we tried, we kept killing our domain so google fail us, do
> you know of a valid reference URL that is clear? that would be good?
> > Thanks
> >
> > On Fri, Dec 14, 2018 at 10:24 AM Mark Andrews wrote:
> > The best way is to configure you zone for dynamic updates and let named
> > automatically resign the zone as needed.
> >
> > > On 14 Dec 2018, at 11:13 am, Edwardo Garcia
> wrote:
> > >
> > > Hi,
> > > What is the best practice for signing/re-singing zones with journal?
> > >
> > > We manually resign our domain, and use journaling, resigning is a PIA.
> > > if we forget to thaw, the zone bails and stays unloaded because
> journal roll forward error, which bring the question why? since resolution
> to this is stop named, remove journal file and restart, could named and
> rndc not be smarter in these instance? or at very least, reload zone from
> file so at least it does not take unsuspecting peoples off air.
> > >
> > > So, way we (try to remember to) do is:
> > > (modify zonefile if need)
> > > rndc freeze
> > > dnssec-signzone -options
> > > rndc thaw
> > >
> > > or is better way? it is the freeze/thaw we keep forgetting :-!
> > >
> > > ___
> > > 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
> >
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> >
>
> --
> 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: dnssec (re)signing and journaling
zone ".com" {
type master;
allow-transfer { sysops; slaves; };
file "xx.signed";
allow-query { any; };
allow-update { key "corp"; };
};
This is what we use now, so by dynamic update we are doing yes?
And now we need just have named do automatic (re)signing?
Last time we tried, we kept killing our domain so google fail us, do you
know of a valid reference URL that is clear? that would be good?
Thanks
On Fri, Dec 14, 2018 at 10:24 AM Mark Andrews wrote:
> The best way is to configure you zone for dynamic updates and let named
> automatically resign the zone as needed.
>
> > On 14 Dec 2018, at 11:13 am, Edwardo Garcia wrote:
> >
> > Hi,
> > What is the best practice for signing/re-singing zones with journal?
> >
> > We manually resign our domain, and use journaling, resigning is a PIA.
> > if we forget to thaw, the zone bails and stays unloaded because journal
> roll forward error, which bring the question why? since resolution to this
> is stop named, remove journal file and restart, could named and rndc not be
> smarter in these instance? or at very least, reload zone from file so at
> least it does not take unsuspecting peoples off air.
> >
> > So, way we (try to remember to) do is:
> > (modify zonefile if need)
> > rndc freeze
> > dnssec-signzone -options
> > rndc thaw
> >
> > or is better way? it is the freeze/thaw we keep forgetting :-!
> >
> > ___
> > 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
>
> --
> 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
dnssec (re)signing and journaling
Hi, What is the best practice for signing/re-singing zones with journal? We manually resign our domain, and use journaling, resigning is a PIA. if we forget to thaw, the zone bails and stays unloaded because journal roll forward error, which bring the question why? since resolution to this is stop named, remove journal file and restart, could named and rndc not be smarter in these instance? or at very least, reload zone from file so at least it does not take unsuspecting peoples off air. So, way we (try to remember to) do is: (modify zonefile if need) rndc freeze dnssec-signzone -options rndc thaw or is better way? it is the freeze/thaw we keep forgetting :-! ___ 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: fe80 errors - thousands
Halo, I do not sorry, there no indication in log as who, but enter server bogus command as Noel reply seem to fix, no more messages since. On Wed, Jun 11, 2014 at 7:06 AM, Rick Jasper rjas...@infoblox.com wrote: Just curious. Do you know what query to which nameserver is returning that bogus fe80:: IP address? ___ 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
fe80 errors - thousands
Halo, in recent week we have see fill daemon_log of this errors, is way to fix? I do wrong? socket.c:5367: unexpected error: Jun 2 05:43:53 korali named[2951]: connect(fe80::#53) 22/Invalid argument ___ 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
