Re: Only one DS key comes back in query

[Matthew Pounsett]

On Mon, May 16, 2022 at 2:41 PM frank picabia  wrote:

> I've been using open source for decades.  Long enough that I rarely need
> to use lists for help.
>
> Here's the RFC mentioning reserved domain name use:
> https://www.rfc-editor.org/rfc/rfc2606.html
>

Those reservations are for testing and documentation examples.  They're not
particularly useful when requesting help for specific problems, unless
you're doing something like a search/replace on detailed query output in
order to redact it.  Even if you do that you have to be very careful not to
change things the wrong way, or it further confuses the issue.  You're much
better off just sharing the domain name you're concerned with.

If you're asking for help about a real configuration, you're going to get
limited effort back from the community if you don't provide them with
enough information to help you.  Since you're not providing DNS queries
(even redacted ones) that show the problem, that means they can't see
enough information to actually answer your questions.  Also hiding the
domain name in question means they can't check for themselves what the
contents of your zone or your parent zone are, and so they are left with
insufficient information to provide you help.  It makes matters worse that
you are using phrases that subtly suggest you may be making incorrect
assumptions, which leads people to really want to check what the real data
is.

And people are absolutely right to tell you that if you're working for such
a large, public company that they would be embarrassed by you asking for
help publicly, then they should pay for support so that they can get that
help privately.
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Getting the name of responding server(s)

[Matthew Pounsett]

On Tue, 7 Sept 2021 at 03:45, Stephane Bortzmeyer  wrote:

> The only solution is chasing the delegations from the root (which is
> what dig +trace is doing). Caching speeds it, this is why it is
> better to go through your resolver than using dig +trace.

Yeah, you can pretty reliably get the answer in one or two steps by
requesting the NS set for the FQDN.  You'll either get your answer, or
get an SOA with the name of the enclosing zone.  Second lookup gets
you the NS set for the enclosing zone.  Just using your local
recursive server to deal with tracking down the answer should work
well, unless for some reason you need to see every possible answer
from every delegating name server.

% dig +noall +answer +authority IN NS www.example.net
example.net. 3591 IN SOA ns.icann.org. noc.dns.icann.org. 2021090201
7200 3600 1209600 3600

% dig +noall +answer IN NS example.net
example.net. 86396 IN NS b.iana-servers.net.
example.net. 86396 IN NS a.iana-servers.net.

Or a one-liner that works whether you supply the FQDN or its enclosing zone:
% dig +noall +answer +authority IN NS www.example.net | head -1 | cut
-f 1 | xargs dig +noall +answer IN NS | awk '{print $NF}'
b.iana-servers.net.
a.iana-servers.net.

% dig +noall +answer +authority IN NS example.net | head -1 | cut -f 1
| xargs dig +noall +answer IN NS | awk '{print $NF}'
a.iana-servers.net.
b.iana-servers.net.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Broken signatures on packages.sury.org

[Matthew Pounsett]

Beginning today, I'm seeing the following errors on systems that use
the ISC Debian packages:

Err:5 https://packages.sury.org/bind buster InRelease
  The following signatures were invalid: EXPKEYSIG B188E2B695BD4743
DEB.SURY.ORG Automatic Signing Key 

I haven't seen any official word from ISC that there are new keys to
grab, so wanted to check that someone isn't messing about with your
repository.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Forwarded lookup failing on no valid RRSIG

[Matthew Pounsett]

On Fri, 18 Dec 2020 at 18:08, Nicolas Bock 
wrote:

> Thanks Mark. Am I correct then that I need to either convince the
> administrator of that DNS to enable DNSSEC or configure my DNS with
> `dnssec-validation = no`?
>

The upstream administrator isn't required to be validating DNSSEC for this
to work, but in order for your DNS server to do DNSSEC validation, their
DNS server must be DNSSEC aware enough to be requesting DNSSEC data when it
queries the authoritative DNS servers.  Of course, the resilience of the
whole thing would also be improved by that server also validating.

If they can't or won't update their server, then yes, you'll either have to
disable validation yourself, or select a better upstream.  Personally I'd
go looking for a better upstream (or just stop using a forwarder entirely,
and do your own direct recursion, if that's possible in your environment).
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: checkzone from stdin?

[Matthew Pounsett]

On Wed, 8 Apr 2020 at 15:55, Anand Buddhdev  wrote:

> Note that it would work with "cat file | ..." but I absolutely hate the
> cat-pipe combination. I've been known to mark down interviewees who
> offer a solution that involves cats and pipes :)
>

That was just a minimal example to demonstrate the limitation.   But yes,
cat and pipe together in the wild only makes sense if the target of the
pipe can *only* take data via stdin, and can't accept a file name on its
command line.

What I'm actually doing is running a bit of code that detects whether a
zone file is compressed or not, and by which compression algorithm if it
is, selects the correct "open()" function depending on the results, and
then reads the file in from that (possibly compressed) file-like object and
feeds it into named-checkzone's stdin.

I like your suggestion of using /dev/stdin as the file though.. I bet I can
make that work until 9.18 is out.
___
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: checkzone from stdin?

[Matthew Pounsett]

Cool, thanks!  Nice to see my feature requests being implemented even
before I ask!  :)

On Wed, 8 Apr 2020 at 15:05, Ondřej Surý  wrote:

> Matt,
>
> this has been merged into March release 9.17.0:
>
> https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/2552
>
> Unfortunately, we don’t backport new features, so either you need to
> follow the 9.17 track or backport the patch yourself. It should be fairly
> straightforward to backport it to 9.16 branch since the codebases don’t
> differ much yet.
>
> Ondrej
> --
> Ondřej Surý — ISC
>
> On 8 Apr 2020, at 20:58, Matthew Pounsett  wrote:
>
> 
>
> It looks to me like named-checkzone isn't able to read a zone file from
> stdin.
>
> % cat example.com.db | named-checkzone example.com -
> zone example.com/IN: loading from master file - failed: file not found
> zone example.com/IN: not loaded due to errors.
>
> % cat example.com.db | named-checkzone example.com
> usage: named-checkzone [-djqvD] [-c class] [-f inputformat] [-F
> outputformat] [-J filename] [-t directory] [-w directory] [-k
> (ignore|warn|fail)] [-n (ignore|warn|fail)] [-m (ignore|warn|fail)] [-r
> (ignore|warn|fail)] [-i (full|full-sibling|local|local-sibling|none)] [-M
> (ignore|warn|fail)] [-S (ignore|warn|fail)] [-W (ignore|warn)] [-o
> filename] zonename filename
>
> If I'm missing something in the man page, could someone provide me with
> the appropriate clue?  If it's not, what are the chances this feature could
> show up in a future version?
>
> In my particular case this would help with reading in zones stored as
> compressed files, so that I can pipe the decompression directly into
> named-checkzone without having to do an extra write to disk.  I can imagine
> it may be useful to others, in different situations, as well.
> ___
> 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

checkzone from stdin?

[Matthew Pounsett]

It looks to me like named-checkzone isn't able to read a zone file from
stdin.

% cat example.com.db | named-checkzone example.com -
zone example.com/IN: loading from master file - failed: file not found
zone example.com/IN: not loaded due to errors.

% cat example.com.db | named-checkzone example.com
usage: named-checkzone [-djqvD] [-c class] [-f inputformat] [-F
outputformat] [-J filename] [-t directory] [-w directory] [-k
(ignore|warn|fail)] [-n (ignore|warn|fail)] [-m (ignore|warn|fail)] [-r
(ignore|warn|fail)] [-i (full|full-sibling|local|local-sibling|none)] [-M
(ignore|warn|fail)] [-S (ignore|warn|fail)] [-W (ignore|warn)] [-o
filename] zonename filename

If I'm missing something in the man page, could someone provide me with the
appropriate clue?  If it's not, what are the chances this feature could
show up in a future version?

In my particular case this would help with reading in zones stored as
compressed files, so that I can pipe the decompression directly into
named-checkzone without having to do an extra write to disk.  I can imagine
it may be useful to others, in different situations, as well.
___
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: CloudSmith repository missing

[Matthew Pounsett]

On Wed, 9 Oct 2019 at 19:14, Ondřej Surý  wrote:

> Hi Matt,
>
> sorry for the confusion with the CloudSmith repositories.  We’ve been
> experimenting with the different models, and we’ve decided to keep the BIND
> 9 packages closer to the official distributions, that means that the
> packages for distributions supported by us are located at following places:
>
> Sorry for any inconvenience our packaging changes might have caused.
>

That's fine.. should be pretty easy to switch over.  You say you've been
experimenting... should I expect the Launchpad repo to be relatively stable
from here on out?

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

CloudSmith repository missing

[Matthew Pounsett]

Hi!  It looks like the BIND Cloudsmith repository, which was there earlier
this week, is no longer present.

Hit:9 https://packages.icinga.com/debian icinga-stretch InRelease
> Ign:10 https://dl.cloudsmith.io/public/isc/bind/deb/debian stretch
> InRelease
> Err:11 https://dl.cloudsmith.io/public/isc/bind/deb/debian stretch Release
>   404  Not Found
> Reading package lists... Done
> E: The repository 'https://dl.cloudsmith.io/public/isc/bind/deb/debian
> stretch Release' does no longer have a Release file.


Looking at ISC's Cloudsmith page[0], I see a "public-bind" repository which
seems to be about two weeks old.  Has that replaced the "bind" repository,
or is that something else?  Or should I not be expecting these repositories
to be stable (yet)?

[0]: 
___
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: Problem with zone delegation with private gTLD

[Matthew Pounsett]

On Tue, 9 Apr 2019 at 06:32, Tony Finch  wrote:
>
> Matthew Pounsett  wrote:
> >
> > RFC2606 reserves test, example, invalid, and localhost, for "testing
> > and documentation,"
>
> However you must either disable validation or set up your own root zone to
> use them. [ RFC 6761 has more details than RCF 2606 about how to use these
> names. ]

Yes, that's right.  The reason I referenced 2606 is that the subject
under discussion was the reason for the reservation, and 6761 defers
to 2606 for that.
___
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: Problem with zone delegation with private gTLD

[Matthew Pounsett]

On Mon, 8 Apr 2019 at 14:33, Matus UHLAR - fantomas  wrote:
>
> I don't find any of existing domains suitable for more permanent usage.

Yes, and I believe that's the desirable situation.  More permanent
uses (such as the (mis)use of .local you mentioned) should make use of
registered domains to ensure uniqueness.
___
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: Problem with zone delegation with private gTLD

[Matthew Pounsett]

On Mon, 8 Apr 2019 at 10:35, Xavier Humbert
 wrote:
>
> On 08/04/2019 13:05, Matus UHLAR - fantomas wrote:
> > I believe there should be reserved gTLD for such usage.
>
> Is this not what the TLD /.invalid/ is supposed to be ?

RFC2606 reserves test, example, invalid, and localhost, for "testing
and documentation," which seems to fit this use-case.  'invalid'
doesn't seem to me to be intended for use as a generic private TLD
though, as was suggested up-thread.  However, if the OP is setting up
a private network, with no Internet connection, for a demonstration,
then any TLD at all could be used; a private root will be required
regardless.
___
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

[Matthew Pounsett]

On Sun, 17 Mar 2019 at 13:34, Grant Taylor via bind-users <
bind-users@lists.isc.org> wrote:

>
> > I mean, sure you can use it perfectly, only not good if hosting hundreds
> > or thousands domains
>
> Why can't you use BIND to host hundreds or thousands of domains?
>

You definitely can.  My personal record is 3.7 million zones in a single
BIND instance, in production.   I did ten million in testing just to prove
we had growing space.  We did updates, adds, and removes at a rate of about
1500 per minute; BIND could have done more, we think, but our provisioning
software hit its limit around there.
___
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: Operational Notification: Extremely large zone transfers can result in corrupted journal files or server process termination

[Matthew Pounsett]

On 13 July 2018 at 06:04, Michał Kępień  wrote:

> Hopefully this will shed some light on the matter:
>
> https://gitlab.isc.org/isc-projects/bind9/issues/339#note_12805
>
> That is helpful, thanks.  That comment says the issue requires a journal
entry of over 4G, however the original bug report indicates it was
triggered by a 1.6GiB IXFR.   But then I suppose there's not a 1:1
relationship between the size of the zone transfer and the size of the
journal entry.

Thanks for the info!
___
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: Operational Notification: Extremely large zone transfers can result in corrupted journal files or server process termination

[Matthew Pounsett]

On 9 July 2018 at 16:22, Klaus Darilion 
wrote:

> What is an "extraordinarily large zone transfer"? We do have regularly
> AXFR and IXFRs around 2GB. Is this "extraordinarily large"?
>

I've also been curious about this.  Are we talking millions of records,
tens or hundreds of millions, or billions?
___
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

[Matthew Pounsett]

On 14 June 2018 at 10:16, Axel Rau  wrote:

>
> Am 14.06.2018 um 16:12 schrieb Alan Clegg :
>
> Additionally, I read this as "the records changed are in an included
> file" -- is the serial number in the "including" zone being incremented?
>
> Yes.
>
> I think at this point you're going to need to provide a lot more detail
about your configuration, and what's special about these zones.  It sounds
like this is not a straightforward configuration, and it's hard to figure
out from the bits and pieces you've provided what could be going wrong.
___
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

[Matthew Pounsett]

On 14 June 2018 at 06:27, Axel Rau  wrote:

>
> Am 07.06.2018 um 13:36 schrieb Axel Rau :
>
>
> occasionally named 9.11.3 fails to increment SOA serial like here:
>
> file: 2018060605 dns: 2018060604
>
>
> It just happened again. An included zone file has been changed from 2 TLSA
> RRs to one:
> - - -
> _443._tcp.git.nussberg.de. 3600 IN TLSA 3 0 1
> DAE0AC343A6694DEAF0BAB42FC8A6B1F82E42799654BD667B458DC91655C6AB4
> - - -
> After reload no TLSAs are picked up by the server:
> - - -
> [hermes:local/etc/rc.d] root# dig AXFR nussberg.de. @localhost | grep TLSA
> [hermes:local/etc/rc.d] root#
>

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?
___
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 rejecting key to update a zone

[Matthew Pounsett]

On 8 June 2018 at 11:01, Mark E. Jeftovic  wrote:

> I've started a fresh install here and started over and still having the
> same issue, even when I crank the debug trace up to 5, I'm not seeing
> anything additional in the logs:
>
> Another long shot... any chance there is an overlapping ACL in the
config?  Maybe an overly-restrictive allow-query?  Something would need to
be overriding your allow-update in order to get a REFUSED response, I
think.
___
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

[Matthew Pounsett]

On 7 June 2018 at 07:36, Axel Rau  wrote:

> Hi all,
>
> occasionally named 9.11.3 fails to increment SOA serial like here:
>
> file: 2018060605 dns: 2018060604
>
> zone file was edited by script and a rndc reload given.
>
[...]

> Manual fixing requires another cycle with zone file editing:
>
>
You don't say this clearly, but it sounds like you're reporting more than
just the serial not updating.  Is that correct?  Are there actual updates
to the zone that are not being picked up?  As Tony says, the serial number
can differ from the file to what's served by the name server when the name
server is doing automatic signing.

Can you clarify which it is?
___
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 we define masters as hostsname?

[Matthew Pounsett]

On 23 May 2018 at 07:37, Blason R  wrote:

> Hi Guys,
>
> Can we define masters as hostname instead of IP address? I guess its not
> possible but wondering if community can shed come light on this?
>
>
The short answer.. no, you can't do that. The definition for the slave zone
statement's 'masters' option (BIND 9.11 ARM pp 139) is pretty clear that
you can only use IP addresses and named masters lists.  You could fake it
by defining a named master list (pp. 70) but I suspect that isn't going to
do what you want.

I think the rationale for not allowing hostnames there is that you can
easily put yourself in a unresolvable (pardon the pun) situation where your
slave can't reach the master until your slave reaches the master and gets a
copy of a key zone.   I can also see the potential for complication even if
there weren't a catch-22 in the configuration, such as what to do if the
hostname referenced has multiple addresses associated with it; that would
have implications for things like how complex it is to track whether a
master is available or not.  I'm sure there are other complexities I
haven't thought of.
___
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: Intermittent "failure trying master... operation canceled" on zone refresh

[Matthew Pounsett]

On 17 May 2018 at 17:05, Rob Moser  wrote:

> We're running a series of RHEL 7.4 machines (kernel version
> 3.10.0-693.1.1.el7.x86_64) running bind version 9.9.4-RedHat-9.9.4-51.el7.
> Our configuration consists of a hidden master and three hidden
> slave/recursive resolvers.  I'm getting a LOT of errors on the slaves that
> look like:
>
> 17-May-2018 13:27:28.421 general: info: zone 
> 34.22.10.in-addr.arpa/IN/internal-view:
> refresh: failure trying master 10.20.30.3#53 (source 0.0.0.0#0): operation
> canceled
>
> In addition to checking for firewalls and other stateful network devices
as Tony mentions, you should also have a look at the condition of the
network in between the hosts.  That feels a lot like moderate packet loss,
or extreme latency, to me.

Are these machines all on the same LAN?  Are there multiple networks in
between them?
___
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 allow-notify

[Matthew Pounsett]

On 17 May 2018 at 13:30, Blason R  wrote:

> Hi,
>
> I have RPZ installed on server and its acting as a master server but
> somehow port setting is not working on master
>
> [...]

>
> So here I am sending notification  to 192.168.5.49 on port 4545; my
> queries are
>
> How do I configure port on slave 4545 so that slave server can start
> listening on that port.
>

Your slave needs to be listening on the correct IP/port to receive the
NOTIFY.  In the current BIND Administrator's Reference Manual[0], the
discussion on Interfaces starts at page 98.


> And my master is failing  after restarting the services due to notify-them
> statement.
>

You don't indicate what the error is, but I'm willing to bet it's the fact
that you're trying to specify a masters list by name as well as a port.  If
you look at the 'also-notify' statement definition, you can see that you're
able to use a 'masters' list OR an IP address and port combination, but not
both (ARM pp. 71).  You should specify the port number as part of the
definition of the masters list, not where you use the masters list.

[0]: 
___
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 source distribution missing?

[Matthew Pounsett]

On 4 May 2018 at 12:23, Evan Hunt  wrote:

> On Fri, May 04, 2018 at 04:19:43PM +, Evan Hunt wrote:
> > You're right, something's broken.  I see it too, and not just on chrome.
> > I'll escalate.  Thanks for bringing this to our attention.
>
> It's fixed now.
>
>
Thanks Evan!  That looks a lot more like what I'm used to seeing. :)
___
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 source distribution missing?

[Matthew Pounsett]

On 4 May 2018 at 08:18, Anand Buddhdev  wrote:

> > Also,  needs an update to its 'welcome' file, because
> > BIND doesn't seem to be distributed from there anymore.
>
> I can see all the BIND downloads at:
>
> ftp://ftp.isc.org/isc/bind9/
>
> Ah yes, there they are!  Thanks.
I will blame the hour and the lack of caffeine for missing that one. :)
___
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 source distribution missing?

[Matthew Pounsett]

Hi ISC!

I'm writing to let you know there seems to be a bug on the ISC web site.
Coming from MacOS Chrome, I'm only being offered the binary Windows
distribution of BIND for download from  and
from .

Browser-detection bug aside.. I think only offering only the binary version
to *anyone* is a mistake.  Regardless of what platform I'm using to
download BIND, I may be deploying it to any number of different places.  It
shouldn't matter what browser I'm using at all, or what my desktop OS is, I
should be able to easily access *all* (current) distributions... not just
the one you think matches the browser I'm using.  So, please dump the
browser detection entirely, and just offer me all the distributions.

Also,  needs an update to its 'welcome' file, because
BIND doesn't seem to be distributed from there anymore.

Thanks!
   Matt
___
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: Release Strategy Clarification

[Matthew Pounsett]

On 26 April 2018 at 13:42, Victoria Risk  wrote:

>
>
> You have correctly interpreted the chart in the blog post, but you don’t
> have to update in January, just when there is a bug you need a fix for.  If
> that bug is a security bug, the red block means, we will issue a security
> patch even though we are no longer issuing regular maintenance on that
> branch. So, effectively there is a quarter, 3 months, of overlap.
>
> Thanks for the clarification, Vicky.   It sounds like ISC and I have
different definitions of "no longer supported." :)Perhaps I could
suggest that the descriptive text for that stage be updated to indicate
that there is limited support (for security related bugs) during that stage.

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

Release Strategy Clarification

[Matthew Pounsett]

This is a question for ISC about the new BIND release plan which I thought
might be a useful clarification for others as well.

I didn't notice this when the new plan was first presented in March, but
the key text in the legend of the Example Release Plan[0] for the red
blocks is "a release that is no longer supported."  This implies that 9.12
will go from being the most recent supported stable version of BIND to
unsupported literally overnight.  It doesn't appear there is a period where
9.12 and 9.14 are both supported, as 9.12 approaches end of life.

Is this an oversight, where the legend text needs updating to "a release
that is approaching end of life," or do we really all have to plan to do
our upgrades on January 1st every year?

Thanks,
   Matt


[0]: 
___
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: RRSIG query

[Matthew Pounsett]

On 10 April 2018 at 12:05, rams  wrote:

> Hi
> Greetings!!
> We have 1Million signed zone records in bind. My zone is going to
> auto-resign after 3 days. If we change RRSIG expire date to greater than
> two months from now then if restart bind, Can we avoid auto-resign in this
> week? is there any impact on resolution or is my zone is valid? what we
> would need to do to make my zone is valid after changing rrsig expire date
> value manually. DO we need to change any other values along with RRSIG
> expire value. Kindly look into this.
>
>
The details of your configuration are probably important here.  It'll be
difficult to give a clear, simple answer without that information.

However, if your have RRSIGs expiring this week then one of two things will
happen:  either they will be resigned this week, or your zone will go
bogus.  If you have RRSIGs expiring and you manage to delay the next
re-sign out beyond that date, then the signatures you have currently will
expire.  If you simply change the signature lifetime (and you have RRSIGs
expiring this week) then after your re-sign happens the new RRSIGs will
have the new signature lifetime, which would delay the need for the _next_
re-sign.
___
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: clean up an ddns zone

[Matthew Pounsett]

On 23 March 2018 at 13:32, Meike Stone via bind-users <
bind-users@lists.isc.org> wrote:

> Hello,
>
> at the moment, I use ISC dhcpd to register all client names in the DNS
> (Bind) via isc's ddns api. Every thing is working well.
> But now, some notebook clients should get company access via UMTS or
> VPN. In this case, a radius server is controlling the IP addresses,
> not the ISC dhcpd.
>

What's the mechanism for getting the IP address to the client?  Is there a
RADIUS client on the client machine, or is your VPN using DHCP to get
addresses to the client?  If the latter, then it likely has a mechanism for
sending the same DNS Update messages that ISC's dhcpd does (DNS Update
messages are a part of the DNS standard, and the ability to send them to
maintain DNS for dynamic addresses is almost ubiquitous among DHCP
implementations).

It's possible your RADIUS server also can do DNS Update messages, but I'm
so far removed from the time when I ran RADIUS servers that I confess I
can't recall whether that was a common option.

Is there any possibility, maybe that the clients send their lease time
> and the Bind does delete the RR (like isc it would do), if the lease
> time is over and if no ddns refresh was made?
>

I'm not aware of any way to automatically expire records in a dynamic
zone.

It's an ugly hack.. but if you could get your clients to also register a
TXT record with a timestamp in it, you could have some sort of cron-based
garbage collection script run to scan the zone for those TXT records, and
delete all the records related to that name when the right amount of time
has elapsed.  That still has some obvious problems though, like what to do
if a client doesn't update the TXT record if/when it renews its lease.
___
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: CNAME at apex, was Re: Issue running "dig txt rs.dns-oarc.net" on 9.12

[Matthew Pounsett]

On 10 March 2018 at 04:08, Matus UHLAR - fantomas  wrote:

> Cathy Almond  wrote:
>>
>>> The rs.dns-oarc.net zone is broken because it returns a CNAME for
>>> queries at the apex.
>>>
>>
> On 09.03.18 15:23, Tony Finch wrote:
>
>> I just got a problem report from a user who has a few personal domains
>> with CNAME at apex that used to work (or at least appeared to work) but
>> no longer do.
>>
>> I've said that the domains are misconfigured, but since this is a
>> relatively widespread misconfiguration, I think it's likely to cause
>> more complaints. Tiresome.
>>
>
> it's the very common result of misconfiguration that something sometimes
> does not work, while sometimes it does.
>

Apex CHAMEs, in particular, have nondeterministic failure modes.  In that,
each resolver deals differently with this misconfiguration, since by
definition there is no correct way to deal with it.  Some resolvers find a
way to gloss over the problem, and others fail hard making the domain name
and everything below it unresolvable for the TTL of either the apex NS set
or the TTL of the CNAME itself, depending on which way it breaks.

Best to just stop doing that so that whether the domain works doesn't
depend on which resolver you're trying to use.
___
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: Issue running "dig txt rs.dns-oarc.net" on 9.12

[Matthew Pounsett]

On 27 January 2018 at 19:11, Matthew Pounsett <m...@conundrum.com> wrote:

> The only thing I can think of that has changed in that time, which has
> ever caused me query issues, is the addition of DNS cookies in the default
> query.  Some broken authoritative servers will incorrectly respond with
> things like FORMERR when they see an EDNS option they don't recognize.  I
> doubt DNS-OARC is running such a name server, but I haven't looked to see.
>
> Serves me right for not actually going any looking at this sooner.. and
for some reason I failed to recognize the name when I saw it.
rs.dns-oarc.net is the DNS-OARC response size tester.  The server
synthesizes a series of large responses via a CNAME chain when you look up
that TXT record, designed to test your recursive server's ability to handle
large responses.  I'm getting similar failure behaviour from Google Public
DNS that you're seeing in 9.12, but I'm not seeing it from my 9.11
recursive server (it works on the first try).


; <<>> DiG 9.11.2 <<>> IN TXT rs.dns-oarc.net @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 63546
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;rs.dns-oarc.net. IN TXT

;; Query time: 4373 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Jan 27 19:20:21 EST 2018
;; MSG SIZE  rcvd: 44


; <<>> DiG 9.11.2 <<>> IN TXT rs.dns-oarc.net @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29585
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;rs.dns-oarc.net. IN TXT

;; ANSWER SECTION:
rs.dns-oarc.net. 1 IN CNAME rst.x4090.rs.dns-oarc.net.
rst.x4090.rs.dns-oarc.net. 58 IN CNAME rst.x4058.x4090.rs.dns-oarc.net.
rst.x4058.x4090.rs.dns-oarc.net. 57 IN CNAME
rst.x4064.x4058.x4090.rs.dns-oarc.net.
rst.x4064.x4058.x4090.rs.dns-oarc.net. 56 IN TXT "74.125.179.74 DNS reply
size limit is at least 4090"
rst.x4064.x4058.x4090.rs.dns-oarc.net. 56 IN TXT "74.125.179.74 sent EDNS
buffer size 4096"
rst.x4064.x4058.x4090.rs.dns-oarc.net. 56 IN TXT "Tested at 2018-01-28
00:21:16 UTC"

;; Query time: 857 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Jan 27 19:21:16 EST 2018
;; MSG SIZE  rcvd: 279

If you want to understand why your resolver is failing, again I'd have a
look at the 'resolver' log channel.  It should have some detail about
what's resulting in the SERVFAIL message.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Issue running "dig txt rs.dns-oarc.net" on 9.12

[Matthew Pounsett]

On 27 January 2018 at 16:24, NNEX Support  wrote:

> Good thought but no luck, it doesn’t matter how many times I run “dig txt
> rs.dns-oarc.net” or how long I wait it continues to SERVFAIL until I run
> "dig txt rs.dns-oarc.net +trace" Interestingly I've found that running
> "dig txt dns-oarc.net +trace" isn't enough to fix it, I actually have to
> run "dig txt rs.dns-oarc.net +trace" before things start working.
>

The reason digging against dns-oarc.net doesn't fix rs.dns-oarc.net is
because they're different zones.

I'm not sure why a +trace would have anything to do with what your resolver
does, since dig only talks to it to get the root NS set.  Again, I suggest
you check the 'resolver' logging channel on your recursive resolver.


> I agree, from my limited understanding this seems to describe what is
> happening well. The thing I'm wondering is why? I'm running older visions
> of named (9.9.4, yum provided RPM on CentOS 6) that seem immune to this
> issue. I've been digging through release notes and can't find any setting
> that has changed between the versions that might explain it (I know 9.9.4
> to 9.12 is a big jump, so I'm sure I'm missing something)
>
> The only thing I can think of that has changed in that time, which has
ever caused me query issues, is the addition of DNS cookies in the default
query.  Some broken authoritative servers will incorrectly respond with
things like FORMERR when they see an EDNS option they don't recognize.  I
doubt DNS-OARC is running such a name server, but I haven't looked to see.
___
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: Issue running "dig txt rs.dns-oarc.net" on 9.12

[Matthew Pounsett]

On 26 January 2018 at 16:23, NNEX Support  wrote:

> I'm sure I'm doing something wrong, but for the life of me I can't figure
> out what. I'm running named 9.12 in a simple recursive setup (built from
> source on CentOS 7).
>
>
[...]


> When I try to run "dig txt rs.dns-oarc.net" I get SERVFAIL. The logs show:
>

[...]


>
> However if I run "dig txt rs.dns-oarc.net +trace" and then "dig txt
> rs.dns-oarc.net" the query completes as expected. It continues to
> complete as expected until I restart named.
>

There's an insecure delegation (NS set, and NSEC proving the nonexistence
of a DS set) from dns-oarc.net to rs.dns-oarc.net.  However, there's
disagreement between the parent and child about what name servers actually
serve rs.dns-oarc.net, and at least some of them are refusing to answer
TCP.  It's likely your recursive server is, for whatever reason, being
drawn to the ones failing to respond, and not getting good data elsewhere
fast enough to answer your query.



A bad interaction of timeouts would explain why you get SERVFAIL on the
first query, and answers on subsequent queries.  Your first one fails to
get a response in time and the recursive server responds with SERVFAIL, but
the back-end queries continue and eventually the local cache is populated.
When you come back and ask again, the answers are there waiting for you,
requiring no upstream queries.

"dig txt rs.dns-oarc.net +trace" goes to your local recursive DNS server to
get the NS set for the root zone, and then proceeds to query authoritative
servers directly for everything else.  It's probably not having any effect
on what you're seeing.  Simply doing "dig txt rs.dns-oarc.net" a second
time a few seconds later without the +trace query would probably give you
the exact same result.

You can track this if you turn on and examine the 'resolver' logging
channel in your recursive name server.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: [Question] zone transfer issue with multiple views

[Matthew Pounsett]

On 8 December 2017 at 17:37, Eoin Kim  wrote:

> Hi,
>
>
> Thanks for your help. But is it possible to do it without additional IP
> address? I thought that I am not really bad with BIND but as soon as I
> started using views, I'm going nowhere [image: ]
>
>
> In order for the slave's View A to transfer from the master's View A, and
the slave's View B to transfer from the master's view B, there has to be
some way for the master to differentiate the two views on the slave and
answer their queries from the correct view.   Source IP address is the
typical way to do that.

You could probably select on source port instead, by setting the slave's
transfer-source to a particular port for each view.  I've never set this up
myself, but I just checked the ARM and it looks like you can use any legal
address_match_list in the view's match-clients list, so you could also
select on TSIG key used, if you assign per-view TSIG keys.
___
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: Proper use of keyid in allow-transfer

[Matthew Pounsett]

On 7 December 2017 at 07:41, MURTARI, JOHN  wrote:

>
>
> The slave server defines the same key and is located at
> 192.168.1.1.  When we use the above on the master, transfers for any zone
> work fine.  If we remove the IP address and try a transfer we get
> ‘denied’.  What are we missing?  Thought we might have to associate the
> keyid with zones on the slave, but couldn’t find any options for that??? We
> don’t use TSIG on these servers.
>

The keys you've defined above are TSIG keys, so yes you're using TSIG–or
trying to at any rate. :)

I'm going to assume you're creatively redacting your key data, and that it
isn't actually "BippityBop", because that isn't a valid hmac-md5 hash.

You don't include your slave config, so I'll point out a couple of common
errors there you can look for:
1) the keys must have not only the same secret, but also the same name on
both the master and slave
2) make sure you've got a server{} clause on the slave which tells it to
use the key when speaking to that server.  And note that server{} is a
root-level directive in BIND... it doesn't go inside the options{} block.
For example, if your master is 192.168.1.2, your slave needs:
server 192.168.1.2 {
   keys { bongo; };
};
Alternatively, there's a config syntax for specifying the key to use on a
per-zone basis by adding it to each server in the masters list in a slave
zone definition.  I think the TSIG section of the BIND ARM (Administrator
Reference Manual) discusses that, and for sure the zone syntax description
will.

If it's not one of those things, then I'd suggest you include a more
complete configuration in your next email (from both sides), possibly with
some log entries showing the failed zone transfer attempts (also from both
sides).
___
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: Email & PTR Issues

[Matthew Pounsett]

On 7 November 2017 at 10:31, James Pifer  wrote:

> Hello. I'm looking for help with an issue I've been fighting for some time.
>
> Background:
> Running BIND 9.9.
> Forwarding UDP & TCP Port 53 through firewall.
>
> I have issues emailing to certain domains. I use my own mail server to
> deliver mail. It is currently not sending through SMTP Relay. The failure
> says that I have a missing PTR record. For example:
>

You may have configured reverse DNS on your DNS server, but that reverse
DNS zone is not delegated to you, so nobody else's DNS server will ever
query yours for that PTR record.  It's being managed by swbell.net, who
returns NXDOMAIN for that lookup.

I'm presuming swbell.net is your ISP.  You either need to get them to
delegate reverse DNS for your address block to you, or have them set up the
PTR record(s) you require in their DNS.

; <<>> DiG 9.11.2 <<>> +trace -x 108.212.144.25
;; global options: +cmd
. 223262 IN NS h.root-servers.net.
. 223262 IN NS a.root-servers.net.
. 223262 IN NS c.root-servers.net.
. 223262 IN NS g.root-servers.net.
. 223262 IN NS i.root-servers.net.
. 223262 IN NS m.root-servers.net.
. 223262 IN NS d.root-servers.net.
. 223262 IN NS e.root-servers.net.
. 223262 IN NS k.root-servers.net.
. 223262 IN NS j.root-servers.net.
. 223262 IN NS l.root-servers.net.
. 223262 IN NS b.root-servers.net.
. 223262 IN NS f.root-servers.net.
. 223262 IN RRSIG NS 8 0 518400 2017111921 2017110620 46809 .
OL3PH3LpCrgzyohVZas9X42iwOpXsYD8CRkNiJZ1Oy6jwIfb8Shy57XN
5noPxtghdHBLutGBIdMwL2rA5AR2yaaVgRC6TM0eSqeixFFeETu6EV89
ZpBgSDNSVL1fmwnSoni1mZRj+F0iLT+Q+t/DveqVwh4o/2czWsnfiqTk
89jZRB30W3Ja9E4EMNW1+WNCkib1KTFvnwwgfYGPtjyFSUIQrv1vOByN
R3Yu11YYkgauY0Q5C7vcUkchwsDlkaWIgnvEZQXRUM3Ibi1QX6kq1g6Q
JW9mSzf7YqrPfU90HId+TSfuvTL4MrkN81iQXSl37+sldtJzDSKOKQij 7Wj1hg==
;; Received 525 bytes from 8.8.8.8#53(8.8.8.8) in 7 ms

in-addr.arpa. 172800 IN NS e.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS f.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS d.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS c.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS b.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS a.in-addr-servers.arpa.
in-addr.arpa. 86400 IN DS 53696 8 2
13E5501C56B20394DA921B51412D48B7089C5EB6957A7C58553C4D4D 424F04DF
in-addr.arpa. 86400 IN DS 63982 8 2
AAF4FB5D213EF25AE44679032EBE3514C487D7ABD99D7F5FEC3383D0 30733C73
in-addr.arpa. 86400 IN DS 47054 8 2
5CAFCCEC201D1933B4C9F6A9C8F51E51F3B39979058AC21B8DF1B1F2 81CBC6F2
in-addr.arpa. 86400 IN RRSIG DS 8 2 86400 2017112012 2017110711
36264 arpa. VMG4mxJ1Kdcm4QsK/i8qP+EzIubfzl2Hlo9hG1aDAZ8/y+GIKz+bYGVG
f1wZKCZAfFPMrDBIVAhghK3eTQooY12oUEGICksbtSukvDQcL6LwqZKf
yfPuSW29Qj+hsdmeDZAwRiaCjAeMf5tucgX7yr9SD08gCTJcaPltjdlv QuM=
;; Received 740 bytes from 198.41.0.4#53(a.root-servers.net) in 18 ms

108.in-addr.arpa. 86400 IN NS r.arin.net.
108.in-addr.arpa. 86400 IN NS u.arin.net.
108.in-addr.arpa. 86400 IN NS x.arin.net.
108.in-addr.arpa. 86400 IN NS y.arin.net.
108.in-addr.arpa. 86400 IN NS z.arin.net.
108.in-addr.arpa. 86400 IN NS arin.authdns.ripe.net.
108.in-addr.arpa. 86400 IN DS 42060 5 1
DCD6C8C3D6F68C6A4495EA2C1C5DA76BBCB466E2
108.in-addr.arpa. 86400 IN RRSIG DS 8 3 86400 20171114073514 20171024172923
50761 in-addr.arpa.
l8UaM1j4VZ14OnIdBoH7b3xgFPyueh6A82423FAp53ohpOf+enHrh26s
O0Vaq3LnIk3fTED6bspZCour38srNTmWWKvYRSzAQ+vAsarAo//Cma4U
nCLAQAJqQRrUzQ2ZXC/AZoC+E0jfyA0saXC3mQb76+iwPx8hLJnw6wD1 Vhj/mwU=
;; Received 387 bytes from 203.119.86.101#53(e.in-addr-servers.arpa) in 236
ms

212.108.in-addr.arpa. 86400 IN NS ns1.swbell.net.
212.108.in-addr.arpa. 86400 IN NS ns3.sbcglobal.net.
212.108.in-addr.arpa. 86400 IN NS ns2.swbell.net.
212.108.in-addr.arpa. 10800 IN NSEC 213.108.in-addr.arpa. NS RRSIG NSEC
212.108.in-addr.arpa. 10800 IN RRSIG NSEC 5 4 10800 20171121173125
20171107163125 14796 108.in-addr.arpa.
aTXD4vS9gVjOP9uzozcUdXhSFuCXKqKUKUpZnHuStZO7QPqXKnB8EOoj
F0lRJDkdvGNng/BwMLj22EFC3kWtFhOTLl2l6oq7tjb+fhGJCWCY5Pbp
Cyc3VSiIU7wCPa2HDJbYMTLKLm4UZOBA1Mlp+0rcGDosGcnqmRl7oGNh Y6A=
;; Received 348 bytes from 192.82.134.30#53(y.arin.net) in 18 ms

212.108.in-addr.arpa. 3600 IN SOA ns1.swbell.net. rm-hostmaster.ems.att.com.
21 10800 900 604800 7200
;; Received 131 bytes from 65.68.49.6#53(ns3.sbcglobal.net) in 92 ms
___
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: Query for newly added/modified data in zone fails at random

[Matthew Pounsett]

On 12 October 2017 at 11:03, Nikkilä, Tommi  wrote:

> Hi!
>
>
>
> My BIND (version 9.9.4-RedHat-9.9.4-51.el7) is displaying some odd
> behavior. When updating a zone, BIND randomly refuses to return the newly
> added  and/or modified data for client. In my named.conf I have dozens of
> views, main interest in the following
>

Each view keeps its own internal state for its zones.  The way you appear
to have this configured, for any zone in 'common-slave.conf' you have
several versions stored (one per view) each trying to write to the same
state file (e.g. slave/db.207.31.172.in-addr.arpa).

If I were to speculate (you'd want to do some more troubleshooting to
confirm), I would suspect you're running into problems with your views
stomping on each other's slave files.
___
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: Strange recursor response time pattern

[Matthew Pounsett]

On 5 September 2017 at 11:56, Havard Eidnes  wrote:

> Hmm...
>
> some further local discussion has made me aware that us running
> "collectd" for monitoring BIND may be contributing to the
> problem; collectd fetches data each 10s by using the BIND-
> configured statistics-channel, thus BIND is processing a TCP
> connection to deliver the statistics data.
>
> It's still somewhat surprising and disappointing that this should
> interfere this much with DNS query processing...
>
> Is that pulling the old-style stats file, or the HTTP-based stats channel?


If the latter... the zone list (and by extension the root document) seems
to take a long time to process, and involves some sort of locking that
blocks all query processing while the list is being generated.  We
encountered this on a 3+ million zone instance.. BIND would stop answering
queries for several minutes if anyone requested the root stats document or
the zone list.

As Ray says, you may be better off individually querying each of the other
documents and processing those rather than polling the root doc to get them
all in one shot.
___
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: botched KSK rollover

[Matthew Pounsett]

On 21 August 2017 at 07:18, Phil Mayers  wrote:

>
> Gandi are another excellent registrar that I can recommend. They have a
> comprehensive API for all their features, including uploading DNSSEC public
> keys and consequent creation of the DS record.
>
> I'm hoping CDS eventually makes this all obsolete.
>
> Gandi also has a beta implementation of
 draft-ietf-regext-dnsoperator-to-rrr-protocol, which requires CDS/CDNSKEY
support, and provides registrars with a way to bootstrap DNSSEC ... so you
may get your wish sooner than 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

Re: Can bind works without defining root servers

[Matthew Pounsett]

On 15 August 2017 at 11:29, King, Harold Clyde (Hal)  wrote:

> How does Bind update the root servers? Does it go out and check, or is a
> release made for each change?
>

Yes. :)

BIND has a compiled-in root hints list that is kept up to date at each
release, which can be overridden with a zone of type 'hint'.   It also does
what's calling "priming queries", which is to contact one of the known root
servers from the hints list, and retrieve and up-to-date authoritative NS
set for the root zone from the root zone itself.
___
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

[Matthew Pounsett]

On 6 February 2017 at 19:59, Mark Andrews  wrote:

>
> Unfortunately we then need to decide what to do with servers that
> don't answer EDNS + DNS COOKIE queries.  Currently we fall back to
> plain DNS which works except when there is a signed zone involved
> and the server is validating.
>
> I really don't want to add new automatic work arounds for broken
> servers but it requires people being willing to accepting that
> lookups will fail.  That manual work arounds will now have to
> be done. e.g. "server ... { send-cookie no; };"


I fully support breaking resolution for such servers.  I'd rather have a
hard failure on my end that I can investigate, and work around if
necessary, than have my server wasting cycles trying to guess what sort of
broken state there is on the far end.   It would also give me the heads up
I need to contact the admin on the far end and report their servers' broken
behaviour.
___
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: Graphing BIND 9.11/9.10 Queries

[Matthew Pounsett]

On 19 January 2017 at 10:16, Phil Mayers  wrote:

> On 19/01/17 15:12, John W. Blue wrote:
>
>> Daniel,
>>
>> Thanks for sharing.  I like the HTTP statistics channel but trying slice
>> up the XML has been challenging.  Going to be checking this combo out.
>>
>
> We moved to the JSON stats recently to get around a memory leak in our XML
> based script. Far nicer IMO.
>
> Yeah, I find processing the JSON stats much easier.. the tools for
importing JSON into  tend to be
pretty straightforward to use.
___
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 transferring zones with incorrect view

[Matthew Pounsett]

On 22 December 2016 at 13:05, Asai <a...@globalchangemusic.org> wrote:

> Still trying to figure this out, still am not doing something right.  I’m
> still getting REFUSED when trying to do transfers from Master to Slave.
> Not sure what I’m doing wrong, so please point out my errors here.  I have
> two views, but neither are getting any transfers so I’ve only included one
> in the config.
>

It would help if you included your entire config.  You're likely editing
out important things.
At the very least, your supplied config is missing the server{} statements
necessary to use TSIG in your zone transfer requests.


>
> Here’s my part of my config for Master and Slave:
>
> MASTER (10.233.0.198):
>
> key WAN-key {
> algorithm hmac-md5;
> secret “FsrWAd2G5saYSd3bOx0mw==";
> };
>
> key LAN-key {
> algorithm hmac-md5;
> secret “4hKGvi4BDswdTD2f1sEE2i==";
> };
>
> acl lan_hosts { key LAN-key; !key WAN-key; 192.168.0.0/16; 10.233.0.0/24;
> localhost; };
> acl wan_queries { key WAN-key; !key LAN-key; !192.168.0.0/16; !
> 10.233.0.0/24; };
>
> include "/etc/rndc.key";
> controls {
> inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { rndc-key; };
>  };
>
> view "LAN” {
>
> match-clients { lan_hosts; };
> allow-transfer { key LAN-key; };
> also-notify { 10.233.0.189 key LAN-key; };
>
> zone “intranet.site" {
> type slave;
> masters {
> 10.233.0.198;
> };
> file "/var/named/slaves/intranet.site.LAN.hosts";
> };
> }
>
>
>
>
> SLAVE (10.233.0.189):
>
> key WAN-key {
> algorithm hmac-md5;
> secret “FsrWAd2G5saYSd3bOx0mw==";
> };
>
> key LAN-key {
> algorithm hmac-md5;
> secret “4hKGvi4BDswdTD2f1sEE2i==";
> };
>
> acl lan_hosts { key LAN-key; !key WAN-key; 192.168.0.0/16; 10.233.0.0/24;
> localhost; };
> acl wan_queries { key WAN-key; !key LAN-key; !192.168.0.0/16; !
> 10.233.0.0/24;  };
>
> include "/etc/rndc.key";
> controls {
> inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { rndc-key; };
>  };
>
> view "LAN” {
>
> match-clients { lan_hosts; };
>
> zone “intranet.site" {
> type slave;
> masters {
> 10.233.0.198;
> };
> file "/var/named/slaves/intranet.site.LAN.hosts";
> };
> }
>
>
>
> On Dec 21, 2016, at 10:59 AM, Asai <a...@globalchangemusic.org> wrote:
>
> Yes, thank you.  I think Mark’s link to the article is the proper
> solution.  Thank you for your reply.
>
>
> On Dec 21, 2016, at 10:55 AM, Matthew Pounsett <m...@conundrum.com> wrote:
>
>
>
> On 20 December 2016 at 16:45, Asai <a...@globalchangemusic.org> wrote:
>
>> Greetings,
>>
>> Quick question.  Using BIND 9.9.4.  I have 2 zones.  One for LAN traffic,
>> and one for WAN traffic.  My secondary server is transferring the wrong
>> zones, so that my WAN zone has all the A records for my LAN zone.
>>
>> Any insights on this?
>>
>> Most likely you've misconfigured your master server such that the slave
> (secondary) sees the wrong zone when doing zone transfers.  But, because
> you haven't provided any real detail about your configuration, no one is
> going to be able to provide much in the way of advice about how to fix it.
>
> You should read the article that Mark Andrews linked, and if you still are
> not able to solve the problem you should return with some details about
> your setup.
>
>
> ___
> 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: BIND transferring zones with incorrect view

[Matthew Pounsett]

On 20 December 2016 at 16:45, Asai  wrote:

> Greetings,
>
> Quick question.  Using BIND 9.9.4.  I have 2 zones.  One for LAN traffic,
> and one for WAN traffic.  My secondary server is transferring the wrong
> zones, so that my WAN zone has all the A records for my LAN zone.
>
> Any insights on this?
>
> Most likely you've misconfigured your master server such that the slave
(secondary) sees the wrong zone when doing zone transfers.  But, because
you haven't provided any real detail about your configuration, no one is
going to be able to provide much in the way of advice about how to fix it.

You should read the article that Mark Andrews linked, and if you still are
not able to solve the problem you should return with some details about
your setup.
___
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: semicolons in dig output

[Matthew Pounsett]

On Fri, Nov 4, 2016 at 13:51 Robert Edmonds <edmo...@mycre.ws> wrote:

> Matthew Pounsett wrote:
> > Was this actually a change between BIND 9.8 and 9.9?  Was it deliberate,
> or
> > an accident that might be reversed at some point?
>
> It's this change:
>
> 3953.   [bug]   Don't escape semi-colon in TXT fields. [RT
> #37159]
>
> The corresponding git commit is here:
>
>
> https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commitdiff;h=9a36fb86f5019f25705d25ea729d03fcf8ecaa95
>
> --
> Robert Edmonds
>

Thanks for the pointer!
___
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: Wildcard SRV record?

[Matthew Pounsett]

On 31 October 2016 at 12:35, Stephen Pape  wrote:

> Is there a better way for me to do this, or do I have to generate a
> whole lot of specific CNAME records?
>

If your subdomains follow a predictable pattern, then this seems like a
prime use of the $GENERATE statement.  You could either use it to generate
the CNAMEs, or directly generate the SRV records themselves.
___
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: acl

[Matthew Pounsett]

On 8 October 2016 at 09:57, Pol Hallen  wrote:

> 192.168.1/24 is not a valid netmask
>>
>
> huh?
> In linux and BSD I always use 192.168.1/24 (how shortcut of 192.168.1.0/24)
> and so on...


You're confusing network configuration with ACL syntax.

Where you're using 192.168.1.50/24 in your OS configuration, what you're
really saying is 192.168.1.50 netmask 255.255.255.0.
When you use it in an ACL, you're saying "the entire /24 that contains
192.168.1.50"


> hint: using /24 everywhere is nonsense
>>
>
> why?
>
> My goal is allow 192.168.1.0/24 (net) and deny 192.168.1.50 (host)
>
> thanks
>
> Pol


It sounds like what you want is to permit 192.168.1.0/24 and deny
192.168.1.50/32.



>
> ___
> 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: Multiple IPs Associated With A Single Name

[Matthew Pounsett]

On 29 September 2016 at 15:07, Tim Daneliuk  wrote:

>
>
> No, not really.  It's for a private cloud microservices system we're
> thinking through.  We already run most/many of the various service
> backends in user space so that the app devs and support folks can control
> their own universe without having to constantly invoke someone with sudo
> or root or firecall permissions.   Because of very strict audit and
> regulatory constraints, there is zero chance they'll ever get root/sudo
> access to the DNS config, so running our private DNS just for this
> subset of private client/cloud users may make sense.
>
> I suppose you could leave yourself an unprivileged config file... have
them put you in group 'dns' or something, and make all the configs and zone
files writable by that group.   At least that way all you need your
sysadmins for is to issue the 'rndc reconfig' command.
___
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: Multiple IPs Associated With A Single Name

[Matthew Pounsett]

On 29 September 2016 at 12:02, Tim Daneliuk  wrote:

> In the dark and dusty reaches of my elderly DNS experience, ISTR a way to
> set up A records so that the request to resolve a name returns a *list
> of associated IPs*.  This is distinct from DNS RR (I think?) which
> simply returns a different *single* IP for each call (I may well be wrong).
>
> Can some kind soul point me to a relevant explanation of how to do the
> hostname -> multiple IP mapping?
>

Just include multiple A resource records (RRs).   It's up to the client how
it uses those records, and what makes sense there is largely application
specific: round robin, try them in series, etc.


>
> Thanks,
> --
> 
> 
> Tim Daneliuk tun...@tundraware.com
> PGP Key: http://www.tundraware.com/PGP/
>
> ___
> 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: dig +trace = Bad Referral orBad Horizontal referral

[Matthew Pounsett]

On 20 September 2016 at 12:50, project722 <project...@gmail.com> wrote:

> I've reverted my configuration back to before we started using views. But,
> if this was a delegation issue, wouldn't we expect to see it regardless of
> using views or not? Works fine without views.
>

It's entirely possible you introduced some error in your zone structure
when you changed configurations for views.  Again, it's impossible to tell
since you've (poorly) substituted all of the zone names and file name in
your configuration.   If you want help from someone in the list, you're
going to have to share details of your configuration.


>
> On Tue, Sep 20, 2016 at 8:58 AM, Matthew Pounsett <m...@conundrum.com>
> wrote:
>
>>
>>
>> On 16 September 2016 at 11:12, project722 <project...@gmail.com> wrote:
>>
>>> I have an interesting problem. I started noticing that when I do a dig
>>> +trace against one of the domains we are authoritative for, we get errors
>>> from our nameservers for "Bad Referral" and you can see where it forwarded
>>> the request back up the namespace tree instead of giving the answer.
>>> Unfortunately I am unable to reproduce this problem at the moment. However
>>> I can reproduce the Bad (HORIZONTAL) referral. Basically once the query is
>>> referred to our name server I see this:
>>>
>>> ;; BAD (HORIZONTAL) REFERRAL
>>> ;; Received 187 bytes from x.x.x.x#53(ns.example.com in 2 ms
>>>
>>
>> A horizontal referral is when one authoritative zone (the parent)
>> delegates a subdomain to a server that responds out of the same parent
>> zone, rather than a subzone.  The DNS is an inverted tree structure, and
>> delegations are always supposed to be "down" the tree toward the leaves.
>> If a delegation ends up being across, then you get a horizontal referral
>> error.
>>
>> Since you obfuscated your configuration nobody is going to be able to
>> provide you with specific advice on where the problem is.  If you can find
>> the error in your authoritative data (or share which zone is giving you
>> problems so that someone here can point it out) that should clear up your
>> issue.
>>
>
>
___
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: dig +trace = Bad Referral orBad Horizontal referral

[Matthew Pounsett]

On 16 September 2016 at 11:12, project722  wrote:

> I have an interesting problem. I started noticing that when I do a dig
> +trace against one of the domains we are authoritative for, we get errors
> from our nameservers for "Bad Referral" and you can see where it forwarded
> the request back up the namespace tree instead of giving the answer.
> Unfortunately I am unable to reproduce this problem at the moment. However
> I can reproduce the Bad (HORIZONTAL) referral. Basically once the query is
> referred to our name server I see this:
>
> ;; BAD (HORIZONTAL) REFERRAL
> ;; Received 187 bytes from x.x.x.x#53(ns.example.com in 2 ms
>

A horizontal referral is when one authoritative zone (the parent) delegates
a subdomain to a server that responds out of the same parent zone, rather
than a subzone.  The DNS is an inverted tree structure, and delegations are
always supposed to be "down" the tree toward the leaves.  If a delegation
ends up being across, then you get a horizontal referral error.

Since you obfuscated your configuration nobody is going to be able to
provide you with specific advice on where the problem is.  If you can find
the error in your authoritative data (or share which zone is giving you
problems so that someone here can point it out) that should clear up your
issue.
___
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: Question about dynamic IPv6-PTR-Generation

[Matthew Pounsett]

On 26 August 2016 at 15:41, Matus UHLAR - fantomas <uh...@fantomas.sk>
wrote:

>
>>> On 26.08.16 14:01, Matthew Pounsett wrote:
>
>> That's not necessarily true for IPv6, where even a modest network could
>> have trillions of addresses that may need PTR records.
>>
>
> that's exactly why using $GENERATE and/or creating new mechanism for that
> is
> useless.
>

$GENERATE is useless in that situation, yes.  But something that provides
rules to a name server to synthesize responses (vs actually generating all
18446744073709551616 PTRs in a /64) is not.
___
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: Question about dynamic IPv6-PTR-Generation

[Matthew Pounsett]

On 26 August 2016 at 13:45, Matus UHLAR - fantomas 
wrote:

> On 26.08.16 07:34, Tom Tom wrote:
>
>> I'm searching a way to respond to IPv6-PTR-Queries like the
>> "$GENERATE"-mechanism for IPv4 has done it.
>>
>
> why? configuring single IP addresses or taking them from DHCP is easier
> than
> creating new useless mechanism.
>

That's not necessarily true for IPv6, where even a modest network could
have trillions of addresses that may need PTR records.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Delegation questions

[Matthew Pounsett]

On 11 August 2016 at 10:14, Bob McDonald  wrote:

>
> Currently, clients sending queries for domain child.example.com. to
> server A get good results.
> However, clients sending queries for domain child.example.com. to server
> C get SERVFAIL because server C has no access to server B. (I'm guessing
> there is a firewall issue)
>

Your problem here is not directly related to the delegation.  Your problem
is that you have a recursive server (C) which is blocked from reaching a
part of the Internet where there is an authoritative server (B) it needs to
contact.

If these servers are not listed in the stub resolvers of systems as their
local recursors, then turn off recursion on the servers.  Otherwise, open
up your firewall rules to allow your recursive servers to reach the entire
Internet, and the entire Internet to reach your authoritative servers.


>
> The question is if I get rid of the delegation and put in a stub zone on
> server A pointing to child.example.com. on server B, can I use forwarders
> for child.example.com. on server C to point at server A for resolution of
> child.example.com.? (Will server A get answers directly from server B or
> will server A simply refer me to server B?)
>

That's a very convoluted way of fixing what is simply a bug in your
firewall configuration.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Delegation questions

[Matthew Pounsett]

On 11 August 2016 at 09:13, Bob McDonald  wrote:

> I have a child domain that is delegated to a second site. Pretty
> straightforward situation. In the parent zone I have NS records that point
> to the DNS servers at the second site.
>
> The issue comes up when a slaved copy of the parent domain is running at a
> third site and that third site doesn't have a rule in their firewall
> allowing DNS access to the second site (where the child domain is
> delegated).
>
> The question is this; can I use stub zones to reference the child domain
> on the master server (instead of delegation) and the use forwarding at the
> third site to direct queries for the child domain through the master
> server?
>
> I hope the picture I've tried to describe is somewhat clear.
>

If the setup is exactly as you describe, then there's probably no reason
for a name server authoritative for the parent zone to ever need to contact
a server authoritative for the child zone.  Delegation from A to B doesn't
imply direct communication between A and B.

That said, you never know where on the Internet queries for a zone will
arrive from.  If you want the Internet at large to be able to resolve names
in your zone, then you can't firewall yourself off from parts of the
Internet.

If any of the servers in this scenario are also acting as recursive
servers, then you have the same problem;  you never know where on the
Internet an authoritative server you need to speak to is going to be, so
you can't firewall your recursive server off from speaking to parts of the
Internet and expect it to work reliably.




>
> Regards,
>
> Bob
>
> ___
> 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: named and use of resolv.conf? - how to "learn" this

[Matthew Pounsett]

On 2 August 2016 at 19:50, Evan Hunt <e...@isc.org> wrote:

> On Tue, Aug 02, 2016 at 05:04:33PM -0400, Matthew Pounsett wrote:
> > Yes it will.  But, as far as I understand, it uses the recursive code
> paths
> > to do that, and won't consult resolv.conf.  Yes?
>
> Correct. However, an option to use the system resolver for this instead
> is a feature request we've been considering.
>
> The reason: Whenever we find a security bug that affects recursive
> operation only, someone who runs an auth-only server inevitably asks
> whether their system is affected, and we always have to say, "well,
> *probably* not, but recursive code *is* sometimes used in authoritative
> servers in order to blah blah etc" and it might be nice to just say no.
>

I'd suggest another reason:  the auth server should be subject to the same
resolution path/rules as other software in the network.  If, for example,
I've got some resolution exception configured in my local recursive servers
(such as a per-zone forwarding rule) it seems likely I'd want the
authoritative server to follow that without having to also configure it
into the authoritative server.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: named and use of resolv.conf? - how to "learn" this

[Matthew Pounsett]

On 2 August 2016 at 17:01, Ray Bellis <r...@isc.org> wrote:

> On 02/08/2016 19:47, Matthew Pounsett wrote:
>
> > In the authoritative configuration, BIND has no need to do DNS lookups
> > of its own, so it wouldn't be any use there.
>
> That's not strictly true - BIND will in some circumstances use its own
> internal resolver to handle the host lookups for NOTIFYs and XFRs if
> they're using hostnames instead of IP lists.
>

Yes it will.  But, as far as I understand, it uses the recursive code paths
to do that, and won't consult resolv.conf.  Yes?


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

Re: named and use of resolv.conf? - how to "learn" this

[Matthew Pounsett]

On 2 August 2016 at 12:25, Spumonti Spumonti  wrote:

> (I've done several searches for this first but the general nature of some
> of these terms returned way too many non-relevant responses)
>
> I was recently told that named does not use resolv.conf when resolving
> names. This was not something I was aware of but at this point I accept
> that. The system in question is an authoritative only server, no recursion
> enabled, that for some zones it hosts, lists secondary name servers in
> other organizations (in other words these name servers are in zones NOT
> hosted on this server)
>
> My real question is: where is this documented? I've read DNS books and
> scoured different sites but couldn't find anything stating this was how
> named behaved. Maybe I just suck at searching for things or was using
> imprecise terms.
>

The fact that named doesn't use resolv.conf wouldn't be documented anywhere
because they're unrelated.   Particularly for an authoritative server,
there's not reason for BIND to consult the system stub config, which is
what resolv.conf is (primarily) for.

To use a somewhat exaggerated comparison, documenting anywhere that BIND
doesn't consult resolv.conf would be like documenting that your car doesn't
need a ladder.

In the authoritative configuration, BIND has no need to do DNS lookups of
its own, so it wouldn't be any use there.   And BIND in recursive mode has
a hints list which tells it where the root servers are.  It will use those
to follow delegations to the correct authoritative server for whatever
lookup it's attempting to do.

resolv.conf configures the stub resolver (and occasionally other software
that behaves like a stub resolver) to tell it where the local recursive
servers are.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Loading all zone files in a directory

[Matthew Pounsett]

On 23 July 2016 at 15:25, Danilo  wrote:

> Is there a way to get Bind to automatically include config files in a
> directory? If not, might it make sense to place a feature request for
> this with the Bind developers? If yes, what would the process be for
> such a request? Or is there a better alternative to this approach?
>

The relevant paragraph in the BIND 9.10 ARM doesn't say it, but I *think*
you can use at least some of the usual shell wildcard characters in the
include statement.

If so, something like:
include "/path/to/config/*.conf";
should work.

You don't say in your email whether you've tested this, but it'd be fairly
easy to check.   If that doesn't work, then no, there is no way to
accomplish what you want. (It seems to me this would be a fairly easy
feature request to grant... Mark?  Evan?)

If include doesn't do that, you should be able to get Ansible to assemble a
single config file from a template though, and include all of your zone
definitions in that.   It might require reorganizing your ansible roles
though, so that your complete zone list is given as variable input into a
role that handles the entire configuration for BIND.
___
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

[Matthew Pounsett]

On 17 May 2016 at 09:29, Woodworth, John R 
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.
> >
> > Agreed. Nice in theory, not going to happen in practice for the ISP
> where I'm working.
>
>
> Ditto here, great feature for smaller shop but not an ISP for a number of
> reasons.
>
> I would also add based on business perspective sometimes "lazy" is
> consumer or market
> driven and can't be simply dismissed. How popular would a brand new 60"
> television be
> without a remote control?
>
> Indeed.  When a business appears "too lazy" to do a thing you want them to
do, what that really means is that there is no business case that makes it
worth their while to spend the money on doing it.
___
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: Logging question about message 'update-security: error: client update denied'

[Matthew Pounsett]

On 16 May 2016 at 19:03, Josh Nielsen  wrote:

> Thank you for the response Mark. I'm still a little confused at what this
> might mean though. Clearly the originating address is my slave DNS server
> (every single one of the messages say "error: client 10.20.0.101").
>
> Are you saying that some process other than named on the same server
> (10.20.0.101) is responsible for these messages (and is there a 'for
> instance' of what could do such a thing?), or that somehow other hosts are
> relaying their update requests (again: from what possible processes?)
> through my slave dns server? What can I look for to figure this out on my
> network?
>

Your DHCP daemon would be one thing that could be generating those
messages.  Often it's configured to update the DNS with the addresses it's
handing out (either forward, reverse, or both).
___
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: Shared libraries loaded after chroot

[Matthew Pounsett]

On 16 May 2016 at 04:38, Marc Haber  wrote:

> I have filed Debian Bug #820974 (http://bugs.debian.org/820974)
> accordingly. The Debian bind people suggest that I copy the respective
> libraries to the chroot so that bind can find them.
>

Yeah, this has been the fix on a lot of systems since GOST was included in
OpenSSL.  It's something to do with the GOST algorithm being implemented
differently from everything else... as a plugin instead of a module, if
memory serves (it probably doesn't).IMHO it's a bug in OpenSSL, not
BIND.

Another option is to compile BIND with GOST support disabled... but that is
awkward for a lot of people using binary package distribution from the OS
vendor.


>
> This, however, would take possibly security relevant libraries from
> the automated update mechanisms of the distributions, and would
> therefore greatly reduce ease of upgrades. It is also not mentioned in
> Chapter 6 of the ARM.
>
> What is the official upstream remedy to this situation?
>
> Frankly, I think this is a bug in bind 9.10, it should load all
> necessary libraries before chrooting itself. I am aware that this
> would probably need parsing of the configuration before chrooting.
>
> What is the recommended way to run bind 9.10 in a chroot?
>
> Greetings
> Marc
>
> --
>
> -
> Marc Haber | "I don't trust Computers. They | Mailadresse im Header
> Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
> Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
> ___
> 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: Forward record for WWW

[Matthew Pounsett]

On 5 May 2016 at 11:55, Stephane Bortzmeyer  wrote:

> On Thu, May 05, 2016 at 03:42:24PM +,
>  Cuttler, Brian R. (HEALTH)  wrote
>  a message of 29 lines which said:
>
> > External record in the zone file is actually
> > wadsworth.org. 300 IN A 199.184.16.22
>
> None of the three name servers for wadsworth.org serve this A record.
>
> It seems the master was *not* reloaded. Did you check its BIND logs to
> see? May be the new zone with the A record at the apex was rejected
> for some reason.
>

Or perhaps the record was added to a hidden master without the serial
number being updated, and so a zone transfer hasn't happened?
___
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

[Matthew Pounsett]

On 2 May 2016 at 16:38,  wrote:

>
>
> On Mon, May 2, 2016, at 12:15 PM, Jeremy C. Reed wrote:
> > What about using a specific zone file just for the purpose of the single
> > A record you want to maintain using dynamic updates?
>
> Well, this is a timely idea for another issue I've been working on ...
>
> Could you expand on this a bit? Maybe an example?
>
> I'm not clear how you go about maintaining a 'different' zone for a record
> that belong in the 'original', parent zone.
>
> He's suggesting something like having example.com and dynamic.example.com
as separate zones, where the A record at the apex of the dynamic.example.com
zone is the host you want to maintain.   That'll let you have different
configurations for both zones (one dynamic, one manual).

example.com. IN SOA (...)
 IN NS ns1.example.com.
 IN NS ns2.example.com.

www  IN A  192.0.2.1
dynamic  IN NS ns1.example.com.
 IN NS ns2.example.com.
---

dynamic.example.com. IN SOA (...).
 IN NS ns1.example.com.
 IN NS ns2.example.com.
 IN A  192.0.2.1  ; use nsupdate to change me
---
___
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?

[Matthew Pounsett]

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

[Matthew Pounsett]

On 2 May 2016 at 10:09,  wrote:

> hi,
>
> What you're describing sounds wrong.  It shouldn't work that way.
>>
> what do you mean by "wrong" and which "it" should not work? :-)
>
>
What I mean is, given a typical configuration, the brokenness you're
observing shouldn't be broken.


> Can you share your configuration so that we can see what's actually
>> happening?
>>
>
> sure :-)
> samples:

Can you share your whole config?  It's possible there are options outside
the zone stanzas that could affect the behaviour of  notifies.
___
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

[Matthew Pounsett]

On 1 May 2016 at 23:57,  wrote:

> hi,
> i have a setup with one normal and some hidden slaves.
> i set up a zone with also-notify and all worked fine.
> all slaves got notifies and updates.
> now i added a key and policy to remote update the zone.
> the updates with nsupdate woks fine.
> but the notify is only sent to the slave, but not to the hidden slaves.
> so just the master and official slave is up to date.
>
> how can i change that?
>
> i use BIND 9.8.4-rpz2+rl005.12-P1 on debian wheezy...
>

What you're describing sounds wrong.  It shouldn't work that way.
Can you share your configuration so that we can see what's actually
happening?
___
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: Compiling BIND9 on CentOS 7

[Matthew Pounsett]

On 27 April 2016 at 08:34, Sean Son 
wrote:

> Thank you for your response. Basically what I am trying to do is migrate
> the BIND server from a Centos 5.11 machine to a CentOS 7.2 machine.  The
> BIND on CentOS 5.11 was compiled manually by source and its named.conf file
> looks very different than what CentOS/Red Hat provides in the RPM package
> named.conf file. Any tips on how I should go about migrating successfully
> from the 5.11 machine to the 7.2 machine?
>

Your best approach is to have a careful look at the named.conf you're
migrating from and understand what options are required by your DNS needs,
and which are just related to how the Centos 5 machine is organized.  You
can then merge the former set (your requirements) into the default config
of the Centos 7 machine.


>
>
> As for the named.service unit file that Reindl provided, will I need to
> call upon any RNDC services? I saw that in the named.service file that
> comes with the RPM/YUM package contains a call to some RNDC service which
> calls up some generate-rndc-key.sh script.. I am not too sure of what the
> names of the files are.
>

rndc is the command line interface to a running BIND server.  (BIND ==
berkeley internet name domain, rndc == remote name domain controller (or
something to that effect)).  The rndc.conf file must agree with the
named.conf file on where BIND's controller interface is (the controls{};
clause in named.conf) and what key to use for authentication, if any.

For example, named.conf might have something like this:
controls {
inet 192.0.2.1 port 953 allow { 192.0.2.100; } keys {"rndc-key"; };
};
While your rndc.conf might have:
options {
default-key "rndc-key";
default-server 192.0.2.1;
default-source-address 192.0.2.100;
default-port 953;
};


It sounds to me like the named.service file you mention is probably
generating a default rndc.conf file if one doesn't already exist.
___
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: Adding CNAME for the root domain issue

[Matthew Pounsett]

On 27 April 2016 at 07:40, Stephane Bortzmeyer <bortzme...@nic.fr> wrote:

> On Wed, Apr 27, 2016 at 07:32:48AM -0700,
>  Matthew Pounsett <m...@conundrum.com> wrote
>  a message of 49 lines which said:
>
> > One of these days I'd like to lead a serious lobbying effort against
> > the browser developers at the W3C to have SRV records for HTTP
> > standardized.
>
> I fully agree and, if you're brave enough to propose it to the DNSOP
> working group at IETF, I volunteer for reviewing/etc.
>
> There is a starting point:
>
> https://datatracker.ietf.org/doc/draft-andrews-http-srv/


Unfortunately, the problem is not one that can be easily fixed at the IETF.
   I'll go have a look at Mark's draft, but here's the core problem as I
see it:

RFC 2782 (SRV) says:

Applicability Statement

   In general, it is expected that SRV records will be used by clients
   for applications where the relevant protocol specification indicates
   that clients should use the SRV record. Such specification MUST
   define the symbolic name to be used in the Service field of the SRV
   record as described below. It also MUST include security
   considerations. Service SRV records SHOULD NOT be used in the absence
   of such specification.


This means that SRV records will not (can not) be used for the web until
the HTTP spec says they can.  This requires W3C action.

At the same time, the browser developers, almost without exception, refuse
to implement SRV because they don't like the idea that they might have to
do another DNS lookup prior to displaying a web page.  And they lobby the
W3C pretty hard to not standardize SRV for HTTP.

That's a pretty serious impasse .. and one that I think is only going to be
overcome by an equally strong lobbying movement from the DNS hosting
industry, when we get tired of trying to educate end users on why CNAME at
apex won't work (end users who don't–and shouldn't need to–care), and get
tired of maintaining messy record synthesis processes.

But this is getting way off topic for BIND-users, and should probably be
moved to dns-operati...@dns-oarc.net if we want to continue.
___
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: Adding CNAME for the root domain issue

[Matthew Pounsett]

On 27 April 2016 at 07:42, Baird, Josh  wrote:

> Any thoughts on a service like Cloudfare's 'CNAME Flattening' [1]?
>
> [1]
> https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/


It's possible.  We do a similar thing at eNom... we allow end-users to
insert CNAME records at the apex of the zone in the UI, but then we replace
those with synthesized records.  It's far from ideal, however.  It means
you've either got to act partly like a recursive server and do back-end
lookups every time a CNAME query comes in, or you have to periodically
re-query every authoritative CNAME at the apex of your zones in order to
refresh the synthesized replacement records before the queries come in.
The former introduces latency, and the latter risks serving out-of-date
records and is a huge workload when you're our size.. or worse..
Cloudflare's size.
___
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: Adding CNAME for the root domain issue

[Matthew Pounsett]

On 27 April 2016 at 07:26, Stephane Bortzmeyer  wrote:

> On Wed, Apr 27, 2016 at 05:05:50PM +0300,
>  Daniel Dawalibi  wrote
>  a message of 52 lines which said:
>
> > our setup requires a CNAME record.
>
> Bad setup. (And has always been bad.)
>
>
This isn't really his fault.  The OP's goal should be achievable (using the
apex domain name to reach a host that is not an A/ record at the apex),
it just can't be done with CNAME.   One of these days I'd like to lead a
serious lobbying effort against the browser developers at the W3C to have
SRV records for HTTP standardized.   That would completely fix this
problem.   The end user gets to do what they want to do, and the DNS
standards aren't violated.
___
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?

[Matthew Pounsett]

On 27 April 2016 at 03:07, Tony Finch <d...@dotat.at> wrote:

> Matthew Pounsett <m...@conundrum.com> wrote:
> >
> > Privsep doesn't actually fix the same problem chroot does.   As I
> > understand it, privsep reduces the attack surface for remote execution
> > exploits by shuffling off privileged operations to a separate process,
> but
> > if that process isn't chrooted and it has a remote code execution flaw
> then
> > your entire system is opened up to attack.
>
> Actually it is normal for privsep processes to chroot themselves, usually
> to /var/empty - e.g.
>

Right, so "no chroot necessary" (which is what I was responding to) isn't
accurate.
___
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?

[Matthew Pounsett]

On 25 April 2016 at 11:44,  wrote:

>
>
>
> I completely gave up on chroot'd ntpd because of the endless weirdness.
> Finally just moved to openntpd as (1) it had safe privsep, (2) no chroot
> req'd, and (3) did the job I need.
>

Privsep doesn't actually fix the same problem chroot does.   As I
understand it, privsep reduces the attack surface for remote execution
exploits by shuffling off privileged operations to a separate process, but
if that process isn't chrooted and it has a remote code execution flaw then
your entire system is opened up to attack.  Likewise, the unprivileged
process still has access to your entire system, and may still be used to
execute unprivileged code in the event of a remote execution
vulnerability.  Combined with other flaws in the system, both can still
lead to a privileged remote attack.   By contrast, chroot contains the
results of a successful remote execution to the environment of that
process, preventing a successful remote execution attack from touching the
filesystem outside the chroot... which limits the possible damage to the
exploited process.  Both things together are better than either one alone.
___
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?

[Matthew Pounsett]

On Monday, 25 April 2016, <jaso...@mail-central.com> wrote:

>
>
> On Mon, Apr 25, 2016, at 10:58 AM, Matthew Pounsett wrote:
> > It's not clear to me why one would want to destroy/rebuild the chroot
> every
> > time you restart the process.
>
> Well, here
>
> (1) Because I inherited it this way, and
> (2) The notes' quoted examples did that too, and
> (3) I'd not yet gotten any/good advice NOT to (security?)


Unless you have a clear reason to do it (perhaps there's some security
consideration I haven't thought of) it seems to me it's unnecessary
complexity that would lead to problems just like this.

>
> TBH, I'm not even sure whether "these days", chroot is still recommended.
> Apparmor or Docker instead? Is privsep taken care of in current bind so we
> don't have to worry about it anymore (e.g., the openntpd vs ntpd case)?
> I'm not clear on it.


Although BIND 9 has never had a remote code execution exploit that I'm
aware of, it's still advisable to run it in a chroot environment.
___
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?

[Matthew Pounsett]

On 25 April 2016 at 13:53,  wrote:

>
>
> I suspect that there's something wrong with what is/isn't copied , and
> maybe when, in that chroot build/destroy script.
>

It's not clear to me why one would want to destroy/rebuild the chroot every
time you restart the process.  However, as long as you're doing that you
should make sure that all the important files are preserved.  As you noted
earlier, it looks like your journal file is probably not preserved.  I'd
start there, and if that doesn't fix it, then have a careful look at what's
in your chroot tree before you shut down the server, and compare that to
what's in the chroot after you start it up again.
___
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?

[Matthew Pounsett]

On 25 April 2016 at 13:44, <jaso...@mail-central.com> wrote:

>
>
> On Mon, Apr 25, 2016, at 10:19 AM, Matthew Pounsett wrote:
> > > TBH I don't understand WHAT to 'expect' from dig to test/verify this^.
> > > What do I dig to get an answer with "TEST STRING" in it?
> >
> > dig in txt test.example.com @ns01.example.com
>
> Thanks.
>
> Unfortunately, that^ returns no TXT record either.  Which to me suggests
> the problem's 'earlier'.
>

Yeah.  I think you need to solve the problem with the vanishing journal
file first.   But, the above dig is what you *should* do to get back the
TXT record that you're adding.  If it's not getting you the record, then
there's a problem with your server somewhere.


>
> Jason
>
___
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?

[Matthew Pounsett]

On Sunday, 24 April 2016,  wrote:

> > This zone would not pass named-checkzone, which interestingly, is the
> same code which named itself uses when initially loading a zone.
>
> It appears to
>
> named-checkzone -t /var/chroot/named example.com
> /namedb/master/example.com.zone
> zone example.com/IN: loaded serial 1461540029
> OK
>
>
> cat /tmp/nsupdate.txt
> server ns01.example.com
> debug yes
> zone example.com.
> update add test.example.com. 300 in TXT "TEST STRING"
> show
> send
>
> $NSUPDATE /tmp/nsupdate.txt
>
> @ server
>
> Apr 24 16:24:02 ns01 named[14954]: 24-Apr-2016 16:24:02.350
> update-security: info: client 10.0.0.17#26427/key jason-key: view external:
> signer "jason-key" approved
> Apr 24 16:24:02 ns01 named[14954]: 24-Apr-2016 16:24:02.350
> update: info: client 10.0.0.17#26427/key jason-key: view external: updating
> zone 'example.com/IN': adding an RR at 'test.example.com' TXT "TEST
> STRING"
>
> TBH I don't understand WHAT to 'expect' from dig to test/verify this^.
> What do I dig to get an answer with "TEST STRING" in it?


dig in txt test.example.com @ns01.example.com

>
> Jason
> ___
> 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: dig ignores +notcp when doing IXFR (DiG 9.5.0-P2)

[Matthew Pounsett]

On 2013-12-06, at 12:11 , Chris Thompson c...@cam.ac.uk wrote:

 
 The sense in which BIND forces use of TCP is that when it gets an
 IXFR request over UDP, it always just replies with the current SOA.
 It doesn't bother to work out whether an incremental transfer is
 possible and if so whether it would fit into the UDP payload.
 
 Of course, if the client's supplied SOA serial is the same, this
 response indicates that no zone transfer is needed.

Yeah, the mechanism is clear.  I was curious about the why rather than the how.

___
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

dig ignores +notcp when doing IXFR (DiG 9.5.0-P2)

[Matthew Pounsett]

I'm trying to debug an IXFR problem with a client, and using dig in its place 
to compare IXFR requests between it and the misbehaving client.  I noticed that 
when I do an IXFR with dig it defaults to TCP rather than UDP.  I tried forcing 
it over with +notcp but I still get a TCP query.

From the man page:
   +[no]tcp
   Use [do not use] TCP when querying name servers. The default
   behavior is to use UDP unless an AXFR or IXFR query is requested,
   in which case a TCP connection is used.

This implies to me that it is simply the default to use TCP for *XFR, but one 
should be able to override it.  Is that the correct interpretation of the man 
page?

Even if that is not the correct interpretation, it seems to me that since IXFRs 
can and do happen over UDP, it should be possible to tell dig to do that.

Is this a bug, or a design flaw?

- Matt
___
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: dig ignores +notcp when doing IXFR (DiG 9.5.0-P2)

[Matthew Pounsett]

On 2013-12-04, at 21:22 , Mark Andrews ma...@isc.org wrote:

 
 The options are processed left to right so the +notcp has to be
 after the ixfr=serial.

There are two reasons I don't understand why this is the case.

1) Since there is only one query in the command, I don't understand why left 
to right matters.  If you could do something like
dig IN IXFR=serial example.com +notcp IN A www.example.com +tcp
then sure.. because changing the order of options would be ambiguous, but you 
can't do that.

2) dig is generally very forgiving of argument order, so I don't see why the 
location of +notcp would be any different.

 dig +short @8.8.8.8 IN A cbc.ca
159.33.3.85

 dig @8.8.8.8 IN A cbc.ca +short
159.33.3.85

 dig IN A cbc.ca +short @8.8.8.8
159.33.3.85


 Note, named will for the use of TCP in its UDP response.

What verb is missing from this sentence?


___
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 problem: bind98-base FreeBSD port

[Matthew Pounsett]

On 2012/07/08, at 22:25, Barry Margolin wrote:

 In article mailman.Okay.  
 
 
 So to answer my earlier question, what file were you talking about copying 
 into the chroot environment for BIND?
 
 The shared library. When you link dynamically, all the libraries have to 
 be in $chroot/usr/lib.

No, they don't.  Shared libraries are picked up at runtime. Chrooting happens 
after that, once the libraries have already been read.



___
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

OpenSSL problem: bind98-base FreeBSD port

[Matthew Pounsett]

I upgraded my OpenSSL and BIND ports on one of my machines yesterday afternoon, 
and ended up with BIND being unable to start due to some problem with OpenSSL.  
Unfortunately, it's not giving me any real information to go on about what the 
problem is.  

 openssl version
WARNING: can't open config file: /usr/local/openssl/openssl.cnf
OpenSSL 1.0.1c 10 May 2012

 sudo named -g -t /var/named/authoritative/ -u bind -d 100
08-Jul-2012 16:45:00.347 starting BIND 9.8.3-P1 -g -t /var/named/authoritative/ 
-u bind -d 100
08-Jul-2012 16:45:00.347 built with '--localstatedir=/var' 
'--disable-linux-caps' '--disable-symtable' '--with-randomdev=/dev/random' 
'--with-openssl=/usr/local' '--with-libxml2=/usr/local' '--with-idn=/usr/local' 
'--with-libiconv=/usr/local' '--enable-largefile' 
'STD_CDEFINES=-DDIG_SIGCHASE=1' '--enable-ipv6' '--enable-threads' 
'--sysconfdir=/etc/namedb' '--prefix=/usr' '--mandir=/usr/share/man' 
'--infodir=/usr/share/info/' '--build=x86_64-portbld-freebsd8.2' 
'build_alias=x86_64-portbld-freebsd8.2' 'CC=cc' 'CFLAGS=-O2 -pipe 
-fno-strict-aliasing' 'LDFLAGS= -rpath=/usr/local/lib' 'CPPFLAGS=' 'CPP=cpp' 
'CXX=c++' 'CXXFLAGS=-O2 -pipe -fno-strict-aliasing'
08-Jul-2012 16:45:00.347 
08-Jul-2012 16:45:00.347 BIND 9 is maintained by Internet Systems Consortium,
08-Jul-2012 16:45:00.347 Inc. (ISC), a non-profit 501(c)(3) public-benefit 
08-Jul-2012 16:45:00.347 corporation.  Support and training for BIND 9 are 
08-Jul-2012 16:45:00.347 available at https://www.isc.org/support
08-Jul-2012 16:45:00.347 
08-Jul-2012 16:45:00.347 found 4 CPUs, using 4 worker threads
08-Jul-2012 16:45:00.349 using up to 4096 sockets
08-Jul-2012 16:45:00.349 Registering DLZ_dlopen driver
08-Jul-2012 16:45:00.349 Registering SDLZ driver 'dlopen'
08-Jul-2012 16:45:00.349 Registering DLZ driver 'dlopen'
08-Jul-2012 16:45:00.351 decrement_reference: delete from rbt: 0x802467058 .
08-Jul-2012 16:45:00.352 initializing DST: openssl failure
08-Jul-2012 16:45:00.352 exiting (due to fatal error)

I found multiple versions of libgcrypt installed, which was generating some 
compile warnings, but cleaning that up didn't help.  There is only one version 
of openssl installed, so no conflicts there..

 ls -d /var/db/pkg/*ssl*
/var/db/pkg/openssl-1.0.1_3

I can recompile without SSL to get my name servers running again, but that's 
not really sustainable.  Does anyone have any suggestions for how to get more 
information out of BIND about what exactly is failing?


___
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 problem: bind98-base FreeBSD port

[Matthew Pounsett]

On 2012/07/08, at 15:04, Michael Sinatra wrote:

 What makes me doubt what I just said is that this has been an issue for more 
 than a year now, so I am not sure why you have escaped it for so long.  I 
 assume you had openssl 1.0.x installed before you upgraded it--or was it an 
 earlier version?

I keep things pretty up to date, and this machine isn't that old anyway.  It's 
possible that due to order of operations when I was building things that bind 
was previously linked against the system openssl libraries, rather than the 
ports version.  

 At any rate, if you run make config in /usr/ports/security/openssl, it gives 
 you the option of compiling the libraries statically.  I have successfully 
 done this in the past and it has worked.  However, anything else that is 
 currently depending on the openssl shared library from ports (as opposed to 
 the bundled system) will need to be recompiled before it will work, as will 
 bind 9.8.

I'll give that a shot.. thanks, it sounds promising.

 Doug Barton may have some better ideas as to how best to make it all work.

Yeah, I have to wonder if there's something that can be done in ports to 
prevent this from being an issue.


___
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 problem: bind98-base FreeBSD port

[Matthew Pounsett]

On 2012/07/08, at 17:46, Doug Barton wrote:

 On 07/08/2012 13:40, Matthew Pounsett wrote:
 Yeah, I have to wonder if there's something that can be done in ports to 
 prevent this from being an issue.
 
 You need to ask the nice openssl people to turn gost into a library
 instead of an engine. Meanwhile, copying the file into the chroot will
 patch over the problem.

Statically linking openssl seems to have fixed it.

But, what file are you talking about?

___
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 problem: bind98-base FreeBSD port

[Matthew Pounsett]

On 2012/07/08, at 20:26, Mark Andrews wrote:

 
 One can also build named w/o GOST support if one wants.  We statically
 link all the engines when building named on Windows.

Unfortunately the port doesn't provide the config hooks to disable GOST support.



___
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 problem: bind98-base FreeBSD port

[Matthew Pounsett]

On 2012/07/08, at 20:29, Matthew Pounsett wrote:

 
 On 2012/07/08, at 20:26, Mark Andrews wrote:
 
 
 One can also build named w/o GOST support if one wants.  We statically
 link all the engines when building named on Windows.
 
 Unfortunately the port doesn't provide the config hooks to disable GOST 
 support.

Actually.. how do you go about doing that anyway?  I was just taking a look at 
writing a patch for the port to allow GOST to be turned off, but BIND's 
configure script doesn't have any information in it about disabling individual 
ciphers.



___
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 problem: bind98-base FreeBSD port

[Matthew Pounsett]

On 2012/07/08, at 20:40, Doug Barton wrote:

 On 07/08/2012 17:33, Matthew Pounsett wrote:
 
 On 2012/07/08, at 20:29, Matthew Pounsett wrote:
 
 
 On 2012/07/08, at 20:26, Mark Andrews wrote:
 
 
 One can also build named w/o GOST support if one wants.  We statically
 link all the engines when building named on Windows.
 
 Unfortunately the port doesn't provide the config hooks to disable GOST 
 support.
 
 Actually.. how do you go about doing that anyway?  I was just taking a look 
 at writing a patch for the port to allow GOST to be turned off, but BIND's 
 configure script doesn't have any information in it about disabling 
 individual ciphers.
 
 I wouldn't accept it anyway. For better or worse, GOST is part of the
 protocol.

Okay.  

So to answer my earlier question, what file were you talking about copying into 
the chroot environment for BIND?



___
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: big improvement in BIND9 auth-server startup time

[Matthew Pounsett]

On 2011/07/13, at 11:15, Evan Hunt wrote:

 
 People who operate big authoritative name servers (particularly with
 large numbers of small zones, e.g., for domain hosting and parking),
 and have had trouble with slow startup, may find this information
 useful:
 
 http://www.isc.org/community/blog/201107/major-improvement-bind-9-startup-performance

Thanks Evan.  I'll also point out to people this PDF which has some more detail 
on the actual performance improvements: 
http://www.isc.org/files/imce/startup-performance.pdf

Was there any work done on measuring the impact on 'reconfig' times, or is that 
an entirely separate piece of code?  I'm curious if the change makes any 
difference to adding large numbers of zones to an already-running server.  e.g. 
if I've got a server handling 500,000 zones and add another 20k, 50k, or 100k 
via 'reconfig'.

Thanks to the ISC folk for doing that work!
   Matt


___
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-operations] Bind 9.8.0 intermittent problem with non-recursive responses

[Matthew Pounsett]

On 2011-05-19, at 21:58, Michael Sinatra wrote:

 If you're saying that you shouldn't *offer* recursive and authoritative 
 services on the same box, then I generally agree.  If you're saying that you 
 shouldn't ever prime your cache with a zone, or have a recursive server be a 
 slave to anything, then I'd say it gets kind of hairy there.

Indeed.  Hairy is an apt description of the situation.  There are many cases 
where it can work fine, and there are also plenty of cases where it won't, and 
the ones where it won't will be difficult for most operators to figure out.  If 
one must run the two services on the same machine, it's much safer to split 
them into separate processes.  

If, for some reason, you can't wait for your TTLs to expire, then forwarding 
the relevant zones to your authoritative servers is a better solution than 
slaving the zones. 

 Moreover, the recommended RPZ configuration as of BIND 9.8.0 is to have your 
 recursive servers slave your RPZ zone, so your recursives will have to slave 
 something if they run RPZ.

RPZ is an entirely different situation.  Nobody's going to be querying your RPZ 
zones, and so there's no case where the server will get confused about which 
resolution algorithms to use.

 You will particularly run into problems if you ever intend to do
 DNSSEC validation on these name servers.. it just won't work.
 
 Yes.  In that case, static-stub or forwarding is your friend.  Although, we 
 should be clear: It won't work on the zones that are slaved by the recursive 
 server.  Presumably one is protecting those zones some other way (TSIG, 
 SIG(0)).  It *will* (and does) work for signed zones for which the recursor 
 is not authoritative.

I'm not even sure forwarding helps here.  But yes, you're right, it breaks only 
for the zones you're slaving... but the fact that they're being slaved suggests 
they're the most important ones.

I don't know of many organizations larger than a few dozen people using SIG(0) 
or TSIG between stub and caching servers... certainly none where the stubs are 
on random student computers.  I'd be rather surprised to find any universities 
at all doing that outside of the machines operated by the computer labs.


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

Re: [dns-operations] Bind 9.8.0 intermittent problem with non-recursive responses

[Matthew Pounsett]

While it's possible you have encountered a bug with BIND, it's generally a bad 
idea to mix recursive and authoritative service in the same process. The RFCs 
that define the resolution algorithms were never written with mixed service in 
mind, and there are conflicts that can result in undefined, and therefore 
unpredictable, behaviours.   It will be hard to determine which you're seeing 
without more specific information about the configuration of the servers in 
question (e.g. which zones they're actually authoritative for).  

You will particularly run into problems if you ever intend to do DNSSEC 
validation on these name servers.. it just won't work.

I maintained the cross-posting for this reply because of the general DNS 
service advice, but my suggestion would be to limit the thread to the 
bind-users until you identify or rule-out a bug.


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

Re: [dns-operations] Bind 9.8.0 intermittent problem with non-recursive responses

[Matthew Pounsett]

On 2011-05-20, at 00:35, Carlos Vicente wrote:

 That's news to me.  What's the failure mode? Does the server return SERVFAIL, 
 or does it not set the AD flag, or...?

It's another undefined condition in the RFCs, and so the outcome is 
implementation specific.  I believe in the case of BIND the authoritative 
algorithm wins out, and so you get RRSIGs and no AD flag.  I haven't tested 
this one out personally, but I vaguely recall the problem coming up on one of 
the DNS operations lists several months ago, so someone else may have a more 
detailed answer.



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

IXFR size limit?

[Matthew Pounsett]

Is there, by any chance, a maximum size to the IXFRs BIND will send?  I've 
noticed an upstream server I slave from is being suspiciously consistent in the 
number of records it sends per IXFR (86,450 plus or minus ~10 records).  The 
upstream server is part of an appliance, but fingerprints as BIND 9.2.3rc1 -- 
9.4.0a0.  

I don't see anything in the ARM for configuring a limit on the number of 
records per zone transfer, but I'm curious if there's something hard-coded 
somewhere...


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

Re: IXFR size limit?

[Matthew Pounsett]

On 2011/02/14, at 10:47, Matthew Pounsett wrote:

 Is there, by any chance, a maximum size to the IXFRs BIND will send?  I've 
 noticed an upstream server I slave from is being suspiciously consistent in 
 the number of records it sends per IXFR (86,450 plus or minus ~10 records).  
 The upstream server is part of an appliance, but fingerprints as BIND 
 9.2.3rc1 -- 9.4.0a0.  

Nevermind.. I spoke too soon.  It turns out the appliance in question is not 
actually doing IXFRs.  I should have checked out the zone size in the first 
place.



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

Re: how to read and answer to this mailing list

[Matthew Pounsett]

On 2010/03/31, at 04:08, Markus Feldmann wrote:

 Matthew Pounsett schrieb:
 On 2010/03/30, at 19:04, Markus Feldmann wrote:
 Warren Kumari schrieb:
 In the footer of every message lurks the following link:
 https://lists.isc.org/mailman/listinfo/bind-users
 Yes ... i read this but you can not answer a mail this way.
 You can answer an email this way.  I'm not sure if the list is open-post or 
 not.. but if it is then you can get the posting address from there and send 
 email to it.  If it isn't, then from that page you can subscribe to the 
 list, and then send email to it.
 Thanks Matthew it works, but it is not very comfortable. therefore i need 2 
 programs. first to read and the second to write/answer. The modern computer 
 technique says hello. :-)

I read and post from the same program.  You asked about mail, so I assumed you 
meant mail.

On 2010/03/30, at 18:43, Markus Feldmann wrote:

 normally i am using the gmane mailing list server to post and read mails from 
 mailing lists, but this mailing list doesn't appear in gmane.


Matt



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

Re: MX records for new additional domain on existing authoritative name servers

[Matthew Pounsett]

Hi Karen.

Please don't start a new thread by replying to an email in an existing 
discussion -- your message can get lost in that other discussion, rather than 
appearing as a new topic for anyone who threads their email.


On 2010/03/30, at 16:30, Lear, Karen (Evolver) wrote:

 I'm adding a new domain to my existing authoritative name servers, and need 
 to add an MX record for a device on the existing domain.  That device will 
 serve both domains until we get a new box in and then we will have separate 
 MX records/devices for each domain.  I have created a new zone file and 
 modified named.conf to include the new zone.  When I run named-checkzone, I 
 get a message about the MX record being out of zone and not having an A 
 record.  However, at the end of my named-checkzone output, I get OK.  Can I 
 restart named as is without causing problems or do I need to address these 
 messages?

It sounds like you're including a record for mx1.olddomain.gov in the 
newdomain.gov zone.  It's hard to be sure without seeing specifics from your 
configuration though.



 
 Thx,
 
 [kl...@mynameserver]$ sudo named-checkzone -t /dns/chroot/conf -D 
 NEWDOMAIN.gov MYNEWZONEFILE
 zone NEWDOMAIN.gov/IN: NEWDOMAIN.gov/MX 'MX1.OLDDOMAIN.gov' (out of zone) has 
 no addresses records (A or )
 zone NEWDOMAIN.gov/IN: NEWDOMAIN.gov/MX 'MX2.OLDDOMAIN.gov' (out of zone) has 
 no addresses records (A or )
 OK
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users

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

Re: Using an MX record from a different domain

[Matthew Pounsett]

On 2010/03/30, at 16:57, Lear, Karen (Evolver) wrote:

  
 I'm adding a new domain to my existing authoritative name servers, and need 
 to add an MX record for a device residing on existing domain.  When I run 
 named-checkzone, I get a message about the MX record being out of zone and 
 not having an A record.  However, at the end of my named-checkzone output, I 
 get OK.  Can I restart named as is without causing problems or do I need to 
 address these messages?
  
 [kl...@dns1 conf]$ sudo named-checkzone -t /dns/chroot/conf -D usptoenews.gov 
 db.usptoenews
 zone usptoenews.gov/IN: usptoenews.gov/MX 'smtpedge1.uspto.gov' (out of zone) 
 has no addresses records (A or )
 zone usptoenews.gov/IN: usptoenews.gov/MX 'smtpedge2.uspto.gov' (out of zone) 
 has no addresses records (A or )

Ah, I see.  On my previous read I mistook this for complaining that there was a 
uspto.gov owner name in the usptonews.gov zone.  

named-checkzone doesn't only check the internal consistency of a zone, it also 
tries to see that it is externally consistent.  e.g. that names referred to in 
other zones also exist.  If for some reason it can't resolve 
smtpedge1.uspto.gov and smtpedge2.uspto.gov it will give you the above errors. 

Since I can resolve those names from here, I suspect there's some problem with 
the resolver on the host where you're running named-checkzone.  Perhaps 
uspto.gov zone is only visible on a view on the outside of the network, and 
you're inside?  

What happens if you try to resolve those two names by hand on that server using 
'host' or 'dig'?

I see this:
 host smtpedge1.uspto.gov
smtpedge1.uspto.gov has address 151.207.243.76
smtpedge1.uspto.gov mail is handled by 5 smtpedge1.uspto.gov.

 host smtpedge2.uspto.gov
smtpedge2.uspto.gov has address 151.207.247.81
smtpedge2.uspto.gov mail is handled by 5 smtpedge2.uspto.gov.

If those are the only errors you're seeing, then the zone is internally 
consistent, and BIND will load it.  However, it's probably worth investigating 
why named-checkzone can't resolve those names, so that you can make sure that 
anyone who needs to reach those MX servers will be able to.

Matt


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

Re: Subdomain delegation only returns SOA on dig

[Matthew Pounsett]

On 2010/03/29, at 15:34, Prabhat Rana wrote:

 
 Hello all,
 I'm running BIND 9.6.1-P1 on a Solaris box. This DNS (ns1.spx.net) is 
 authoritative to domain spx.net (this is just example). And I'm trying to 
 delegate nse.spx.net to ns1.nse.spx.net. I think I have configured correctly 
 but when I run a dig from a different DNS node for a subdoamin within 
 nse.spx.net like mil.nse.spx.net, it responds only SOA in the Auth section. 
 Its missing the NS from the zone files. The snapshot of my named.conf file
 
 zone spx.net {
type master;
file /opt/named/db.spx.net;
 };
 
 zone nse.spx.net {
type master;
file /opt/named/db.nse.spx.net;
 };

Do these both appear on the same name server (ns1.spx.net)?  If so, then 
ns1.spx.net thinks it is authoritative for nse.spx.net, and isn't going to hand 
out a referral.

If you want ns1.spx.net to refer queries for nse.spx.net to ns1.nse.spx.net, 
then you need to add this record to the spx.net zone, and remove the 
nse.spx.net zone from ns1.spx.net:
nse IN NS ns1.nse.spx.net

Matt


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

Re: how to read and answer to this mailing list

[Matthew Pounsett]

On 2010/03/30, at 19:04, Markus Feldmann wrote:

 Warren Kumari schrieb:
 In the footer of every message lurks the following link:
 https://lists.isc.org/mailman/listinfo/bind-users
 Yes ... i read this but you can not answer a mail this way.

You can answer an email this way.  I'm not sure if the list is open-post or 
not.. but if it is then you can get the posting address from there and send 
email to it.  If it isn't, then from that page you can subscribe to the list, 
and then send email to it.

 And i mean not this mailing list but the dhcp-users mailing list.

Then you're probably looking for 
https://lists.isc.org/mailman/listinfo/dhcp-users.

Matt


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

Re: Intermittent failures resolving .org domains in BIND 9.7.0 with DLV enabled

[Matthew Pounsett]

On 2010/03/28, at 18:48, Roy Badami wrote:

 configured).  The queries are resulting in SERVFAIL, and I'm pretty
 sure the failures are DNSSEC-related, as when I've seen problems as
 they occur (dig failing from the command line) then repeating the
 query with the CD bit allowed it to succeed.

It looks to me like your example, freebsd.org, is insecure.  

There are no DS records for freebsd.org in the org zone, so BIND can't follow 
the trust chain from the org.dlv.isc.org DLV record.

;  DiG 9.6.0-APPLE-P2  +norec +dnssec IN DS freebsd.org 
@a0.org.afilias-nst.info
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 52863
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
[...]

There also appears to be no DLV record for freebsd.org:

;  DiG 9.6.0-APPLE-P2  +norec +dnssec IN DLV freebsd.org.dlv.isc.org 
@ns.isc.afilias-nst.info
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 23858
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;freebsd.org.dlv.isc.org.   IN  DLV

;; AUTHORITY SECTION:
dlv.isc.org.3600IN  SOA ns-int.isc.org. 
hostmaster.isc.org. 2010032802 7200 3600 2419200 3600
dlv.isc.org.3600IN  RRSIG   SOA 5 3 3600 20100427130003 
20100328130003 64263 dlv.isc.org. 
IbRdfwxFInY6FuHtsfVatqrNvMIoifQTrohzEZF1UsTx9XAowU1Zz57L 
YcHPu3ReAdYOL+IwkG8syNQ/LSLnpZY3K3Av/HSmPV524KWbm39J+k+G 
BMmIIsnvC4I40UUr7f/AXF14JgdAu9eokvvLvqR0CcAY0dq9HGHjdXC1 HbI=
flame.org.dlv.isc.org.  3600IN  NSEC863.freenum.org.dlv.isc.org. 
RRSIG NSEC DLV
flame.org.dlv.isc.org.  3600IN  RRSIG   NSEC 5 5 3600 20100427130003 
20100328130003 64263 dlv.isc.org. 
KZRZadIqTS8p6V3fRz7bsOrP3A/gTqJzeVtWTOqhrRbChLt0jVbhY4fR 
1pBogkhc84xcv7i0odHMzWCIpmQdv4Q/ODnophPdgrfPcxB93s3dMQ/D 
j0o2KTYsx1qJo0O1RWqhicUdwGoVYm5rZFLxy/uBV0dJe0KGrSmY21Gw U/c=
org.dlv.isc.org.3600IN  NSEC1mg.org.dlv.isc.org. RRSIG NSEC 
DLV
org.dlv.isc.org.3600IN  RRSIG   NSEC 5 4 3600 20100427130003 
20100328130003 64263 dlv.isc.org. 
YCe9L3iuJ5YD5hj7s1Z9wGsDkhLhqchNki+bSffHGxoYZVaQnMZXgWpS 
fYJZsFyJA3h1uEs5FvuLeLv1Poej2EhDyXucMHAgTJy4fbDjaw3Q8/MP 
et17Ki0TSNvMFdusCJl93aSZBnKponKR67ofvb8wwt5SDCYrR41EgvzE WZs=

;; Query time: 58 msec
;; SERVER: 199.254.63.254#53(199.254.63.254)
;; WHEN: Mon Mar 29 04:22:48 2010
;; MSG SIZE  rcvd: 721

Note both the NXDOMAIN status and the NSEC record covering 
flame.org.dlv.isc.org through 863.freenum.org.dlv.isc.org.  The NSEC record is 
used to prove that no domains which sort between those two names exist in the 
dlv.isc.org zone.

Just to make sure, I looked for RRSIGs in the freebsd.org zone, wondering if 
maybe the DLV record has simply disappeared from the dlv.isc.org zone somehow.. 
but it doesn't look like freebsd.org has been signed at all:

;  DiG 9.6.0-APPLE-P2  +norec +dnssec IN  mx2.freebsd.org 
@ns2.isc-sns.com
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 17599
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 11

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

;; ANSWER SECTION:
mx2.freebsd.org.3600IN  2001:4f8:fff6::35

Note the absence of an RRSIG in the ANSWER section.  If freebsd.org were 
signed, you'd expect to see an answer similar to this:

;  DiG 9.6.0-APPLE-P2  +norec +dnssec IN  ns1.isc-sns.net 
@ns1.isc-sns.net
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 52801
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;ns1.isc-sns.net.   IN  

;; ANSWER SECTION:
ns1.isc-sns.net.3600IN  2001:470:1a::1
ns1.isc-sns.net.3600IN  RRSIG    5 3 3600 2010042620 
2010032720 10377 isc-sns.net. 
qk8txlEYx6d8Mor155Rz0Te2vdQSPDoaJZM5FaXLfyNpruv7z3gdwtAI 
BrmDCKhzmyYni4GQmqZPYmceVjp1rcD17B5O+2/NET+obm3pcHKuzRZs 
e0PyP1LITahboUZzBoIyd7/jqs2+EwFKJgUs7v41UNp5oIz2vs0YuBo6 1Hc=


Have you checked the other domains you're having problems with to see that 
they're actually secured?
If you supply some info from your resolver configuration, someone here might be 
able to help debug the problem.

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

Re: Notify storms

[Matthew Pounsett]

On 2010/01/20, at 13:03, Dave Sparro wrote:

 We would like to make this better.
 Can anyone help with ideas on this?  Are we missing something obvious?
   
 
 In that situation I'd consider using CVS on all of the servers to maintain 
 the DNS data.
 Just make all of the servers masters, and forget about slaves.

Agreed .. that's definitely one solution.  With your data already in a version 
control system, and that many name servers, you might benefit from replacing 
zone transfers with a configuration management tool (cfengine, bcfg2, etc.) 
which can take care of noticing that there's new data in the version control 
system, getting it onto the slaves, and then telling them to reload or reconfig 
as appropriate (depending on whether it's zone files or named.conf that 
changed).


Another option if you want to stick with the master/slave approach is to tier 
your slaves.   Reduce the masters to just two or three, and then assign 10 or 
so of the slaves to be intermediate masters.  The intermediates slave from the 
real masters, and then every other server slaves from, at most, two or three of 
the intermediates each.  If you group these appropriately, then you can get it 
down to a maximum of 10 or so slaves talking to any one upstream master, with a 
nice mesh to maintain redundancies.  How you divide them up is up to you ... 
regionally works well though.

Matt


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