Re: Zones-unable-update

[Alan Clegg]

On 1/6/2020 4:09 AM, Fajar A. Nugraha wrote:

zone "kalam.com.sa" {
 type slave;
...
 masters {
 212.119.92.5;
 };
 };

How many IPs, and what IPs, did you put on the masters there? It
should only be ns1 (the master). If you put two, change it.


I would disagree.  YMMV.

AlanC
___
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: Can i remove @0x in my log query message, bind 9.11

[Alan Clegg]

On 11/4/2019 5:57 AM, Tony Finch wrote:

Nguyen Huy Bac  wrote:


So, my question is: Can and How to remove @0x in my
log query message.


There is no convenient way. You have to apply this patch:

diff --git a/lib/ns/client.c b/lib/ns/client.c
index f16ece8c49..7861f12084 100644
--- a/lib/ns/client.c
+++ b/lib/ns/client.c
@@ -4066,8 +4066,8 @@ ns_client_logv(ns_client_t *client, isc_logcategory_t 
*category,
}

isc_log_write(ns_lctx, category, module, level,
- "client @%p %s%s%s%s%s%s%s%s: %s",
- client, peerbuf, sep1, signer, sep2, qname, sep3,
+ "client %s%s%s%s%s%s%s%s: %s",
+ peerbuf, sep1, signer, sep2, qname, sep3,
  sep4, viewname, msgbuf);
  }


While this patch does what it says, it doesn't mention the fact that all 
versions of BIND for the foreseeable future are going to have this 
additional field (it's in all currently supported versions of BIND), so 
you will be MUCH better off fixing the software that is ingesting the 
log file than to patch BIND every time you upgrade.


AlanC

___
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

[Alan Clegg]

On 10/25/2019 5:26 AM, Ritah Mulinde wrote:
> Hello All
> kindly post the procedure for enabling dnssec on bind 9.9.6 running on
> OpenSuse 13.2

Step 1:  upgrade to a supported version of BIND (see: 
https://kb.isc.org/docs/aa-00896)


Step 2:  Follow Tony's advice regarding configuring DNSSEC

AlanC
___
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-Efficientip

[Alan Clegg]

On 10/20/2019 2:09 AM, MEjaz wrote:

As you know these days  there has been several security threats, So 
deciding to go with *Efficient iP DDI and DNS Security Solution* 
https://www.efficientip.com/


You may want to ask what EfficientIP runs under the covers...

AlanC
___
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: DNS RPZ Protection From DoH

[Alan Clegg]

On 10/2/19 8:00 AM, Blason R wrote:
> Hmm that is a good idea to block the DOH queries but what I understood
> is blocking on perimeter level would be more appropriate.

To nullify the abilities of DoH, you can block port TCP/443.

That is pretty much guaranteed to keep DoH from working, but you may
want to test this solution in the lab before you deploy widely.

This method of controlling DoH may have side-effects.

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

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

Re: rndc - sync before reload?

[Alan Clegg]

On 7/14/19 8:00 PM, John W. Blue wrote:
> Please elaborate on the technical reason why instead of being terse.

I'll give a short version:

"rndc reload" existed from the early days of BIND with the first notice
in CHANGES being [bug] 287 in 9.1.0b1.

"rndc sync" came along with [func] 3084 in BIND 9.9.0a1.

You don't need to sync before you reload.

As to the internals, I dunno.

AlanC

___
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: Regarding named related issue observed with bind 9.11.5-P4 version

[Alan Clegg]

On 4/11/19 9:38 AM, Alan Clegg wrote:
> On 4/10/19 3:53 PM, Chandra Rao wrote:
>> lrwxrwxrwx 1 root root 6 Apr  2 13:30 /var/run -> ../run
> 
> So, /var/run is a symlink to /var/run.
> 
> That's probably not gonna work to well.

Ok, I'm an idiot.

Ignore me.

(but look at the permissions, etc. on /run)

AlanC
___
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: Regarding named related issue observed with bind 9.11.5-P4 version

[Alan Clegg]

On 4/10/19 3:53 PM, Chandra Rao wrote:
> lrwxrwxrwx 1 root root 6 Apr  2 13:30 /var/run -> ../run

So, /var/run is a symlink to /var/run.

That's probably not gonna work to well.

AlanC
___
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: Regarding named related issue observed with bind 9.11.5-P4 version

[Alan Clegg]

On 4/10/19 11:10 AM, Karl Lovink wrote:
> Alan,
> 
> Are you running bind on a Linux box with apparmor. Check your apparmor 
> configuration: /etc/apparmor.d/usr.sbin.named.

I'm not, but the OP might be.:-)

AlanC
___
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: Regarding named related issue observed with bind 9.11.5-P4 version

[Alan Clegg]

On 4/10/19 10:19 AM, Alan Clegg wrote:
> On 4/3/19 5:26 AM, Chandra Rao wrote:
>> While launching the named service coming from the latest bind as
>> mentioned below, We have observed that it's is not able to create
>> "/var/run/named" directory with the named user in the cluster. Due to
>> this we are not able to store the files "named.pid" and "session.key".
> 
> named does not create the directory structure.  You will need to do that
> yourself.

Correcting myself before others do (sigh):

You've not shown how much of the /var/run directory structure exists.
Does /var/run exist?  What are the permissions on it?

I've just now looked at the only instance of the "couldn't mkdir"
message in the BIND source code:

if (mkdir(filename, mode) == -1) {
strerror_r(errno, strbuf, sizeof(strbuf));
(*report)("couldn't mkdir '%s': %s", filename,
  strbuf);
goto error;
}

(my original comment was based on logging directory structure, not that
used by session information).

AlanC
___
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: Regarding named related issue observed with bind 9.11.5-P4 version

[Alan Clegg]

On 4/3/19 5:26 AM, Chandra Rao wrote:
> While launching the named service coming from the latest bind as
> mentioned below, We have observed that it's is not able to create
> "/var/run/named" directory with the named user in the cluster. Due to
> this we are not able to store the files "named.pid" and "session.key".

named does not create the directory structure.  You will need to do that
yourself.

AlanC
___
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: allow-update in global options (was Re: bind and certbot with dns-challenge)

[Alan Clegg]

On 4/2/19 6:00 PM, Sam Wilson wrote:

>> During a cleanup of other code (specifically named-checkconf), code was
>> changed that enforced what was believed to have been the default
>> previously: specifically, allow-update was only allowed in zone stanzas.
> 
> Can I ask who believed it was previously the default?  I hope I'm not
> misreading the first dozen or so lines of this page (which seems to be
> reflected in previous editions of the ARM).
> 
> 

The answer to your question is:  "someone at ISC".

However, can you post exactly what you mean by "this page" and what
default we are talking about?  Based on the history of this e-mail
thread, I think that we are talking about "allow-update" being available
at the global view (up until 9.13.3) and it not being allowed there (the
rest of the 9.13 branch up until 9.14.0)

In the options section of the ARM I see:

allow-update
Specifies which hosts are allowed to submit Dynamic DNS updates for
master zones. The default is to deny updates from all hosts. Note that
allowing updates based on the requestor's IP address is insecure; see
the section called “Dynamic Update Security” for details.

in 9.12
(https://ftp.isc.org/isc/bind9/cur/9.12/doc/arm/Bv9ARM.ch05.html#options_grammar)
and:

allow-update
When set in the zone statement for a master zone, specifies which hosts
are allowed to submit Dynamic DNS updates to that zone. The default is
to deny updates from all hosts. This can only be set at the zone level,
not in options or view.

in 9.13 and 9.14.  The text here (as referred to in your link) is the
updated text that was changed at the same time that the code change was
made, thus matching what was released in 9.14.

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

Last Chance! Was: Re: Whither the statistics? Request from ISC for your input.

[Alan Clegg]

Coming up on the end of this opportunity for input.  This is a great
chance to help us out!

On Saturday, I'll share some interesting info about this request for input!

Alan Clegg, ISC

On 3/23/19 4:04 PM, Alan Clegg wrote:
> Some of you have already seen this and I thank you for your responses!
> 
> I'm now opening the question up to the entirety of BIND users.
> 
> I've been asked to lead a discussion next weekend on "what statistics
> our users really care about".  I'd like to get the presentation done by
> Friday, so if you want your voice heard, please holler out!
> 
> It is obvious from some of the stats that we currently make available
> that they were intended to assist in the debugging of BIND internals and
> some of the stats that are missing are things that were overlooked
> because the guys writing the code don't run multiple huge BIND farms
> that require minute-by-minute monitoring.
> 
> If you have a few minutes, can you provide me a short list of the
> statistics that you really want to be able to get out of BIND?  I'm
> interested in both the ones that are there already and the ones that aren't.
> 
> This is NOT a promise of getting anything into BIND in the short term,
> but it will be used as input as we work on "re-instrumenting" the monster.
> 
> If you don't mind, please reply to me directly (acl...@isc.org) and I'll
> get the results compiled and prepared.  I've set the "Reply-To" header,
> but I'm not sure if the list manager strips that off...   ;-)
> 
> AlanC, ISC
> ___
> 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

Whither the statistics? Request from ISC for your input.

[Alan Clegg]

Some of you have already seen this and I thank you for your responses!

I'm now opening the question up to the entirety of BIND users.

I've been asked to lead a discussion next weekend on "what statistics
our users really care about".  I'd like to get the presentation done by
Friday, so if you want your voice heard, please holler out!

It is obvious from some of the stats that we currently make available
that they were intended to assist in the debugging of BIND internals and
some of the stats that are missing are things that were overlooked
because the guys writing the code don't run multiple huge BIND farms
that require minute-by-minute monitoring.

If you have a few minutes, can you provide me a short list of the
statistics that you really want to be able to get out of BIND?  I'm
interested in both the ones that are there already and the ones that aren't.

This is NOT a promise of getting anything into BIND in the short term,
but it will be used as input as we work on "re-instrumenting" the monster.

If you don't mind, please reply to me directly (acl...@isc.org) and I'll
get the results compiled and prepared.  I've set the "Reply-To" header,
but I'm not sure if the list manager strips that off...   ;-)

AlanC, ISC
___
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

9.14.0 now available

[Alan Clegg]

For those of you (like me) that may not be on the -announce list, I
would like to make you aware of the following:

 https://lists.isc.org/pipermail/bind-announce/2019-March/001122.html

AlanC
___
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: ISC BIND 9.12.3-P1 Question re: DNSSEC Zone Signing

[Alan Clegg]

On 3/18/19 7:33 PM, LeBlanc, Daniel James wrote:

> I have a pair of ISC BIND 9.12.3-P1 servers that are configured as
> slaves to a pair of Hidden Master servers.  The Hidden Masters are a
> proprietary product and unfortunately when used to sign the zones, the
> SOA records are not populated as expected.  As a result, I was looking
> into signing the zones within ISC BIND instead.  Reviewed the
> literature, came up with a plan and the required configuration changes.
>  However, things are not proceeding as I had hoped…

As Mark noted, the "update-policy local" is not going to work as
expected, but I'd like to expound a bit..

I would recommend, not knowing how you are currently configured nor what
you found on "how to do this", the following:

Modify one of your existing slave servers to act as an in-line signer.
Have your hidden master ONLY zone transfer to this chosen signer.

Configure your zones on the in-line signer as you have already noted.
You now have keying material only on the in-line signing system.
Protect it as you would anything valuable.

Set up any other existing servers as slaves of the in-line signer. In
this way, you will have only one server that needs to keep you DNSKEYs
safe, have keys updated in only one location, and actually do the "heavy
lifting" of signing on that one box.

I realize you say you only have two slaves at this point, but when the
third (or 12th) comes along, this centralization of signing is going to
make your life much easier.  You won't have to worry about key
distribution, keeping everything in sync as far as key rollover, etc.

Caveats:  This will create "single points of failure" that now includes
both your hidden master and the inline-signer.  If the inline-signer
falls over, the other slave(s) will continue to serve the zone data
until either the in-line signer is fixed, or the expire timer in the SOA
comes around and your zones all get deathly ill.   Add extra monitoring
to the "distribution master" so that you know immediately if it has issues.

If you were already doing all of this, carry on!  Highly recommended
solution!  If you are using another method, I'm curious as to your
configuration.

AlanC
___
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: allow-update in global options (was Re: bind and certbot with dns-challenge)

[Alan Clegg]

On 3/17/19 10:43 PM, Grant Taylor via bind-users wrote:
> On 3/17/19 6:31 PM, Alan Clegg wrote:
>> The change was an unintended consequence ending up in what was thought
>> to have been the correct behavior all along, so.. Yes.
>>
>> How many zones are you authoritative for?

> I think most people on this list have forgotten how to count as low as
> the number of zones that I am authoritative for.

Let me say that I didn't mean to disparage or discount small operators.
 I'm purely gathering data.  I personally have 10 zones that I am
authoritative for on 2 BIND instances, so I'm fighting the "small
operator" fight right along with everyone else.

Having said that, my $DAYJOB revolves (just a bit) around doing
BIND/DHCP stuff all day long, so I may have a leg up on being able to
twiddle with my configurations a bit more.  ;-)

Thanks for your input and I do agree that there will be people bitten by
this - it's now being discussed as to how to deal with this (both short-
and long-term).

AlanC
___
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: allow-update in global options (was Re: bind and certbot with dns-challenge)

[Alan Clegg]

On 3/18/19 6:53 AM, G.W. Haywood via bind-users wrote:

> I've been reading this exchange with growing frustration, and I hope a
> forthright response will be excused - especially since I now have to
> dash out to the hospital so I don't have more time to work on this.
> 
> On Mon, 18 Mar 2019, or possibly earlier, Alan Clegg wrote:
> 
>> The change was an unintended consequence ...
> 
> Please try not to let things like that escape into the wild, and
> please, please, NEVER turn them into deliberate actions purely for
> your own convenience.  If this means that you have to pull a release,
> then so what?  You've put me first.  That's fine by me.

You misunderstand what I was saying.

It was believed that "allow-update" was already disallowed - the code
being changed was just to add a message to better explain what was
happening.  The fact that this (seemingly non-related) change caused it
to come to the top was the "unintended consequence".

>> How many zones are you authoritative for?  Would it be a major
>> difficulty to (once) change the existing zones and then modify your
>> provisioning to add the "allow-update" option in the zone stanza?
> 
> Please don't even *think* questions like that.  Maybe you could code
> it yourself, and send the script out with the next release, and take
> the flack when it breaks, and next time, well, not do it.

Thanks for telling me what not to think or ask.

If I don't ask questions, I don't get answers.  I am attempting to help.
I am attempting to figure out the lay of the land so that we can have
good internal conversations at ISC.

There are so many different ways that people can write their
configuration files (because ISC over the years has tried to accommodate
as many user requirements as possible) that the thought of writing a
"one-code-fits-all" to cover all of the possible ways this may need to
be changed is rather daunting.

>> ... roasted because they don't read the release notes.
> 
> Seems to me that you don't care anything like enough about this.

You tell me what to think, then you tell me that I don't care.

That's crap.  As anyone that ever took my classes in the past will tell
you, I really DO care about the user experience and about our customers
and users.  Quite a few changes in BIND were brought forward from the
classes that I taught due to my interest in making things better.

If I didn't care, why I am putting myself out to the slings and arrows?
 If I didn't care, I would not have, on a Sunday, asked internal
engineers exactly what the thought process was that had lead us to where
we were.

It surprised me that this was occurring and I decided to take it to the
list in a very open and honest way.

Take the personal attacks elsewhere if you don't mind.

>> If we (ISC) base our changes on what we've gotten in response to the
>> surveys, we will make changes based on the fact that nearly all of the
>> somewhere around 20 people that use BIND are using Solaris.
>>
>> Not enough people actually respond to our surveys to base any real
>> changes on the results.
> 
> Apologies for speaking frankly, but that's a lie.
I would like an apology for this because I am not a liar.

But I won't hold my breath.

While I said that we have thick skins due to having done this for a
while, I never expected to be called a liar.  I do not believe that we
have met, and for that I am sorry because you might have a different
view of me, but this... wow.

I'm ignoring the rest for now.

Alan Clegg
ISC
___
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: allow-update in global options (was Re: bind and certbot with dns-challenge)

[Alan Clegg]

On 3/17/19 5:52 PM, Grant Taylor via bind-users wrote:
> On 3/17/19 2:37 PM, Alan Clegg wrote:
>> It turns out that this series of changes, taken as a whole, removed
>> allow-update as a global option.
> 
> That sounds like either an unintended consequence -or- a change in
> anticipated ~> expected behavior by some people.

The change was an unintended consequence ending up in what was thought
to have been the correct behavior all along, so.. Yes.

>> The question now becomes:  Is there a need for the ability to apply
>> allow-update across all zones in your configuration?
> 
> I use allow-update at the global options level.

How many zones are you authoritative for?  Would it be a major
difficulty to (once) change the existing zones and then modify your
provisioning to add the "allow-update" option in the zone stanza?

>> Smaller operators should be able to add the allow-update per zone very
>> easily, and large operators should (probably) be doing things at a
>> much more granular level.
> 
> Can I add allow-update per zone?  Yes.
> 
> Will I be annoyed at needing to add the allow-update to each zone?  Yes.
> 
> Even if the allow-update wasn't intended to function at the global
> options level, the point remains that it has done so and the current
> expected behavior is that it will continue to do so.

Ford Pinto Automobiles weren't meant to burst into flames when hit from
the rear either, but ... yeah, not really to the same level, but again,
I'm interested in how many people (and how big their zone lists are)
would have an issue with a one-time change.

> So, if there is an official change to the contrary of the unofficial
> behavior, I think that it needs to be VERY CLEARLY communicated.

When you say VERY CLEARLY communicated, to what level would you raise
this communication?  Would you consider having it in the release notes
good enough?

I remember when the "allow-recursion" default ACL was changed from "any"
to "localhost; localnets;" and a few people (big networks) didn't read
the release notes... yeah, even if you have things well documented,
somebody is going to get roasted because they don't read the release notes.

>> I'm sure that there will be internal discussion here at ISC regarding
>> this topic over the next week.
> 
> Good.
> 
> I look forward to hearing what the general consensus is.

And when 9.14.0 is released, you'll definitely know what it is, but I'm
hoping to have something to tell you before then.  ;-)

> If the consensus is that the new behavior is desired, I would hope ~>
> expect for a survey of the BIND user community like I've seen in the
> past about removing / significantly altering functionality.

If we (ISC) base our changes on what we've gotten in response to the
surveys, we will make changes based on the fact that nearly all of the
somewhere around 20 people that use BIND are using Solaris.

Not enough people actually respond to our surveys to base any real
changes on the results.

Please, to EVERYONE on the list, when you see a survey from us, help us
to make the experience that you are having with BIND better by filling
out the survey.

If anyone can tell me why we have such low response rates to our
surveys, please let me know that as well... WE NEED YOUR INPUT.

>> We are hoping to release 9.14.0 soon and this would be an "allowed"
>> change (at a .0 release).  If we don't make this change in 9.14.0, it
>> won't be allowed in an official production release until 9.16.0 due to
>> the "no changes to the configuration file except at .0 releases" rule.
> 
> Hum.  I'd hate to think that do to misfortune of timing, we'd be stuck
> with this unexpected / inconsistent with prior version behavior until
> 9.16.0 came out.

No, the misfortune here is that if we DON'T put it in now, we will have
to wait for 9.16.0.  I'm guessing that if it goes into 9.14.0, it won't
be coming back out - there will be the "moment of pain" when people
change to the new option structure and then "voila", it's all over.

To change the current "we don't allow allow-updates in global options"
at this point will require a code change.  We are in code-freeze, so to
revert to the other behavior will delay the release of BIND 9.14.0.

>> At this moment, I (personally) believe that the change is fixing a
>> bug, as "allow-update" was not planned and is not a good idea at the
>> global option level.  I believe that it should be allowed only in zone
>> stanzas.
> 
> Opinions aside, the fact is that it has worked as a global option
> historically and this is a non-trivial change in behavior.

I agree that it has worked that way in the past, however, I do not
consider it to be non-trivial from the operations per

allow-update in global options (was Re: bind and certbot with dns-challenge)

[Alan Clegg]

On 3/17/19 2:51 PM, Alan Clegg wrote:
> On 3/17/19 7:13 AM, Stephan von Krawczynski wrote:
>> Hello all,
>>
>> I am using "BIND 9.13.7 (Development Release) " on arch linux. Up
>> to few days ago everything was fine using "certbot renew". I had
>> "allow-update" in nameds' global section, everything worked well. Updating to
>> the above version threw a config error that "allow-update" has no global 
>> scope
>> and is to be used in every single zone definition.
> 
> And you may have found a bug.  I'm checking internally at this time.

So, after a discussion with one of the BIND engineers this afternoon,
this turned out to be quite an interesting and deep-rooted issue.

During a cleanup of other code (specifically named-checkconf), code was
changed that enforced what was believed to have been the default
previously: specifically, allow-update was only allowed in zone stanzas.
 The chain of changes follows:

5136.   [cleanup]   Check in named-checkconf that allow-update and
allow-update-forwarding are not set at the
view/options level; fix documentation. [GL #512]

This, if the change remains, will be updated to [func] and additional
documentation will be added to the release notes.

The other changes down this long and twisting passage are:

4836.   [bug]   Zones created using "rndc addzone" could
temporarily fail to inherit an "allow-transfer"
ACL that had been configured in the options
statement. [RT #46603]

and

2373.  [bug]   Default values of zone ACLs were re-parsed each
   time a new zone was configured, causing an
   overconsumption of memory. [RT #18092]

It turns out that this series of changes, taken as a whole, removed
allow-update as a global option.

The question now becomes:  Is there a need for the ability to apply
allow-update across all zones in your configuration?

Smaller operators should be able to add the allow-update per zone very
easily, and large operators should (probably) be doing things at a much
more granular level.

I'm sure that there will be internal discussion here at ISC regarding
this topic over the next week.

We are hoping to release 9.14.0 soon and this would be an "allowed"
change (at a .0 release).  If we don't make this change in 9.14.0, it
won't be allowed in an official production release until 9.16.0 due to
the "no changes to the configuration file except at .0 releases" rule.

At this moment, I (personally) believe that the change is fixing a bug,
as "allow-update" was not planned and is not a good idea at the global
option level.  I believe that it should be allowed only in zone stanzas.

If you have thoughts/opinions, please let us know!

Alan Clegg, ISC
___
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 certbot with dns-challenge

[Alan Clegg]

On 3/17/19 7:13 AM, Stephan von Krawczynski wrote:
> Hello all,
> 
> I am using "BIND 9.13.7 (Development Release) " on arch linux. Up
> to few days ago everything was fine using "certbot renew". I had
> "allow-update" in nameds' global section, everything worked well. Updating to
> the above version threw a config error that "allow-update" has no global scope
> and is to be used in every single zone definition.

And you may have found a bug.  I'm checking internally at this time.

> And this brought me here with one question: why is it that bind/named does not
> evolve to a really useable nameserver for the most use-cases _today_, but
> instead gets more unusable with every new release?

Please provide input.  BIND is open source and is available for requests
etc. via gitlab.  We don't INTENTIONALLY make it "more unusable with
each release, but without your input we may be doing things that seem
good from the implementation side, but not from the operations side.

Provide input!  You'll help shape the world!

> I mean, sure you can use it perfectly, only not good if hosting hundreds or
> thousands domains - only this small change I just described lets your config
> file grow massively -, only not good if you want to implement something like
> blacklists, not good for an adblocker and so on.

I'm not sure how this relates.  Please feel free to follow up here (on
in Gitlab) with a bit more including "this configuration worked great
and is operationally what we need, but you broke it.  We do take
constructive criticism (and we also have thick skins, having been at it
as long as we have).

> But all that would be dead easy to do, iff really wanted.
> So why is it, that there is no global way of defining default zone
> definitions which are only overriden by the actual zone definition?

Some options just don't make sense at the global level.  Those are only
available at the view or zone level.

> Why is there no way to define a hosts-type-of-file with an URL-to-IP list?

Because DNS data only deals with DNS data and not URLs?   Again, give an
example of what you want, it will be considered and may actually appear
as a feature in future releases.  (this one, I doubt, however).

> Do you really want people to define 50.000 zones to perform adblocking?
> Configs have to be reloaded every now and then, is there really no idea how to
> shorten things a bit?

RPZ works at a global level.  Again, not sure what this question means.

> Don't get me wrong, bind is great (ok, collapsing during runtime since last 2
> updates, but ...).

Did you report these "collapses"?  This is the type of thing that tends
to happen when your distribution runs "Development Release" code.

> Nevertheless there are some things that can be enhanced quite a bit.

Tell us!  Help us!  Together we can be stronger!

Alan Clegg, ISC

___
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: DNS load balancing: UDP or TCP ?

[Alan Clegg]

On 2/20/19 10:22 AM, Alan Clegg wrote:
> On 2/20/19 7:55 AM, Roberto Carna wrote:
> 
>> DNS clients send a UDP query to a DNS server, if no response is received
>> until some seconds, then they try with UDP.
>> You tell me this is not true, just clients try with UDP is the response
>> is truncated.
> 
> Tony is correct, the first paragraph above IS NOT TRUE.

Assuming that the first paragraph above was re-written to the way it was
in the original post which was (something along the lines of):

> DNS clients send a UDP query to a DNS server, if no response is
> received until some seconds, then they try with TCP.

I really don't like this pair of threads (this one and the one with no
subject line).

Answers have been given.  The people here are WAY smart.  Test and verify!

AlanC
___
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: DNS load balancing: UDP or TCP ?

[Alan Clegg]

On 2/20/19 7:55 AM, Roberto Carna wrote:

> DNS clients send a UDP query to a DNS server, if no response is received
> until some seconds, then they try with UDP.
> You tell me this is not true, just clients try with UDP is the response
> is truncated.

Tony is correct, the first paragraph above IS NOT TRUE.

Truncation is a situation in which the server responding to a client
provides a message that won't fit in the specified packet size that the
specification (and possibly the client, but I won't get into that here)
has set for the response, thus providing a response that does not
contain the entire response and sets the header bit TC=1.

This has nothing to do with TCP vs. UDP in the initial query.  There is
no fallback from UDP to TCP when the initial UDP query times out.

Please read up on `dnsdist` and give it a try.

Thanks!
AlanC
___
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: Forward zone inside a view

[Alan Clegg]

On 2/7/19 2:30 PM, Roberto Carna wrote:
> Dear, thanks for your contact. I've used teamviewer.com
>  just for tests.
> 
> Desktops I mentioned can only access to web apps from internal domains,
> but in some web apps there are links to download Teamviewer client
> software from Internet. I can create a private zone "teamviewer.com
> " with all the hostnames and IP's we will use,
> but if they change I will be in trouble.

Sounds to me like a use for a global block with RPZ and a passthrough
for the domain that needs to be ... uh ... passed through.

And from my experience, this is never going to work because whatever the
"only thing we want to resolve" is, it will rely on something else that
you don't (currently) resolve.

Anyone that has ever tried to block their "smart TV" so that it only
allows certain apps but not others will know exactly what I'm talking about.

AlanC
___
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: incorrect section name: $ORIGIN

[Alan Clegg]

On 2/4/19 9:47 AM, Alan Clegg wrote:
> On 2/4/19 7:03 AM, @lbutlr wrote:
> 
>> # nsupdate -d -v -l example.com
>> Creating key...
>> namefromtext
>> keycreate
>> incorrect section name: $ORIGIN
> 
> I'd recommend that you use nsupdate in interactive mode first.


The point of this which I had forgotten by the time I got done with the
examples was:

The file that you pass in to `nsupdate` is the "update add" and "update
delete" commands that I gave samples of in the previous mail.

Also, you probably don't want/need the "-v" command line option on nsupdate.

AlanC
___
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: incorrect section name: $ORIGIN

[Alan Clegg]

On 2/4/19 7:03 AM, @lbutlr wrote:

> # nsupdate -d -v -l example.com
> Creating key...
> namefromtext
> keycreate
> incorrect section name: $ORIGIN

I'd recommend that you use nsupdate in interactive mode first.

--SNIP--
root@svlg-gateway:/etc/namedb# nsupdate -l
> update add funnyrecord.boat 3600 in a 1.1.1.1
> send
> quit
--SNIP--

Here, I've added an A record "funnyrecord.boat" to the local nameserver.
 It was accepted (no error message) and the record was signed:

--SNIP--
root@svlg-gateway:/etc/namedb# dig funnyrecord.boat +dnssec

; <<>> DiG 9.13.5 <<>> funnyrecord.boat +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35274
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 840786d22b259dd36f9300b85c584de5adea6d3ab34b6fde (good)
;; QUESTION SECTION:
;funnyrecord.boat.  IN  A

;; ANSWER SECTION:
funnyrecord.boat.   3600IN  A   1.1.1.1
funnyrecord.boat.   3600IN  RRSIG   A 8 2 3600 20190306143508 
20190204133508
27363 boat. ULJiOVWd3jordtZZnp/1wUZul8Y6xLcEu0kh8mtCDFXGG2QlsKdyeZxb
dO54X241NOJRN6dI2RKH05DtErlhFHjLpnrus4BahuZKbWeuOXApCZ4r
+XPqManyq+3hyEFCJ8QM1fHSBbuDIyz7nKjr+T+xh/8pUowqNgMoBx+Y 08c=

;; Query time: 1 msec
;; SERVER: 44.127.8.1#53(44.127.8.1)
;; WHEN: Mon Feb 04 14:36:21 UTC 2019
;; MSG SIZE  rcvd: 253
--SNIP--

I can also remove records:

--SNIP--
root@svlg-gateway:/etc/namedb# nsupdate -l
> update delete funnyrecord.boat
> send
> quit
root@svlg-gateway:/etc/namedb# dig funnyrecord.boat +dnssec

; <<>> DiG 9.13.5 <<>> funnyrecord.boat +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16202
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 044b781a89250d108be3c3345c584e25b636b5386f74056a (good)
;; QUESTION SECTION:
;funnyrecord.boat.  IN  A

;; AUTHORITY SECTION:
boat.   300 IN  SOA admin. ns1.boat. 169 3600 600 
86400 300
boat.   300 IN  RRSIG   SOA 8 1 8600 20190306143720 
20190204133720 27363
boat. rx9ZfD6u9O5Hz1+1KkUnr0kqq8k45ljYmTQj1kFb6xQ7HFG13XkMkzbl
DDzjAoO1BIymYm8S1Kxq5lMXPNvAnPEChlhRW6xWVnWg4UyWnkzkzRCc
hME2NdE4WxSDZ3MMAnEELk29whmYcPIKVQJPgYjtHFJ7KS23PgoWb0qp ciA=
boat.   300 IN  NSECalans-time-capsule.boat. NS SOA 
RRSIG NSEC DNSKEY
TYPE65534
boat.   300 IN  RRSIG   NSEC 8 1 300 20190222045229 
20190123035229 27363
boat. AevHxXgaJkotnUTv1jUJnBigUjkUO4gcI/V5AieuCR4cBdxMiRYa1WYS
pI+qPQcAzgTf7p/0RCXq45CVrjiXCoh/eEaQgxlqASSCTabCgVE9i0Dw
eVgE6NDXe4gtu3GEjhecCj3x3Xd2q6DEWYYQNJkg6fjjZr8xYCsjdYhw V88=
canboat.boat.   300 IN  NSECGoogle-Home-Mini.boat. A TXT 
RRSIG NSEC
canboat.boat.   300 IN  RRSIG   NSEC 8 2 300 20190306143720 
20190204133720
27363 boat. RGLL6h/nX4/MMt+b2w9BA8LAg3R+5oXn73KG6DAKP57Q1Ak+NyFBYeil
4Pkz5w7qgA4k4nRrriTJ0kmckTlaODfx1KWZEOR33nqctK37lOIaenmx
Rd7d98qP7/+A0v68T5DSXI9ZNlx5688isxXo2ZTLP2bKFEWYbDZXBEtr DdM=

;; Query time: 1 msec
;; SERVER: 44.127.8.1#53(44.127.8.1)
;; WHEN: Mon Feb 04 14:37:25 UTC 2019
;; MSG SIZE  rcvd: 741
--SNIP--

Those are the basic things you can do with nsupdate... add and delete.
Changes are done by deleting the old and then adding the new.

The SOA record is updated automatically and all is well with the world.

AlanC
___
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: Refresh of the .signed DNSSEC file?

[Alan Clegg]

On 2/2/19 7:54 AM, @lbutlr wrote:
> Based having update-policy local; auto-dnssec maintain; in the zone,
> when I make changed to example.com I was expecting that
> example.com.signed will be refreshed.
> 
> This doesn’t seem to be happening.
> 
> I just went through several domains and changed the serial number and
> removed an old subdomain (ftp) from them, did an rndc reload, and …
> nothing.
> 

Since you are using "update-policy local;", when you make changes with
"nsupdate -l", does the right thing happen?

AlanC
___
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: SSHFP observation

[Alan Clegg]

On 1/31/19 7:19 PM, Mark Andrews wrote:

>> Question: How does named (actually 'dig') know that any given data (in
>> this case "AA") can't be a fingerprint?
>> Difficulty: You are only allowed to use the information provided in RFC
>> 4255 and errata in your answer.
> 
> Mathematics.  I’ll presume I can use all of the RFC some of which state
> minimum sizes for cryptographic hashes.  Developers are expected to use
> all their knowledge.

Developers are supposed to follow the RFC.  For "future proofing", I
can't see adding a constraint that isn't in the RFC.

> There is no minimum size on that field though clearly 8 bits
> is insane. Is a empty field allowed?

I'm not going to question anyone's sanity.  We do DNS for a living.  How
sane is that?  Hm?  Yeah, thought so.

>> My reading: The RFC doesn't specify what a fingerprint is other than "an
>> opaque octet string [..] which is placed as-is in the RDATA fingerprint
>> field.”
> 
> It also specifies that 1 is SHA-1 and there is a followup RFC that specifies
> 2 is SHA256.  In this case the record is clearly wrong as it is too short
> to be SHA1.

That means that we have a BUNCH of "still to be allocated" algorithms.
I'm not smart enough to say exactly what they are going to need to
encode in that "fingerprint" field other than something encoded in hex.
 One byte?  More?  Sure!

The RFC doesn't specify a minimum,  named doesn't enforce a two-byte
minimum - what are we arguing about again?

Oh yeah... dig doesn't like one byte.

So... WHY are we arguing about this?
___
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: SSHFP observation

[Alan Clegg]

On 1/31/19 6:44 PM, Lee wrote:
> On 1/31/19, Alan Clegg  wrote:
>> On 1/31/19 4:57 PM, Mark Andrews wrote:
>>
>>> Given type 1 is a SHA-1 fingerprint it isn’t legal.  Named just
>>> hasn’t added type to length to the parsing code.
>>>
>>> No real SSHFP will be 1 octet long.
>>
>> While I agree that it's junk, the RFC doesn't give the DNS software the
>> ability to make that decision from my reading.
>>
>> There is nothing in the RFC about validating the correctness of the data:
> 
> I'm not following your logic.  The RFC says a field is the fingerprint
> and the user supplied data can't possibly be a fingerprint.  It seems
> to me there's a requirement to reject the user supplied data since it
> can't possibly be a fingerprint.

Question: How does named (actually 'dig') know that any given data (in
this case "AA") can't be a fingerprint?

Difficulty: You are only allowed to use the information provided in RFC
4255 and errata in your answer.

My reading: The RFC doesn't specify what a fingerprint is other than "an
opaque octet string [..] which is placed as-is in the RDATA fingerprint
field."

To be fair, the RFC does point off to the SSH TLS documentation.  If we
wander off into that realm, we may want to start considering validating
that the hex data is a crypto. valid fingerprint, etc. etc.

That's the way I read it.

In any case, either:
  1)  named should not load the zone
it's just as bad as an A record with 5 octets
(this is a bug in named)
or
  2)  dig should provide the correct decoding of the
data provided to it by named.
(this is a bug in dig)

I don't care which, but I'm leaning towards #2.

And no, an empty field is NOT allowed due to the same logic as "My
reading" above (answering Mark's question that came in while I was
researching and typing this)

Be well, all.

AlanC
___
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: SSHFP observation

[Alan Clegg]

On 1/31/19 4:57 PM, Mark Andrews wrote:

> Given type 1 is a SHA-1 fingerprint it isn’t legal.  Named just
> hasn’t added type to length to the parsing code.
> 
> No real SSHFP will be 1 octet long.

While I agree that it's junk, the RFC doesn't give the DNS software the
ability to make that decision from my reading.

There is nothing in the RFC about validating the correctness of the data:

--
   The RDATA of the presentation format of the SSHFP resource record
   consists of two numbers (algorithm and fingerprint type) followed by
   the fingerprint itself, presented in hex, e.g.:

   host.example.  SSHFP 2 1 123456789abcdef67890123456789abcdef67890
--

AlanC
___
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: SSHFP observation

[Alan Clegg]

On 1/31/19 2:16 PM, Alan Clegg wrote:

> Ok, fair point.  I'll bring it up with the BIND team.
> 
> If I don't return in 2 weeks, send in a search party.

After a bit of discussion:

   https://gitlab.isc.org/isc-projects/bind9/issues/852

has been re-opened.  I still think it's a junk fingerprint, but it does
appear to me to be legal per-RFC.

AlanC
___
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: SSHFP observation

[Alan Clegg]

On 1/31/19 1:12 PM, Matus UHLAR - fantomas wrote:

> On 31.01.19 12:33, Alan Clegg wrote:
>> These are not valid SSH Fingerprints.
>>
>> Garbage in, garbage out.
>>
>> I see no bug.
> 
> well, either BIND should reject those records as invalid and not to send
> them, or dig (from bind package) should not complain about malformed
> responses.

Ok, fair point.  I'll bring it up with the BIND team.

If I don't return in 2 weeks, send in a search party.

AlanC
___
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: SSHFP observation

[Alan Clegg]

On 1/31/19 12:30 PM, rams wrote:
> Thank you Mukund,Jim and Alan to look my issue.
> 
> We are seeing the issue only when sshfp fingerprint value less than 4
> characters.
> 
> It is working fine value with >=4 characters.

These are not valid SSH Fingerprints.

Garbage in, garbage out.

I see no bug.
___
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: Fwd: SSHFP observation

[Alan Clegg]

On 1/31/19 10:56 AM, Jim Popovitch via bind-users wrote:
> est1.ramesh-sshfp.com. 86400   IN  SSHFP 1 1 aa
> test2.ramesh-sshfp.com. 86400   IN  SSHFP 1 1 00

When I use these exact lines (with the "aa" and "00"), I get just what
he did.

When I use lines with correct SSHFP values, they work fine:

svlg-gateway IN SSHFP 1 2
5d0d289579841c3f158d5d6e3f9358d6ffa72f4e8a4625480e1502471121
svlg-gateway IN SSHFP 2 2
dbe0bb71cdcc3179a63a39e924c54b7884058318219f76ddc502f4d0b56f9041
svlg-gateway IN SSHFP 3 2
6fae021dd9c8d84448a0a15623751a1e35e56f5aa2d86193097b6d1008c14c42
svlg-gateway IN SSHFP 4 2
da6681ec8d06d7da14121bf717849c4044a1ccdac9a8a6398ceb1de1cafd5d3f
test1   SSHFP 1 1 aa
test2   SSHFP 1 1 00


root@svlg-gateway:/etc/namedb/zone# dig test1.boat sshfp
;; Warning: Message parser reports malformed message packet.

; <<>> DiG 9.13.5 <<>> test1.boat sshfp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41738
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: Message has 42 extra bytes at end

;; QUESTION SECTION:
;test1.boat.IN  SSHFP

;; Query time: 1 msec
;; SERVER: 44.127.8.1#53(44.127.8.1)
;; WHEN: Thu Jan 31 16:25:27 UTC 2019
;; MSG SIZE  rcvd: 82

root@svlg-gateway:/etc/namedb/zone# dig svlg-gateway.boat  sshfp

; <<>> DiG 9.13.5 <<>> svlg-gateway.boat sshfp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36644
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: fc5043961ba7f3de20111bd95c5321822d0203038e0ff9df (good)
;; QUESTION SECTION:
;svlg-gateway.boat. IN  SSHFP

;; ANSWER SECTION:
svlg-gateway.boat.  300 IN  SSHFP   3 2
6FAE021DD9C8D84448A0A15623751A1E35E56F5AA2D86193097B6D10 08C14C42
svlg-gateway.boat.  300 IN  SSHFP   2 2
DBE0BB71CDCC3179A63A39E924C54B7884058318219F76DDC502F4D0 B56F9041
svlg-gateway.boat.  300 IN  SSHFP   1 2
5D0D289579841C3F158D5D6E3F9358D6FFA72F4E8A4625480E15 02471121
svlg-gateway.boat.  300 IN  SSHFP   4 2
DA6681EC8D06D7DA14121BF717849C4044A1CCDAC9A8A6398CEB1DE1 CAFD5D3F

;; Query time: 1 msec
;; SERVER: 44.127.8.1#53(44.127.8.1)
;; WHEN: Thu Jan 31 16:25:38 UTC 2019
;; MSG SIZE  rcvd: 258
___
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 has a database option instead of zone files?

[Alan Clegg]

On 1/27/19 1:42 AM, rams wrote:
> Does Bind has a database option to read zones [if zones are in database]
> instead  of zone files? if yes , how to setup? can someone help me.

A search with the terms "bind backend database" provides a number of
resources that might interest you.

Now, if you come back with a problem

AlanC
___
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: DNSEC and Bin 9.12

[Alan Clegg]

On 1/26/19 2:30 PM, @lbutlr wrote:
> On 26 Jan 2019, at 12:20, @lbutlr  wrote:
>> I then removed "auto-dnssec maintain" and "inline-signing yes" from the zone 
>> record in name.conf and now everything is behaving as expected when I query 
>> localhost for the DNSSEC info.
> 
> I should have said, I have update-policy local; in the zone record, but if I 
> add "inline-signing yes;" and/or "auto-dnssec allow;" then the query fails.

I have the following snippet in my named.conf and it works great:

zone "boat" {
type master;
file "zone/boat";
update-policy local;
auto-dnssec maintain;
notify no;
};

This is a "fake TLD" for "boat" that I maintain locally (on my boat).

It is DNSSEC signed, updates signatures automatically (as needed) and is
able to be updated locally (nsupdate -l).

I created the keys using something along the lines of:

root@svlg-gateway:~# dnssec-keygen -a rsasha256 boat
Generating key pair...+ ..+
Kboat.+008+41586
root@svlg-gateway:~# dnssec-keygen -f k -a rsasha256 boat
Generating key
pair+
.+

then, making sure that the keys were in the directory specified by
key-directory option, I did an "rndc loadkeys".

With the appropriate trust anchors in place, data in the zone validates.

Does this help at all?  If not, can you be a bit more detailed in the
problem you are trying to solve?

AlanC
___
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 Service

[Alan Clegg]

On 1/22/19 10:12 AM, Jordan Tinsley wrote:

> Just wondering how to get the named service setup when compiling from
> source?

I'm kinda old school, but adding "/usr/local/sbin/named" to
/etc/rc.local has always worked for me.

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

Tuning BIND servers - looking for operational experience

[Alan Clegg]

Greetings, BIND Operators!

As the maintainers of BIND, ISC is often approached by users of our
software asking about tuning for maximized performance.  To assist in
this, we are working on a number of knowledge base articles and we are
asking for community input.

The majority of "high-performance" operational experience within ISC
revolves around two very specialized endeavors, F-Root
(https://www.isc.org/f-root/) and the ISC Performance Lab
(https://www.isc.org/blogs/isc-performance-lab/).  While both of these
are "high performance" offerings, the reality is that they match a very
tiny demographic as far as operational usefulness goes.

What I would like to ask of the community is for real-world experience -
what did you do to "make BIND run better/faster/stronger"?  Have you
come across the "magic sysctl setting" that took your performance from
10kqps to 50kqps?  Did you find anything that was detrimental to your
performance that was surprising?  Any interesting "sweet spots" in
tunable settings that you found that might be useful to others?

If you want to create a thread here, that's fine or I'm more than
willing to take direct input via e-mail.  Please do note that the goal
of this is to create a document that assists the community-at-large and
your input will be used (with credit!) to that end.

Thanks!
AlanC
___
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

[Alan Clegg]

On 9/28/18 9:26 AM, Alex wrote:

>> Has your provider enabled qos?  I'd bet their dropping packets that
>> exceed qos rate limits would be considered "working as expected".
> 
> I asked and they had no idea what that even meant. The technician that
> was here replacing the modem also had no idea outside of what the
> hardware does.

You may want to consider buying a VPS somewhere other than behind the
modem at your (assumed) residence.

There are lots of 'em, some costing less than $5/month for a decent
little box (I have several scattered around the world) and when you have
a problem, they have a good chance of understanding what you are asking.

AlanC
-- 
Why don't we wander and follow la vie dansante.
___
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: My IXFR/AXFR stopped suddenly

[Alan Clegg]

On 7/7/18 12:25 AM, Blason R wrote:
> Well, I just tried transferring zone using dig and it was successful
> from slave
> 
> On slave
> dig AXFR block.now @xx.xx.xx.xx
> 
> On master xfer-out.log
> 
> 07-Jul-2018 09:53:11.520 client xx.xx.xx.xx#16129 (immediate.block):
> transfer of 'block.now/IN': AXFR started (serial 2018061016)
> 07-Jul-2018 09:53:11.521 client xx.xx.xx.xx#16129 (immediate.block):
> transfer of 'block.now/IN': AXFR ended
> 

This isn't using port 15455.

AlanC
-- 
Why don't we wander and follow la vie dansante.



signature.asc
Description: OpenPGP digital 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

Re: inline-signing: SOA serial out of sync

[Alan Clegg]

On 6/14/18 9:44 AM, Matthew Pounsett wrote:

> It just happened again. An included zone file has been changed from
> 2 TLSA RRs to one:

[...]

> This now sounds very different from the original report.  Are you saying
> that the zone started with two TLSA records, you changed it to have only
> one, reloaded the zone, but then none were present?
> 
> That's a very different problem from just not picking up a zone update.
> 
> Have you checked the logs for errors during zone loading?  

Additionally, I read this as "the records changed are in an included
file" -- is the serial number in the "including" zone being incremented?

AlanC



signature.asc
Description: OpenPGP digital 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

Re: "Hiding" version.bind in /etc/bind/named.conf.options doesn't work

[Alan Clegg]

On 2/28/18 10:57 AM, Bob Harold wrote:

> Those instructions assume that the  /etc/bind/named.conf.options file
> is 'included' in the main named.conf file.
> Just add the "version" line to your named.conf file options section.

[...]

> So my config file is at:
> /replicated/jail/named/etc/named.conf

Beware, however of modifying "base" files that were installed by the
package management system.  If you change /etc/named.conf and it gets
overwritten by your next package based upgrade (or the modified file
causes your automated upgrade system to stop upgrading that package),
you will be badly surprised.

(been there, done that, have the scrapes and bruises)



signature.asc
Description: OpenPGP digital 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

Re: SOA settings

[Alan Clegg]

On 2/2/18 2:57 PM, Warren Kumari wrote:

> Hopefully Lewis knows / understand that we are just squabbling amongst
> ourselves because we've know each other for a long time and this is in
> good humor.

Wait... who are you guys??!?

Happy Friday!



signature.asc
Description: OpenPGP digital 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

Re: DNSTAP output file rolling trouble in BIND 9.12.0rc1

[Alan Clegg]

Looks like something that ISC would like to have logged as a bug...  And
a perfect thing to find in rc1. 8-)

AlanC

On 1/2/18 3:00 PM, Jay Ford wrote:
> I'm having some odd trouble with DNSTAP output file rolling in BIND
> 9.12.0rc1.
> 
> I have named built like:
>    BIND 9.12.0rc1 
>    running on Linux x86_64 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-1
> (2016-03-06)
>    built by make with 'STD_CDEFINES=-DISC_FACILITY=LOG_LOCAL5'
> '--libdir=/usr/lib/x86_64-linux-gnu' '--with-openssl' '--enable-dnstap'
> '--enable-fixed-rrset' '--disable-openssl-version-check'
> '--with-libtool' '--enable-dnsrps'
>    compiled by GCC 6.3.0 20170516
>    compiled with OpenSSL version: OpenSSL 1.1.0f  25 May 2017
>    linked to OpenSSL version: OpenSSL 1.1.0f  25 May 2017
>    compiled with libxml2 version: 2.9.4
>    linked to libxml2 version: 20904
>    threads support is enabled
> 
> I have DNSTAP configured like:
>    dnstap {
>   client query;
>    };
>    dnstap-output file "tmp/dnstap.out" versions 10 size 10m;
> 
> It mostly works as expected, except that named:
>    o  logs twice about rolling the file every time, such as:
>  Jan  2 05:15:42 named[24758]: dnstap: info: rolling dnstap
>     destination 'tmp/dnstap.out'
>  Jan  2 05:15:42 named[24758]: dnstap: info: rolling dnstap
>     destination 'tmp/dnstap.out'
>    o  sometimes crashes after logging that, possibly after rolling the file
>    o  writes to multiple output files simultaneously, such as:
>  ls -lt dnstap* | head -2
>  -rw-r--r-- 1 bind bind  1282048 Jan  2 16:24 dnstap.out
>  -rw-r--r-- 1 bind bind  1273856 Jan  2 16:24 dnstap.out.0
>   & 2 minutes later:
>  ls -lt dnstap* | head -2
>  -rw-r--r-- 1 bind bind  1286144 Jan  2 16:26 dnstap.out
>  -rw-r--r-- 1 bind bind  1277952 Jan  2 16:26 dnstap.out.0
> 
> This system had 4 worker threads in use.  Another similar system with
> only 1 thread does not have such trouble, which got me wondering about
> problems with threads & DNSTAP, specifically output file rolling. 
> Reducing the threads on the afflicted system (via named option "-n 1")
> seems to avoid the problem, but it's a little early to tell, & it's not
> a desirable fix.
> 
> I'd appreciate it if somebody who knows the code would comment on the
> threads vs DNSTAP possibility or point me in some other direction to
> figure this out.
> 
> I have a named core file & can provide more config... details if required.
> 
> 
> Jay Ford, Network Engineering Group, Information Technology Services
> University of Iowa, Iowa City, IA 52242
> ___
> 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



signature.asc
Description: OpenPGP digital 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

Re: bind-users Digest, Vol 2770, Issue 2

[Alan Clegg]

On 11/21/17 12:05 PM, Ron Wingfield wrote:
> . . .well, I never expected to get "flamed" as by GED, "/As a general
> observation, not knowing what you're doing is dangerous
> on the Internet.  Please take some time out of your undoubtedly busy
> life to try to ensure that you aren't a menace to the rest of us.  A
> good start might be to read the famous DNS and BIND/."
> 
> Actually I have two copies of Cricket Liu's book, both 4th and 5th
> edition.  (4th ed. autographed.)
I worked with Cricket and owning books is worthless without understanding.

> Regardless, the reason for two name servers pointing to the same IP
> address is because the domain registrar requires two designated name
> servers; so since we only have the one platform running DNS with BIND
> Version: 9.10.2 Perhaps in the future a second installation may be
> incorporated.

Buy a $5/month VPS from Linode, Digital Ocean, or whatever.

The reason for the "two servers" is a valid one.

AlanC



signature.asc
Description: OpenPGP digital 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

Re: What is wrong with my second $ORIGIN

[Alan Clegg]

On 9/14/17 8:35 AM, Reindl Harald wrote:


>> so that it doesn't matter whether you have the trailing . or not.
>>
>> Downside, of course, is that you have to repeat your domain name about a
>> gazillion times.
> 
> scripting is the better answer

Dynamic zones is the better, better answer.  8-)

Have a great day!
AlanC



signature.asc
Description: OpenPGP digital 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

Re: Testing...

[Alan Clegg]

On 8/30/17 12:44 PM, Tony Finch wrote:

> There are reasons I am no longer a postmaster...

And they all said Ramen...

AlanC



signature.asc
Description: OpenPGP digital 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

Re: Testing...

[Alan Clegg]

On 8/30/17 11:25 AM, Adamiec, Lawrence wrote:
> I see your email on the list.

Thanks to those that have responded both on- and off-list.

It appears that I just don't see my own posts for whatever reason.  8-)

[You know how long it's been since I debugged a mailing list issue??!]

No additional responses needed at this time.

AlanC



signature.asc
Description: OpenPGP digital 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

Testing...

[Alan Clegg]

I don't think I can post to this list for some reason.

I'd like to be able to respond to questions, but my responses never seem
to show up...

this is just a test to see if I am visible on the list.

Thanks!
AlanC



signature.asc
Description: OpenPGP digital 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

Re: Can bind works without defining root servers

[Alan Clegg]

Root hints have been built in forever.  (and that's "forever" in
Internet years)

On 8/15/17 10:58 AM, Duleep Thilakarathne wrote:
> Hi,
> 
> I can observe, bind can resolve host names without following entry  in
> named.conf. could anyone help me to understand this default behavior.
> 
> 
> zone "." {
>   type hint;
>   file "root.servers";
> };
> 
> regards
> DT
> 
> 
> ___
> 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
> 



signature.asc
Description: OpenPGP digital 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

Re: header intact

[Alan Clegg]

But body missing.

On 7/19/17 4:30 AM, Moosa Karimulla Shaik wrote:
> 
> 
> -- 
> 
> Thanks
> 
> Moosa Karimulla Shaik.
> Cont: +91-9642451252
> 
> 
> ___
> 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
> 



signature.asc
Description: OpenPGP digital 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

Re: difference in responses between UDP and TCP

[Alan Clegg]

On 6/15/17 6:20 AM, Arun Natarajan wrote:
> Hello,
> 
> Wondering why we are seeing different serial numbers from a bind
> authoritative server for requests over UDP and TCP.
> 
> dig +tcp soa @ns.example.com  example.com
>  +short
> ns1.example.com . hostmaster.example.com
> . 2017061505 10800 3600 360 3600
> 
> dig +notcp soa @ns.example.com  example.com
>  +short
> ns1.example.com . hostmaster.example.com
> . 2017061506 10800 3600 360 3600
> 
> any idea?

Twelve.



signature.asc
Description: OpenPGP digital 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

Re: Troubleshooting BIND stops responding

[Alan Clegg]

On 3/30/17 6:02 AM, Mark Elkins wrote:
> Stopping right here, Recursive lookup and Authoritative services are
> completely different services - and require different servers
> (preferably, though you could run multiple incidents of nameservers on a
> single server - but that can get ugly).

Actually, no.  Running both recursive and authoritative does not require
different servers and does not require running multiple instances of
bind.  It's not recommended, but it's not hard, and it has worked for
lots of people for lots of years.

> Your two recursive servers should remain as recursive servers, only
> giving replies to your customer base. When you start running DNSSEC,
> this becomes even more important, a recursive server running as an
> authoritative server for a zone can not give a proper DNSSEC reply when
> asked about Zones carried in its config.

Actually, the only thing it doesn't do is the validation.  It gives
responses just fine as long as you aren't validating your own data.
Trusting the "AD" bit is a great concept, but you really want to
validate as close to the end-point as possible.

> Rather keep things simple.
> 
> I would presume that you have multiple authoritative servers for your
> "vtt.net" domain. If you need more redundancy, add in more authoritative
> nameservers or better still an AnyCast instance. Even any of your local
> Authoritative Nameservers should ask your recursive servers when they
> need to look up information that is not part of the Zones they manage.
> Enough of the preaching.

Interesting to go from "keep things simple" to "let's use anycast" in
three sentences.

Too many people are trying to solve problems that don't exist with
additional complexity that cause additional issues elsewhere in the
network stack.  If your nameserver has issues with basic responses, good
luck debugging that while also dealing with routing problems in your
network and wondering which server you should actually be looking at.

Sorry to sound like an old grouch, but I'm really feeling like and old
grouch these days.

> If you were to run IPv6, a number of errors would disappear, otherwise
> force BIND not to do any IPv6. Adding IPv6 though would be preferable.  ;-)

Keep things simple... When your nameserver isn't responding, don't think
about running IPv6, fix the problem at hand.  And "if you run IPv6, a
number of errors disappear".  I'm just shaking my head.

> Don't think though that any of this is causing your problem. You could
> always upgrade your version of BIND. On my Gentoo Laptop, I'm  running
> BIND 9.11.0-P3, so you are a bit behind.

And there is the useful nugget.

Yes, OP, see if your problems continue once you upgrade.

AlanC



signature.asc
Description: OpenPGP digital 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

Re: Bind failing to start on new 9.9.4 server

[Alan Clegg]

On 2/9/17 8:53 AM, Robert Moskowitz wrote:
> 
> 
> On 02/09/2017 09:31 AM, Ray Bellis wrote:
>> On 09/02/2017 14:28, Robert Moskowitz wrote:
>>> I am migrating to Centos7 from Centos6.  Going from Bind 9.8.2 to 9.9.4,
>>> I am building this on a new server.  I currently do not have DNSSEC
>>> enabled, and not enabling it for the initial migration work.
>>>
>>> I have looked over changes in named.conf and believe I have made the
>>> necessary changes.  My named.conf is  loading as are the zone files.
>>> This is what 'systemctl -l status named' shows:
>> I'd suggest that you try starting named manually with the '-g' flag so
>> that it sends all output to stderr without forking.
>>
>> This should hopefully reveal why it's failing to start.
>>
> '-g' is not a valid option.

"named -g" isn't valid?

Wow, they really HAVE changed the code.



signature.asc
Description: OpenPGP digital 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

Re: bind 9 goes rogue and revert zone information

[Alan Clegg]

On 2/7/17 4:31 PM, Alberto Colosi wrote:
> lucky you say
> 
> zombie host and hijacked resourced poisoned DNS are not an hack 
> 
> In years as Security Desk Seat I had at leat one attack from zombie
> hosts from a US University. Admins even not known was hacked.
> 
> Target of hackers is not only credit cards or other so valuable things.
> Even only a zombie host is a valuable item for them.

I didn't say that there weren't people around messing with DNS.

What I said was this e-mail does not have anything to do with such an event.

Don't chase ghosts.



signature.asc
Description: OpenPGP digital 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

Re: bind 9 goes rogue and revert zone information

[Alan Clegg]

On 2/7/17 8:42 AM, Alberto Colosi wrote:
> IP ports not open does not mean is not hacked.
> 
> a vulnerability can be used to make a change or an access

Occam's razor... if you were a hacker and broke into someone's DNS
server, would the thing that you focus on be resetting the data every 24
hours?

This isn't a hack, this is a screwed up backup/restore or virtualization
configuration.

Don't waste time chasing ghosts.



signature.asc
Description: OpenPGP digital 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

Re: Enforce EDNS

[Alan Clegg]

On 2/7/17 3:11 PM, Mark Andrews wrote:

>>> Break them.  That's the only way it will eventually get fixed
>>
>> if things would be that easy
>>
>> the admins of the broken servers ar the very last which are affected, 
>> admins with a recent named have to bite the bullet of user terror and 
>> users typically don#t give a damn when it worked yesterday
>>
>> the admins of the broken server don't give a damn about as long they can 
>> point their fingers and say "look, the rest of the world has no lookup 
>> errors"
>>
>> if it would be that easy the problem of spam would not exist for many 
>> years while in reality you waste most of our time to write exceptions 
>> here and there, disable rules or score them lower because you are not in 
>> the position to educate every admin of sending servers out there
> 
> You go over the admins head.  You go to the board of directors.
> You go the the minister responsible (yes, I have had to do that
> along with a copy to the shadow minister and the company that the
> DNS was outsourced to for government domains).  Good old snail mail.

I wish I lived and worked in an ivory tower.

Reindl is right.

If you are in (some) academia, or running this server at your house, you
can get away with "he didn't follow the rules, so I'm not talking to
him".  You just plain can't get away with that in the commercial world.

Remember those Korean IPTV servers that were authoritative but didn't
respond with the AA bit?  The thing that kicked back and caused a very
speedy reversal in the enforcement of that rule is called business pressure.

Yes, we know the rules, yes, we'd love if the rules were strictly
enforced (assuming we don't take the hit when someone else screws up),
but the business world doesn't allow us to enforce the rules, we have to
work as best we can in the world that we are provided.

The idea that "BIND leads the way, allowing no rule breaking, business
needs be damned" will only lead to either a fork of "friendlierBIND",
vendors that include BIND under the covers turning off the strict
enforcement by forking their own BIND versions (do you think this isn't
being done already?), or migration off of BIND completely (do you think
that this isn't being considered already?).

Maybe a "strict-compliance yes;" option?  Those that are willing to take
the hit set it to yes, everyone that needs to ensure business continuity
set it to no?  (and for gods sake, make it default to no)

As with the "let's randomly add a string into the middle of the log
message for everyone", this "let's just break it because the RFCs say
so" isn't going to go over well with lots of people.





signature.asc
Description: OpenPGP digital 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

Re: Bind Queries log file format

[Alan Clegg]

On 2/3/17 10:45 AM, Mukund Sivaraman wrote:
> On Fri, Feb 03, 2017 at 08:51:01AM -0600, Alan Clegg wrote:
>> On 2/3/17 8:01 AM, Mukund Sivaraman wrote:

>> Adding code to allow enabling or disabling this output on the fly would
>> work MUCH better (as an example, see "rndc querylog"/ options "querylog
>> [on | off ]").
>>
>> Adding a "well, we needed this one time" value to the middle of a
>> long-standardized log file does no customer any good and inconveniences
>> everyone.
>>
>> You own the code and can do whatever you want to, but I'd recommend
>> making the default log message what it was prior to 9.10 and adding
>> additional fields via pre-configuration and "rndc".
> 
> We may move it to the end of the log message (bugs ticket #44606 has
> been created for looking at it). Maybe its location was poor.. please
> can everyone who participated in this thread say whether having it at
> the end will be ok?

Since we are all going to have to change our configs (and those of all
the people around the world that don't read this list), just make a
decision.

> Making it a configurable option misses the reason it is the way it is -
> please see the first paragraph quoted above.

The "rndc" option allows those that KNOW that they may need the data
begin the collection where everyone else isn't impacted.  If you know
that this customer is at risk, tell them "run this command, it's going
to fark up your log files, but it won't screw over everyone else in the
world... once we get that data we are looking for, you can back down by
doing this other command.

> This seems to be a case where having it is inconvenient, and not having
> it is inconvenient.

I really don't care, but I hate seeing ISC make unilateral decisions
that don't really need to be made and messing up clients everywhere.

I swore after the response that I got last time I offered input on this
thread that I wouldn't be stupid enough to do it again.  I've proven
myself to be just as stupid as before.

IMNSHO: THE LOG FILE IS NOT THE PLACE FOR ONE-OFF DEBUGGING INFORMATION.
 

AlanC



signature.asc
Description: OpenPGP digital 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

Re: Bind Queries log file format

[Alan Clegg]

On 2/3/17 8:01 AM, Mukund Sivaraman wrote:

> We have the debug log level, but consider the case when an operator has
> a non-deterministic or rare crash that isn't reproducible because the
> operator has no information about what caused it. All we have is the
> config, log that was already generated before the crash and perhaps a
> backtrace and core to deduce the steps leading to the crash. It's not
> possible to re-run that scenario with debug logging.
> 
> I'll create a ticket to put the client pointer at the end if that'll
> help, but note that the syntax in 9.10 was not consistent either. 9.10
> would log the client pointer when the client object didn't have a valid
> peer.

Adding code to allow enabling or disabling this output on the fly would
work MUCH better (as an example, see "rndc querylog"/ options "querylog
[on | off ]").

Adding a "well, we needed this one time" value to the middle of a
long-standardized log file does no customer any good and inconveniences
everyone.

You own the code and can do whatever you want to, but I'd recommend
making the default log message what it was prior to 9.10 and adding
additional fields via pre-configuration and "rndc".

AlanC



signature.asc
Description: OpenPGP digital 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

Re: bind-9.11.0-P2 on Debian 9.0 (stretch)

[Alan Clegg]

On 1/26/17 1:50 PM, Dennis Clarke wrote:
> On 01/26/2017 06:39 PM, Alan Clegg wrote:
>> On 1/26/17 1:31 PM, Dennis Clarke wrote:
>>> The POSIX and XPG4 approach [is a great idea]
>>
>> (My text in brackets)
>>
>> Said no one, ever.
> 
>Clearly I just said it ... and have before ... as have others for
> about twenty years or at least since 1999.

http://www.informatica.co.cr/linux/research/1992/0302.htm

And I've been saying otherwise since 1992 (which I believe pre-dates ELF
and RUNPATH/RPATH).

But, enough flamage.  I blame Trump (and Oracle).



signature.asc
Description: OpenPGP digital 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

Re: bind-9.11.0-P2 on Debian 9.0 (stretch)

[Alan Clegg]

On 1/26/17 1:31 PM, Dennis Clarke wrote:
> The POSIX and XPG4 approach [is a great idea]

(My text in brackets)

Said no one, ever.

AlanC



signature.asc
Description: OpenPGP digital 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

Re: Bind Queries log file format

[Alan Clegg]

On 1/25/17 7:44 AM, Steven Carr wrote:
> On 25 January 2017 at 10:59, Tony Finch  wrote:
>> It's the address in memory of the data structure representing the client.
>> It is mentioned in the CHANGES file (#4471) and in the release notes - see
>> https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commitdiff;h=c4b7db49326be650fa95a7ede6e066bbe1268561
>>
>> though the pointer field first turned up in
>> https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commitdiff;h=a26a62cef2adba0520c5955d740fc75fa7f2c7f5
> 
> Question back to the BIND team... why? what is the purpose of having
> this value exposed in query logs? what exactly is it adding? If it was
> a debug log then I can understand the need to have the memory address
> exposed, but for the "regular" user what is the use case?

BIND is always in debug mode, even when it's not in debug mode.

I find this addition to the log to be annoying and useless in 99% of
actual end-user use cases.

And why shouldn't you need to re-jigger all of your monitoring scripts
to skip that field?

AlanC



signature.asc
Description: OpenPGP digital 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

Re: Spurious DNSKEY records on slave

[Alan Clegg]

On 8/18/16 1:29 PM, Jim Fenton wrote:

> The extra DNSKEY records were not present in the zone file of the master
> server, so I reinitiated a zone transfer and this did not help. I
> checked the signed zone file on the master with named-checkzone and only
> the desired DNSKEY records were there.

Had your slaves done a successful zone transfer of the newly signed
data?  How did you check to see that the DNSKEYs were actually there?

Remember that the text versions of the zone files on slaves are only
updated about every 15 minutes, so you may have been looking at "stale"
data that was only in the human readable version.  If you did a "dig
@127.0.0.1 zone DNSKEY" while logged into the slave, you would know for
certain what was being served.

AlanC



signature.asc
Description: OpenPGP digital 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

Re: OPenssl 1.1 and Bind

[Alan Clegg]

On 8/18/16 12:32 AM, Vinícius Ferrão wrote:
> OpenSSL 1.0 will continue to be supported. There's no rush to go to 1.1 
> release.
> 
> I can't see this as an issue.

You've never dealt with "The Doctor" before, have you?



signature.asc
Description: OpenPGP digital 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

Re: Help required to test some Negative Responses from Bind Server.

[Alan Clegg]

SERVFAIL:   create a delegation NS record in your zone to a server that
isn't authoritative for the zone being delegated.
REFUSED:  create an ACL that matches (and denies) the query being done
NOERROR w/ no RR:   query for  example.com 

As for NOTIMP, I'm not aware of an easy path, but I'm sure that someone here
knows.

AlanC

On 6/28/16, 2:07 AM, "bind-users on behalf of Harshith Mulky"

wrote:

> Hello Experts,
> 
> 
> 
> As a tester who is testing a client(lwres) developed on same bind stack.
> 
> I would want to generate scenarios and test how the client responds when the
> bind server responds with negative Responses
> 
> 
> 
> I was able to test Negative response like NXDOMAIN as it was straight forward
> where a record is not present in particular Domain file
> 
> 
> 
> I would want to test a scenario where bind Server responds with the following
> Response Codes
> 
> 
> 
> 1. SERVFAIL
> 
> 2. REFUSED
> 
> 3. Receiving NOERROR, but no RR in response
> 
> 4. NOTIMP
> 
> 
> 
> If I have a basic Zone file like this, Can I be able to test the above 4
> scenarios
> 
> 
> 
> 
> $ORIGIN example.com.
> $TTL 600
> @  IN  SOA atlanta.example.com. admin.example.com.  (
>   2003022720 ; Serial
>   56800  ; Refresh
>   14400  ; Retry
>   360; Expire
>   2h ); Minimum
> 
>   IN  NS  atlanta.example.com.
> 
> 
> atlanta.example.com.  IN A10.54.48.68
> 
> ; zone ims.blueslice.com direct  - for some phones
> ;srvtesting.com.   IN A10.128.254.115
> ;example.com.   IN A10.54.25.75
> 
> ;; order preference flags service regexp replacement.
> ;IN NAPTR   22   34   "u""SIP+D2U"   ""
> _sip._udp.test1.com.
> IN NAPTR   22   32   "u""SIP+D2U"   ""
> _sip._udp.example.com.
> IN NAPTR   22   32   "u""SIP+D2T"   ""
> _sip._tcp.example.com.
> ;IN NAPTR   45   56   "u""SIP+D2T"   ""
> _sip._tcp.srvtesting.com.
> ;IN NAPTR   45   56   "u""SIP+D2S"   ""
> _sip._sctp.srvtesting.com.
> 
> ; SRV records for each sip service
> ; service.prot.name   ttl class rr pri weight port target
> ;_sip._udp   IN  SRV  32  7700 denver.example.com.
> _sip._udp   IN  SRV   040  7701
> denver1.example.com.
> _sip._tcp   IN  SRV   040  7701
> denver1.example.com.
> _sip._udp   IN  SRV   010  7702
> denver2.example.com.
> _sip._udp   IN  SRV   110  7703
> denver3.example.com.
> _sip._udp   IN  SRV   210  7704
> denver4.example.com.
> _sip._tcp   IN  SRV  11  0
> icscf52.srvtesting.com.
> _sip._sctp  IN  SRV  11  12215
> icscf71.srvtesting.com.
> 
> 
> denver1.example.com.  IN A10.54.80.150
> denver1.example.com.  IN A10.54.80.17
> denver2.example.com.  IN A10.54.80.150
>   IN A10.54.80.35
> ;denver3.example.com.  IN    fd00:10:6b50:4500::88
> ;denver2.example.com.  IN    fd00:10:6b50:4500::21
> ;denver2.example.com.  IN    fd00:10:6b50:4500::22
> example.com.  IN A   10.54.80.150
> example.com.  IN    fd00:10:6b50:4500::88
> denver1.example.com.  IN    fd00:10:6b50:4500::88
> 
> 
> 
> Thanks
> 
> Harshith
> ___ 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: writeable file 'domain.com': already in use

[Alan Clegg]

Change where it says:  file "foo"; so that you don't have two zones with
"foo".

AlanC

On 6/16/16, 4:16 AM, "Daniel Dawalibi"  wrote:

>Do you have the correct syntax to be adjusted on both views?
>
>-Original Message-
>From: bind-users-boun...@lists.isc.org
>[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Ray Bellis
>Sent: 16 June, 2016 11:04 AM
>To: bind-users@lists.isc.org
>Subject: Re: writeable file 'domain.com': already in use
>
>On 16/06/2016 07:53, Daniel Dawalibi wrote:
>
>> We are upgrading our DNS authoritative BIND version 9.10.4-P1 but we
>> are facing "writing errors" on the slave zone files that are
>> transferred from other Master DNS servers.
>> 
>> Our configuration consists of two views  (local and inter) and the
>> domain is configured in both views sections.
>> 
>> The problem was solved after removing the zone from one VIEW but is
>> there any workaround for this issue without removing the zone from the
>> view section (either Local or Inter)?
>
>BIND 9.10.4 doesn't allow you to use the same filename for the same zone
>in
>different views (since the content should be different).
>
>Simply change the "file" directive in one of the views and you should be
>fine.
>
>Ray
>
>
>___
>Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>unsubscribe from this list
>
>bind-users mailing list
>bind-users@lists.isc.org
>https://lists.isc.org/mailman/listinfo/bind-users
>
>___
>Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>unsubscribe from this list
>
>bind-users mailing list
>bind-users@lists.isc.org
>https://lists.isc.org/mailman/listinfo/bind-users


___
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: native-pkcs11 and smartcard-hsm

[Alan Clegg]

I'd like to say a big THANK YOU for the work you are doing on this.

I've made a couple of half-hearted attempts at doing exactly what you are
doing and never had the time to complete the task - or to document where I
got.

Once it's all working (and documented), I'll be more than happy to run a
server in this mode.  8-)

I'd also like to see ISC make BIND more functional in this "HSM
functioning as an HSM only" mode in the mainline code.

AlanC

On 5/26/16, 5:20 AM, "FUSTE Emmanuel"  wrote:

>Le 25/05/2016 16:27, FUSTE Emmanuel a écrit :
>> Le 25/05/2016 14:29, FUSTE Emmanuel a écrit :
>>> Le 24/05/2016 16:36, FUSTE Emmanuel a écrit :
 Le 23/05/2016 16:40, FUSTE Emmanuel a écrit :
> Hello,
>
> I'm trying to use a smartcard-hsm usb stick (v1.2) with BIND
>9.10.3-P4.
> This stick is working with powerdns and support all crypto operations
> required for basic DNSSEC support.
>
> But I get this warning/error:
> "PKCS#11 provider has no digest service".
> "This HSM will not work with BIND 9 using native PKCS#11."
>
> Bind version:
> BIND 9.10.3-P4-Debian 
> built by make with '--prefix=/usr' '--mandir=/usr/share/man'
> '--libdir=/usr/lib/i386-linux-gnu' '--infodir=/usr/share/info'
> '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/'
> '--enable-threads' '--enable-largefile' '--with-libtool'
> '--enable-shared' '--enable-static' '--with-openssl=/usr'
> '--with-gssapi=/usr' '--with-gnu-ld' '--with-geoip=/usr'
>'--with-atf=no'
> '--enable-ipv6' '--enable-rrl' '--enable-filter-'
> '--enable-native-pkcs11'
> '--with-pkcs11=/usr/lib/i386-linux-gnu/softhsm/libsofthsm2.so'
> 'CFLAGS=-g -O2 -fPIE -fstack-protector-strong -Wformat
> -Werror=format-security -fno-strict-aliasing
> -fno-delete-null-pointer-checks -DNO_VERSION_DATE' 'LDFLAGS=-fPIE
>-pie
> -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2
> -DDIG_SIGCHASE'
> compiled by GCC 5.3.1 20160429
> compiled with OpenSSL version: OpenSSL 1.0.2h  3 May 2016
> linked to OpenSSL version: OpenSSL 1.0.2h  3 May 2016
> compiled with libxml2 version: 2.9.3
> linked to libxml2 version: 20903
>
> pkcs11-torens informations:
> pkcs11-tokens -m /usr/lib/i386-linux-gnu/opensc-pkcs11.so
> Warning: PKCS#11 provider has no digest service
> This HSM will not work with BIND 9 using native PKCS#11.
>
> DEFAULTS
>  rand_token=0x80300368
>  best_rsa_token=0x80300368
>  best_dsa_token=(nil)
>  best_dh_token=(nil)
>  digest_token=(nil)
>  best_ec_token=(nil)
>  best_gost_token=(nil)
>  aes_token=(nil)
>
> TOKEN
>  address=0x80300368
>  slotID=0
>  label=SmartCard-HSM (UserPIN)
>  manufacturerID=www.CardContact.de
>  model=PKCS#15 emulated
>  serialNumber=DECC0100872
>  supported operations=0x6 (RAND,RSA)
>
> PKCS11 mechanism returned by pkcs11-tool:
> pkcs11-tool -M
> Using slot 0 with a present token (0x0)
> Supported mechanisms:
>SHA-1, digest
>SHA256, digest
>SHA384, digest
>SHA512, digest
>MD5, digest
>RIPEMD160, digest
>GOSTR3411, digest
>ECDSA, keySize={192,320}, hw, sign, other flags=0x1d0
>ECDSA-SHA1, keySize={192,320}, hw, sign, other flags=0x1d0
>ECDH1-COFACTOR-DERIVE, keySize={192,320}, hw, derive, other
> flags=0x1d0
>ECDH1-DERIVE, keySize={192,320}, hw, derive, other
>flags=0x1d0
>ECDSA-KEY-PAIR-GEN, keySize={192,320}, hw, generate_key_pair,
>other
> flags=0x1d0
>RSA-X-509, keySize={1024,2048}, hw, decrypt, sign, verify
>RSA-PKCS, keySize={1024,2048}, hw, decrypt, sign, verify
>SHA1-RSA-PKCS, keySize={1024,2048}, sign, verify
>SHA256-RSA-PKCS, keySize={1024,2048}, sign, verify
>SHA384-RSA-PKCS, keySize={1024,2048}, sign, verify
>SHA512-RSA-PKCS, keySize={1024,2048}, sign, verify
>MD5-RSA-PKCS, keySize={1024,2048}, sign, verify
>RIPEMD160-RSA-PKCS, keySize={1024,2048}, sign, verify
>RSA-PKCS-KEY-PAIR-GEN, keySize={1024,2048}, generate_key_pair
>
> Perhaps Bind require more, but all needed digest services are here.
> Is something that will be fixed ? How could I help to get it fixed ?
> Does anyone have any insights or suggestions?
>
> Thanks,
>
> Emmanuel.

 Ok, digging into docs and code give me some answers:

 In native PKCS11 mode, all crypto operations are offhanded to the HSM.
 This is totally 

Re: Forward zone not working

[Alan Clegg]

On 5/16/16, 6:30 PM, "Mark Andrews"  wrote:

>Ideally every machine should be registering its own PTR record in
>the DNS and addresses without machines shouldn't have PTR records.
>The only reason ISP did this is that they were too lazy to manage
>PTR records for their customers.

And because no ISP wants "you.suck.isp.com" to show up in their DNS.

Same fight, different address space.

AlanC


___
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: Forward zone not working

[Alan Clegg]

On 5/16/16, 5:35 PM, "MegaBrutal" <megabru...@gmail.com> wrote:

>2016-05-16 19:45 GMT+02:00 Alan Clegg <a...@clegg.com>:
>> On 5/16/16, 1:30 PM, "MegaBrutal" <bind-users-boun...@lists.isc.org on
>> behalf of megabru...@gmail.com> wrote:
>>
>>>I want to have valid reverse & forward hostnames set up
>>>for this /64 subnet.
>>
>> This is silly.  Don't do this.
>
>Why?

Because it's too f'n big and nobody cares about PTR records if they aren't
associated with an address that is actively doing something (i.e., outbound
e-mail service).

>Most ISPs set up reverse & forward domain names for pool addresses.

In IPv4 space, sure.

>OK, I'm not an ISP, but it really seems to be a widely accepted and
>endorsed policy, to the point that addresses not having a reverse DNS
>often treated as suspicious.

I promise that the 18,446,744,073,709,551,616 addresses in your /64
aren't doing anything interesting enough for a PTR record to matter.

AlanC


___
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: Forward zone not working

[Alan Clegg]

On 5/16/16, 1:30 PM, "MegaBrutal"  wrote:

>I want to have valid reverse & forward hostnames set up
>for this /64 subnet.

This is silly.  Don't do this.

AlanC


___
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: Nsupdate usage scenario

[Alan Clegg]

On 5/4/16, 4:27 PM, "/dev/rob0"  wrote:

>My personal recommendation: get over the idea of looking at zone
>files; use "dig axfr example.com. | less".  Let named manage and
>serve the DNS data as it will.  Comments can be included as TXT
>records if you like.

So much this.

AlanC


___
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: also-notify and nsupdate doesnt work

[Alan Clegg]

Aye... I'm sitting here looking for zone transfer use of TSIG...

It's too early in the morning.

*sigh*

On 5/2/16, 10:30 AM, "jo...@hasig.de"  wrote:

>hi,
>
> > There's nothing in this part of the configuration that links key usage
>to
> > the zone.
>
>sure. the * is.
>and the update works great.
>the serial counts up,
>the update is taken,
>the slave is motified and updated.
>
>the only thing is, that the "also-notify" servers get no notify.
>(if i do an rndc update abc.net on a hidden slave, the transfer is taken
>correct.).
>
>jonny
>


___
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: also-notify and nsupdate doesnt work

[Alan Clegg]

On 5/2/16, 10:09 AM, "bind-users-boun...@lists.isc.org on behalf of
jo...@hasig.de"  wrote:
>
>1.
>zone "abc.net" {
> notify yes;
> type master;
> file "abc.net";
> allow-transfer { any; };
> also-notify { 1.2.3.4;};
>};
>
>works. master, slave and hidden (1.2.3.4) gets notifies and updates.
>
>2.
>key "abc.net" {
> algorithm hmac-md5;
> secret "LB8hpcA...==";
>};
>
>zone "abc.net" {
> notify yes;
> type master;
> update-policy { grant * self - A TXT; };
> file "abc.net";
> allow-transfer { any; };
> also-notify { 1.2.3.4;};
>};


There's nothing in this part of the configuration that links key usage to
the zone.

AlanC


___
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: 'succesful' nsupdate of remote server not persistent across nameserver restart?

[Alan Clegg]

>
>
>
>
>On Mon, May 2, 2016, at 07:17 AM, Matthew Pounsett wrote:
>> The general procedure is
>> 1) use 'rndc freeze ' to stop dynamic updates to the zone
>> 2) edit the file
>> 3) use 'rndc thaw ' to re-enable dynamic updates
>> 
>> If the zone is not set up to use dynamic updates, then:
>> 1) edit the zone file
>> 2) 'rndc reload '


Or:

nsupdate zone
> update add label ttl in a 1.2.3.4
> send
> quit

All done


___
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: 'succesful' nsupdate of remote server not persistent across nameserver restart?

[Alan Clegg]

On 5/2/16, 10:17 AM, "Matthew Pounsett"  wrote:
> 
> 
> On 2 May 2016 at 10:05,   wrote:
>> General question --
>> 
>> When I want to change a zone file's data manually, say to add an A record,
>> what's the right procedure:
>> 
> If the zone is set up for dynamic updates, like the examples you've given,
> then in order to touch the zone file directly you need to temporarily tell
> BIND to stop managing the file.
> 
> The general procedure is
> 1) use 'rndc freeze ' to stop dynamic updates to the zone
> 2) edit the file
> 3) use 'rndc thaw ' to re-enable dynamic updates
> 
> If the zone is not set up to use dynamic updates, then:
> 1) edit the zone file
> 2) 'rndc reload '


How about just "use nsupdate" since that's what this entire discussion was
about?  Once you move to dynamic zones, doing "freeze/thaw" is silly and
disruptive of the update mechanism.

AlanC


___
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: Can bind be configured to not drop RR's from the cache when the upstream DNS server is unresponsive

[Alan Clegg]

On 3/17/16, 10:15 AM, "Ron"  wrote:

> According to the BIND9 docs:
> 
> cleaning-interval This interval is effectively obsolete. Previously, the
>server would remove
> expired resource records from the cache every cleaning-interval minutes.
>BIND 9 now
> manages cache memory in a more sophisticated manner and does not rely on
>the periodic
> cleaning any more. Specifying this option therefore has no effect on the
>server¹s behavior.

This is about data in cache that is expired.  BIND never served expired
data to query requests.

I can definitely see how this could be confused, however.  Good catch.

AlanC


___
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: Database driven ACL

[Alan Clegg]

On 2/29/16, 4:04 PM, "/dev/rob0"  wrote:

>On Mon, Feb 29, 2016 at 11:18:33AM +0200, Ali Jawad wrote:
>> Is there a mature/tested method of loading ACLs through a DB query
>> instead of editing the config file or reading/writing into a text
>> file ?
>
>I like this idea.  I'd further suggest using either:
>  1. An abstraction layer such that any DB backend might be used; or
>  2. sqlite3

Would also be cool to have a meta-zone or type (overlay similar to RPZ
perhaps?) that could be used to configure DNS options.

Then your existing DNS tools could act as your management interface.

AlanC


___
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: CVE-2015-7547: getaddrinfo() stack-based buffer overflow

[Alan Clegg]

On 2/17/16, 11:34 AM, "Reindl Harald"  wrote:

>Am 17.02.2016 um 17:22 schrieb Dominique Jullier:
>> Are they any thoughts around, how to handle yesterday's glibc
>> vulnerability[1][2] from the side bind?
>>
>> Since it is a rather painful task in order to update all hosts to a new
>> version of glibc, we were thinking about other possible workarounds
>
>Fedora, RHEL and Debian as well as likely all other relevant
>distributions are providing a patched glibc - dunno what is "rather
>painful" to apply a ordinary update like kernel security updates and
>restart all network relevant processes or reboot

While I agree that the "major distributions" (and even the minor ones) are
getting patches out, I'd like to point out something that Alan Cox posted
over on G+:

"You can upgrade all your servers but if that little cheapo plastic box on
your network somewhere has a vulnerable post 2008 glibc and ever does DNS
lookups chances are it's the equivalent of a trapdoor into your network."

https://plus.google.com/+AlanClegg/posts/R1UkJjHMMB6

There does need to be something a bit deeper than "patch your servers"..

AlanC
>


___
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: Writeable file already in use

[Alan Clegg]

On 1/5/16 6:26 AM, Jan-Piet Mens wrote:
>> This might make you sad if you have lots of zones or large zones.
> 
> .. or even just want to look at what was transferred (whitout having to
> recurse to a `dig axfr').
> 
> I see no reason to omit 'file' (except on a diskless slave ;-)

I ran into one exception to this rule - it seemed that the customer had
security requirements that did not allow "transient data" to be written
to disk.  They had to make sure that if the physical device was stolen,
all of their zone data didn't follow it out the door.

AlanC
-- 
Why don't we wander and follow la vie dansante.



signature.asc
Description: OpenPGP digital 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

Re: SRV Request to DNS

[Alan Clegg]

On 10/14/15 11:29 AM, Barry Margolin wrote:

> Are there *any* current, well-known protocols that make use of SRV 
> records to find the port? The examples I've seen just use it to find a 
> server (analogous to the way MX records are used for mail).

I guess it depends on what you define as a well-known protocol...

Teamspeak 3:
https://support.teamspeakusa.com/index.php?/Knowledgebase/Article/View/293/12/does-teamspeak-3-support-dns-srv-records

AlanC
-- 
When I do still catch the odd glimpse, it's peripheral; mere fragments
of mad-doctor chrome, confining themselves to the corner of the eye.



signature.asc
Description: OpenPGP digital 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

Re: Fwd: problem using setuid ("-u" option) with BIND 9.10.3 on RedHat when listening on tun/tap interface

[Alan Clegg]

On 9/29/15 5:29 PM, Gordon Lang wrote:

> But now the question is whether or not there is a way to make things
> work without disabling threads?  Does anyone have insight into why
> supporting threads might interfere with the normal SUID bit based change
> of the effective user id?

Did you see the response from Mark Andrews?

He's pretty much the authority.

AlanC
-- 
When I do still catch the odd glimpse, it's peripheral; mere fragments
of mad-doctor chrome, confining themselves to the corner of the eye.



signature.asc
Description: OpenPGP digital 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

Re: Speeding up DNS change propagation

[Alan Clegg]

Remember, however, that if you are clearing YOUR caches by restarting,
everyone else around the world is still seeing the data with the
original TTL still "in place".

The right thing to do is to lower the TTL on the auth servers to an
acceptable "outage" value before you make the change, wait for the
original TTL to expire (removing the data from the caches around the
world and replacing with your new, lower value), make the change, and
then when everything is working correctly, raise the TTL back to your
original value.

On 9/18/15 3:46 PM, Danny Sinang wrote:
> Ah, many thanks ! :)
> 
> On Fri, Sep 18, 2015 at 3:37 PM, John Miller  > wrote:
> 
> The .com nameservers don't know anything about ftp.example.com
> ; they
> just know the nameservers for example.com .  So
> have no fear -- BIND
> will not cache an upstream response for ftp.example.com
> : you'll only
> hear about ftp.example.com  from the
> example.com  nameservers.
> 
> Pretty much all upstream nameservers: root NSs, .com NSs,
> example.com 
> NSs--are authoritative-only.  They don't cache or offer cached
> responses.  (Not 100% accurate, but nearly always so.)
> 
> John
> 
> On Fri, Sep 18, 2015 at 2:58 PM, Danny Sinang  > wrote:
> > As a follow-up to your answer for question #2, after my clearing
> the cache
> > or restarting BIND, won't BIND find an old cache of
> "ftp.example.com " in the
> > ".com" top level DNS server ?
> >
> > Regards,
> > Danny
> >
> > On Fri, Sep 18, 2015 at 2:51 PM, John Miller
> > wrote:
> >>
> >> On Fri, Sep 18, 2015 at 2:35 PM, Danny Sinang  > wrote:
> >> > Hi,
> >> >
> >> > Our vendor is changing their FTP server's IP address tomorrow.
> >> >
> >> > 1. How can I tell how long their DNS change will propagate to us ?
> >>
> >> Whatever TTL you have cached when the vendor makes the switch is how
> >> long it'll take for your caching servers to pick up the change.
> >>
> >> >  a. Do I just run dig a "ftp.example.com
> " and look for the TTL for
> >> > that
> >> > DNS entry ?
> >> >  b. Every time I run that command, the TTL is shrinking.
> How do I
> >> > find
> >> > out the full TTL for it ?
> >>
> >> If you want to know the full TTL, ask the company's NSs directly -
> >> authoritative servers only give out the full TTL.
> >>
> >> > 2. Can I just restart BIND tomorrow to clear its cache and
> force it to
> >> > query
> >> > the "example.com " name server for
> "ftp.example.com " (so as not to wait
> >> > for
> >> > the propagation to reach us) ?
> >>
> >> Sure can.  Depending on your BIND version, you can also run rndc
> >> flushname  and it'll clear just that name from your cache.
> >>
> >> If the TTL is very long, don't forget about client-side caching as
> >> well.  Windows and OS X cache DNS lookups by default.
> >>
> >> John
> >> ___
> >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> >> unsubscribe from this list
> >>
> >> bind-users mailing list
> >> bind-users@lists.isc.org 
> >> https://lists.isc.org/mailman/listinfo/bind-users
> >
> >
> 
> 
> 
> --
> John Miller
> Systems Engineer
> Brandeis University
> johnm...@brandeis.edu 
> (781) 736-4619 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org 
> https://lists.isc.org/mailman/listinfo/bind-users
> 
> 
> 
> 
> ___
> 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
> 

-- 
When I do still catch the odd glimpse, it's peripheral; mere fragments
of mad-doctor chrome, confining themselves to the corner of the eye.



signature.asc
Description: OpenPGP digital 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

Re: Troubleshooting Information

[Alan Clegg]

On 8/28/15 9:19 AM, Bob McDonald wrote:
 It appears that receiving an NSID response depends on having server-id
 set in the options block. However, I'm seeing no way to restrict such
 queries.

You don't have to set the server-id information to anything that an
external entity would find interesting.  Set the server-ids to 1, 2,
3, or binary blob 1, binary blob 2, binary blob 3 and you are set.

The magic of NSID is that you are able to use it through load
balancers, etc.

Do a normal A record lookup, set the NSID bit and you still get the A
record, but in addition, you get the server-id information from the
server that actually responded to the request.

Please remember that even if you are doing your best at hiding all of
the information that is kept in the easter egg zones, there are other
ways to determine the type/location/whatever of your nameservers.

fpdns may be undermining almost all of your efforts.

And, my last input of the day:  Script kiddies are going to shotgun
attacks against your nameserver - they don't care about the version data
provided.

Targeted attacks are going to be much more deliberate and they are going
to be much more intelligent than basing the attack on the chaos data
provided by your nameserver - They don't care about the version data
provided.

AlanC
-- 
When I do still catch the odd glimpse, it's peripheral; mere fragments
of mad-doctor chrome, confining themselves to the corner of the eye.



signature.asc
Description: OpenPGP digital 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

Re: DNS Negative Caching

[Alan Clegg]

 on the DNS Zone file we have these records
 $ORIGIN e164.arpa.
 @   IN SOA  picardvm2.e164.arpa. e164-contacts.e164.arpa.  (
  2002022404 ; serial
  3H ; refresh
  15 ; retry
  1w ; expire
 *3h* ; minimum
 )

I wasn't really following this thread, but now that I see this, I would
like to add that the expire timer is also used as the default TTL for
resource records that do not have one specified, and if there is not an
explicit $TTL statement in the zone file.

Personally, I doubt that a 1 week TTL is a good idea.

AlanC
-- 
When I do still catch the odd glimpse, it's peripheral; mere fragments
of mad-doctor chrome, confining themselves to the corner of the eye.



signature.asc
Description: OpenPGP digital 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

Re: DNS Negative Caching

[Alan Clegg]

On 8/27/15 10:24 AM, Reindl Harald wrote:

 I wasn't really following this thread, but now that I see this, I would
 like to add that the expire timer is also used as the default TTL for
 resource records that do not have one specified, and if there is not an
 explicit $TTL statement in the zone file.

 Personally, I doubt that a 1 week TTL is a good idea
 
 it is a damned good idea because it's the value after your slaves start
 to drop zones in case of connection / zone-transfer troubles

Oh, what a day... yes, the formatting of the zone snippet threw me.

Yes, EXPIRE should be long (and probably longer than 1w), it's the
MINIMUM (last value in the SOA RDATA) that I was meaning to point out.

Thanks for that..

 a zone without an explicit $TTL statement is questionable to say it polite

But, quite common IRL.

AlanC
-- 
When I do still catch the odd glimpse, it's peripheral; mere fragments
of mad-doctor chrome, confining themselves to the corner of the eye.



signature.asc
Description: OpenPGP digital 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

Re: Troubleshooting Information

[Alan Clegg]

Has anyone recommended doing debugging via NSID instead of the CH class
data?

On 8/27/15 12:55 PM, Bob McDonald wrote:
 If I set this up as follow, it works.
 
 view bind chaos {
 recursion no;
 allow-query { 127.0.0.1; none; };
 zone  authors.bind ch { type master; database _builtin authors;  };
 zone hostname.bind ch { type master; database _builtin hostname; };
 zone  version.bind ch { type master; database _builtin version;  };
 zone id.server ch { type master; database _builtin id;   };
 };
 
 Queries from 127.0.0.1 are answered correctly, queries from anywhere
 else are met with a REFUSED reply.
 
 However, the answers show as coming from view bind in the statistics.
 There is also a view named _bind which seems to serve those same
 zones. (named won't start if I try to name the view _bind.)
 
 I can get answers from the zones in view _bind if I accept/reject via
 the match-clients statement. If I also remove the zones from view
 bind, it returns a SERFAIL to queries for selected devices in that
 view of class chaos. I think I understand this last one.
 
 Setting recursion off does not seem to affect the warning message
 generated by omitting the root hints zone for class chaos.
 
 Bob
 
 
 On Wed, Aug 26, 2015 at 5:50 AM, Bob McDonald bmcdonal...@gmail.com
 mailto:bmcdonal...@gmail.com wrote:
 
 The warning is issued either way (with or without recursion
 specified). But I see the logic in not needing it if recursion is
 set to no.
 
 Thanks again,
 
 Bob
 
 On Wed, Aug 26, 2015 at 5:45 AM, Tony Finch d...@dotat.at
 mailto:d...@dotat.at wrote:
 
 Bob McDonald bmcdonal...@gmail.com
 mailto:bmcdonal...@gmail.com wrote:
 
  I'd still include the hint zone (as I'm partial to not having 
 unnecessary
  warnings on startup).
 
 The recursion no directive means you shouldn't have a hint
 zone in that
 view. (I don't know if it will complain about the inconsistency.)
 
  Also a lot of folks use localhost and/or localnets in DNS 
 configuration.
  Just from a security standpoint, I prefer to be more specific. 
 localhost
  and/or localnets can be much more template friendly, I know.
 
 I just used them as placeholders since they are used in the
 default ACLs :-)
 
 Tony.
 --
 f.anthony.n.finch  d...@dotat.at mailto:d...@dotat.at 
 http://dotat.at/
 Viking, North Utsire: Easterly 4 or 5, increasing 6 at times.
 Slight or
 moderate, but rough in southwest Viking. Showers later. Good,
 occasionally
 poor later.
 
 
 
 
 
 ___
 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
 

-- 
When I do still catch the odd glimpse, it's peripheral; mere fragments
of mad-doctor chrome, confining themselves to the corner of the eye.



signature.asc
Description: OpenPGP digital 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

Re: BIND9 Feature Request: 'fowarders' priority round-robin pools

[Alan Clegg]

On 8/24/15 3:09 PM, n...@eml.cc wrote:
 
 
 On Mon, Aug 24, 2015, at 11:56 AM, Darcy Kevin (FCA) wrote:
 So, if your link is saturated to the point that you can't hold up a VPN 
 connection reliably, you fall back to an less-secure method of resolution?
 
 No.

Actually, yes.  That's pretty much exactly what you are doing.

 
 Non-deterministic security, what a concept!
 
 Didn't take long for you to resort to childish snark to did it?

If what a concept is snark, then I'm one of the snarkiest people in
the world.  However, he's pointing out a problem with your configuration.

 Has it occurred to you, that you're giving the bad guys -- the ones that 
 want to pry on your query data -- an incentive to also partially DoS your 
 link, as a way to downgrade your query security?
 
 No, because I prefer not to waste my time with hypothetical/idle speculation.

Unfortunately, security has a lot to do with figuring out the weak
points in a configuration - that which you call hypothetical/idle
speculation.  Not good.

 -1 on this feature request.
 
 I don't know who you are.  Is that an opinion, or a project decision?

I'm with Kevin on this one.  -1 on this feature request.

AlanC
-- 
When I do still catch the odd glimpse, it's peripheral; mere fragments
of mad-doctor chrome, confining themselves to the corner of the eye.



signature.asc
Description: OpenPGP digital 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

Re: BIND9 Feature Request: 'fowarders' priority round-robin pools

[Alan Clegg]

On 8/24/15 3:21 PM, n...@eml.cc wrote:
 Somehow all that ^ puffery translates into NOT wanting to allow the
 user to prioritize the use of forwarders the way they want?

You are trying to use forwarders in a way that they are not intended,
and is not a good idea.  That is the translation of all of the responses
to this point.

All puffery aside.

AlanC
-- 
When I do still catch the odd glimpse, it's peripheral; mere fragments
of mad-doctor chrome, confining themselves to the corner of the eye.



signature.asc
Description: OpenPGP digital 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

Re: Help DNS

[Alan Clegg]

On 8/23/15 8:30 PM, Daniel Ryšlink wrote:

 A few pointers - try to use the recommended MMDDnn format for SERIAL
 in SOA. Also try not to use nslookup.

Half of this I agree with.  Half I do not.

The serial number is just a number, as long as you increment it, the
format is completely up to you.  I like using the epoch date if I'm
updating via script, or n+1 where n was the previous serial number if
I'm editing by hand.

Never, EVER use nslookup.

AlanC
-- 
When I do still catch the odd glimpse, it's peripheral; mere fragments
of mad-doctor chrome, confining themselves to the corner of the eye.



signature.asc
Description: OpenPGP digital 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

Re: Block propagation for a specific record A

[Alan Clegg]

On 7/29/15 4:59 AM, Job wrote:
 Hello,
 
 for a test page purpuose, we would like to avoid propagation only for a 
 specific record A, example:
 test.domain.com
 
 We need to test if users set up our DNS server in ethernet configuration, and 
 they display correctly the test page.
 But, if test.domain.com propagate, we are not sure they use our DNS server!
 
 Is there a way?

Create the A record in a delegated zone that is only available to be
queried by your recursive servers.

AlanC



signature.asc
Description: OpenPGP digital 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

Re: tsig indicates error

[Alan Clegg]

Possible problems:
   Mismatched keys.
   Mismatched key names.
   Mismatched clocks.

On 7/24/2015 10:52 AM, Managed Pvt nets wrote:
 Hi All,
  
 I have recently built a server to act as a secondary / slave for my
 zones. Built on Debian 8.1 and running BIND 9.9.5. On trying to
 transfer zones from my master I am getting this error here, what could
 I be missing:
  
 ===
 Jul 24 15:33:55 huffer named[493]: zone myzonename.co.zw/IN: refresh:
 failure trying master aaa.bbb.ccc.ddd#53 (source 0.0.0.0#0): tsig
 indicates error
 ===
  
 regards,
  
 Mollatt.


 ___
 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



signature.asc
Description: OpenPGP digital 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

Re: DNSSEC validation on 9.7.4 not working

[Alan Clegg]

I've always recommended either a cache flush or a complete restart of
named after turning on DNSSEC.

I thought I opened a ticket about this, but probably not.

AlanC

On 6/24/15 3:46 AM, frnk...@iname.com wrote:
 Ding-ding-ding -- issuing rndc flushname . did the trick, Mark.
 
 I'd encourage this troubleshooting tip to be documented in one of those
 how-to guides.  I don't think waiting for a TTL is a good idea if most
 queries are failing with bad cache hit.
 
 Frank
 
 -Original Message-
 From: Mark Andrews [mailto:ma...@isc.org] 
 Sent: Tuesday, June 23, 2015 11:03 PM
 To: Frank Bulk
 Cc: bind-us...@isc.org
 Subject: Re: DNSSEC validation on 9.7.4 not working
 
 
 I suspect that the DNSKEY record for the root will be marked as a
 'answer' rather than 'secure' (rndc dumpdb) and flushing the cache
 will fix the issue as will waiting ~30703 seconds.  'rndc flushname .'
 should also work though I forget where we added flushname.
 
 Mark
 
 In message 005701d0ae2f$ef2798f0$cd76cad0$@iname.com, Frank Bulk writes:
 Here you go:

 root@nagios:/etc/bind# dig @127.0.0.1 +dnssec +cd ds com; dig @127.0.0.1
 +dnssec +cd dnskey .

 ;  DiG 9.7.3  @127.0.0.1 +dnssec +cd ds com
 ; (1 server found)
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 38536
 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags: do; udp: 4096
 ;; QUESTION SECTION:
 ;com.   IN  DS

 ;; ANSWER SECTION:
 com.86400   IN  DS  30909 8 2
 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
 com.86400   IN  RRSIG   DS 8 1 86400
 2015070317
 2015062316 48613 .
 ioJ6KyZ9ig0PsFBdo5jfM/9hLEX9qn06QaitkJubhcH3m/DPBi2o9xTu
 Cs9Aabwm/tSlGc+JVc3oBVSwv6LakHUY9v7aJn77pD244tnnlgNeR+z4
 kkZSn1Kp5tHmhKx8sNYe8Fe9rTA/9hC+3IokE949ppf+3CEyjJ4uhJhm lN0=

 ;; Query time: 54 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Tue Jun 23 22:41:31 2015
 ;; MSG SIZE  rcvd: 239


 ;  DiG 9.7.3  @127.0.0.1 +dnssec +cd dnskey .
 ; (1 server found)
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 11727
 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

 ;; OPT PSEUDOSECTION:
 ; EDNS: version: 0, flags: do; udp: 4096
 ;; QUESTION SECTION:
 ;.  IN  DNSKEY

 ;; ANSWER SECTION:
 .   30703   IN  DNSKEY  256 3 8
 AwEAAZyIkCwEYeG29NV+4cOdKE4DPng/4BqJeoOhKqzJbl+LR33TPWsr
 wBRfmAi9wvR/Qc6IV4MFMXjmkclXns+atIQZ9uQV3YAvKv/cVuO7Mneu
 MssIQixaMw+jp73R7zIUNMbLBgJRQXI57Rl+pvXBAkgHndVwv+aJkf7y GEuE9Dtj
 .   30703   IN  DNSKEY  256 3 8
 AwEAAa67bQck1JjopOOFc+iMISFcp/osWrEst2wbKbuQSUWu77QC9UHL
 ipiHgWN7JlqVAEjKITZz49hhkLmOpmLK55pTq+RD2kwoyNWk9cvpc+tS
 nIxT7i93O+3oVeLYjMWrkDAz7K45rObbHDuSBwYZKrcSIUCZnCpNMUtn PFl/04cb
 .   30703   IN  DNSKEY  257 3 8
 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
 FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
 bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
 X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
 W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
 Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0=
 .   30703   IN  RRSIG   DNSKEY 8 0 172800
 20150705235959 2015062000 19036 .
 W6ZIOh5tJ1ph3C0c9Fqot+55jCewbk/cWRquGOeRnWkag7rx/XgsEfvd
 HLr1HsSIlag+lt1OvTlsLgvVk/yUcOAZA/NvMRPbFfbyrEi82YpZ70Z2
 B995qkT7dCf/3uBynAzubAPshUfEi7LuBy9bzyYPMvtRZptEnBz3xsAf
 4gmrRTX0BW66ve2xqvitZrPVH2WaYR70iJbJWbKKDCPl9rwEcit95gyi
 CNQLOIPFq2XgHDmo01Pr4evPbSowny6kNXzuDHgKQn1+BWX5zhbr74OE
 3FZXo2DUXm8BA5OhMY0bMg32kjzQLu+lxBWpaXabjFoALNFG4WRRdx1s 4+Wuhg==

 ;; Query time: 0 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Tue Jun 23 22:41:31 2015
 ;; MSG SIZE  rcvd: 883

 root@nagios:/etc/bind# date -u
 Wed Jun 24 03:41:52 UTC 2015
 root@nagios:/etc/bind#

 Frank

 -Original Message-
 From: Mark Andrews [mailto:ma...@isc.org] 
 Sent: Tuesday, June 23, 2015 10:31 PM
 To: Frank Bulk frnk...@iname.com
 Cc: bind-us...@isc.org
 Subject: Re: DNSSEC validation on 9.7.4 not working


 Should have asked for +dnssec on those queries.  Also date -u.


 In message 005601d0ae2c$b698b6c0$23ca2440$@iname.com, Frank Bulk
 writes:
 Mark,

 Sorry for top-posting -- my email client makes it difficult to do
 otherwise.

 Yes, I'm absolutely sure there's no software or physical firewall (we're
 an
 ISP), and there's also no load-balancer in front of this box.  I've also
 used the EDNS tests and I can get a 4000+ byte response.  There's also
 no
 forwarder configured.

 Here's the requested output:


 root@nagios:/etc/bind# dig @127.0.0.1 +cd ds com; dig @127.0.0.1 +cd
 dnskey
 .

 ;  DiG 9.7.3  @127.0.0.1 +cd ds com
 ; (1 server found)
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 

Re: Fwd: Getting an error on a simple DNS configuration

[Alan Clegg]

allow-recursion { ... };

not

allow-recursion ( ... );

And you need a ; at the end of your list:

 allow-recursion {207.151.36.0;};

On 6/3/15 5:14 PM, Samad Agha wrote:
 I put the allow-recursion clause under my options, the #service named
 restart failed. Where exactly should I place this allow-recursion clause?
  
 [root@new-dns2 ~]# cat /etc/named.conf
 options {
  directory /var/named;
 allow-recursion (207.151.36.0);
  };
  
 zone 0.0.127.in-addr.arpa {
 type master;
 file db.127.0.0;
 };
 [root@new-dns2 ~]#
  
 [root@new-dns2 ~]# service named restart
 Stopping named: .  [  OK  ]
 Starting named:
 Error in named configuration:
 /etc/named.conf:3: '{' expected near '(207.151.36.0)'
[FAILED]
 [root@new-dns2 ~]#
 
 
 ___
 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
 



signature.asc
Description: OpenPGP digital 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

Re: Suppress log entry...

[Alan Clegg]

On 4/13/15 2:08 AM, SH Development wrote:
 Is there a way to suppress the build information in the log every time BIND 
 restarts/reloads?  I’m getting:
 
 built with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' 
 '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' 
 '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' 
 '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' 
 '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' 
 '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool' 
 '--localstatedir=/var' '--enable-threads' '--enable-ipv6' 
 '--enable-filter-' '--with-pic' '--disable-static' 
 '--disable-openssl-version-check' '--with-dlopen=yes' '--with-dlz-ldap=yes' 
 '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' 
 '--with-gssapi=yes' '--disable-isc-spnego' 
 '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' 
 '--enable-fixed-rrset' 'build_alias=x86_64-redhat-linux-gnu' 
 'host_alias=x86_64-redhat-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' 
 'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexce
ptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' 
'CPPFLAGS= -DDIG_SIGCHASE’

It's a single line that is generated and actually gives a significantly
important amount of information.

I'm curious as to why you feel it should be suppressed... I was teaching
the class in which the addition of this line was brought up and find it
extremely useful.

AlanC



signature.asc
Description: OpenPGP digital 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

Re: Native pkcs#11 and auto-dnssec feature

[Alan Clegg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 4/9/15 2:58 AM, Catalin Leanca wrote:
 If the label contains a pin-source field, tools using the
 generated key files will be able to use the HSM for signing and
 other operations without any need for an operator to manually enter
 a PIN.

Which, for the most part, makes the use of a PIN at all an exercise in
futility.

AlanC
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJVJrlmAAoJEOW2o5eiJADbR50H/jZuHyYb7vIm69R9nXUTeOfD
7NknwCkR1tOGebOk4eB7paN3elm8vowg71ys0yU+lFquEidZYXGrGGsDwFUyN1c+
cs+ZepDVnFvLjSTbPgH8CR8Wy3fcBxQWpkjO8sdbQBU1LuvG4qzmAjcknNIyhXg0
dLbG20Ny3Jk6owEmezzWDF6/HyeZgllvmY8ztRQjzHHBXdXI2Emu12dc4TX/mp6p
FEHgIpnKvnjm7bjx7j8JWj2PT0OpyFaaqmda0wYJvc5rdAH2Wi9VWgNf3CAxGFfP
iqNTJorMQptRPixWalS/eQmDvj0ND5z4Wla0/mYEAu9FlibfezPwz8t8b8AJso8=
=9vA8
-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

Re: configured bind 9.10.1 as slave gettting data in binary form

[Alan Clegg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


 Or you can allow your slave files to remain in binary format (it
 gives you a roughly factor-4 speedup in loading the files, which
 can be significant with large zones).  When you want to look at the
 text version, convert them:
 
 $ named-checkzone -Djfraw example.com slave-zonefile

Or you can read what is actually being served and not worry about any
synchronization issues what-so-ever by using:

  dig +onesoa @127.0.0.1 slave-zone AXFR

AlanC
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJVJstUAAoJEOW2o5eiJADbHikIAMHB8xhoB5xQJrQJYWY0oRD8
DFpyrb0mIpHV6aEQ5B1BUE0+RoNXszMH8n7wWcMZJ5xKmsWibcnsyoYy4DIMhcFM
GhSX43xu1VyEXf2ZkmbC3KLZRFbsdBXsujhomb482HpfNTy0N8p7q68EzEI7mh12
vzRpIOM5g+moU8GuxD8WlULh3Tzq5TEJlpxITVeR3tsIzboXIORgK3vrRJzU8Zyo
aexcglswePbd2okv6HlLF1FBwUykk9l4z+ms1Gge65NggOYFtQQY+krquS/t9mQz
opZlmPQMKbt2D11LWkqQm6Q2mWXDFBWI6jezfJoiNwt8q0S/Sx0jZKR7STBgYxA=
=CCjP
-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

BIND stats into Munin

[Alan Clegg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Are you interested in seeing a nice graph of what your BIND server is
doing when you aren't live-streaming the query log?

Shumon Huque released (quite a while ago, it seems) a nice Python
based plugin for Munin that provides a good view of BIND (late 9.9 and
9.10) statistics.

For those interested:   https://github.com/shuque/bind9stats

Enjoy!  I certainly do.

AlanC
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJVAtkHAAoJEOW2o5eiJADbx14H/RCDZLFjVHHHb0eVWg3kEAcA
igRYTawuTWYLrCAwQUEhKtSKQBh+5CTbO6nq80EMMMeL9OPs56AoLWV4JO/lmDW5
JE+b0rcgkD6ObLtNhseFevQsf9N1dQkt4apfUEL5OJXhWXlP3vt6zknWIDpSR+jS
H1Rn2E5JfdLk8T9QCVTkkrksz1qvavt2P1NaLIOQJ/qbnv/KsI1CxeruBv1cxaC1
L+/tSq3fSRLNQmkO9UG+2SRVqB9kyex1KSe5RF85wzJbbX37g+YPicL8Twaj1i07
FZITKklevTUT8pSOEhlfaKECXrNXB2VkLlkh0TI9h6ADzAjlKbnlwl+XKbxHr+8=
=ISBN
-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

Re: Is it possible to have separate query logs for different views?

[Alan Clegg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 3/9/15 3:04 AM, Peter Olsson wrote:
 Hello!
 
 Is it possible to have separate query logs for different views?
 
 I tried putting this in the view block, but it failed with unknown
 option 'logging':
 
 logging { channel logging_query { file
 /var/log/named/query-inside.log versions 30 size 5M; print-time
 yes; severity debug; }; };

Nope.  Logging is global only, not per view.

AlanC
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJU/k8MAAoJEOW2o5eiJADbLAcH/R00aujdwht4RNRrfGbgIWRM
057lnBKLMvWRR2IJmJBRcOvJW3teVXYCwlu4BYhfswKTfFbX9Xnb8ZfnmZuHurEv
2Itmv2R4Fx1RG3U4JLfxZRlgjBKdiVXHnITO94h9YygY7F91M1MjtdPa5SqcC5DA
Ij2dr4kD6ePxJjkaWOsId96T5X6FAQYboWAFeY6dvHxmU3DFafXyDybD7tV00AOX
qNgQMTuh6uM3mopqQonMFpr2O9O8eypZaioX4+53g34X9ID7lnfeDnkE8FikvwzW
lmTMLLHai5myi4TMkWB6dNJ2nICWpG2hCOkdkEb1UdGCJMEod2mqGQpzrT1QS1k=
=vfB1
-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

Re: caching-only name server

[Alan Clegg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 2/19/15 9:52 PM, Vijay Viswanathan wrote:

 looks like the default /etc/named.conf is designed to run much more
 than caching server

There no named.conf distributed with BIND from ISC.  What you are
seeing is from your operating system distribution or a third-party.

If you are looking to just run a cache, what you had in your first
configuration snippet is just fine, and actually has some extra (the
zone for localhost).

AlanC
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJU5zqTAAoJEOW2o5eiJADbUyoIAJAe3vZEZYkdtzm5rIj7wYvG
bAgiH84GPhZMNxmQIK1sU3xBaQiSb5DWKg+hpauoplku+6fpNJ4hpMGZK56nhPkr
2+PJpOhVdpTfmSxGKd6VGp2/MyHVFGnR6uwdvL24fxqcL6b1WA/ps/r7Ovorh0aa
uJkIPd/bZQYcyGxHIs1hXjc8xIc8pS64Ac9C2A1NwzFHDIKDEfuiMtzJ/IGfHv86
EiT7FKBLO2eG1u5O0aH9HGTOiTqBM7Z+7E6dzcLnB3LOcwsYSEh2eJlmOhwNVVcw
s18SIWdO7z9aYVqpcDQgbmJxCn+83veg8rTuy92QR5sTwLHBYfhVq+qA82RAqfc=
=veTd
-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

Re: caching-only name server

[Alan Clegg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2/20/15 12:59 PM, Vijay Viswanathan wrote:
 sorry I didn't understand, with the snip i have without the listen 
 directive, i should be able to run BIND (named) as recursion only
 server installed in all client machines to speed up their
 browsing/DNS lookup?

You _could_ run this on every client machine, but if you do, you lose
the function of caching between clients.

Consider the case that your clients all have a need to go to xyz.com

If you have each client running its own copy of BIND, you have every
client doing that lookup and waiting for the response, etc.

If you have a couple of centralized servers running BIND, only the
first client to lookup xyz.com (against each server) has to wait for
the response, at which time the response is cached for the other clients.

Honestly, there are too many variables for us to be able to tell you
which mechanism works best in your specific case.

AlanC

-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJU53vMAAoJEOW2o5eiJADbNTUIAK0v981BQOTQj+vTGyD6a/Lv
B4ORAt5xgROa9g7VIlL6pmoURiujjF9kZvDG/3kOeaaC1nXIvt2HlOfL+hmEAO6v
bIF3o6KghIe5bUGU6EOQuXt4L3ahT8OQx9wi/3tOGkx5Uezxy91kjyfy21mRIYWF
DE9+K/Lux52KmIIX0CIb4W61FWtFgyA2QL0XbiH45R06nrHM4LMcYgeQ3H3V1TLx
BfFx/rjL1kltgAScqLXx1QKvnKwd6Fxn78zHDCsbdIxtuX5egyT/mNQHzKETj5Gj
740eIcWJ2MaKo7KWyxcpjIj7dcfkNYQoYdqyE7q2OwNp7b3wXrfGTiVPla2cyTg=
=xrCy
-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