Re: queries for external hostnames inside my domain?

[Browne, Stuart via bind-users]

You might want to look at the requestor machine's "search" domains.

If the stub resolver starts appending search domains when it doesn't get a 
response it can use.

Stuart 

On 8/9/20, 09:51, "bind-users on behalf of L. A. Walsh" 
 wrote:

Notice: This email is from an external sender.



On 9/7/2020 4:03 PM, Greg Rivers wrote:
> On Monday, 7 September 2020 17:46:47 CDT L. A. Walsh wrote:
>> First I'll see some server name:
>>
>> 05-Sep-2020 15:30:23.374 queries: info: client @0x7fbcb804e720
>> 127.0.0.1#36542 (PeerSrv.org): view internal: query: PeerSrv.org IN 
>> + (127.0.0.1)
>>
>> followed by a 2nd one:
>>
>> 05-Sep-2020 15:30:24.316 queries: info: client @0x7fbce40d5100
>> 127.0.0.1#36542 (PeerSrv.org.internal.Tlinx.org): view internal:
>> query:PeerSrv.org.internal.Tlinx.org IN  + (127.0.0.1)
>>
>> Where internal is a subdomain within tlinx.org.
>>
>> wondering why I
>> see a 2nd lookup with the query looking for the domain inside my internal
>> domain.
>>
>> Anyone seen this behavior before?
>>
>> It probably doesn't add up to even 1% of my lookups, but I am
>> curious.
>>
> Those are not "IPv6 queries", they are queries over IPv4 for  
records, -

Good point -- even as I asked that I had something like that scratching
on the inside of my head that I didn't quite remember or get.  That
makes sense.

I know the other comes from inside my dom as well, but why the
ipv6 queries generate both an absolute query (from dns-root), and a
relative query inside my domain?  When I look at it, I can tell
it looks odd and something seems to be looking up external domains from
the internal interface, but what might be causing it to also look for
it in the internal domain?  A program bug?

Thanks!
___
Please visit 
https://urldefense.com/v3/__https://lists.isc.org/mailman/listinfo/bind-users__;!!N14HnBHF!vysYKWt_ec-btTnWt9H139TT3Kad4eUDbDHXLUG5DomMtkcukRYVVT6ckw8DzCt-sNgqYVQ$
  to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at 
https://urldefense.com/v3/__https://www.isc.org/contact/__;!!N14HnBHF!vysYKWt_ec-btTnWt9H139TT3Kad4eUDbDHXLUG5DomMtkcukRYVVT6ckw8DzCt-nD1Yklc$
  for more information.


bind-users mailing list
bind-users@lists.isc.org

https://urldefense.com/v3/__https://lists.isc.org/mailman/listinfo/bind-users__;!!N14HnBHF!vysYKWt_ec-btTnWt9H139TT3Kad4eUDbDHXLUG5DomMtkcukRYVVT6ckw8DzCt-sNgqYVQ$


___
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

[Browne, Stuart via bind-users]

Just one quick one before I run off to lunch with regards to section 2:

- Try to avoid crossing NUMA boundaries. At high throughput, the context 
switching and far memory calls kills performance.

Stuart

From: bind-users  on behalf of Victoria Risk 

Date: Wednesday, 8 July 2020 at 11:58
To: bind-users 
Subject: Request for review of performance advice

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.

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 balancer to 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://urldefense.com/v3/__https:/indico.dns-oarc.net/event/19/contributions/234/attachments/217/411/DNS_perf_OARC_Apr_14.pdf__;!!N14HnBHF!rk-RfzR0chw8mToGMWAwQAF_WiiXKZM3KXol3WR8YPytPoI_cWyNe5BZ_rsEqdV7T9SIQ1M$
 )

2b) Consider using with-tuning-large. 
(https://urldefense.com/v3/__https:/kb.isc.org/docs/aa-01314__;!!N14HnBHF!rk-RfzR0chw8mToGMWAwQAF_WiiXKZM3KXol3WR8YPytPoI_cWyNe5BZ_rsEqdV7ufSMbnU$)
 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://urldefense.com/v3/__https:/kb.isc.org/docs/choosing-a-read-write-lock-implementation-to-use-with-named__;!!N14HnBHF!rk-RfzR0chw8mToGMWAwQAF_WiiXKZM3KXol3WR8YPytPoI_cWyNe5BZ_rsEqdV7mVVUg4A$
 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 do to assemble the query response as well as reducing the 
amount of outbound traffic


3c) Disable synth-from-dnssec. While this seemed like a good idea, it turns 
out, in practice it does not improve performance.


3d) Tune your zone transfers. 
(https://urldefense.com/v3/__https:/kb.isc.org/docs/aa-00726__;!!N14HnBHF!rk-RfzR0chw8mToGMWAwQAF_WiiXKZM3KXol3WR8YPytPoI_cWyNe5BZ_rsEqdV7K_7-VnQ$)
When tuning the behavior of the primary, there are several factors that you can 
control:
- The rate of notifications of 

Re: DoH plugin for BIND

[Browne, Stuart via bind-users]

On 6/5/20, 02:21, "bind-users on behalf of Chuck Aurora" 
 wrote:

On 2020-05-02 14:35, Reindl Harald wrote:
> Am 02.05.20 um 21:31 schrieb Chuck Aurora:
>> On 2020-05-02 13:23, Erich Eckner wrote:
>>> Will there be client-side DoT/DoH support in bind, too? E.g. will my
>>> recursive (or forwarding) resolver be able to resolve upstream dns 
>>> via
>> 
>> Well, a recursive resolver cannot use DoT/DoH for iterative queries to
>> authoritative NS servers, unless authoritative servers offered 
>> DoT/DoH,
>> and I don't think that's likely to happen.
>> 
>> Basically by deciding you want DoH/DoT upstream, you also have decided
>> that you want to use forwarders.
> 
> says who?
> 
> 
https://urldefense.com/v3/__https://www.cira.ca/newsroom/canadian-shield/cira-launches-canadian-shield-provide-free-privacy-and-security-canadians__;!!N14HnBHF!v42jWsqHVYR66-kDn-I36X0gH8si5RaYdK5EtC2sj_oJv97ch7idccKrJ34oSLUxu9D8ZKU$
 

Thanks for the reply, but FWIW, I don't have a clue what point you
intended to make?  I looked at that CIRA page twice, and it is simply
a DoH/DoT forwarder.  Absolutely nothing in that release mentions any
change in DNS protocol.

DoH/DoT covers only one hop: the end user to the recursive resolver.
Beyond that one hop is good old-fashioned unencrypted DNS.  By using
DoH/DoT, whether in your own stub resolver or in a [future] BIND, you
are using that DoH/DoT server as your forwarder.

>From all the reading I've done, DoT/DoH is about each individual hop. You 
>control your hop. Beyond you, it's anonymized anyway as a batch/bunch of 
>requests from a recursing resolver. The CIRA service is just inserting 
>themselves as the recursing resolver (even if they implement that via an 
>"app").

SMTP encryption is the same. You can control your hop; what anybody beyond you 
does is out of your control.

Stuart

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Bind 9.14 and bind-tools 9.16

[Browne, Stuart via bind-users]

It looks to me as if you are trying to generate a TSIG key for DNS updates. Try 
using "tsig-keygen" instead.

Stuart

> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
> @lbutlr
> Sent: Monday, 2 March 2020 1:13 PM
> To: bind-users
> Subject: Bind 9.14 and bind-tools 9.16
> 
> With my install of bind 9.14 bindtools 9.16.0 was also installed.
> 
> This version is missing some (legacy) algorithms that I am still using on
> my system, specifically hmac-sha256
> 
> dnssec-keygen [options] name
> 
> Version: 9.16.0
> name: owner of the key
> Options:
> -a :
> RSASHA1 | NSEC3RSASHA1 |
> RSASHA256 | RSASHA512 |
> ECDSAP256SHA256 | ECDSAP384SHA384 |
> ED25519 | ED448 | DH
> 
> This is the only version of bind-tools in FreeBSD 12.1 AFAICT.
> 
> I need to generate hmac-sha256 for lets encrypt/dehydrated (at least that
> is what the documentation says).
> 
> dnssec-keygen -a HMAC-SHA512 -b 512 -n HOST -K  _acme-
> challenge. 
> --
> "Are you pondering what I'm pondering?"
> "I think so, Brain, but 'Snowball for Windows’?"
> 
> 
> ___
> Please visit
> https://urldefense.com/v3/__https://lists.isc.org/mailman/listinfo/bind-
> users__;!!N14HnBHF!v5sIUD50pNXv63eja8IZq6Nsp6hrn4TY2GnWaJB6TMF2WQNbTnrP1fC
> u0u1Snq24f4xJl5w$  to unsubscribe from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://urldefense.com/v3/__https://lists.isc.org/mailman/listinfo/bind-
> users__;!!N14HnBHF!v5sIUD50pNXv63eja8IZq6Nsp6hrn4TY2GnWaJB6TMF2WQNbTnrP1fC
> u0u1Snq24f4xJl5w$
___
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 zones not updated

[Browne, Stuart via bind-users]

Sadly, no ideas other than a shared experience. It's not just the Windows 
release nor is it just the 9.14 series of releases; we've been witnessing this 
since the 9.10 releases on Linux (whilst using inline-signing). I don't recall 
off the top of my head if we saw it in the 9.9 series; even for my memory that 
is too many iterations ago.

It isn't a regular occurrence by any means and it is fixed with a service 
restart. Sadly we only see this in our production environment and coupled with 
the time between the occurrence of the issue and the detection of the issue, 
getting decent debugging information has been challenging (which is why we 
haven't done much else about it other than restarting it when we see it occur).

Stuart

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Jukka 
Pakkanen
Sent: Thursday, 23 January 2020 9:41 AM
To: Jukka Pakkanen; bind-us...@isc.org
Subject: VS: DNSSEC zones not updated

Anyone, any ideas?

Lähettäjä: bind-users 
mailto:bind-users-boun...@lists.isc.org>> 
Puolesta Jukka Pakkanen
Lähetetty: 22. tammikuuta 2020 13:30
Vastaanottaja: bind-us...@isc.org
Aihe: Re: DNSSEC zones not updated

And we also get after a change and a reload the "secure_serial: not exact" 
error, of course because the signed zone is not in sync with the non-signed 
anymore. So I guess the question is why it is not signing automatically after 
updates to zone.


Get Outlook for 
Android

From: jukka.pakka...@qnet.fi 
mailto:jukka.pakka...@qnet.fi>>
Sent: Wednesday, January 22, 2020 1:13:11 PM
To: Ondřej Surý mailto:ond...@isc.org>>
Cc: bind-us...@isc.org 
mailto:bind-us...@isc.org>>
Subject: Re: DNSSEC zones not updated

Yed we have quite several times by now  when trying to find the culprit. Also 
the whole windows 2019 server. And it is not only this domain/zone, but all of 
them.
Get Outlook for 
Android


From: Ondřej Surý mailto:ond...@isc.org>>
Sent: Wednesday, January 22, 2020 1:08:22 PM
To: Jukka Pakkanen mailto:jukka.pakka...@qnet.fi>>
Cc: bind-us...@isc.org 
mailto:bind-us...@isc.org>>
Subject: Re: DNSSEC zones not updated

Hi,

did you try stopping BIND, removing journal files and then starting BIND again?

If the signed copy of the zone got corrupted in the memory, you might be 
dumping the corrupted version on disk again with `rndc reload`.

Ondrej
--
Ondřej Surý
ond...@isc.org

> On 22 Jan 2020, at 12:11, Jukka Pakkanen 
> mailto:jukka.pakka...@qnet.fi>> wrote:
>
>
> Running BIND 9.14.9 Windows.   The zone data is not updated for some reason 
> anymore, and same problem in all our signed zones. Example "gemtrade.fi":
>
> zone "gemtrade.fi" {
> type master;
> file "named.gemtrade";
> inline-signing yes;
> auto-dnssec maintain;
> };
>
>
> ;
> ;File: named.gemtrade
> ;
> $TTL 60
> @IN SOAns1.qnet.fi. helpdesk.qnet.fi. (
>   202001234  ; serial number
>   28800  ; refresh every 12 hours
>   7200   ; retry after 2 hours
>   604800 ; expire after 2 weeks
>   33600) ; default ttl is 2 days
> gemtrade.fi.IN A  62.142.217.154
>  IN MX 55 qntsrv8.qnet.fi.
> IN MX 25 qntsrv9.qnet.fi.
>  IN NS ns1.qnet.fi.
>  IN NS ns2.qnet.fi.
>  IN NS ns3.qnet.fi.
> www IN A 62.142.217.154
> _autodiscover._tcp  IN SRV0 5 443 mail.qnet.fi.
> localhost.gemtrade.fi.   IN A  127.0.0.1
>
>
> Used to work fine, now no matter what change I make to the zone file and 
> reload, it does not show up in queries, but the old data, weeks behind.  The 
> SOA & serial numbers *are* updating in the queries, but the actual records 
> not.  Example the MX records, currently I have priorities 55 and 25, still 
> inquiries return the old 20 and 20. Same with any records, the changes does 
> not get updated.
>
> Deleting the .jnl file does not help, after "rndc reload gemtrade.fi" a new 
> .jnl file is created, but queries still return old data.
>
> The named process has all possible rights in the file structure.
>
> What might be wrong?
>
> ___
> Please visit 
> 

RE: BIND and persistent connections

[Browne, Stuart via bind-users]

Not sure if I responded to this last year, but thanks.

Stuart

> -Original Message-
> From: Tony Finch [mailto:d...@dotat.at]
> Sent: Wednesday, 19 December 2018 10:26 PM
> To: Browne, Stuart
> Cc: bind-users@lists.isc.org
> Subject: Re: BIND and persistent connections
> 
> Browne, Stuart via bind-users  wrote:
> >
> > I was wondering if anybody had any thoughts on how to limit the
> > concurrency or at least the lifetime of these persistent connections
> > within BIND.
> 
> If you are running BIND 9.12, you have a bunch of new options related to
> RFC 7827 EDNS TCP keepalive (see below for examples). The timeouts default
> to 30 seconds (same as before the options were added). They also affect
> connections that don't use the EDNS keepalive option.
> 
> I have reduced mine, mainly to reduce the concurrency used by Android
> DNS-over-TLS. (I'm using nginx as a DoT proxy so there's one back-end TCP
> connection per client TLS connection.)
> 
>   tcp-idle-timeout 50; # 5 seconds
>   tcp-initial-timeout 25; # 2.5s minimum permitted
>   tcp-keepalive-timeout 50; # 5 seconds
>   tcp-advertised-timeout 50; # 5 seconds
> 
> Excessive concurrency is still a problem.
> 
> Tony.
> --
> f.anthony.n.finch  
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__dotat.at_=DwIBAg=MOptNlVtIETeDALC_lULrw=udvvbouEjrWNUMab5xo_vLbU
> E6LRGu5fmxLhrDvVJS8=JTnM4a1inaCfDoxVF_4YSLxG0ZMNs5KM-
> vGYEvYGn3E=NwdB8uMWwCIVphZw-jaaoVtu7PprQCHjwb6Fn_kuKgk=
> Viking, North Utsire, South Utsire: Southeasterly 6 to gale 8,
> occasionally
> severe gale 9 at first. Very rough or high, becoming rough later. Rain
> then
> showers. Good occasionally poor at first.
___
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: SERVFAIL when looking up TXT from particular domain

[Browne, Stuart via bind-users]

Trying with +cd, +noedns and +tcp elicits a similar result; a SERVFAIL.

As these work fine if querying the authoritative servers directly (or using 
+trace), it appears to be a quirk in the resolver code.

Stuart

> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
> Carl Byington via bind-users
> Sent: Thursday, 27 June 2019 11:17 AM
> To: bind-users@lists.isc.org
> Subject: Re: SERVFAIL when looking up TXT from particular domain
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On Wed, 2019-06-26 at 13:16 +, Dennis via bind-users wrote:
> > dig TXT cleanmail4.capgeminioutsourcing.nl @localhost
> 
> 
> dig TXT cleanmail4.capgeminioutsourcing.nl +nodnssec
> @ns1.capgeminioutsourcing.nl.
> ;; MSG SIZE  rcvd: 124
> 
> 
> dig TXT cleanmail4.capgeminioutsourcing.nl +dnssec
> @ns1.capgeminioutsourcing.nl.
> ;; MSG SIZE  rcvd: 4931
> 
> 
> Check your ability to receive fragmented ip packets.
> 
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.14 (GNU/Linux)
> 
> iEYEAREKAAYFAl0UGRIACgkQL6j7milTFsFh1gCfcny3HFKDxUH8p9bxF6vVeSZm
> 0rIAn3rUK0pCmDeQeStpakHQaldlvoN8
> =cOJV
> -END PGP SIGNATURE-
> 
> 
> ___
> 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

RE: A policy for removing named.conf options.

[Browne, Stuart via bind-users]

> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
> Evan Hunt
> Sent: Friday, 14 June 2019 5:40 AM
> To: Warren Kumari
> Cc: Ondřej Surý; comp-protocols-dns-b...@isc.org
> Subject: Re: A policy for removing named.conf options.
> 
> On Thu, Jun 13, 2019 at 02:52:34PM -0400, Warren Kumari wrote:
> > all sorts of annoyance -- if I'm running low on space for cache, and
> > spend much time twiddling the "max-acache-size" knob before
> > discovering that someone has simply snipped the wires to it, I'd be
> > super-grumpy.
> 
> But hopefully in this scenario you're paying attention to log messages,
> and would have seen the "obsolete option" warning.
> 
> The question is, should your nameserver complain and keep running, or
> should it reufse to run? And for "max-acache-size", enh, I'd probably
> be okay with it.
> 
> But a standard policy that covers all deprecated options would need
> to be stricter than "enh".

For options that have passed their warning phase and have been removed, I'm all 
for BIND failing to start and named-checkconf erroring out , rather than 
quietly ignoring them.

Usless cruft is useless. You're going to the trouble of doing a 
major-version-upgrade, take the time to tune the config to suit it.

If you're using automation tools, hopefully you've run it through at least one 
test system before hitting production, yes?

Stuart

___
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: Bind9 stops responding for some clients

[Browne, Stuart via bind-users]

Congratulations on finding the cause.

Sometimes, it's the simplest of things.

Stuart

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Gregory 
Sloop
Sent: Thursday, 6 June 2019 12:37 PM
To: bind-users@lists.isc.org
Subject: Re: Bind9 stops responding for some clients

Thanks for the idea.
I did resolve this a day or two ago.

The story is;
This server was a fairly recent replacement for an older Ubuntu setup. The new 
server as well as the old one are/were VM's - yet on different VM platforms. 
The old VM was turned off, and was marked never to start except unless manually 
started. [There were a few other things on the VM host that had yet to be 
migrated - so we didn't want it entirely off quite yet.]

The problem happened again in the last day or two - and packet captures showed 
that no packets were even arriving at the new VM.
Since there really wasn't anything that should be blocking that traffic, I 
checked the arp table on a problem client.
The arp table showed an "incorrect" MAC address for the current BIND server. 
[The MAC in the arp table didn't match the MAC for the new VM.]

While I didn't have the MAC address for the "old" deactivated server handy, it 
was the first obvious problem/solution to check.
Sure enough, after connection to the VM hypervisor, I could see that the "old" 
BIND vm was active.

I killed it, and service returned to normal.

So, the "solution" was pretty routine.
What made it more "interesting" and perhaps odd is how seemingly randomly the 
problem would crop up.
And it would only impact some clients, not all. There was no pattern that 
seemed to explain why some got the current/correct BIND server and others 
didn't. [The arp poisoning certainly wasn't anywhere nearly universal.]
And why was it so infrequent - it would go many days between issues.
I have to assume the bad VM had been up for some time, at least since the 
problems started.
There are quite a number of odd-ish other things too, but not worth detailing.

Probably it's just one of those "undefined" situations where you can't 
anticipate some predictable order to what happens when you screw it up. Rather 
than burn additional time trying to grok what was going on - it's simply best 
to say "don't do that - bad things happen, though I can't say what bad things 
will happen and in which logical order. They just will - so DON'T DO THAT!"

[And yeah, I obviously knew all about not doing that. But it happened anyway, 
in spite of specific steps to prevent it. I'm still not sure why.]

In the end, it's a somewhat complicated story with a very obvious cause - but 
it wasn't so clear at the outset.

TLDR version;
Don't run your old and new bind servers on the same IP address - ether by 
accident or intentionally. Bad stuff will happen!
It might be really odd, or it might be plain as day -  but in either case it 
won't be good! :)

Thanks all for the suggestions!
Here's hoping I don't need to ask for BIND assistance for another 20 years! :)

-Greg


I just randomly spotted this post, and thought I would toss in 2¢

How many nics and how many it's are on the servers?  Are the failing clients on 
the same subnet as the server?

--


___
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: Bind9 stops responding for some clients

[Browne, Stuart via bind-users]

Whilst you mentioned 150 seats and you mentioned 'no firewalls', you didn't 
mention the network topology at all, in particular is traffic passing through a 
commercial firewall/router (hardware or virtualized) to get to the DNS server? 
If there is, it may be worth checking what packet inspection is turned on for 
DNS traffic (Cisco, Juniper and Checkpoint have been known to have buggy 
inspection routines in the past).

I might also be worthwhile to see what your open filehandles are like and 
whether there's any rate limiting configured in the distributed BIND 
configuration.

Stuart

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of John W. 
Blue
Sent: Friday, 31 May 2019 11:47 AM
To: bind-users@lists.isc.org
Subject: Re: Bind9 stops responding for some clients

Good job on the amount of troubleshooting work done so far.

Next steps should be to run tcpdump on the interface for port 53 to see what is 
happening when an outage is in progress.  What you will be looking for 
specifically is the query packet in and the response packet out.

Use the following command:

tcpdump -n -i eth0 port domain and host 172.24.67.32

Swap out eth0 for whatever you have configured and the host IP address for a 
host that is having problems.

John

Sent from 
Nine

From: Gregory Sloop mailto:gr...@sloop.net>>
Sent: Thursday, May 30, 2019 7:11 PM
To: bind-users@lists.isc.org
Subject: Bind9 stops responding for some clients

So, this is a very odd situation and I'm kind of grasping at straws here.
So, I've come to see if any of you have any good straws!

The setup.
---
Ubuntu 18.04 LTS is the distro we're running on.
All software is packaged [from the distro] - not compiled from sources.
Bind9 acting as a recursive resolver for a smallish network. 150 seats.
They're also handling DHCP and Chrony/NTP requests.
[I actually have a pair of these handling DNS/DHCP/NTP this is the master.]

They are running on a Xen/XCP VM.

The one I'm having problems is the master for several internal zones - the one 
that's working fine is the slave for those same zones. None of the zones are 
large.

Intermittently, Bind9 simply stops handling queries from *some* hosts.
Meaning, it simply times out for responses for those hosts.
Yet BIND *is* working fine for lots of other machines on the same networks. 
It's working fine doing dig queries locally on the server, and handles dns 
queries fine for lots of other machines. Yet, again, some machines simply get 
time-outs. I can't find any pattern to which machines get timeouts and which 
don't.

I've checked - no firewalls, fail2ban or the like that might be causing this.
No selinux/apparmour.
Hosts that can't do dns queries can ping the dns server fine.
[So, there's at least some network pathway to the DNS machine.]

Review of the logs for bind don't show anything that looks like a problem to me.
[But I'm not sure what keywords I ought to be looking for, in an effort to find 
symptoms/problems.]

Finally, the two bind/dhcp/ntp servers are currently running on the same Xen 
host, so if it's somehow host related, I'd expect both to have problems, but 
they don't.

Top doesn't show any CPU distress.
Processes look fine
Memory in use is far below what allocated to the machine. [1G allocated, like 
<400M used.]
Restart of BIND doesn't do anything, at least in the cases I've seen - which 
aren't all that many yet.
A restart of the whole VM does appear to fix the issue immediately.
These appear to occur every 3-5 days.
Oh, and if you simply wait, it eventually starts handling queries for all hosts 
again - but it might be a couple+ hours.

Any suggestions on things I might hunt for in the logs in an attempt to figure 
out what's happening?
Other suggestions for things to look for/consider?

TIA
-Greg
___
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: what is this python stuff in 9.11.7 ??

[Browne, Stuart via bind-users]

Maybe to state a little clearer; the dnssec-keymgr is for the automation of 
creation and date management of keys.

All of the actual signing does not require the new python bit. If you're happy 
managing your keys with dnssec-keygen and dnssec-settime, you can continue 
using those (non-python) tools.

If you want to have a completely hands-off experience with automated key 
generation and rollover (without having to write your own wrappers), you might 
want to look into the new keymgr.

Stuart

> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
> Anand Buddhdev
> Sent: Friday, 31 May 2019 8:45 AM
> To: Dennis Clarke; bind-users@lists.isc.org
> Subject: Re: what is this python stuff in 9.11.7 ??
> 
> On 31/05/2019 00:21, Dennis Clarke wrote:
> 
> > Someone somewhere figured it made sense to drag in a dependency the
> size
> > of python?
> 
> The dnssec-keymgr and a couple of other utilities were introduced in
> 9.11.0. This is mentioned in the release notes. They are not new to
> 9.11.7.
> 
> > It must be a "soft" dependency as named itself seems to need :
> 
> Correct. The BIND daemon doesn't need python. It's only needed by some
> of the DNSSEC key management utilities. If you are not going to sign
> zones with BIND, you can safely build without python.
> 
> > But a massive brontosaurus lumbering in the size of Python?
> >
> > Did anyone discuss this in the open or was it a management decision to
> > be followed next by mono and C# and perhaps libbloatware.so.1 ??
> 
> There's no need to be so dramatic about this. Python isn't that big, and
> as I said above, you can safely build and run BIND without it if you
> don't want to sign zones with it.
> 
> Regards,
> Anand
___
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

BIND and persistent connections

[Browne, Stuart via bind-users]

Hi,

I noticed that over the last few days on a number of our name servers in Tokyo 
that Google has started making persistent TCP connections to our name servers.

I'm all for this as a concept, but it appears they're making many thousands of 
connections and not tearing them down after any given time or number of queries 
(that I can identify at least) over both IPv4 and IPv6.

I was wondering if anybody had any thoughts on how to limit the concurrency or 
at least the lifetime of these persistent connections within BIND.

Stuart Browne

___
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

Views, Match-Destination, Alternate Ports

[Browne, Stuart via bind-users]

Hi,

Whilst I've confirmed that notifies can be sent to alternate ports (using 
masters definitions), I can't seem to mangle BIND to use an alternate port in a 
view's match-destination configuration item (as it takes an ACL and they don't 
take ports from what I can read/test).

Am I missing something here? Is it not possible to define multiple views with 
different destination ports?

Stuart
___
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: concurrent-session

[Browne, Stuart via bind-users]

It does depend somewhat on what you mean by concurrent sessions.

Do you mean incoming queries?
Do you mean incoming zone transfers?
Do you mean outgoing zone transfers?

Each is a different tunable.

Ultimately, system-wide file descriptor limits do come in to play, but the zone 
transfers listed above is the only thing with defaults.

Stuart

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of MEjaz
Sent: Thursday, 1 November 2018 5:28 PM
To: bind-users@lists.isc.org
Subject: concurrent-session

Hello

How many concurrent session By default bind supports. It is restricted the O/S 
and hardware resources?

Your advice would be highly appreciated thanks in advance.

Ejaz


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: BIND and UDP tuning

[Browne, Stuart via bind-users]

> -Original Message-
> From: bind-users On Behalf Of Alex

 

> I'm leaning towards that, too. The problem persists even when using
> the provider's DNS servers. I thought for sure I'd see some verifiable
> info from other people having problems with cable, such as from
> dslreports, etc, but there really hasn't been anything. The comment
> made about DOCSIS earlier in this thread was helpful.
> 
> Do you believe it could be impacting all data, not just bind/DNS/UDP?
> 
> Do people not generally use cable as even a fallback link for
> secondary services? I figured it was because there's no SLA, not
> because it doesn't work well with many protocols. I'd imagine services
> like Netflix and youtube don't have problems is because they 1) don't
> require a lot of DNS traffic and 2) http is a really simple protocol
> and 3) the link is probably engineered to be used for that?

I use sendmail and bind at home for my purposes, and don't have these sorts of 
issues. But what probably solves this for most users is the fact that most 
home-sort-of-users use TCP rather than UDP.

UDP is designed as a lossy protocol; no resends, no guaranteed delivery at a 
protocol level. If you're really concerned with the occasional SERVFAIL due to 
this (which your stub resolver should be retrying), you could try convincing 
BIND to recurse using TCP only. It's not a good idea (and I'm pretty sure 
doesn't have the option to do it natively)...

Stuart
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: BIND and UDP tuning

[Browne, Stuart via bind-users]

> -Original Message-
> From: Tony Finch [mailto:d...@dotat.at]
> 
> >   - { name: 'net.ipv4.tcp_sack', value: 0 }
> 
> Why? SACK is super important for TCP performance over links that have any
> degree of lossiness, and I don't recall hearing of any caveats.
> 
> Tony.
> --
> f.anthony.n.finch  

If I recall correctly, it had to do with the fact that we were in a 
very-network-close test environment with very-small packets so it wasn't 
necessary to even consider resends. I don't recall whether it did anything at 
all to the results; it is just one of the various things I stuck into the 
blender in order to see if it made a difference and was still in at the end of 
testing. The number of test iterations I went through was in the hundreds and 
most of it was "Moar! MOAR!" rather than good arguments; more about proving a 
design could reach a theoretical limit than whether it would be 100% stable in 
production. 

The environment design that these tests were preparing for haven't been 
implemented yet; that's what I'm working on over the next few weeks, so I'll be 
going over these settings with some kid-gloves and being a little gentler as we 
don't need a single location churning out 2M5 qps; we're quite happy with 2M.

Let's hear it for overkill!

Stuart
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: BIND and UDP tuning

[Browne, Stuart via bind-users]

> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
> Alex
> Sent: Thursday, 27 September 2018 2:52 AM
> To: bind-users@lists.isc.org
> Subject: BIND and UDP tuning
> 
> Hi,
> 
> I reported a few weeks ago that I was experiencing a really high
> number of "SERVFAIL" messages in my bind-9.11.4-P1 system running on
> fedora28, and I haven't yet found a solution. This is all now running
> on a 165/35 cable system.
> 
> I found a program named dropwatch which is showing a significant
> number of dropped UDP packets, particularly when there are bursts of
> email traffic:
> 
> 12 drops at skb_queue_purge+13 (0x9f79a0c3)
> 1 drops at __udp4_lib_rcv+1e6 (0x9f83bdf6)
> 4 drops at __udp4_lib_rcv+1e6 (0x9f83bdf6)
> 5 drops at nf_hook_slow+a7 (0x9f7faff7)
> 3 drops at sk_stream_kill_queues+48 (0x9f7a1158)
> 3 drops at __udp4_lib_rcv+1e6 (0x9f83bdf6)
> ...
> 
> # netstat -us
> ...
> Udp:
> 23449482 packets received
> 1724269 packets to unknown port received
> 8248 packet receive errors
> 31394909 packets sent
> 8243 receive buffer errors
> 0 send buffer errors
> InCsumErrors: 5
> IgnoredMulti: 43247
> 
> The SERVFAIL messages don't necessarily correspond to the UDP packet
> errors shown by netstat, but the dropwatch output is continuous. The
> netstat packet receive errors also don't seem to correspond to
> "SERVFAIL" or "Name service" errors:
> 
> 26-Sep-2018 12:42:49.743 query-errors: info: client @0x7fb3c41634d0
> 127.0.0.1#44104 (46.36.47.104.wl.mailspike.net): query failed
> (SERVFAIL) for 46.36.47.104.wl.mailspike.net/IN/A at
> ../../../bin/named/query.c:8580
> 
> Sep 26 12:47:11 mail03 postfix/dnsblog[22821]: warning: dnsblog_query:
> lookup error for DNS query 196.91.107.80.bl.spameatingmonkey.net: Host
> or domain name not found. Name service error for
> name=196.91.107.80.bl.spameatingmonkey.net type=A: Host not found, try
> again
> 
> I've been following this thread from some time ago, but nothing I've
> done has made a difference. I really don't know what the buffer sizes
> should be.
> https://urldefense.proofpoint.com/v2/url?u=http-3A__bind-2Dusers-
> 2Dforum.2342410.n4.nabble.com_Tuning-2Dsuggestions-2Dfor-2Dhigh-2Dcore-
> 2Dcount-2DLinux-2Dservers-
> 2Dtd3899.html=DwICAg=MOptNlVtIETeDALC_lULrw=udvvbouEjrWNUMab5xo_vLb
> UE6LRGu5fmxLhrDvVJS8=5XQNuuRQ4kxK03zqoWaJHIdaJvNdsyTKHuFlDKedbpc=5Dqh
> ne-5w5V_1coBTBvTITwK2EFeankOegTaofy8S5w=
> 
> Are there specific bind tunables you might recommend? edns-udp-size,
> perhaps?
> 
> Any ideas on other tunables such as net.core.*mem_default etc?

*chuckles to self*

I was just referring back to that thread myself to try remember what I did.

I ended up tuning the following items:

  - name: SYSCTL system tuning, basics
sysctl:
  name: "{{ item.name }}"
  value: "{{ item.value }}"
  sysctl_set: yes
  state: present
with_items:
  - { name: 'vm.swappiness', value: 0 }
  - { name: 'net.core.netdev_max_backlog', value: 32768 }
  - { name: 'net.core.netdev_budget', value: 2700 }
  - { name: 'net.ipv4.tcp_sack', value: 0 }
  - { name: 'net.core.somaxconn', value: 2048 }
  - { name: 'net.core.rmem_default', value: 16777216 }
  - { name: 'net.core.rmem_max', value: 16777216 }
  - { name: 'net.core.wmem_default', value: 16777216 }
  - { name: 'net.core.wmem_max', value: 16777216 }

(Yeah, I was using ansible for that testing!)

The checking of the /proc/net/softnet_stat is what was driving some of those 
settings, so you may want to dig into that. I never did solve the netstat 
showing issues though, so keep that in mind.

If you are running high query throughput and have many CPU cores, the pinning 
of cores was a significant performance improvement.

You've not said here what sort of query throughput you are having here however. 
Be aware that if this is running in a virtualized environment, you may want to 
be looking at the host machine instead of the guest as the network performance 
there can have a significant impact.

Whilst mentioned in passing on that thread, there was also poking around with 
TOE, pause, coalesce adaptive and ring size settings (look at ethtool -K, 
ethtool -A, ethtool -C and ethtool -G), but sadly have lost the specific 
commands. 

Stuart Browne
Neustar, Inc. / Sr Systems Admin
Level 8, 10 Queens Road, Melbourne, Australia VIC 3004
Office: +61.3.9866.3710
stuart.browne@team.neustar / home.neustar

Follow Neustar: LinkedIn / Twitter

Reduce your environmental footprint. Print only if necessary.

The information contained in this email message is intended only for the use of 
the recipient(s) named above and may contain confidential and/or privileged 
information. If you are not the intended recipient you have received this email 
message in error and any review, dissemination, distribution, or copying of 
this message is strictly prohibited. If you have received 

RE: Beginner - Bind - Bad dotted quad

[Browne, Stuart via bind-users]

>From my reading of the error message and the zone data provided, they don't 
>match.

The error is stating near db.fin line 17 that the label is 'hp4000.' (note the 
full-stop); this doesn't appear to be the case with the pasted data.

Did you modify the zone data before pasting it in (i.e. mask some names or ip 
addresses or something?)

Stuart

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
Maurizio Caloro
Sent: Monday, 24 September 2018 1:41 PM
To: bind-users@lists.isc.org
Subject: Beginner - Bind - Bad dotted quad

Hello together
Iam new to this group and i have a little understanding and implementation 
problem form e new bind 9.11 DNS Server.
Please can i ask here for help.

I see on syslog that me error are ___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: [BIND] RE: KSK Rollover

[Browne, Stuart via bind-users]

The kicker was probably this line:

Sep  6 15:44:40 ns3 audit:  { write } for  pid=15447 comm="named" 
name="named.secroots" dev="dm-0" ino=135707451 
scontext=system_u:system_r:named_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 
tclass=file permissive=0

The SELinux context that BIND runs in on a red hat system doesn't have access 
to write to a file of etc_t. After moving the file to /var/named somewhere, a 
restorecon should have reset it to something like var_named_t or 
var_named_cache_t which it would have had access to write to.

>From the line, 'permissive=0' so it suggests a SELinux-enforcing environment.
Stuart

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Brent 
Swingle
Sent: Friday, 7 September 2018 12:05 PM
To: bind-users@lists.isc.org
Subject: Re: [BIND] RE: KSK Rollover

This matter has been resolved with input from Evan.  I was able to add a file 
path for secroots to the named.conf file and push the output file to a temp 
directory that was not permission restricted.

secroots-file "/tmp/named.secroots" ;


Ultimately when I ran "rndc secroots" it created the output file here:

/tmp/systemd-private-b2ebff459df9471e8bf444e2d2b1116e-named.service-HX1NF5/tmp/named.secroots


The data in the file seems to be as desired if I understand the KSK Rollover 
test correctly, I should see 20326 which pertains to the new key:

[root@ns3 tmp]# cat named.secroots
06-Sep-2018 18:47:16.190

Start view internal-in

./RSASHA256/20326 ; managed
./RSASHA256/19036 ; managed
dlv.isc.org/RSASHA1/19297 ; managed

Start view external-in

./RSASHA256/20326 ; managed
./RSASHA256/19036 ; managed
dlv.isc.org/RSASHA1/19297 ; managed

Start view external-chaos

dumpsecroots failed: not found




I did not fully try Carl's input below but I believe it would have worked as 
well.  I had performed a "chmod 770 /var/named" but I did not follow it up with 
the SELinux modification.  The last error I had was SELinux barking so I'd 
anticipate his suggestion was the correct one.

Does the 'named' user have write access to /var/named? The default
redhat setup has /var/named as 0750, with /var/named/data as 0770. Also,
the default redhat selinux config prevents named writing to /var/named.

chmod 770 /var/named
setsebool -P named_write_master_zones=true
rndc secroots




Thanks everyone for assisting with this matter.
___
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: 'tsig-keygen' vs 'dnssec-keygen' - keysize

[Browne, Stuart via bind-users]

> -Original Message-
> From: Evan Hunt [mailto:e...@isc.org]
> Sent: Thursday, 6 September 2018 4:35 PM
> To: Browne, Stuart
> Cc: Mark Andrews; bind-users@lists.isc.org
> Subject: Re: 'tsig-keygen' vs 'dnssec-keygen' - keysize
> 


> > Is there no cryptographic difference between the short/long output?
> 
> As I understand it (though I haven't studied this in a while and may be
> fuzzy), the HMAC algorithm shortens keys that are longer than the block
> size before it uses them, so it's true, long keys aren't necessary or
> particularly helpful.
> 
> > Incidentally using bind-9.11 I was unable to use the truncation method
> > you mentioned below (not that I really want to). Is it a 9.12 onwards
> > thing?
> 
> No, but Mark's comment may have been confusing.  You can set up keys
> that way in named.conf ("algorithm hmac-md5-96;" or whatever). At first
> I thought he was talking about tsig-keygen; perhaps you read it the same
> way I did?
> 
> --
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.

Yes, I did read it the same way as you Evan.

Thanks for the clarification on the HMAC usage.

Stuart
___
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: 'tsig-keygen' vs 'dnssec-keygen' - keysize

[Browne, Stuart via bind-users]

Ok, then here goes me in my not-really-understanding HMAC properly.

When using 'dnssec-keygen -a hmac-md5 -b 512 -n HOST some-name' (512 being the 
max keysize lited in 'dnssec-keygen -h'), we end up with an 88 byte string of 
secret data.

When using 'tsig-keygen -a hmac-md5 some-name', we end up with a 24 bytes 
string of secret data.

Is there no cryptographic difference between the short/long output?

For the sha* types, the length of the secret material appears to be the same, 
but not for the md5.

Sadly, I have some software that requires the use of hmac-md5's for tsigs that 
I cannot work around at this time.

Incidentally using bind-9.11 I was unable to use the truncation method you 
mentioned below (not that I really want to). Is it a 9.12 onwards thing?

Stuart

> -Original Message-
> From: Mark Andrews [mailto:ma...@isc.org]
> Sent: Wednesday, 5 September 2018 3:40 PM
> To: Browne, Stuart
> Cc: bind-users@lists.isc.org
> Subject: Re: 'tsig-keygen' vs 'dnssec-keygen' - keysize
> 
> 
> > On 5 Sep 2018, at 2:50 pm, Browne, Stuart via bind-users  us...@lists.isc.org> wrote:
> >
> > Was adding in some new internal functionality and noted that the 'tsig-
> keygen' tool doesn’t
> > give the ability to alter the keysize like dnssec-keygen does for
> generating HMAC based tsig keys.
> >
> > I also noticed that in 9.13, dnssec-keygen will no longer be able to
> generate HMAC tsig's, so
> > I'm wondering if the ability to manipulate the tsig keysize will be
> implemented in tsig-keygen
> > to maintain compatibility, or if there is some work-around I've not
> found to be able to set this.
> 
> There is zero point in fiddling with the key sizes of hmacs.  It has no
> impact on the size
> of the HMAC in the TSIG records.  It has negligible impact on the size of
> named.conf, nor
> on the size of a database if we ever get around to storing tsig keys in a
> database, even
> with 100’s of millions of keys.
> 
> tsig-keygen generates maximal sized shared keys for the given algorithm
> which provides
> the largest possible search space for a brute force attack.
> 
> The hmac algorithm used impacts the size of the HMAC in the TSIG record.
> To generate
> truncated hmac append “-” e.g. -128 to the algorithm name.
> 
> Mark
> 
> > Stuart Browne
> > Neustar, Inc. / Sr Systems Admin
> > Level 8, 10 Queens Road, Melbourne, Australia VIC 3004
> > Office: +61.3.9866.3710
> > stuart.browne@team.neustar / home.neustar
> >
> > Follow Neustar: LinkedIn / Twitter
> >
> > Reduce your environmental footprint. Print only if necessary.
> >
> > The information contained in this email message is intended only for
> the use of the recipient(s) named above and may contain confidential
> and/or privileged information. If you are not the intended recipient you
> have received this email message in error and any review, dissemination,
> distribution, or copying of this message is strictly prohibited. If you
> have received this communication in error, please notify us immediately
> and delete the original message.
> >
> >
> > ___
> > Please visit https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__lists.isc.org_mailman_listinfo_bind-
> 2Dusers=DwIFaQ=MOptNlVtIETeDALC_lULrw=udvvbouEjrWNUMab5xo_vLbUE6LRG
> u5fmxLhrDvVJS8=VyYL0iKiBdsY762FkEGyvUr-
> FH5Z6vWh3Zs7JPh9g_U=SC48Vs3lYvTTgdQlXnms2TK6qbKVLErW2vjypiecjek= to
> unsubscribe from this list
> >
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__lists.isc.org_mailman_listinfo_bind-
> 2Dusers=DwIFaQ=MOptNlVtIETeDALC_lULrw=udvvbouEjrWNUMab5xo_vLbUE6LRG
> u5fmxLhrDvVJS8=VyYL0iKiBdsY762FkEGyvUr-
> FH5Z6vWh3Zs7JPh9g_U=SC48Vs3lYvTTgdQlXnms2TK6qbKVLErW2vjypiecjek=
> 
> --
> 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

'tsig-keygen' vs 'dnssec-keygen' - keysize

[Browne, Stuart via bind-users]

Was adding in some new internal functionality and noted that the 'tsig-keygen' 
tool doesn't give the ability to alter the keysize like dnssec-keygen does for 
generating HMAC based tsig keys.

I also noticed that in 9.13, dnssec-keygen will no longer be able to generate 
HMAC tsig's, so I'm wondering if the ability to manipulate the tsig keysize 
will be implemented in tsig-keygen to maintain compatibility, or if there is 
some work-around I've not found to be able to set this.

Stuart Browne
Neustar, Inc. / Sr Systems Admin
Level 8, 10 Queens Road, Melbourne, Australia VIC 3004
Office: +61.3.9866.3710
stuart.browne@team.neustar / home.neustar

Follow Neustar: LinkedIn / Twitter

Reduce your environmental footprint. Print only if necessary.

The information contained in this email message is intended only for the use of 
the recipient(s) named above and may contain confidential and/or privileged 
information. If you are not the intended recipient you have received this email 
message in error and any review, dissemination, distribution, or copying of 
this message is strictly prohibited. If you have received this communication in 
error, please notify us immediately and delete the original message.


___
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: named tcp dos?

[Browne, Stuart via bind-users]

> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
> Randy Bush
> Sent: Friday, 3 August 2018 6:08 AM
> 
> >> ... are there that many folk doing tcp out there?
> > All name servers fall back to TCP when they receive truncated replies.
> 
> we know the protocol.  [ and we know folk have idiot middleboxen ]
> 
> what i was asking was the distribution of this in the wild.

We run about 300 TLD's on our DNS platform and get roughly 5-10% TCP queries. 
In comparison, we get about 25-30% IPv6 queries.

Those rates are fairly consistent.

> 
> randy

Stuart
___
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: Authoritative dns with private IP for hostname

[Browne, Stuart via bind-users]

Be wary of DNAME's; they can be quite limited.

Here's an example from our old system:

internal.   3600IN  SOA mgmt1.mel.internal.local. 
sysadmin.external.com.au. 2014051201 28800 14400 360 86400
internal.   3600IN  NS  mgmt1.mel.internal.local.
internal.   3600IN  NS  mgmt1.syd.internal.local.
internal.   3600IN  DNAME   external.com.au.

Which means internally we can look up "host.internal" and it will translate to 
"host.external.com.au".

Stuart

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Elias 
Pereira
Sent: Tuesday, 31 July 2018 10:06 AM
To: Grant Taylor; bind-users@lists.isc.org
Subject: Re: Authoritative dns with private IP for hostname

Could you give me an example of how to do with DNAME?

Em seg, 30 de jul de 2018 20:16, Grant Taylor via bind-users 
mailto:bind-users@lists.isc.org>> escreveu:
On 07/30/2018 04:54 PM, Elias Pereira wrote:
> Thanks to everyone that help me!!!

You're welcome.

> The Grant Taylor tuto works like a charm!!! :)

I'm glad that it worked for you.

Note:  I call this technique "Apex Override".

I believe the Apex Override technique can be used anywhere you want to
selectively override a (single) FQDN.

I suspect there are some more nefarious things that you can do with
this, particularly if combined with DNAME.  But I try to keep my hit a
lighter shade of gray.



--
Grant. . . .
unix || die

___
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

RE: Logrotate for bind9

[Browne, Stuart via bind-users]

How about a clear, direct example of using external service 'logrotate' (this 
is from one of my redhat systems, but the same concept applies to 
Ubuntu/Debian):

[be...@dns-nomnom1.den ~]$ cat /etc/logrotate.d/named
/var/log/named/*.log {
  compress
  create 0644 named named
  daily
  dateext
  missingok
  notifempty
  rotate 30
  sharedscripts
  postrotate
/usr/sbin/rndc reconfig > /dev/null 2>/dev/null || true
  endscript
}

We put our logs in the custom location of '/var/log/named/'; if you put them 
somewhere else, you'll need to change that. The other settings are direct 
references to Anand's email. Finally, you'll want to change the 30 to 180 to 
keep 180 different days worth of logs.

BIND internally doesn't have the concept based rotation, only size-based 
rotation. In order to achieve per-day logs, you'll need to use the external 
tool 'logrotate' (or similar) for your rotation. If you do that, you'll want to 
disable BIND's rotation in the logs configuration (if you're using that 
currently), so not this:

logging {
channel ns_log {
file "/var/log/named/named.log" versions 3 size 256M;
severity dynamic;
print-time yes;
print-severity yes;
print-category yes;
};
...
category default { ns_log; };
category general { ns_log; };
category config { ns_log; };
};

But this:

logging {
channel ns_log {
file "/var/log/named/named.log";
severity dynamic;
print-time yes;
print-severity yes;
print-category yes;
};
...
category default { ns_log; };
category general { ns_log; };
category config { ns_log; };
};

Hope this clarifies the idea a little for you.

Stuart

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Blason R
Sent: Thursday, 5 July 2018 4:44 PM
To: bicw...@gmail.com
Cc: bind-users
Subject: Re: Logrotate for bind9

What exactly are those? Well what I wated to achieve here is to rotate the logs 
daily and start new file; then compress

On Thu, Jul 5, 2018 at 6:21 AM Rohan Henry 
mailto:bicw...@gmail.com>> wrote:
Why not use Bind logging option?

On Jul 4, 2018 8:51 AM, "Blason R" 
mailto:blaso...@gmail.com>> wrote:
Hi There,

I am not getting appropriate results for my custom daily logrorate for bind9 
logs on Ubuntu.

Can someone please help me with the settings which would include below   stuff

  1.  Should rotate daily
  2.  Compress
  3.  create new file
  4.  keep last 180 entries


Do I need stop bind9 while logs are being rotated? What is the correct 
procedure to start logs in new file?

___
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

RE: Handling expired domains

[Browne, Stuart via bind-users]

Assuming the slave can retrieve the SOA and zone, yup. It should just come 
right back online.

Stuart

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
rohan.henry cwjamaica.com
Sent: Friday, 29 June 2018 8:48 AM
To: bind-users@lists.isc.org
Subject: Handling expired domains

Hello All,

If all zones on a slave server expire because the slave could not reach the 
master shouldn't the slave start working again once the master becomes 
reachable without having to tweak anything like the serial?

Thanks.

Regards,
Rohan
___
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: Stopping name server abuse

[Browne, Stuart via bind-users]

If the incoming query has already been parsed and it BIND instance now knows it 
doesn't need to respond, it's already done all the work, so there's no point 
not sending the response. To introduce something before the BIND instance in 
userspace, then for every legitimate query you are double-processing; more 
wasted resources.

In either case, by 'not responding', you're tying up even more resources (open 
sockets or other connection tracking mechanisms if you haven't disabled them) 
until the connections all time out.

If you're filtering on an upstream device that can do that level of analysis 
without hurting your network, then maybe, but once again, you're 
double-processing every legitimate query; you're only moving the cost to a 
different device.

It's best to respond nicely and move on.

Unless the DNS server is massively under-resourced or the query load is in the 
many-thousands-per-second range, there shouldn't be that much of an issue with 
the server coping with the load; but from what I can tell on this thread, it's 
more about "The customer is no longer paying so I want to stop spending money 
or resources for them".

Stuart

> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
> Paul Kosinski
> Sent: Monday, 25 June 2018 1:40 PM
> To: bind-users@lists.isc.org
> Subject: Re: Stopping name server abuse
> 
> Is it possible to get BIND not to respond at all, thereby causing
> a timeout on the query? That would perhaps reduce load more than
> NXDOMAIN or deleting the sone(s) would.
> 
> 
> On Mon, 25 Jun 2018 00:03:09 +0200
> jo...@hasig.de wrote:
> 
> > yes, but it minimizes the use of resources because the only answer is
> > nxdomain. j.
> >
> > Am 24.06.2018 um 23:41 schrieb Barry Margolin:
> > > In article ,
> > >   jo...@hasig.de wrote:
> > >
> > >> hi,
> > >> why dont you just delete the zones?
> > >
> > > That won't stop the queries from coming to the server.
___
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: Stealth NS records

[Browne, Stuart via bind-users]

A number of places use a 'stealth' (or 'hidden') master as a bit of protection 
from potential bad actors. It's a network domain barrier between the master 
(usually on an internal-only network) from a public network with potential bad 
actors.

For example, a dynamic update for a zone will contact the mname defined in the 
SOA record unless told otherwise. If you watch your DNS traffic closely on a 
properly configured public authoritative server, you will see many failed 
dynamic updates.

I agree with Darcy in that it causes zones to be inaccurate from an integrity 
checking perspective; on a properly configured server, there should be no 
security issues, but it can create some piece of mind.

The concept, I believe, is a hold-out behaviour older environments where the 
software security couldn't be trusted (or you work in a 
paranoid-security-culture company).

Stuart

> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
> Darcy Kevin (FCA)
> Sent: Wednesday, 4 April 2018 7:42 AM
> To: bind-users@lists.isc.org
> Subject: [EXTERNAL] RE: Stealth NS records
> 
> "Stealth" implies something that isn't seen in the normal course of
> activity, so it's really the *wrong* word to use here, since the apex NS
> records are seen during normal iterative resolution, and in fact the apex
> NS records take precedence over the delegated NS records in the sense of
> RFC 2181 data-ranking. So, to call them "stealth" seems mistaken, and
> misleading.
> 
> A better term than "stealth NS" would be "mismatched NS". From an
> integrity-check perspective, IMO the mismatch condition should be flagged
> as questionable if the apex NS records are a superset of the delegated
> ones, and worrisome if completely disjoint.
> 
> 
>   - Kevin
> 
> 
> 
> -Original Message-
> From: bind-users  On Behalf Of Matus
> UHLAR - fantomas
> Sent: Friday, March 30, 2018 4:27 AM
> To: bind-users@lists.isc.org
> Subject: Re: Stealth NS records
> 
> On 30.03.18 15:44, PANG J. wrote:
> >I saw a zone check on intodns.com shows,
> >
> >Stealth NS records were sent:
> >ns2.xxx.com
> >ns1.xxx.com
> >
> >So what's a stealth NS record?
> 
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__massivedns.com_blog_dns-2Dreport-2Dtutorials_what-2Dare-2Dstealth-
> 2Dns-
> 2Drecords_=DwICAg=MOptNlVtIETeDALC_lULrw=udvvbouEjrWNUMab5xo_vLbUE6
> LRGu5fmxLhrDvVJS8=4QsJieBpLVGXq6C7UZcSGjOoNfc4AdS3O2xn99qCzss=fOk8VAH
> JBEQHZKHQg_MmDjog8kkvcyx2MxaUKeC7vXo=
> 
> maybe I could explain more deeply if you have sent the domain.
> 
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ;
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.fantomas.sk_=DwICAg=MOptNlVtIETeDALC_lULrw=udvvbouEjrWNUMab
> 5xo_vLbUE6LRGu5fmxLhrDvVJS8=4QsJieBpLVGXq6C7UZcSGjOoNfc4AdS3O2xn99qCzss
> =vCrjKTQXZ0_8Hbsun2FSpJ3jDWde90bS-EUlioBPFQ0=
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> Linux IS user friendly, it's just selective who its friends are...
> ___
> Please visit https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__lists.isc.org_mailman_listinfo_bind-
> 2Dusers=DwICAg=MOptNlVtIETeDALC_lULrw=udvvbouEjrWNUMab5xo_vLbUE6LRG
> u5fmxLhrDvVJS8=4QsJieBpLVGXq6C7UZcSGjOoNfc4AdS3O2xn99qCzss=GYBqR0XLzb
> LyreHLjhVv8W55ubpSa-93WNQlX1JXnZA= to unsubscribe from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__lists.isc.org_mailman_listinfo_bind-
> 2Dusers=DwICAg=MOptNlVtIETeDALC_lULrw=udvvbouEjrWNUMab5xo_vLbUE6LRG
> u5fmxLhrDvVJS8=4QsJieBpLVGXq6C7UZcSGjOoNfc4AdS3O2xn99qCzss=GYBqR0XLzb
> LyreHLjhVv8W55ubpSa-93WNQlX1JXnZA=
> ___
> Please visit https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__lists.isc.org_mailman_listinfo_bind-
> 2Dusers=DwICAg=MOptNlVtIETeDALC_lULrw=udvvbouEjrWNUMab5xo_vLbUE6LRG
> u5fmxLhrDvVJS8=4QsJieBpLVGXq6C7UZcSGjOoNfc4AdS3O2xn99qCzss=GYBqR0XLzb
> LyreHLjhVv8W55ubpSa-93WNQlX1JXnZA= to unsubscribe from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__lists.isc.org_mailman_listinfo_bind-
> 2Dusers=DwICAg=MOptNlVtIETeDALC_lULrw=udvvbouEjrWNUMab5xo_vLbUE6LRG
> u5fmxLhrDvVJS8=4QsJieBpLVGXq6C7UZcSGjOoNfc4AdS3O2xn99qCzss=GYBqR0XLzb
> LyreHLjhVv8W55ubpSa-93WNQlX1JXnZA=
___
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

BIND and ulimit's on Linux

[Browne, Stuart via bind-users]

Hi,

Just a quick question.

I've recently run in to another daemon (not associated with BIND) that 
inherited its 'nofile' ulimit before dropping privileges and was wanting to 
confirm that BIND doesn't work this way.

On some of our servers (zone distribution points) where lots of AXFR's (over 
LAN) come in, we occasionally see them not respond to queries for brief times. 
The servers are reporting a 'file-nr' value close (but not exceeding) root's 
nofile ulimit, and was wondering if this could be related.

Stuart
___
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