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
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: Configure error - openSSL. Mac OS X
James Brown jlbr...@bordo.com.au 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.finch d...@dotat.at http://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
Re: IPv6 PTR Records
On Mar 10, 2014, at 8:28 AM, Maechler Philippe pmaechler...@glattnet.ch 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: 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: 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
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: 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
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?
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 forward only and forward first.
Forwarding
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
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: 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 stdio.h
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
On 11 Mar 2014, at 2:15 pm, Mark Andrews ma...@isc.org 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 stdio.h
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
In message cc69566a-e662-4cee-af15-a9629f591...@bordo.com.au, James Brown wri
tes:
On 11 Mar 2014, at 2:15 pm, Mark Andrews ma...@isc.org 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 stdio.h
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 stdio.h
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
Mark Andrews writes:
In message cc69566a-e662-4cee-af15-a9629f591...@bordo.com.au, James Brown w
ri
tes:
On 11 Mar 2014, at 2:15 pm, Mark Andrews ma...@isc.org 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 stdio.h
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 stdio.h
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
On 11 Mar 2014, at 4:09 pm, Mark Andrews ma...@isc.org wrote:
I didn't think I would need to say save the contents of the program to
conftest.c.
cat conftest.c 'EOF'
#include stdio.h
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 stdio.h
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
In message 54602b24-14d9-42b4-ad2e-55adf4805...@bordo.com.au, James Brown wri
tes:
On 11 Mar 2014, at 4:09 pm, Mark Andrews ma...@isc.org wrote:
I didn't think I would need to say save the contents of the program to
conftest.c.
cat conftest.c 'EOF'
#include stdio.h
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 stdio.h
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
