Re: Configure error - openSSL. Mac OS X
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
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
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
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
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
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
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?
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
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?
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?
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?
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?
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
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
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
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
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
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
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
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
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