Re: Configure error - openSSL. Mac OS X

2014-03-10 Thread Mark Andrews

In message <54602b24-14d9-42b4-ad2e-55adf4805...@bordo.com.au>, James Brown wri
tes:
> 
> On 11 Mar 2014, at 4:09 pm, Mark Andrews  wrote:
> 
> > 
> > I didn't think I would need to say "save the contents of the program to
> > conftest.c".
> > 
> > cat > conftest.c << 'EOF'
> > #include 
> > int
> > main ()
> > {
> > FILE *f = fopen ("conftest.out", "w");
> > return ferror (f) || fclose (f) != 0;
> > 
> > ;
> > return 0;
> > }
> > EOF
> > gcc -o conftestconftest.c
> > ./conftest
> 
> Getting further now!
> 
> $ cat > conftest.c << 'EOF'
> > #include 
> > int
> > main ()
> > {
> > FILE *f = fopen ("conftest.out", "w");
> > return ferror (f) || fclose (f) != 0;
> > 
> > ;
> > return 0;
> > }
> > EOF
> BordoDNS:bind-9.9.5 jlbrown$ gcc -o conftestconftest.c
> BordoDNS:bind-9.9.5 jlbrown$ ./conftest
> BordoDNS:bind-9.9.5 jlbrown$ 
> 
> James.

Also which version of OpenSSL did you compile?

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


Re: Configure error - openSSL. Mac OS X

2014-03-10 Thread James Brown

On 11 Mar 2014, at 4:09 pm, Mark Andrews  wrote:

> 
> I didn't think I would need to say "save the contents of the program to
> conftest.c".
> 
> cat > conftest.c << 'EOF'
> #include 
> int
> main ()
> {
> FILE *f = fopen ("conftest.out", "w");
> return ferror (f) || fclose (f) != 0;
> 
> ;
> return 0;
> }
> EOF
> gcc -o conftestconftest.c
> ./conftest

Getting further now!

$ cat > conftest.c << 'EOF'
> #include 
> int
> main ()
> {
> FILE *f = fopen ("conftest.out", "w");
> return ferror (f) || fclose (f) != 0;
> 
> ;
> return 0;
> }
> EOF
BordoDNS:bind-9.9.5 jlbrown$ gcc -o conftestconftest.c
BordoDNS:bind-9.9.5 jlbrown$ ./conftest
BordoDNS:bind-9.9.5 jlbrown$ 

James.

___
Please visit https://lists.isc.org/mailman/listinfo/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: Configure error - openSSL. Mac OS X

2014-03-10 Thread Mark Andrews

Mark Andrews writes:
> 
> In message , James Brown w
> ri
> tes:
> >
> > On 11 Mar 2014, at 2:15 pm, Mark Andrews  wrote:
> >
> > >
> > > The first thing is that configure has decided that we are cross
> > > compiling which is because the simple executable did not run.
> > >
> > > configure:3472: checking whether we are cross compiling
> > > configure:3510: result: yes
> > >
> > > I haven't upgraded my machine to Mavericks yet so I can't test this.
> > > The version of clang you are using works with 10.8.5 so the first
> > > thing I would do is make sure you are completely up to date at the
> > > OS level.
> > >
> > > The program that configure is trying to compile and run is:
> > >
> > > #include 
> > > int
> > > main ()
> > > {
> > > FILE *f = fopen ("conftest.out", "w");
> > > return ferror (f) || fclose (f) != 0;
> > >
> > >  ;
> > >  return 0;
> > > }
> > >
> > > So I would do that by hand.
> > >
> > > gcc -o conftestconftest.c
> > > ./conftest
> >
> > gcc can't find contest.c, and neither can I!
> >
> > BordoDNS:bind-9.9.5 me$ gcc -o conftestconftest.c
> > clang: error: no such file or directory: 'conftest.c'
> > clang: error: no input files
> 
> I didn't think I would need to say "save the contents of the program to
> conftest.c".
> 
> cat > conftest.c << 'EOF'
> #include 
> int
> main ()
> {
> FILE *f = fopen ("conftest.out", "w");
> return ferror (f) || fclose (f) != 0;
> 
> ;
>  return 0;
> }
> EOF
> gcc -o conftestconftest.c
> ./conftest

and add "echo $?" at the end to report the exit status.
 
> > James.
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


Re: Configure error - openSSL. Mac OS X

2014-03-10 Thread Mark Andrews

In message , James Brown wri
tes:
>
> On 11 Mar 2014, at 2:15 pm, Mark Andrews  wrote:
>
> >
> > The first thing is that configure has decided that we are cross
> > compiling which is because the simple executable did not run.
> >
> > configure:3472: checking whether we are cross compiling
> > configure:3510: result: yes
> >
> > I haven't upgraded my machine to Mavericks yet so I can't test this.
> > The version of clang you are using works with 10.8.5 so the first
> > thing I would do is make sure you are completely up to date at the
> > OS level.
> >
> > The program that configure is trying to compile and run is:
> >
> > #include 
> > int
> > main ()
> > {
> > FILE *f = fopen ("conftest.out", "w");
> > return ferror (f) || fclose (f) != 0;
> >
> >  ;
> >  return 0;
> > }
> >
> > So I would do that by hand.
> >
> > gcc -o conftestconftest.c
> > ./conftest
>
> gcc can't find contest.c, and neither can I!
>
> BordoDNS:bind-9.9.5 me$ gcc -o conftestconftest.c
> clang: error: no such file or directory: 'conftest.c'
> clang: error: no input files

I didn't think I would need to say "save the contents of the program to
conftest.c".

cat > conftest.c << 'EOF'
#include 
int
main ()
{
FILE *f = fopen ("conftest.out", "w");
return ferror (f) || fclose (f) != 0;

;
 return 0;
}
EOF
gcc -o conftestconftest.c
./conftest



> James.
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


Re: Configure error - openSSL. Mac OS X

2014-03-10 Thread James Brown

On 11 Mar 2014, at 2:15 pm, Mark Andrews  wrote:

> 
> The first thing is that configure has decided that we are cross
> compiling which is because the simple executable did not run.
> 
> configure:3472: checking whether we are cross compiling
> configure:3510: result: yes
> 
> I haven't upgraded my machine to Mavericks yet so I can't test this.
> The version of clang you are using works with 10.8.5 so the first
> thing I would do is make sure you are completely up to date at the
> OS level.
> 
> The program that configure is trying to compile and run is:
> 
> #include 
> int
> main ()
> {
> FILE *f = fopen ("conftest.out", "w");
> return ferror (f) || fclose (f) != 0;
> 
>  ;
>  return 0;
> }
> 
> So I would do that by hand.
> 
> gcc -o conftestconftest.c
> ./conftest

gcc can’t find contest.c, and neither can I!

BordoDNS:bind-9.9.5 me$ gcc -o conftestconftest.c
clang: error: no such file or directory: 'conftest.c'
clang: error: no input files

James.___
Please visit https://lists.isc.org/mailman/listinfo/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: Configure error - openSSL. Mac OS X

2014-03-10 Thread Mark Andrews

The first thing is that configure has decided that we are cross
compiling which is because the simple executable did not run.

configure:3472: checking whether we are cross compiling
configure:3510: result: yes

I haven't upgraded my machine to Mavericks yet so I can't test this.
The version of clang you are using works with 10.8.5 so the first
thing I would do is make sure you are completely up to date at the
OS level.

The program that configure is trying to compile and run is:

#include 
int
main ()
{
FILE *f = fopen ("conftest.out", "w");
 return ferror (f) || fclose (f) != 0;

  ;
  return 0;
}

So I would do that by hand.

gcc -o conftestconftest.c
./conftest

If that fails open a bug report with Apple.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


Re: Configure error - openSSL. Mac OS X

2014-03-10 Thread Mark Andrews

Go back to the orginal configure args and post the errors from config.log.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


Re: Internal clients' queries for "myhostname." get sent to forwarders. Why?

2014-03-10 Thread Dave Warren

On 2014-03-10 15:05, Andreas Ntaflos wrote:

On 2014-03-10 22:23, Kevin Darcy wrote:

Options:


First, thanks a lot for the reply! So it seems what I described is 
indeed the expected behaviour for the type of DNS we operate?


To put it another way, why wouldn't it? How would your local BIND know 
whether or not a query for "myhostname." or "museum." is valid or not? 
One of those has records (although just NS records, no A records)






1) Change nameservice-switch order (e.g. /etc/nsswitch.conf) on your
hosts to prefer another source of name resolution (e.g. /etc/hosts)
which can resolve the shortname. Thus DNS is never used for these 
lookups


This might be a solution but I find that our DNS setup is just complex 
enough that relying on /etc/hosts would probably introduce more 
problems. Then there's managing /etc/hosts on hundreds of machines, 
which we could of course do with Puppet, but I find that highly 
unappealing. Currently we use Puppet to ensure /etc/hosts contains 
just "127.0.0.1 localhost" and nothing else.


Can you configure your environment to also write the machine's own 
hostname into the hosts file? We're generally not talking about storing 
every single host into every single HOSTS file, just having each machine 
know it's own hostname matches 127.0.0.1.


This should happen automatically and transparently in the Windows world 
(without appearing in the HOSTS file explicitly), but not in the *nix world.


Beyond that, in the Windows world, a machine will append the local 
domain's search suffix before doing a bare "hostname" lookup, so these 
queries typically won't leak as long as your local search suffix points 
to a zone that resolves local hosts and gives a valid answer. I suspect 
the same is true in *nix environments, but it's been a while since I 
mucked around, so I don't know what modern *nix does.






2) Simply :-) change your DNS architecture fundamentally, from one which
forwards requests to the Internet by default (aka "the Microsoft way"),
to one with an internal root zone and conditionally forwarding only
those parts of the namespace that your internal clients actually need to
see.


I confess that I didn't think there was any feasible way other than 
what you call "the Microsoft way" to operate this kind of internal 
DNS. I also don't think I've ever consciously heard of the setup you 
describe. Can you point me to some reading material on what this 
entails and how to get there?


In general there isn't much to it, if you don't set up a forwarded then 
BIND will use it's .hints file to locate the root servers, and from 
there, it will resolve whatever it needs to resolve recursively, taking 
over the roll of your upstream forwarder.


I'm sure someone can post a link to proper documentation, if you need it.

Incidentally, in the Windows world, you do the same, just leave the 
forwarders list blank and Microsoft DNS does full recursion. The old DNS 
setup wizards encouraged forwarders since they made a lot more sense in 
the high-latency, well maintained DNS server worlds of yester-year, but 
today, you'll probably do a better job of doing your own recursion if 
only because most ISPs do a terrible job of their own DNS servers.



--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren


___
Please visit https://lists.isc.org/mailman/listinfo/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: Configure error - openSSL. Mac OS X

2014-03-10 Thread James Brown

On 11 Mar 2014, at 3:05 am, Tony Finch  wrote:
> Try
> 
> LDFLAGS="-Wl,-R/usr/local/ssl/lib" ./configure --enable-threads --with-atf 
> --enable-newstats --enable-rrl --with-ecdsa --with-gost 
> --with-openssl=/usr/local/ssl
> 
> Tony.
> -- 
> f.anthony.n.finchhttp://dotat.at/
> Malin: Variable 3 or 4, becoming southerly 5 or 6 in northwest. Moderate or
> rough. Fair. Good.

Thanks Tony.

Unfortunately I get:

LDFLAGS="-Wl,-R/usr/local/ssl/lib" ./configure --enable-threads --with-atf 
--enable-newstats --enable-rrl --with-ecdsa --with-gost 
--with-openssl=/usr/local/ssl
checking build system type... x86_64-apple-darwin13.1.0
checking host system type... x86_64-apple-darwin13.1.0
checking whether make sets $(MAKE)... yes
checking how to print strings... printf
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/Users/jlbrown/Downloads/bind-9.9.5':
configure: error: C compiler cannot create executables
See `config.log' for more details

Looking at config.log I see:

configure:3036: checking for gcc
configure:3052: found /usr/bin/gcc
configure:3063: result: gcc
configure:3292: checking for C compiler version
configure:3301: gcc --version >&5
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1
configure:3312: $? = 0
configure:3301: gcc -v >&5
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.1.0
Thread model: posix
configure:3312: $? = 0
configure:3301: gcc -V >&5
clang: error: argument to '-V' is missing (expected 1 value)
clang: error: no input files
configure:3312: $? = 1
configure:3301: gcc -qversion >&5
clang: error: no input files
configure:3312: $? = 1
configure:3332: checking whether the C compiler works
configure:3354: gcc   -Wl,-R/usr/local/ssl/lib /usr/bin/ conftest.c  >&5
ld: unknown option: -R/usr/local/ssl/lib
clang: error: linker command failed with exit code 1 (use -v to see invocation)
configure:3358: $? = 1
configure:3396: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| /* end confdefs.h.  */


James.___
Please visit https://lists.isc.org/mailman/listinfo/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: Internal clients' queries for "myhostname." get sent to forwarders. Why?

2014-03-10 Thread Kevin Darcy

On 3/10/2014 6:05 PM, Andreas Ntaflos wrote:

On 2014-03-10 22:23, Kevin Darcy wrote:

Options:


First, thanks a lot for the reply! So it seems what I described is 
indeed the expected behaviour for the type of DNS we operate?



1) Change nameservice-switch order (e.g. /etc/nsswitch.conf) on your
hosts to prefer another source of name resolution (e.g. /etc/hosts)
which can resolve the shortname. Thus DNS is never used for these 
lookups


This might be a solution but I find that our DNS setup is just complex 
enough that relying on /etc/hosts would probably introduce more 
problems. Then there's managing /etc/hosts on hundreds of machines, 
which we could of course do with Puppet, but I find that highly 
unappealing. Currently we use Puppet to ensure /etc/hosts contains 
just "127.0.0.1 localhost" and nothing else.
That's pretty hardcore. I think it's more common for /etc/hosts to 
resolve the shortname and at least the primary FQDN of the local host.





2) Simply :-) change your DNS architecture fundamentally, from one which
forwards requests to the Internet by default (aka "the Microsoft way"),
to one with an internal root zone and conditionally forwarding only
those parts of the namespace that your internal clients actually need to
see.


I confess that I didn't think there was any feasible way other than 
what you call "the Microsoft way" to operate this kind of internal 
DNS. I also don't think I've ever consciously heard of the setup you 
describe. Can you point me to some reading material on what this 
entails and how to get there?
Well, there's 2 pieces to this: the authoritative core for the root 
zone, and then the conditional forwarding for the external namespaces 
that need to be made visible.


For setting up and running an internal root on a single primary master 
server, just look at the Internet Standards and/or BIND documentation, 
since an "internal" root zone isn't fundamentally different than "the" 
root zone, or for that matter, much different from any regular zone that 
you define (the major difference being, there is no parent from which to 
delegate it). Once you have the internal root up on its primary master, 
then you should define some slaves (as per the documentation), at least 
some of which should be *published* slaves (as per standards, you need 2 
or more of those). Outside of your authoritative core, you may then 
define other internal nameservers with a "hints" file containing all of 
your internal published slaves for the root zone. Essentially, you're 
re-creating, on a small scale, what is done on the Internet -- an 
authoritative core for root, with "edge" nameservers pointing to that 
core with their "hints" files.


For conditional forwarding, again, look at the BIND documentation 
(pseudo-zones of "type forward"). These need to be defined on *every* 
nameserver where you want the external namespaces to be visible (a 
configuration-management system helps here, to ensure configuration 
consistency; you mentioned you were using Puppet). For a forwarded 
*external* zone, you want "forward only" as the mode, since otherwise 
your internal boxes will try to use your internal root (which will give 
the wrong information) for names in the zone, whenever the forwarders 
are unavailable. Another big gotcha with BIND: if you want to 
conditionally forward a namespace, and you're authoritative for its 
closest-enclosing ancestor zone (potentially that ancestor zone is your 
internal root if there's nothing defined in between), you need to 
*delegate* the zone that you want to conditionally forward. It doesn't 
really matter what you delegate it *to* -- it can be something bogus -- 
but the delegation needs to *exist* in order for BIND to "see" the zone 
cut and forward appropriately.


Last but not least, if you conditionally forward a namespace (e.g. 
example.com) outside, and then you want to carve out an _exception_ to 
that namespace internally (e.g. internal.example.com), that has, itself, 
one or more subzone levels to its hierarchy (e.g. 
foo.bar.internal.example.com), then, on any nameserver that isn't 
authoritative for *all* of those subzones in the hierarchy, you should 
use the BIND-idiomatic "forwarders { };" syntax to "cancel" forwarding 
for the exception namespace, e.g.


zone "example.com" {
type forward;
forward only;
forwarders { 192.0.2.1; 203.0.113.1; };
};

zone "internal.example.com" {
type slave; // or master, or stub...
file "internal.example.com";
forwarders { }; // cancel forwarding for all subzones
};

Failure to do so will cause queries in subzones (e.g. 
foo.bar.internal.example.com) to forward according to the 
closest-enclosing *forwarded* zone (example.com in the above example), 
which will attempt to resolve externally, rather than internally.


(Obligatory: I would have preferred to see this implemented more 
intuitively as a "forward cancel", "forward not" or "forward 
not-for-subzones" mode choice among "forwar

Re: Internal clients' queries for "myhostname." get sent to forwarders. Why?

2014-03-10 Thread Andreas Ntaflos

On 2014-03-10 22:23, Kevin Darcy wrote:

Options:


First, thanks a lot for the reply! So it seems what I described is 
indeed the expected behaviour for the type of DNS we operate?



1) Change nameservice-switch order (e.g. /etc/nsswitch.conf) on your
hosts to prefer another source of name resolution (e.g. /etc/hosts)
which can resolve the shortname. Thus DNS is never used for these lookups


This might be a solution but I find that our DNS setup is just complex 
enough that relying on /etc/hosts would probably introduce more 
problems. Then there's managing /etc/hosts on hundreds of machines, 
which we could of course do with Puppet, but I find that highly 
unappealing. Currently we use Puppet to ensure /etc/hosts contains just 
"127.0.0.1 localhost" and nothing else.



2) Simply :-) change your DNS architecture fundamentally, from one which
forwards requests to the Internet by default (aka "the Microsoft way"),
to one with an internal root zone and conditionally forwarding only
those parts of the namespace that your internal clients actually need to
see.


I confess that I didn't think there was any feasible way other than what 
you call "the Microsoft way" to operate this kind of internal DNS. I 
also don't think I've ever consciously heard of the setup you describe. 
Can you point me to some reading material on what this entails and how 
to get there?


Thanks again!

Andreas



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

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

Re: Internal clients' queries for "myhostname." get sent to forwarders. Why?

2014-03-10 Thread Kevin Darcy

Options:

1) Change nameservice-switch order (e.g. /etc/nsswitch.conf) on your 
hosts to prefer another source of name resolution (e.g. /etc/hosts) 
which can resolve the shortname. Thus DNS is never used for these lookups
2) Simply :-) change your DNS architecture fundamentally, from one which 
forwards requests to the Internet by default (aka "the Microsoft way"), 
to one with an internal root zone and conditionally forwarding only 
those parts of the namespace that your internal clients actually need to 
see.


- Kevin

On 3/10/2014 3:58 PM, Andreas Ntaflos wrote:

Hi list,

I hope I succeeded in articulating the problem we are facing and I
apologize for the length of this post.

Short version:

Using Bind 9 on Ubuntu 12.04 for internal DNS (master for zones
"dc01.example.at.", "7.1.10.in-addr.arpa.", ...) with forwarders (ISP's
nameservers) for everything outside of internal zones.

The Problem: Clients, when running "hostname -f" or "hostname -i",
create queries for "myhostname." which are sent to the forwarders which
respond with NXDomain. This generates load on the forwarders and exposes
our internally used hostnames, both of which seems unnecessary and
possible dangerous.

This doesn't seem like normal or healthy behaviour. What can we do to
stop it?

Long version:

In our internal networks we are running Bind 9 on Ubuntu 12.04
(9.8.1.dfsg.P1-4ubuntu0.8). The nameserver is configured to be master
for the zone "dc01.example.at" (obviously we don't use "example", but
the other domain components are real). It also serves in-addr.arpa zones
for the internal IP addresses (7.1.10.in-addr.arpa., and so on).
Recursion is enabled for internal clients.

The internal nameserver uses our ISP's nameservers as forwarders for
everything outside of the zones for which it is master.

All clients in our internal networks have names like
"auth01.mgmt.dc01.example.at" or "puppet02.dev.dc01.example.at". All
clients' resolvers are configured with one nameserver and multiple
search domains, like this:

# /etc/hosts:
127.0.0.1 localhost

# /etc/resolv.conf:
nameserver 10.1.7.42
search mgmt.dc01.example.at dc01.example.at

Clients are Ubuntu and Debian machines (10.04, 12.04, Lenny, Wheezy).

This all works fine (and has for years now), but recently we became
aware of the fact that whenever a client system runs "hostname -f" or
"hostname -i" it will ask the internal nameserver for hostname plus each
search domain (which is fine), AND for the plain hostname with a
trailing dot (which is not fine). I can see this from the nameserver's
query logs and from tcpdump.

For example, on "auth01.mgmt.dc01.example.at" the nameserver gets asked for:

auth01.mgmt.dc01.example.at.
auth01.dc.example.at.
auth01.

The nameserver replies correctly with the client's FQDN or IP address
for the first query, as well as with NXDomain for the second query (also
correct) but then forwards the third query ("auth01.") to the configured
forwarders (our ISPs nameservers). This naturally returns NXDomain.

I am confused and worried by this behaviour. Since we have quite a few
hosts in our internal networks (all running Puppet agents) the
forwarders get hit with requests for "hostname." like above multiple
times per second. It also exposes to the forwarders the hostnames of our
internal machines, which isn't great.

Is this the expected behaviour? What can we do to stop our internal
nameserver from forwarding queries for "hostname." to our ISPs nameservers?

I have not included any Bind configuration or zone files here, but I can
provide anything needed to facilitate debugging this issue. Please let
me know!

Thanks in advance for any help and pointers, particularly RTFM. I have
had a really hard time googling this :(

Andreas



___
Please visit https://lists.isc.org/mailman/listinfo/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

Internal clients' queries for "myhostname." get sent to forwarders. Why?

2014-03-10 Thread Andreas Ntaflos
Hi list,

I hope I succeeded in articulating the problem we are facing and I
apologize for the length of this post.

Short version:

Using Bind 9 on Ubuntu 12.04 for internal DNS (master for zones
"dc01.example.at.", "7.1.10.in-addr.arpa.", ...) with forwarders (ISP's
nameservers) for everything outside of internal zones.

The Problem: Clients, when running "hostname -f" or "hostname -i",
create queries for "myhostname." which are sent to the forwarders which
respond with NXDomain. This generates load on the forwarders and exposes
our internally used hostnames, both of which seems unnecessary and
possible dangerous.

This doesn't seem like normal or healthy behaviour. What can we do to
stop it?

Long version:

In our internal networks we are running Bind 9 on Ubuntu 12.04
(9.8.1.dfsg.P1-4ubuntu0.8). The nameserver is configured to be master
for the zone "dc01.example.at" (obviously we don't use "example", but
the other domain components are real). It also serves in-addr.arpa zones
for the internal IP addresses (7.1.10.in-addr.arpa., and so on).
Recursion is enabled for internal clients.

The internal nameserver uses our ISP's nameservers as forwarders for
everything outside of the zones for which it is master.

All clients in our internal networks have names like
"auth01.mgmt.dc01.example.at" or "puppet02.dev.dc01.example.at". All
clients' resolvers are configured with one nameserver and multiple
search domains, like this:

# /etc/hosts:
127.0.0.1 localhost

# /etc/resolv.conf:
nameserver 10.1.7.42
search mgmt.dc01.example.at dc01.example.at

Clients are Ubuntu and Debian machines (10.04, 12.04, Lenny, Wheezy).

This all works fine (and has for years now), but recently we became
aware of the fact that whenever a client system runs "hostname -f" or
"hostname -i" it will ask the internal nameserver for hostname plus each
search domain (which is fine), AND for the plain hostname with a
trailing dot (which is not fine). I can see this from the nameserver's
query logs and from tcpdump.

For example, on "auth01.mgmt.dc01.example.at" the nameserver gets asked for:

auth01.mgmt.dc01.example.at.
auth01.dc.example.at.
auth01.

The nameserver replies correctly with the client's FQDN or IP address
for the first query, as well as with NXDomain for the second query (also
correct) but then forwards the third query ("auth01.") to the configured
forwarders (our ISPs nameservers). This naturally returns NXDomain.

I am confused and worried by this behaviour. Since we have quite a few
hosts in our internal networks (all running Puppet agents) the
forwarders get hit with requests for "hostname." like above multiple
times per second. It also exposes to the forwarders the hostnames of our
internal machines, which isn't great.

Is this the expected behaviour? What can we do to stop our internal
nameserver from forwarding queries for "hostname." to our ISPs nameservers?

I have not included any Bind configuration or zone files here, but I can
provide anything needed to facilitate debugging this issue. Please let
me know!

Thanks in advance for any help and pointers, particularly RTFM. I have
had a really hard time googling this :(

Andreas



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

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

Re: changing NSEC3 salt

2014-03-10 Thread Graham Clinch



On Mon, Mar 10, 2014 at 12:38:34PM +, Graham Clinch wrote:

This isn't quite what I see with inline-signing on 9.9.5:

If I switch from NSEC to NSEC3, my zone continues to have an NSEC chain
until the moment it has an NSEC3 chain.

If I replace an existing NSEC3 chain with a new salt, I seem to lose a
load of RRSIGs, and there are no NSEC or NSEC3 records until the
operation completes!!  For example, the are no signatures on the
DNSKEYs, which feels like a disaster.


That's certainly not what's supposed to happen, and it isn't the
behavior I'm seeing.


Thanks Evan - I've mostly been investigating with dig. Note that this is 
all against a test server that is not publicly visible, and our publicly 
visible zone is not (yet) signed.


I said 'the[re] are no signatures on the DNSKEYs, which feels like a 
disaster.', but in this run, the problem stage doesn't even have 
DNSKEYs.  I'm not sure if I saw a different output earlier, or if I'm 
just loosing it more generally...


I asked two queries at each stage:
hinfo: dig +multi +dnssec -t hinfo lancs.ac.uk @signer
any: dig +multi +dnssec -t any lancs.ac.uk @signer

(HINFO is intended to show the nsec/nsec3 existence, whilst ANY is to 
show the dnskey, etc).


I'm directly querying the host doing the inline signing, so there 
shouldn't be any caching issues.


Because the dig output is so voluminous, I've placed the output files on 
a webserver.


Dig on the client is from v9.8, whilst named is '9.9.5-2-Ubuntu'.

Here's a big dump of stages I went through - the problem is seen at 
stage 4, so feel free to skip ahead...


1) zone is signed, with nsec chain *steady state*:

hinfo:
http://www.lancaster.ac.uk/staff/clinch/scratch/bind9_nsec3_regen/1.txt
any:
http://www.lancaster.ac.uk/staff/clinch/scratch/bind9_nsec3_regen/2.txt

2) Begin nsec3 chain generation *in progress*:

$ /usr/sbin/rndc signing -nsec3param 1 0 10 ff11 lancs.ac.uk
$ rndc signing -list
Creating NSEC3 chain 1 0 10 FF11
Done signing with key 21498/RSASHA256
Done signing with key 33442/RSASHA256

hinfo:
http://www.lancaster.ac.uk/staff/clinch/scratch/bind9_nsec3_regen/3.txt
any:
http://www.lancaster.ac.uk/staff/clinch/scratch/bind9_nsec3_regen/4.txt

3) nsec3 chain *steady state*

hinfo:
http://www.lancaster.ac.uk/staff/clinch/scratch/bind9_nsec3_regen/5.txt
any:
http://www.lancaster.ac.uk/staff/clinch/scratch/bind9_nsec3_regen/6.txt

PROBLEM: 4) Another nsec3 chain generation *in progress*:

$ /usr/sbin/rndc signing -nsec3param 1 0 10 ff22 lancs.ac.uk
$ /usr/sbin/rndc signing -list lancs.ac.uk
Removing NSEC3 chain 1 0 10 FF11 / creating NSEC chain
Creating NSEC3 chain 1 0 10 FF22
Done signing with key 21498/RSASHA256
Done signing with key 33442/RSASHA256

hinfo:
http://www.lancaster.ac.uk/staff/clinch/scratch/bind9_nsec3_regen/7.txt
any:
http://www.lancaster.ac.uk/staff/clinch/scratch/bind9_nsec3_regen/8.txt

5) 2nd nsec3 chain *steady state*

hinfo:
http://www.lancaster.ac.uk/staff/clinch/scratch/bind9_nsec3_regen/9.txt
any:
http://www.lancaster.ac.uk/staff/clinch/scratch/bind9_nsec3_regen/10.txt

Graham

--
Graham Clinch
Systems Programmer,
Lancaster University
___
Please visit https://lists.isc.org/mailman/listinfo/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: changing NSEC3 salt

2014-03-10 Thread Tony Finch
Evan Hunt  wrote:
>
> What should happen is:
>
>  - the old NSEC3PARAM is removed

Isn't that a bit early? Can a secondary transfer the zone while there is
no NSEC3PARAM?

>  - a private-type record is created, indicating that a
>new NSEC3 chain is being created
>  - all the new NSEC3 records are added to the zone

>  - the new NSEC3PARAM is created

I would have thought this should be an atomic replacement of the
NSEC3PARAM record.

>  - all the old NSEC3 records are removed from the zone
>  - the private-type record is cleaned up

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Malin: Southerly 4 or 5, increasing 6 at times in northwest. Moderate or
rough. Fair. Good.
___
Please visit https://lists.isc.org/mailman/listinfo/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: changing NSEC3 salt

2014-03-10 Thread Evan Hunt
On Mon, Mar 10, 2014 at 12:38:34PM +, Graham Clinch wrote:
> This isn't quite what I see with inline-signing on 9.9.5:
> 
> If I switch from NSEC to NSEC3, my zone continues to have an NSEC chain 
> until the moment it has an NSEC3 chain.
> 
> If I replace an existing NSEC3 chain with a new salt, I seem to lose a 
> load of RRSIGs, and there are no NSEC or NSEC3 records until the 
> operation completes!!  For example, the are no signatures on the 
> DNSKEYs, which feels like a disaster.

That's certainly not what's supposed to happen, and it isn't the
behavior I'm seeing.

What should happen is:

 - the old NSEC3PARAM is removed
 - a private-type record is created, indicating that a
   new NSEC3 chain is being created
 - all the new NSEC3 records are added to the zone
 - the new NSEC3PARAM is created
 - all the old NSEC3 records are removed from the zone
 - the private-type record is cleaned up

Looking at the journal file with named-journalprint confirms
that's what's happening on my test system.  How are you doing
your tests?

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/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: IPv6 PTR Records

2014-03-10 Thread Jay Ford

On Mon, 10 Mar 2014, Maechler Philippe wrote:

How do you manage your IPv6 Reverse Entries?

Let's assume that we have a /32 IPv6 subnet for our needs and that we only
publish PTR records where they are needed like for mail servers and maybe
DNS and web servers.

Our Network is: 2001:db8::/32
This would give us a Zone named 8.b.d.0.1.0.0.2.ip6.arpa

Our DNS has the ip 2001:db8:193:192::20/64 and the other one has
2001:db8:193:193::20/64

1) Would you create an entry in 8.b.d.0.1.0.0.2.ip6.arpa like:

20.2.9.1.0.3.9.1.0  IN A  dns1.example.org.
20.3.9.1.0.3.9.1.0  IN A  dns2.example.org.


As Chris Buxton pointed out, you lost a few necessary 0s & need "0.2" on the
tail instead of "20".

Provided you get the syntax right, any of those can work.

Choose whatever level of delegation is convenient.  We do most of ours at the 
/64 boundary, but we do some sparse subnets delegated at /56 & such to avoid 
having a bunch of zones with almost nothing in them.



Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-f...@uiowa.edu, phone: 319-335-
___
Please visit https://lists.isc.org/mailman/listinfo/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: IPv6 PTR Records

2014-03-10 Thread Chris Buxton
On Mar 10, 2014, at 8:28 AM, Maechler Philippe  wrote:
> Let´s assume that we have a /32 IPv6 subnet for our needs and that we only 
> publish PTR records where they are needed like for mail servers and maybe DNS 
> and web servers. 
>  
>  
> Our Network is: 2001:db8::/32
> This would give us a Zone named 8.b.d.0.1.0.0.2.ip6.arpa

You could do that, or you could create one reverse zone per /64, or break it at 
any label you like.

> Our DNS has the ip 2001:db8:193:192::20/64 and the other one has 
> 2001:db8:193:193::20/64
>  
> 1) Would you create an entry in 8.b.d.0.1.0.0.2.ip6.arpa like:
>  
> 20.2.9.1.0.3.9.1.0  IN A  dns1.example.org.
> 20.3.9.1.0.3.9.1.0  IN A  dns2.example.org.

The correct answer is:

$ORIGIN 8.b.d.0.1.0.0.2.ip6.arpa.
0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.9.1.0.3.9.1.0 PTR dns1.example.com.
0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.9.1.0.3.9.1.0 PTR dns1.example.com.

Again, you can delegate subzones at any arbitrary label.

> 2) In the near future we will have a lot more entries in the reverse Zone 
> and, so I guess, some parts of it will be delegated to other servers. When 
> would you start delegating parts of Zone 8.b.d.0.1.0.0.2.ip6.arpa into other 
> Zone-Files?
> How far down the tree would you go for de delegation?

Personally, I would create a reverse zone for each /64 subnet.

> 3) Will a recursive resolver have problems if I only have a SOA for 
> 8.b.d.0.1.0.0.2.ip6.arpa and no SOA for the zones below like 
> 1.0.3.9.1.0.8.b.d.0.1.0.0.2.ip6.arpa?

There's a difference between zones and domains. A zone is equal to a domain 
minus any delegated subzones. You are permitted to delegated a subzone several 
labels down the tree from its parent zone. In other words, it's perfectly 
legitimate to have a zone at the /32 level and then child zones at the /64 
level, with no delegated subzones in between (at the /36, /40, /44, etc. 
levels).

> The reason I ask is:
> We had generic A records for our IPv4 space: 
> dynamic.001-002.003-004.catv.example.org IN A 1.2.3.4 and some mailservers 
> complained that there was no zone for 001-002.003-004.catv.example.org. nor 
> 003-0004.catv.example.org. and no entry for catv.example.org. (we only had 
> the example.org Zone with host a host dynamic.001-002.003-004.catv)

That's a different question, for the names of your A records. I don't know why 
a mail server would complain about this, but perhaps others with recent mail 
server admin experience can comment here.

Regards,
Chris Buxton
___
Please visit https://lists.isc.org/mailman/listinfo/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: Configure error - openSSL. Mac OS X

2014-03-10 Thread Tony Finch
James Brown  wrote:

> I have recently upgraded to openSSL 1.0.1f.
>
> When I try to configure bind 9.9.5 I'm getting an error:
>
> checking for OpenSSL library... using OpenSSL from /usr/local/ssl/lib and 
> /usr/local/ssl/include
> checking whether linking with OpenSSL works... no
> configure: error: Could not run test program using OpenSSL from
> /usr/local/ssl/lib and /usr/local/ssl/include.
> Please check the argument to --with-openssl and your
> shared library configuration (e.g., LD_LIBRARY_PATH).

Try

LDFLAGS="-Wl,-R/usr/local/ssl/lib" ./configure --enable-threads --with-atf 
--enable-newstats --enable-rrl --with-ecdsa --with-gost 
--with-openssl=/usr/local/ssl

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Malin: Variable 3 or 4, becoming southerly 5 or 6 in northwest. Moderate or
rough. Fair. Good.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


IPv6 PTR Records

2014-03-10 Thread Maechler Philippe

Hello bind-users
 
How do you manage your IPv6 Reverse Entries?
 
 
Let´s assume that we have a /32 IPv6 subnet for our needs and that we only 
publish PTR records where they are needed like for mail servers and maybe DNS 
and web servers. 
 
 
Our Network is: 2001:db8::/32
This would give us a Zone named 8.b.d.0.1.0.0.2.ip6.arpa
 
Our DNS has the ip 2001:db8:193:192::20/64 and the other one has 
2001:db8:193:193::20/64
 
1) Would you create an entry in 8.b.d.0.1.0.0.2.ip6.arpa like:
 
20.2.9.1.0.3.9.1.0  IN A  dns1.example.org.
20.3.9.1.0.3.9.1.0  IN A  dns2.example.org.
 
Or (also in 8.b.d.0.1.0.0.2.ip6.arpa)
 
$ORIGIN 2.9.1.0.3.9.1.0.8.b.d.0.1.0.0.2.ip6.arpa
dns1    IN    A     dns1.example.org.
 
$ORIGIN 3.9.1.0.3.9.1.0.8.b.d.0.1.0.0.2.ip6.arpa
dns2    IN    A     dns2.example.org.
 
Or... the third aproach is the complex one:
In the Zone 8.b.d.0.1.0.0.2.ip6.arpa
delegate 0.8.b.d.0.1.0.0.2.ip6.arpa to dns1.example.org
 
In the Zone 0.8.b.d.0.1.0.0.2.ip6.arpa
delegate 1.0.8.b.d.0.1.0.0.2.ip6.arpa to dns1.example.org
 
In the Zone 1.0.8.b.d.0.1.0.0.2.ip6.arpa
delegate 9.1.0.8.b.d.0.1.0.0.2.ip6.arpa to dns1.example.org
 
and so on until we reach 20.3.9.1.0.3.9.1.0.8.b.d.0.1.0.0.2.ip6.arpa. There I 
create an entry like
20  IN    A dns1.example.org.
 
 
 
2) In the near future we will have a lot more entries in the reverse Zone and, 
so I guess, some parts of it will be delegated to other servers. When would you 
start delegating parts of Zone 8.b.d.0.1.0.0.2.ip6.arpa into other Zone-Files?
How far down the tree would you go for de delegation?
 
3) Will a recursive resolver have problems if I only have a SOA for 
8.b.d.0.1.0.0.2.ip6.arpa and no SOA for the zones below like 
1.0.3.9.1.0.8.b.d.0.1.0.0.2.ip6.arpa?
 
The reason I ask is:
We had generic A records for our IPv4 space: 
dynamic.001-002.003-004.catv.example.org IN A 1.2.3.4 and some mailservers 
complained that there was no zone for 001-002.003-004.catv.example.org. nor 
003-0004.catv.example.org. and no entry for catv.example.org. (we only had the 
example.org Zone with host a host dynamic.001-002.003-004.catv)
 
 
Tia for your inputs and tips
 
Philippe





___
Please visit https://lists.isc.org/mailman/listinfo/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: changing NSEC3 salt

2014-03-10 Thread Graham Clinch

Hi,

Sorry to hijack this older thread, but..


rndc signing -nsec3param ...

I would expect the old NSEC3 chain and old NSEC3PARAM record to be
removed, once the new chain is in place.

(Similarly, the new NSEC3PARAM record will not appear in the zone until
the new NSEC3 chain has been completely generated).


This isn't quite what I see with inline-signing on 9.9.5:

If I switch from NSEC to NSEC3, my zone continues to have an NSEC chain 
until the moment it has an NSEC3 chain.


If I replace an existing NSEC3 chain with a new salt, I seem to lose a 
load of RRSIGs, and there are no NSEC or NSEC3 records until the 
operation completes!!  For example, the are no signatures on the 
DNSKEYs, which feels like a disaster.


Am I doing something wrong?  I hope so!

Graham

--
Graham Clinch
Systems Programmer,
Lancaster University
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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