How to prepublish additional DNSKEY

2020-07-08 Thread Klaus Darilion
Hello all!

A signed zone shall be moved to another DNS provider. Hence I want to add the 
public KSK of the gaining DNS provider as additional DNSKEY to the zone. My 
setup ist:

Bind1 as hidden primary --> Bind2 as bump-in-the-wire signer -> public facing 
secondaries

I tried to add the DNSKEY to the zone file of Bind1. Bind1 accepts the DNSKEY. 
But Bind2 only shows the DNSKEYs from the local key-directory, the original 
DNSKEY is removed/ignored.

I also tried to add the additonal DNSKEY into the key-directory of Bind2 (no 
.private file, only .key file). It did not worked too.

So, how is the correct process to add an additional DNSKEY (only the public key 
is known).

Thanks
Klaus

___
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


Bind 9.16.x won't start from systemd

2020-07-08 Thread Adrian van Bloois
Hi,
When I try to start bind 9.16.x from systemd it fails not being able to
find something. When I start it straight from the CMD-line like:
sudo  /usr/local/sbin/named
There is no problem and it works fine.
What could be the problem???

Adrian




-- 
Adri P. van Bloois


   "The greatest threat to our planet is the belief that someone else
   will save it."
Robert Swan.
___
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: Bind 9.16.x won't start from systemd

2020-07-08 Thread G.W. Haywood via bind-users

Hi there,

On Wed, 8 Jul 2020, Adrian van Bloois wrote:


When I try to start bind 9.16.x from systemd it fails not being able to
find something. When I start it straight from the CMD-line like:
sudo  /usr/local/sbin/named
There is no problem and it works fine.
What could be the problem???


systemd.

--

73,
Ged.
___
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: Bind 9.16.x won't start from systemd

2020-07-08 Thread Ondřej Surý
Adrian,

your email didn’t contain any useful information we can go by.  It’s hard to 
debug anything
by just going „fails not being able to find something“. You will have to 
provide the list with
the logs, etc. if you want people to actually provide helpful advices.


And Ged, could we please keep the noise to minimum to the list?  Your email was 
not helpful,
so I would appreciate if you could cut the trolling on the list to the minimum.

Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org

> On 8 Jul 2020, at 13:29, G.W. Haywood via bind-users 
>  wrote:
> 
> Hi there,
> 
> On Wed, 8 Jul 2020, Adrian van Bloois wrote:
> 
>> When I try to start bind 9.16.x from systemd it fails not being able to
>> find something. When I start it straight from the CMD-line like:
>> sudo  /usr/local/sbin/named
>> There is no problem and it works fine.
>> What could be the problem???
> 
> systemd.
> 
> --
> 
> 73,
> Ged.
> ___
> 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



signature.asc
Description: Message signed with OpenPGP
___
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: How to prepublish additional DNSKEY

2020-07-08 Thread Tony Finch
Klaus Darilion  wrote:
>
> A signed zone shall be moved to another DNS provider. Hence I want to
> add the public KSK of the gaining DNS provider as additional DNSKEY to
> the zone.

I guess you might already have seen this draft - it discusses long-term
multi-provider setups rather than transitional ones, so it isn't direcly
on point, but it still has some useful ideas.

https://tools.ietf.org/html/draft-ietf-dnsop-multi-provider-dnssec

> So, how is the correct process to add an additional DNSKEY (only the public 
> key is known).

I think you are looking for `dnssec-importkey`.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Viking, North Utsire, South Utsire, Northeast Forties: Northwesterly 4 to 6,
becoming variable 2 to 4 except in South Utsire. 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


Re: Bind 9.16.x won't start from systemd

2020-07-08 Thread @lbutlr
On 08 Jul 2020, at 05:03, Adrian van Bloois  wrote:
> When I try to start bind 9.16.x from systemd it fails not being able to
> find something.

… 

> What could be the problem???

Not really possible to guess without the error message.


-- 
"Are you pondering what I'm pondering?"
"I think so, Brain, but would Danish flies work just as well?"

___
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_RRL_MAX_RATE defines 1000

2020-07-08 Thread Tony Finch
程智勇  wrote:
>
> So could anybody tell me why DNS_RRL_MAX_RATE defined 1000?

RRL is designed for authoritative DNS servers. Legitimate queries come
from recursive resolvers with caches. There should not be more than one
query for each RRset from each resolver per TTL. So a normal response rate
limit is relatively small - I set it to 10.

If you are hitting 1000 queries per second, that implies either there
are 1000 resolvers behind one IP address (which is VERY unlikely); or the
query traffic is abusive.

Are you sure the dropped traffic is legitimate?

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Channel Islands: West to southwest 4 to 5, occasionally 6 mid-channel
overnight and Thursday morning, occasionally west to northwest 2 to 4 in the
far south of the area. Slight to moderate with a low swell, perhaps
occasionally rather rough mid-channel until late morning. Occasional mist and
fog, especially overnight rain and drizzle at times, especially from Thursday
morning. Moderate to poor or very poor, locally good at times.___
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: How to prepublish additional DNSKEY

2020-07-08 Thread Shumon Huque
On Wed, Jul 8, 2020 at 11:33 AM Tony Finch  wrote:

> Klaus Darilion  wrote:
> >
> > A signed zone shall be moved to another DNS provider. Hence I want to
> > add the public KSK of the gaining DNS provider as additional DNSKEY to
> > the zone.
>
> I guess you might already have seen this draft - it discusses long-term
> multi-provider setups rather than transitional ones, so it isn't direcly
> on point, but it still has some useful ideas.
>
> https://tools.ietf.org/html/draft-ietf-dnsop-multi-provider-dnssec


Thanks for mentioning our draft Tony. The provider handoff case can just
be considered a transitional state of the multi-provider setup, so the same
technique can be applied to Klaus's problem. Klaus's case just needs a
further step of detaching the losing provider later by deleting their ZSK.

Our scheme imports only the ZSK public key rather than the KSK.  I don't
think importing the KSK alone works, because the other provider's data
is signed by their ZSK. I suggest looking at the steps outlined in Model 2,
which is more applicable to the general case of provider transfer.


> > So, how is the correct process to add an additional DNSKEY (only the
> public key is known).
>
> I think you are looking for `dnssec-importkey`.
>

Yes, dnssec-importkey works fine with BIND's auto-dnssec configuration
for this task. If you're signing outside BIND (e.g. with dnssec-signzone), I
assume you can stitch together the DNSKEY RRset with the imported ZSK
manually or with some scripting.

Shumon Huque
___
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: Request for review of performance advice

2020-07-08 Thread John Thurston


On 7/7/2020 5:57 PM, Victoria Risk wrote:
A while ago we created a KB article with tips on how to improve your 
performance with our Kea dhcp server. The tips were fairly obvious to 
our developers and this was pretty successful. We would like to do 
something similar for BIND, provide a dozen or so tips for how to 
maximize your throughput with BIND. However, as usual, everything is 
more complicated with BIND.


This is an excellent idea.

If it comes to fruition, I ask there be some guidance offered on when 
such optimizations are useful. I've seen places where such a guide-sheet 
is followed when the guidelines were suitable for a business with 10X or 
100X the traffic the customer sees.


That is, a configuration which benefits an organization seeing 100,000 
qps may be excessively complex (or brittle) for one seeing 100 qps.


--
Do things because you should, not just because you can.

John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska




Can those of you who care about performance, who have worked to improve 
your performance, share some of your suggestions that have the most 
impact?  Please also comment if you think any of these ideas below are 
stupid or dangerous. I have combined advice for resolvers and for 
authoritative servers, I hope it is clear which is which...


The ideas we have fall into four general categories:

System design
1a) Use a load balancerto specialize your resolvers and maximize your 
cache hit ratio.  A load balancer is traditionally designed to spread 
the traffic out evenly among a pool of servers, but it can also be used 
to concentrate related queries on one server to make its cache as hot as 
possible. For example, if all queries for domains in .info are sent to 
one server in a pool, there is a better chance that an answer will be in 
the cache there.


1b) If you have a large authoritative system with many servers, consider 
dedicating some machines to propagate transfers. These machines, called 
transfer servers, would not answer client queries, but just send 
notifies and process IXFR requests.


1c) Deploy ghost secondaries.  If you store copies of authoritative 
zones on resolvers (resolvers as undelegated secondaries), you can avoid 
querying those authoritative zones. The most obvious uses of this would 
be mirroring the root zone locally or mirroring your own authoritative 
zones on your resolver.


we have other system design ideas that we suspect would help, but we are 
not sure, so I will wait to see if anyone suggests them.


OS settings and the system environment
2a) Run on bare metal if possible, not on virtual machines or in the 
cloud. (any idea how much difference this makes? the only reference we 
can cite is pretty out of date - 
https://indico.dns-oarc.net/event/19/contributions/234/attachments/217/411/DNS_perf_OARC_Apr_14.pdf 
 
)


2b) Consider using with-tuning-large. (https://kb.isc.org/docs/aa-01314 
) 
This is a compile time option, so not something you can switch on and 
off during production.


2c) Consider which R/W lock choice you want to use - 
https://kb.isc.org/docs/choosing-a-read-write-lock-implementation-to-use-with-named 
 
For the highest tested query rates (> 100,000 queries per second), 
pthreads read-write locks with hyper-threading /enabled/seem to be the 
best-performing choice by far.


2d) Pay attention to your choice of NIC cards. We have found wide 
variations in their performance. (Can anyone suggest what specifically 
to look for?)


2e) Make sure your socket send buffers are big enough. (not sure if this 
is obsolete advice, do we need to tell people how to tell if their 
buffers are causing delays?)


2f) When the number of CPUs is very large (32 or more), the increase in 
UDP listeners may not provide any performance improvement and might 
actually reduce throughput slightly due to the overhead of the 
additional structures and tasks. We suggest trying different values of 
-U to find the optimal one for your production environment.



named Features
3a) Minimize logging. Query logging is expensive (can cost you 20% or 
more of your throughput) so don’t do it unless you are using the logs 
for something. Logging with dnstap is lower impact, but still fairly 
expensive. Don’t run in debug mode unless necessary.


3b) Use named.conf option minimal-responses yes; to reduce the amount of 
work that named needs to

Re: Request for review of performance advice

2020-07-08 Thread Chuck Aurora

On 2020-07-07 20:57, Victoria Risk wrote:

A while ago we created a KB article with tips on how to improve your
performance with our Kea dhcp server. The tips were fairly obvious to
our developers and this was pretty successful. We would like to do
something similar for BIND, provide a dozen or so tips for how to
maximize your throughput with BIND. However, as usual, everything is
more complicated with BIND.

[big snip]

Any further suggestions, corrections or warnings are very welcome.


Vicky, I'd suggest separating these performance tips into two separate
articles: authoritative and recursive.  Lumping both together is going
to create more confusion.

___
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_RRL_MAX_RATE defines 1000

2020-07-08 Thread Zhiyong Cheng
Thanks for this reply : )

We are using named cluster in our internal network as the authoritative DNS. So 
there are no cache servers between clients and named cluster. Maybe we should 
add one but it is just another story.

There was a strange thing when I tested RRL using queryperf.  I generated 1 
qnames to test.txt and every qname queried once. The queryperf’s output pastes 
below:

Statistics:

 Parse input file: once
 Ended due to: reaching end of file

 Queries sent: 1 queries
 Queries completed: 9820 queries
 Queries lost: 180 queries
 Queries delayed(?): 0 queries

 RTT max: 0.009435 sec
 RTT min: 0.72 sec
 RTT average: 0.000503 sec
 RTT std deviation: 0.000785 sec
 RTT out of range: 0 queries

 Percentage completed: 98.20%
 Percentage lost: 1.80%

 Started at: Thu Jul 9 11:16:03 2020
 Finished at: Thu Jul 9 11:16:48 2020
 Ran for: 45.300412 seconds

 Queries per second: 216.775070 qps

The named rate-limiting logs pastes below:

09-Jul-2020 11:16:54.055 rate-limit: info: client @0x7f83b44ed190 
10.0.0.10#38722 (anvq.internal): view : rate limit drop all response to 
10.0.0.10/32
09-Jul-2020 11:16:54.055 rate-limit: info: client @0x7f83b4414020 
10.0.0.10#38722 (anwi.internal): view : rate limit drop all response to 
10.0.0.10/32
09-Jul-2020 11:16:54.055 rate-limit: info: client @0x7f83b4518840 
10.0.0.10#38722 (anvf.internal): view : rate limit drop all response to 
10.0.0.10/32
09-Jul-2020 11:16:54.055 rate-limit: info: client @0x7f83b4552680 
10.0.0.10#38722 (anvx.internal): view : rate limit drop all response to 
10.0.0.10/32
09-Jul-2020 11:16:54.055 rate-limit: info: client @0x7f83b44dea00 
10.0.0.10#38722 (anwa.internal): view : rate limit drop all response to 
10.0.0.10/32
09-Jul-2020 11:16:54.055 rate-limit: info: client @0x7f83b4487ca0 
10.0.0.10#38722 (anva.internal): view : rate limit drop all response to 
10.0.0.10/32
09-Jul-2020 11:16:54.055 rate-limit: info: client @0x7f83b4405890 
10.0.0.10#38722 (anwg.internal): view : rate limit drop all response to 
10.0.0.10/32
09-Jul-2020 11:16:54.055 rate-limit: info: client @0x7f83b4526fd0 
10.0.0.10#38722 (anvr.internal): view : rate limit drop all response to 
10.0.0.10/32
09-Jul-2020 11:16:54.055 rate-limit: info: client @0x7f83b446ad80 
10.0.0.10#38722 (anvs.internal): view : rate limit drop all response to 
10.0.0.10/32
09-Jul-2020 11:16:54.055 rate-limit: info: client @0x7f83b4430f40 
10.0.0.10#38722 (anvh.internal): view : rate limit drop all response to 
10.0.0.10/32
09-Jul-2020 11:16:54.055 rate-limit: info: client @0x7f83b44227b0 
10.0.0.10#38722 (anvj.internal): view : rate limit drop all response to 
10.0.0.10/32
09-Jul-2020 11:16:54.055 rate-limit: info: client @0x7f83b450a0b0 
10.0.0.10#38722 (anvm.internal): view : rate limit drop all response to 
10.0.0.10/32
09-Jul-2020 11:16:54.055 rate-limit: info: client @0x7f83b44a4bc0 
10.0.0.10#38722 (anwe.internal): view : rate limit drop all response to 
10.0.0.10/32
09-Jul-2020 11:16:54.055 rate-limit: info: client @0x7f83b4496430 
10.0.0.10#38722 (anwh.internal): view : rate limit drop all response to 
10.0.0.10/32

To my mind the RRL should not limit queries with different qnames from the same 
client. So is it my misunderstanding or wrong config?

BIND version pastes below:

version: BIND 9.11.4-P2 (Extended Support Version) 
在 2020年7月8日 +0800 PM11:45,Tony Finch ,写道:
> 程智勇  wrote:
> >
> > So could anybody tell me why DNS_RRL_MAX_RATE defined 1000?
>
> RRL is designed for authoritative DNS servers. Legitimate queries come
> from recursive resolvers with caches. There should not be more than one
> query for each RRset from each resolver per TTL. So a normal response rate
> limit is relatively small - I set it to 10.
>
> If you are hitting 1000 queries per second, that implies either there
> are 1000 resolvers behind one IP address (which is VERY unlikely); or the
> query traffic is abusive.
>
> Are you sure the dropped traffic is legitimate?
>
> Tony.
> --
> f.anthony.n.finch  http://dotat.at/
> Channel Islands: West to southwest 4 to 5, occasionally 6 mid-channel
> overnight and Thursday morning, occasionally west to northwest 2 to 4 in the
> far south of the area. Slight to moderate with a low swell, perhaps
> occasionally rather rough mid-channel until late morning. Occasional mist and
> fog, especially overnight rain and drizzle at times, especially from Thursday
> morning. Moderate to poor or very poor, locally good at times.
___
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