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

[Matthew Pounsett]

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

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

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

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

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

[Matthew Pounsett]

On 2013-12-05, at 01:37 , Mark Andrews  wrote:

> 
>>> Note, named will for the use of TCP in its UDP response.
> 
>   s/for/force/

Always? Regardless of response size?  Interesting.  What's the rationale for 
doing it that way?

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

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

[Matthew Pounsett]

On 25 April 2016 at 13:44,  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 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 Monday, 25 April 2016,  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 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 27 April 2016 at 03:07, Tony Finch  wrote:

> Matthew Pounsett  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: Adding CNAME for the root domain issue

[Matthew Pounsett]

On 27 April 2016 at 06:56, John Levine  wrote:

> Assuming you mean this (notice the dots):
>
>  Domain.com.  CNAME  x.y.com.
>  www CNAME x.y.com.
>

No, this does not work.  You're forgetting what goes around the example
records:

domain.com. IN SOA ...
domain.com IN CNAME x.y.com.
domain.com IN NS ...
www.domain.com. IN CNAME x.y.com.

This is not only against the standards, but is nonsensical when you
consider the semantic meaning of CNAME "for all data related to domain.com,
please see x.y.com".   That doesn't make sense when there are also other
records present at that owner name.
___
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: 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:40, Stephane Bortzmeyer  wrote:

> On Wed, Apr 27, 2016 at 07:32:48AM -0700,
>  Matthew Pounsett  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: 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: 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: 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: '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: 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: 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: 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: 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: 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: 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: 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: named and use of resolv.conf? - how to "learn" this

[Matthew Pounsett]

On 2 August 2016 at 17:01, Ray Bellis  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 19:50, Evan Hunt  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: 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: 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: 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: Question about dynamic IPv6-PTR-Generation

[Matthew Pounsett]

On 26 August 2016 at 15:41, Matus UHLAR - fantomas 
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: Load balancer for Bind

[Matthew Pounsett]

On 14 September 2016 at 12:17, Job  wrote:

> Hello,
>
> which is the best load balancer for two or more Bind DNS Server, located
> in the same farm?
> I read something about HAProxy but it does not manage udp connection and
> the interesting security proxy/balancer DnsDist does not pass original
> client ip for Bind-DLZ...
>
> Your best option is something that can do the job statelessly.  As Warren
says, anything that keeps state (firewall, load balancer, etc.) becomes a
DoS target... or, at best, becomes the thing that runs out of resources
before your network or your DNS servers do.

Mostly that means using a routing protocol to do LAN-scope Anycast via
ECMP.  ISC has a technote that explains how to do 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

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

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

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

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: bind-dlz and %client% token

[Matthew Pounsett]

On 27-Nov-2008, at 11:50 , Jakub Heichman wrote:


Hello all,

I'm looking to implementing a DNS server based on bind-dlz with mysql
backend that would allow me to give different DNS responses based on
clients' IP addresses.


The closest match to this in BIND currently is views.  If you've got  
fairly broad categories of IP addresses that you might give different  
answers to, and the addresses in each category are fairly fixed, then  
it would be pretty easy to set them up in views to present differing  
answers to each category.


Whether or not this will work depends on things like how many  
categories of source addresses you want, how easy it is to aggregate  
those addresses into CIDR statements (there's a limit on how long the  
match statement can be I think) and how often the categories will  
change.


HTH,
  Matt





PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: setup default DNS server with only one record

[Matthew Pounsett]

On 11-Dec-2008, at 04:08 , Chris Henderson wrote:


I am trying to setup a default DNS server for one of my restricted
network segment so that no matter what people type in their browser,
they will be redirected to a single IP address or the hostname. The
zone file that I have setup is partially working - it resolves
.mydomain.com to a single IP address but doesn't resolve
.some-other-domain.com (eg. www.cnn.com) - it just gives up.
Here is my zone file. Any help would be highly appreciated. Thanks.


Your DNS server needs to be authoritative for all of the zones you  
want to do this with.  In order to do this to *all* host names, your  
name server is going to have to claim to be authoritative for the root.


PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Conflicting glue records?

[Matthew Pounsett]

On 08-Jan-2009, at 03:41 , Dawn Connelly wrote:


Right, but his question was regarding the host record for the name
server. You tell the registrar the name and IP address of the name
servers that are authoritative for the domain. The registrar then
pushes those glue records to the root servers. Root doesn't care what
the name and/or IP address of the name servers are. They are unrelated
across domains. There isn't any cross domain verification. If you say
that the FQDN and IP address of the authoritative name server is
something, the registrar believes you and tells root. Root believes
the registrar. The registrar and root don't do a lookup on the FQDN of
the name server that is provided- hence it being called a glue record.
You have to manually enter that data. At least that has been the case
with ever registrar I've dealt with.


Again, this is quite wrong, on several points.

Host records for his domain don't go into the root unless he's  
managing a TLD.. and if that's the case he's not dealing with a  
registrar.


Whether or not the registrar or the registry do a lookup on the host  
records being supplied is irrelevant to why the entry in the DNS is  
called glue.  In cases where a nameserver is a subdomain of the domain  
it is authoritative for, delegations can't happen without the parent  
zone supplying an IP address... without the address being supplied by  
the parent zone you'd have a catch-22 in the resolution process.   
Supplying that IP address "glues" the two zones together.. hence the  
name.


And finally to the poster's original question..

This is actually more of an issues of registr operations and/or EPP,  
rather than DNS.  According to the EPP spec only the registrar  
sponsoring the domain can register host records within it.  So, to  
borrow from someone else's example, only the domain holder for  
apple.com can register the host records ns1.apple.com and  
ns2.apple.com.  The orange.com registrant can't create a host record  
for ns1.apple.com and register an IP address with it.   The registrar  
*may* accept this data from the registrant anyway, but it shouldn't  
(according to the spec) be passed on to the registry.  I suppose the  
registry could also accept it from the registrar (though in the case  
of .com I doubt this violation is occurring) but it shouldn't be  
published into the DNS.  Only the host records registered by the  
apple.com domain holder should wind up there.


Matt


PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: unwanted delegations was: What to do about openDNS

[Matthew Pounsett]

On 20-Jan-2009, at 21:24 , Danny Thomas wrote:


Scott Haneda wrote:
I brought this up a few months back.  For me, it is getting worse,  
and I am not able to come up with a solution.


I have many clients who reg domains.  They all point to my NS.   
Sometimes, the client lapses hosting with me, and I delete the  
zones.  They usually leave the domain reg'd and my NS's listed.

The system should recognise the rights of nameserver operators.
There should be some process by which unwanted delegations can be  
removed.
Obviously doing this on the basis of an email is not a good idea,  
but perhaps
the nameserver operator can publish their desire in a credible  
fashion:


I think the fix would be to registry operations, not the protocol.

Registries that implement host records (so, at least the gTLDs) could  
accept the word of the registrant of the zone that contains a name  
server (or the word of their registrar on their behalf) that the  
server is no longer authoritative for zone X.  Registries that haven't  
implemented host records could also do it, but it may be more  
complicated to implement, depending on their particular system.





PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: unwanted delegations was: What to do about openDNS

[Matthew Pounsett]

On 21-Jan-2009, at 03:23 , Scott Haneda wrote:


On Jan 20, 2009, at 6:42 PM, Matthew Pounsett wrote:

Registries that implement host records (so, at least the gTLDs)  
could accept the word of the registrant of the zone that contains a  
name server (or the word of their registrar on their behalf) that  
the server is no longer authoritative for zone X.  Registries that  
haven't implemented host records could also do it, but it may be  
more complicated to implement, depending on their particular system.



This is actually an interesting idea to me.

However, the one thing that no one has chimed in on yet, is this  
seems to me to be an openDNS issue.  The current DNS system works  
pretty well.  It actually handles this case rather gracefully, with  
proper caching there is no real danger.  My issue is the relentless  
pounding openDNS does, and for reasons I am not able to even guess.


It does sound like they're doing something at least odd, if not  
completely wrong.  I suspect it's probably related to the way they  
substitute  opcode 3 (nxdomain) with their own answers -- they're  
probably making absolutely certain that the host doesn't exist, or  
something.  What you describe seems excessive, though.





PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: allow-query-cache and resolution time

[Matthew Pounsett]

On 22-Jan-2009, at 16:00 , LENA MATUSOVSKAYA, BLOOMBERG/ 731 LEXIN  
wrote:



Hello,

Thank you for answering my quesiton yesterday.

I have a new question about allow-query-cache and its effect on a  
dns server' response resolution time.


allow-query-cache "specifies which hosts are allowed to get answers  
from the cache". I'm assuming this is refering to the memory cache.
If allow-query-cache is set to "none" in options/views statement  
does it mean that the DNS server's query response time would be less  
efficient/slower than with setting allow-query-cache to "any"?
If the answer is allow-query-cache is leff efficient, is it possible  
to override the setting for some zones and how? allow-query-cache  
cannot be used within zone statements.



I'm going to assume you're talking about a recursive server and not an  
authoritative server.


You generally do not want to restrict caching by zone, but rather by  
query source.  That is, you want the computers in your network to be  
able to do recursion (and get responses from cache) for all zones, but  
you do not want computers outside your network (outside of your  
control) using your recursive server at all, because that makes you a  
vector for denial of service against other people's networks.


Normally, the setting on a recursive server for allow-query-cache will  
match your restrictions on recursion.  That is, the same clients which  
are allowed to send recursive queries are allowed to get answers from  
cache.





PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"

[Matthew Pounsett]

On 25-Jan-2009, at 03:44 , Al Stu wrote:

"When a domain name associated with an MX RR is looked up and the  
associated data field obtained, the data field of that response MUST  
contain a domain name.That domain name, when queried, MUST  
return at least one address record (e.g., A or  RR) that gives  
the IP address of the SMTP server to which the message should be  
directed."


Correct.  And when a that domain name is a CNAME pointing to an A RR  
the query returns not only the alias but also the real name and the  
IP address from the A RR.  Thus meeting the requirements to "return  
at least one address record (e.t., A or  RR)".  But yet ISC  
seems to find it necessary to throw a message that it is "illegal",  
when it clearly is not.


You've added an additional step in your second paragraph that is  
prohibited by the section you quoted in the first.  The section from  
the RFC describes a situation where A is queried for and an MX record  
pointing to B is returned.  When B is queried for, an address record  
MUST be the answer.   The situation you have described is that A is  
queried for resulting in an MX record pointing to B.  When B is  
queried for, a CNAME pointing to C is returned, and that when C is  
queried an address record is returned.  Do you see the difference?


The RFCs are quite clear that CNAMEs are not permitted in the RDATA  
for an MX.





PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"

[Matthew Pounsett]

On 25-Jan-2009, at 12:41 , Al Stu wrote:

"That domain name, when queried, MUST return at least one address  
record (e.g., A or  RR) that gives the IP address of the SMTP  
server to which the message should be directed."


@ 1800 IN A 1.2.3.4
srv1 1800 IN A 1.2.3.4
mx 1800 IN CNAME blah.xyz.com.
@ 1800 IN MX 1 mx.xyz.com.

Requirements met.


In the example above, when I query for "IN A mx.xyz.com?" I do not get  
an address record back (A, )..instead I get a CNAME record.   
Requirements NOT met.


I don't see the connection to srv1.  Did you mean for "mx 1800 IN  
CNAME blah.xyz.com." to be "mx 1800 IN CNAME srv1.xyz.com."?  That  
still doesn't meet requirements, because the record returned there as  
the ANSWER is a CNAME, not an A or  record.  I think you might be  
confusing the ADDITIONAL section of a DNS message with the ANSWER  
section.  They are not the same thing.






PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"

[Matthew Pounsett]

On 25-Jan-2009, at 13:15 , Al Stu wrote:


Yes, blah was supposed to be srv1.

I do receive both the CNAME and A records for the A mx.xyz.com  
query.  See attached capture file.


In the capture file three global search and replacements were  
performed to match the previous example.


1) domain name was replaced with xyz
2) server name was replaced with srv1
3) server ip address was replaced with 1.2.3.4

Requirements are met.


Al, I'm sorry, but you're wrong.  If you look closely at what you just  
typed, you'll see that's three steps.. not the two steps required by  
the MUST in the RFC.


Your attachment didn't make it through the list manager.  I suggest  
you paste in some dig output instead.  If you do, you'll notice that  
the IP address you're receiving is in the ADDITIONAL section of the  
DNS message, which does not qualify as an ANSWER.


I'm going to stop contributing to this thread now.. if you insist on  
ignoring the pointers people have given you to the text in the RFCs,  
and insist on reading your own interpretation into it, we cannot stop  
you.





PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"

[Matthew Pounsett]

On 25-Jan-2009, at 23:06 , Barry Margolin wrote:


In article ,
Matthew Pounsett  wrote:

In the example above, when I query for "IN A mx.xyz.com?" I do not  
get

an address record back (A, )..instead I get a CNAME record.
Requirements NOT met.


Then there's something wrong with your resolver, since they're  
supposed

to follow CNAME records automatically, and return the requested record
type from the canonical name.


You're right, of course.  I was over simplifying my point, which was  
that the answer to the question asked is not an address record.  I  
should probably know better than to do that. :)





PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Forcing a secondary update...

[Matthew Pounsett]

On 26-Jan-2009, at 17:50, Jeff Justice wrote:

Without getting into how I managed to accomplish this, I have wound  
up with a secondary DNS that has incorrect information in it but the  
serial numbers are the same as on the master.


So, my question is:  how can I get the secondary to sync up?  I  
presume all I would need to do is make a single change to the zones  
on the master, thus changing the serial number, and causing the  
secondary to update.


The info in the master is correct, so I really don't need to change  
anything, but I could add something then delete it.  Is there an  
automated way I can do this, or batch method?  There are just enough  
zones as to make this a real hassle if I were to do it one by one.


An update to the serial number is the indicator to the master, and  
then to the slaves, that some change has occurred and the zone should  
be re-loaded or transferred.. but an actual change to the data isn't  
required to make that happen.  You can just update the serial number  
on the master and tell it to reload without altering any other data...  
the rest will take care of itself.


Matt





PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: What are these entries in the log file - " query: . IN NS +"?

[Matthew Pounsett]

On 26-Jan-2009, at 23:03, Tony Toews [MVP] wrote:

Ah, I think I see what is happening here.  Searching at the below  
article for

63.217.28.226
http://tech.slashdot.org/tech/09/01/24/0113210.shtml shows a reply  
stating:


"The problem seems to kick in for DNS servers that arent rejecting  
the queries.

Someone is channeling ye 'ole smurfing methods.

They're requesting a list of all DNS root servers. If the server  
don't reject the
query, a 17 byte query becomes a 50k response (or something like  
that) to the spoofed

address."


that's right.  By configuring the DNS server to respond with REJECT to  
queries for which it isn't authoritative, you make it respond with a  
packet that's exactly the same size as the original query -- negating  
the amplification side of the attack.   Once the attacker realizes  
nobody is amplifying, it makes the method unattractive, since it's  
more costly than other types (such as a simple ping flood).






PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: my DNS not resolving

[Matthew Pounsett]

On 29-Jan-2009, at 13:49, S. Jeff Cold wrote:


BIND List,

I have a server running OpenSuse 11.1 with BIND 9.5.0P2-18.1.   
This server has a dedicated IP address from my ISP.  I want this  
server to resolve my registered domain jatec.us.  The server has  
internet connectivity.  If I dig jatec.us, I get:



[...]

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2074
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0


Your domain doesn't appear to have been registered yet (or, perhaps,  
is registered but is simply not yet in the .us zone):


; <<>> DiG 9.5.0-P1 <<>> jatec.us @K.GTLD.BIZ
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 17247
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;jatec.us.  IN  A

;; AUTHORITY SECTION:
us.			900	IN	SOA	a.gtld.biz. hostmaster.neustar.biz. 2003490289 900  
900 604800 86400


;; Query time: 20 msec
;; SERVER: 156.154.72.65#53(156.154.72.65)
;; WHEN: Thu Jan 29 14:48:05 2009
;; MSG SIZE  rcvd: 91


When did you register the domain?
How often does .us update their zone?

Matt




PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT "Illegal"

[Matthew Pounsett]

On 31-Jan-2009, at 13:18, Al Stu wrote:



And what business of yours would it be if I did?  That is pretty  
much the point here.  What business is it of yours, ISC, or anyone  
else if I chose to run my DNS with MX's pointing to CNAMES?  If it  
is a "bad" practice, fine so be it.  But it has practical and  
beneficial uses.  For ISC to deem it "illegal" is a fallacy and  
inappropriate..


ISC did not deem it illegal.  The IETF working group that designed the  
protocol deemed it illegal.  If you have a problem with it, take it up  
with the DNSEXT working group.


You have been presented with the means to turn off the behaviour.  Use  
that or don't; it's up to you.  Please stop whining about it.


*plonk*

 


PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: A newbies Bind question

[Matthew Pounsett]

On 31-Jan-2009, at 13:24, Peter Privat wrote:


My question:
Is it possible for my friends out there somewhere in cybespace to  
also use my DNS server by entering its IP their DNS settings?


So far I haven't managed to make it work. If another computer  
somewhere out there in the cloud is entering the IP of my private  
DNS server into their internet settings, they are not able to use  
that DNS server. It doesn't provide DNS at all. Seems like it is  
blocked or doesn't allow computers that is not on the same subnet,  
or something. Is there a configuration that I've missed? How do the  
ISP's make their DNS servers usable for everyone?


By default, BIND blocks IP addresses that aren't on a local network  
from using it for recursion.  Setting up an open DNS server which  
permits anyone to use it creates an easy vector for your DNS server to  
be used in Denial of Service attacks, so the default is to be  
completely closed.It is not recommended to open up your DNS server  
to the world.  If your friends have static IP addresses (i.e. the IP  
addresses of their computers aren't ever changed by their ISP) then  
you can allow them in using the 'allow-query' and 'allow-recursion'  
options.


There's HTML documentation for the 'options' grammar at 





PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND still will not resolve

[Matthew Pounsett]

On 02-Feb-2009, at 14:03, S. Jeff Cold wrote:


BIND list,

   Well, I thought I had this DNS problem licked with my ISP  
volunteering as a secondary name server, but I guess not.  My server  
still will not resolve my jatec.us domain.  Maybe I have something  
wrong in named.conf or the zone files?  I can't figure it to be so  
difficult, but it just will not resolve.


Your authoritative DNS servers aren't configured to be authoritative  
for jatec.us.   nx1.xmission.com gives an upward referral to the root,  
and iceman.jatec.us gives a REFUSED response.  Both behaviours  
indicate that the servers don't believe they're authoritative for the  
zone.


Looking at your configuration, I don't see a "zone" statement anywhere  
to load a jatec.us zone file.





PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: single-character host names

[Matthew Pounsett]

On 25-Feb-2009, at 16:46, Mike Bernhardt wrote:

So what is the accepted view on this currently? Is there another RFC  
that

has made it OK now?


I'm not going to say this definitively, because I'm not certain, but I  
think 952 may have been updated by a later RFC.  Certainly there are  
several examples of infrastructure, including the root name servers  
themselves, successfully using single-character host names.





PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: single-character host names

[Matthew Pounsett]

On 25-Feb-2009, at 17:14, Evan Hunt wrote:


Actually, to be lawyerly about it, while RFC952 says you can't have
a single-character name, it also defines names as including periods
to delimit domain-name components.  So, "m.google.com." is really a
13-character name, with a single-character component at the beginning,
not a single-character name.


Serves me right to try to respond off the top of my head without  
checking the reference. :)


You're right, 952 talks about the DOD Host Table, and predates period- 
separated labels forming a FQDN becoming ubiquitous.  Most of what it  
dealt with are single-label names in that host table.


The OP should be looking to RFC1035 section 2.3.1 for the  
specification for modern host names.






PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: TSIG verify failure

[Matthew Pounsett]

On 28-Feb-2009, at 04:11, Jeremie Le Hen wrote:


AXFR fails invariably with the following error: "tsig verify failure".
Do, by chance, TSIG packets use IP address during encryption?
I've been struggling to understand the problem for maybe 8 hours, but
I'm clueless now...  Any help would be welcome.


Check the clocks on your two machines, as they need to be in sync; the  
signatures are time-dependent. 
 


PGP.sig
Description: This is a digitally signed message part
___
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: [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

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


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: named-xfer?

[Matthew Pounsett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 02-Apr-2009, at 18:33, Michelle Konzack wrote:


Hello,

I have to fetch some zones from  but it   
seems,

"named-xfer" does not more exist in bind9.

How can I now manualy download a zone?


dig IN AXFR zone @server > file

that will do it.

HTH,
   Matt



-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.11 (Darwin)

iEYEARECAAYFAknVPjUACgkQmFeRJ0tjIxGScwCglUdG03D0kpBtAuo7i7tJ1PIk
kDUAmgN1qYmoGJWduaN0NcI9qYlj6oAs
=8CUR
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Delegation of DHCP blocks within same server?

[Matthew Pounsett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 20-May-2009, at 19:03, John Cole wrote:


For a concrete example:

10.0.0.0/16 is presently handled by a single zone file.
10.1.3.0/24 is DHCP issued
10.1.4.0/24 is DHCP issued


I haven't tested this... but I'm 99% certain that you can simply load  
them as three separate zones, exactly as you might expect.  BIND  
should recognize that the zone{} statements for 10.1.3/24 and  
10.1.4/24 are more-specific than what's in 10.0/16 and act  
accordingly.  Along those same lines, if you happen to have data for  
either 10.1.3/24 or 10.1.4/24 inside the 10.0/16 zone file, you should  
get an error.



-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.11 (Darwin)

iEYEARECAAYFAkoUmPAACgkQmFeRJ0tjIxGe4gCgkhfqzbwL9BcT4MtXtqQSMQ08
pmEAn2YNy86QLMcpPd8Rl09d965NskJc
=2nvo
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: proving a server doesn't have a zone

[Matthew Pounsett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 01-Jun-2009, at 15:42, Todd Snyder wrote:


I'm sure I'm just having a dumb moment, and that the return codes from
dig can give me what I need, but I can't figure it out.


Indeed, dig can help you here.  Send the server a non-recursive query  
for something in the zone in question (doesn't matter if what you  
query for actually exists or not).  The server will either respond  
with the AA bit set, or not, and that's how you know.


Note the absence of an 'aa' entry in the flags field, on the 6th line  
of the output, below.


% dig +norec @a.gtld-servers.net foo.rim.com

; <<>> DiG 9.4.3-P1 <<>> +norec @a.gtld-servers.net foo.rim.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44151
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;foo.rim.com.   IN  A

;; AUTHORITY SECTION:
rim.com.172800  IN  NS  xns01lhr.rim.net.
rim.com.172800  IN  NS  xns01ykf.rim.net.

;; ADDITIONAL SECTION:
xns01lhr.rim.net.   172800  IN  A   193.109.81.21
xns01ykf.rim.net.   172800  IN  A   206.51.26.10

;; Query time: 80 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Mon Jun  1 15:46:55 2009
;; MSG SIZE  rcvd: 114


In this second example, the server is authoritative for rim.com, and  
answers with the aa bit set:


% dig +norec @xns01lhr.rim.net foo.rim.com

; <<>> DiG 9.4.3-P1 <<>> +norec @xns01lhr.rim.net foo.rim.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51004
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;foo.rim.com.   IN  A

;; AUTHORITY SECTION:
rim.com.		600	IN	SOA	xns01ykf.rim.net. dnsadmin.rim.net. 2009052301  
7200 3600 1209600 600


;; Query time: 138 msec
;; SERVER: 193.109.81.21#53(193.109.81.21)
;; WHEN: Mon Jun  1 15:48:17 2009
;; MSG SIZE  rcvd: 90



-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.11 (Darwin)

iEYEARECAAYFAkokMKkACgkQmFeRJ0tjIxEf3gCfVHPc6VKX7xScMYeQXlsXI5Hu
3T4An3H6++LcSn0wW1D2hr4P25i3RO5H
=sI+e
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Dynamic DNS and Slave Servers

[Matthew Pounsett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 18-Jun-2009, at 14:25, Gregory Hicks wrote:



Kevin:

I'll bite!  What is the difference between a sub*domain* and a
sub*zone*?

I don't see how you could have the one w/o the other.  But that could
be because I'm feeling especially slow today.


foo.example.com is a subdomain of example.com.  It is only a subzone  
if there's a delegation from example.com to foo.example.com (if  
there's a zone cut).




-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.11 (Darwin)

iEYEARECAAYFAko6hykACgkQmFeRJ0tjIxFOKACfREn+EkxLDUByLlpUdu2e1PL9
t74AnREgfx5+eGz1eh1Dl1XWa/HDQPy+
=VSPv
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Glue record miunderstanding

[Matthew Pounsett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 01-Oct-2009, at 16:03, Scott Haneda wrote:

Is it also correct, I only need a NS glue record for the actual NS  
itself.  There does not need to be a glue record for very zone that  
I am providing DNS for?


The only case where glue *must* be present is when a nameserver name  
is a subdomain of the zone it's authoritative for.


So,  if ns1.example.com is one of the nameservers for example.com,  
then there must be glue in the com zone.  In all other cases it is not  
required.  However, some registries may include glue even when its not  
necessary, since it simplifies the logic of generating their zone.


To check if glue is present, ask your parent's nameservers for some  
record inside your zone.  When you get back the delegation response,  
if glue is present it'll be included in the ADDITIONAL section.


Here's a real-world example.  In this case, glue is unnecessary in the  
com zone, but Verisign is including it anyway:


18:24:04 % dig +norec IN A www.example.com @a.gtld-servers.net

; <<>> DiG 9.4.3-P3 <<>> +norec IN A www.example.com @a.gtld-servers.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55065
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;www.example.com.   IN  A

;; AUTHORITY SECTION:
example.com.172800  IN  NS  a.iana-servers.net.
example.com.172800  IN  NS  b.iana-servers.net.

;; ADDITIONAL SECTION:
a.iana-servers.net. 172800  IN  A   192.0.34.43
b.iana-servers.net. 172800  IN  A   193.0.0.236

;; Query time: 65 msec
;; SERVER:
;; WHEN: Thu Oct  1 18:24:13 2009
;; MSG SIZE  rcvd: 113

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.11 (Darwin)

iEYEARECAAYFAkrFLHkACgkQmFeRJ0tjIxF8qwCeILXgTweMvfy5/44oA3PTV//G
z5YAoJBBRer7pj1RE9xfUdGG2GugFUfM
=crTH
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Glue record miunderstanding

[Matthew Pounsett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 01-Oct-2009, at 19:03, Scott Haneda wrote:

So I see my NS is listed in the additional section.  This to me  
tells me there is in fact glue, so I should consider the report at http://intodns.com/hostwizard.com 
 to be inaccurate?


Yeah, I just ran a few queries and can't figure out what exactly it's  
complaining about.


Matt



-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.11 (Darwin)

iEYEARECAAYFAkrFTN4ACgkQmFeRJ0tjIxHkYwCfdIo1dfhDzGov84ouWPviqWrk
5IIAnAy44CUqm7gfX43PQ88KOdUQv47K
=XnOk
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Nslookup not showng TTL

[Matthew Pounsett]

On 15-Oct-2009, at 16:03, John Horne wrote:


On Thu, 2009-10-15 at 13:15 -0400, Kevin Darcy wrote:


Removing features from nslookup gets us that much closer to KILLING  
and

BURYING it. Forever.


So why does the ISC still distribute it?
(Although I guess the answer may simply be "because people still use
it".)


There was a while there that nslookup printed a big warning banner  
telling you not to use it because it'd been deprecated and would go  
away any day now.   That doesn't seem to be there anymore, sadly.   I  
kinda wish it would just vanish.




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

Re: isc.org has signed delegation

[Matthew Pounsett]

On 22-Oct-2009, at 01:16, Loren M. Lang wrote:


I just noticed that isc.org has a signed delegation from the .org name
servers.  I am curious what registrar you went through to get this.


.org is doing a limited production release of DNSSEC right now,  
referred to as "Friends & Family."   There are a small number of  
secured delegations which were arranged directly between the registry  
and the registrants involved; ISC is one of those registrants.  A full  
production rollout, where you can supply DS records to your registrar,  
will be coming later.


Matt



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

Re: BIND9 slave

[Matthew Pounsett]

On 07-Dec-2009, at 08:37, George wrote:


Is there a way to make the slave server automatically get and update
any new domains that are added to the master server?


This question pops up about once every two months on the list.  There  
are several other discussions on the subject that you could search for  
and read.


In short, though:  There's nothing in the protocol for doing that, and  
BIND does not currently have a proprietary way of doing this.


Previous discussions on the list have covered a number of different  
ways of implementing this yourself.  Most are pretty simple  
descriptions of perl scripts that modify your master sever's  
named.conf to work on the slave so that it can be automatically scp'd  
over when it's updated.  My personal favourite is Paul Vixie's  
'federated domains' example, described here:





If you search the list you'll find many, many others.

Matt




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

Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?

[Matthew Pounsett]

On 2010/01/11, at 12:57, Rick Dicaire wrote:

> If I understand this correctly, the lack of an ANSWER section for 
> query would denote there is no ipv6 glue at the TLD?

No, that would indicate that the name server you queried is not authoritative 
for the record you queried about.  Glue, by definition, is non-authoritative 
data, and so appears in the ADDITIONAL section, as in the example you pasted.

By contrast, Verisign's servers have long included glue in the ANSWER section.  
This is widely considered to be at best suboptimal, and by many (or most) to be 
a bug.  Verisign has indicated that this behaviour is coming to an end, 
although I don't recall off the top of my head if they've announced a date.

Matt


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

Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?

[Matthew Pounsett]

On 2010/01/11, at 12:29, Mathew J. Newton wrote:

> Specifically, the Dig tool at http://www.kloth.net/services/dig.php seems
> unable to resolve my records and I can't help but feel it's a problem at
> my end rather than theirs!

The problem may be at Kloth.. but at least one of the many possible problems 
they might be having could be corrected by a slightly different configuration 
at your end.

According to RFC you must have at least two name servers on different networks 
for each delegation.  I interpret this as two name servers *per address 
protocol* that you want to support.  So, if you want to support queries from 
the v4 Internet (there may be reasons you don't) then you should have at least 
two name servers responding to queries over v4.

Koth may be having network trouble on v4 which prevents them from getting at 
77.103.161.0/24.  If that is the problem, a second v4 name server in a 
different subnet (at a different site) might present them with a path to a name 
server that can answer their query.  This is the reason why there is a 
redundancy requirement in the RFC.


That said.. there is nothing wrong with a name server that only answers using 
one address protocol or the other.  And there is functional precedent in 
infrastructure for name servers that are only on v6.  j.gtld.biz, which is 
authoritative for the us. zone only has a v6 address.  While this occasionally 
confuses an operator here and there, the DNS likes it just fine.

Matt


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

Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?

[Matthew Pounsett]

On 2010/01/11, at 14:48, Mathew J. Newton wrote:

>> FWIW, at least one of the afilias hosts had the same IPv4 address for
>> ns[12].v6ns.org.
> 
>>> ns1.v6ns.org.   86400   IN  A   77.103.161.36
>>> ns1.v6ns.org.   86400   IN  2a01:348:133::a1
>>> ns2.v6ns.org.   86400   IN  A   77.103.161.36
>>> ns2.v6ns.org.   86400   IN  2a01:348:6:a1::2
> 
> Hmm.. That's interesting. I know for a fact that my registrar wouldn't
> allow me to enter two servers with the same address, however within my
> zone I may have had ns[12] set with IPv4 records set for a period (a few
> days ago). This makes me wonder where .org is getting its records from - a
> combination of glue provided by the registrar and cached results from my
> zone?

The org. name servers are authoritative-only.. no caching takes place.

Also, the registry is contractually prevented from modifying zone data supplied 
by the registrars, which would preclude it from cloning the v4 address from one 
name server to the other.  Besides, as database objects, the relationship 
between one name server and the other would be pretty loose, and there'd be no 
reasonable way to assume that ns2.v6ns.org is authoritative for everything that 
ns1.v6ns.org is authoritative for.

I suspect that, even though they threw an error, your registrar went ahead and 
passed on the same IPv4 address for both name servers to the registry.

Matt



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

Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?

[Matthew Pounsett]

On 2010/01/11, at 15:16, Matthew Pounsett wrote:

> By contrast, Verisign's servers have long included glue in the ANSWER 
> section.  This is widely considered to be at best suboptimal, and by many (or 
> most) to be a bug.  Verisign has indicated that this behaviour is coming to 
> an end, although I don't recall off the top of my head if they've announced a 
> date.

Following up my own email.. someone pointed me to the specific reference to the 
vague memory I had floating around in my head:

<https://lists.dns-oarc.net/pipermail/dns-operations/2010-January/004838.html>

To summarize, the behaviour I mentioned above is scheduled to go away on March 
1st, 2010.. at which point the com/net servers should start answering with glue 
in the ADDITIONAL section.

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

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: Intermittent failures resolving .org domains in BIND 9.7.0 with DLV enabled

[Matthew Pounsett]

On 2010/03/29, at 06:04, Roy Badami wrote:

> 
>> It looks to me like your example, freebsd.org, is insecure.  
> 
> Yes, I agree freebsd.org is insecure, but I still want to be able to
> resolve it :-)

The point was, you should not be getting DNSSEC-related errors from a domain 
that is not secured.  As requested, please supply configuration information... 
without that, it's unlikely anyone is going to be able to help you.

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 
.

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/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: Load Balancer for DNS

[Matthew Pounsett]

On 2010/04/05, at 02:06, sasa sasa wrote:

> Hello everyone,
> 
> Any one used any load balancer for DNSs? any recommendation? it's 2 
> caching-only DNSs, and I'd like to make a load balance between them using 
> software.

Unless you're willing to spend a lot of money, load balancers are generally not 
the best way to go.  They tend to be specced out for "average" internet 
traffic, which has a much lower packets/megabit ratio than DNS traffic does.  
You're much better off using routing protocols to balance traffic between DNS 
servers.

Have a look at this[1] how-to .. it'll point you to a technote by ISC about how 
to do OSPF anycast within a LAN, as well as explain a slightly simpler (but 
Cisco-only) solution.

Cheers,
  Matt

[1] 


___
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: dig +trace = Bad Referral orBad Horizontal referral

[Matthew Pounsett]

On 20 September 2016 at 12:50, project722  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 
> wrote:
>
>>
>>
>> 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: 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: Multiple IPs Associated With A Single Name

[Matthew Pounsett]

On 29 September 2016 at 14:18, Tim Daneliuk  wrote:

>
> What I am stuck on is this:  Is there any simple (i.e., non-root) way
> to write a client or otherwise configure userspace to go to the
> non-standard
> port and run my sort of man-in-the-middle server?  Or is this just a stupid
> idea?
>
>
There's no way to specify a port number in a delegation, so if this is an
authoritative DNS server that you expect random clients on the Internet to
contact, it must run on port 53... so you'll need root access to start it
up.  I'm not aware of stub resolvers that accept port numbers in their
configuration either  (e.g. glibc and resolv.conf) ... although I'll admit
I haven't gone to double check that... but I think you're out of luck for a
recursive server as well.

Configuration for forwarders and stub zones can include a port number,
however.  So in theory you could have a server somewhere that answers on
port 53 forwarding queries to your server that answers on an unprivileged
port.

That seems like a lot of complexity to go to in order to avoid running a
name server as root, though.  You'd probably be better off convincing your
systems people to set up sudo in such a way that you can administer a DNS
server running on a privileged port, and nothing else.
___
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: 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: 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