can ping web server but cannot connect with a web browser

I have set up a new FreeBSD DNS server as the DNS server for my private network. This new DNS server has an IP of 192.168.2.2. My web server has the IP address 192.168.2.4. From a computer on the network with the IP address 192.168.2.23 I cannot connect to my web server with a browser any more.

Everything was working with my old DNS server but something with the setting on the new BIND9 server must be wrong and I cannot figure out what. I can ping my web server from the computer with the IP address 192.168.2.23.

Code:
PING 192.168.2.4 (192.168.2.4): 56 data bytes
64 bytes from 192.168.2.4: icmp_seq=0 ttl=64 time=1.477 ms
64 bytes from 192.168.2.4: icmp_seq=1 ttl=64 time=1.679 ms
64 bytes from 192.168.2.4: icmp_seq=2 ttl=64 time=1.512 ms
64 bytes from 192.168.2.4: icmp_seq=3 ttl=64 time=1.063 ms
^C
--- 192.168.2.4 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss

If I use dig [url=http://www.collins.net]www.collins.net[/url] all the correct information for the web server are correct. below are the dig results.

Code:
; <<>> DiG 9.8.3-P1 <<>> www.collins.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56870
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;www.collins.net.		IN	A

;; ANSWER SECTION:
www.collins.net.	3600	IN	A	192.168.2.4

;; AUTHORITY SECTION:
collins.net.		3600	IN	NS	ns2.collins.net.
collins.net.		3600	IN	NS	ns3.collins.net.

;; ADDITIONAL SECTION:
ns2.collins.net.	3600	IN	A	192.168.2.2
ns3.collins.net.	3600	IN	A	192.168.2.3

;; Query time: 5 msec
;; SERVER: 192.168.2.2#53(192.168.2.2)
;; WHEN: Sat Oct 13 20:12:20 2012
;; MSG SIZE  rcvd: 117

All looks fine. When I open a web browser I get a message that it cannot open the page http://www.collins.net because it can't connect to the server www.collins.net. If I type the IP addess of the web server I can connect to the web server. It has to be a problem with how I have BIND9 configured.

Can someone please help me figure out what could be wrong with how I have BIND configured?
 
This might sound silly, but maybe the https isn't running?

Try code:
$ telnet 192.168.2.4 http

Try running that from your client end, and from the web server itself.
 
1) On your server, check your DNS logs.
2) On your client, when you run
$ host [url=http://www.collins.net]www.collins.net[/url]
what do you get as a reply?
3) Is 192.168.2.23 the only LAN IP from which you are unable to connect to your server? If so, check its /etc/resolv.conf and its /etc/hosts files.
 
Where are the dns logs?
Code:
$ host www.collins.net
 www.collins.net has address 192.168.2.4
All machines are unable to connect.

resolv.conf
Code:
#
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.
#
nameserver 192.168.2.2
nameserver 8.8.8.8
hosts
Code:
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1	localhost
255.255.255.255	broadcasthost
::1             localhost 
fe80::1%lo0	localhost
# 74.208.10.249	gs.apple.com
 
jaxxed said:
This might sound silly, but maybe the https isn't running?

Try code:
$/>telnet 192.168.2.4 http

Try running that from your client end, and from the web server itself.
Code:
$ telnet 192.168.2.4 http
Trying 192.168.2.4...
Connected to 192.168.2.4.
Escape character is '^]'.
 
gizmowiz said:
Where are the dns logs?

Depends on your settings. I think it defaults to /var/log/messages. If not, just:
# grep named /var/log/*

and see where your logs are. Once found, run:

# tail -f /var/log/pathtologfile

and restart named(8) to see what it says.

To be honest, I think that jaxxed is right. Are you sure you can access http or https on your server? Try running telnet against your server for both ports 80 and 443 (follow jaxxed's syntax). If it prompts:

Code:
Trying 192.168.2.4...
Connected to www.collins.net.
Escape character is '^]'.

then everything works fine (which shouldn't, since you're saying you can't connect to it). Otherwise, I am afraid that you may have a problem with your http server settings.
 
here is the resultsfrom the log on the restart.
Code:
Oct 14 12:56:59 ns2 named[803]: stopping command channel on 127.0.0.1#953
Oct 14 12:56:59 ns2 named[803]: exiting
Oct 14 12:57:02 ns2 named[18764]: starting BIND 9.8.1-P1 -c /etc/namedb/named.conf
Oct 14 12:57:02 ns2 named[18764]: built with '--prefix=/usr' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--enable-threads' '--enable-getifaddrs' '--disable-linux-caps' '--with-openssl=/usr' '--with-randomdev=/dev/random' '--without-idn' '--without-libxml2'
Oct 14 12:57:02 ns2 named[18764]: command channel listening on 127.0.0.1#953
Oct 14 12:57:02 ns2 named[18764]: running

I do not think it is the web server. If you try and connect to http://www.collins.net you will get the web page. If I change my dns setting to only have the name server 192.168.2.2 then I can connect to the web server. The problem then is that I cannot get to the internet so if I add 8.8.8.8 back as a name server to the client then I can get to the internet but cannot get to servers on the private network.

I have forwarders in the named.conf here is my named.conf file.
Code:
acl lan {
	127.0.0.0/8;
	192.168.1.0/24;
	192.168.2.0/24;
	};
// $FreeBSD: release/9.0.0/etc/namedb/named.conf 224125 2011-07-17 06:20:47Z dougb $
//
// Refer to the named.conf(5) and named(8) man pages, and the documentation
// in /usr/share/doc/bind9 for more details.
//
// If you are going to set up an authoritative server, make sure you
// understand the hairy details of how DNS works.  Even with
// simple mistakes, you can break connectivity for affected parties,
// or cause huge amounts of useless Internet traffic.

options {
	// All file and path names are relative to the chroot directory,
	// if any, and should be fully qualified.
	directory	"/etc/namedb/working";
	pid-file	"/var/run/named/pid";
	dump-file	"/var/dump/named_dump.db";
	statistics-file	"/var/stats/named.stats";

// If named is being used only as a local resolver, this is a safe default.
// For named to be accessible to the network, comment this option, specify
// the proper IP address, or delete this option.
	listen-on	{127.0.0.1; 192.168/16; };

// If you have IPv6 enabled on this system, uncomment this option for
// use as a local resolver.  To give access to the network, specify
// an IPv6 address, or the keyword "any".
//	listen-on-v6	{ ::1; };

// These zones are already covered by the empty zones listed below.
// If you remove the related empty zones below, comment these lines out.
	disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
	disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
	disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";

// If you've got a DNS server around at your upstream provider, enter
// its IP address here, and enable the line below.  This will make you
// benefit from its cache, thus reduce overall DNS traffic in the Internet.

	forwarders {
		208.84.76.10;
		208.84.76.11;
		8.8.8.8;
		};


// If the 'forwarders' clause is not empty the default is to 'forward first'
// which will fall back to sending a query from your local server if the name
// servers in 'forwarders' do not have the answer.  Alternatively you can
// force your name server to never initiate queries of its own by enabling the
// following line:
//	forward only;

// If you wish to have forwarding configured automatically based on
// the entries in /etc/resolv.conf, uncomment the following line and
// set named_auto_forward=yes in /etc/rc.conf.  You can also enable
// named_auto_forward_only (the effect of which is described above).
//	include "/etc/namedb/auto_forward.conf";

	/*
	   Modern versions of BIND use a random UDP port for each outgoing
	   query by default in order to dramatically reduce the possibility
	   of cache poisoning.  All users are strongly encouraged to utilize
	   this feature, and to configure their firewalls to accommodate it.

	   AS A LAST RESORT in order to get around a restrictive firewall
	   policy you can try enabling the option below.  Use of this option
	   will significantly reduce your ability to withstand cache poisoning
	   attacks, and should be avoided if at all possible.

	   Replace NNNNN in the example with a number between 49160 and 65530.
	*/
	// query-source address * port NNNNN;
	recursion yes;
	allow-recursion {any;};
	allow-query {
		any;
		};
	notify yes;
};

// If you enable a local name server, don't forget to enter 127.0.0.1
// first in your /etc/resolv.conf so this server will be queried.
// Also, make sure to enable it in /etc/rc.conf.

// The traditional root hints mechanism. Use this, OR the slave zones below.
zone "." { type hint; file "/etc/namedb/named.root"; };

/*	Slaving the following zones from the root name servers has some
	significant advantages:
	1. Faster local resolution for your users
	2. No spurious traffic will be sent from your network to the roots
	3. Greater resilience to any potential root server failure/DDoS

	On the other hand, this method requires more monitoring than the
	hints file to be sure that an unexpected failure mode has not
	incapacitated your server.  Name servers that are serving a lot
	of clients will benefit more from this approach than individual
	hosts.  Use with caution.

	To use this mechanism, uncomment the entries below, and comment
	the hint zone above.

	As documented at http://dns.icann.org/services/axfr/ these zones:
	"." (the root), ARPA, IN-ADDR.ARPA, IP6.ARPA, and ROOT-SERVERS.NET
	are availble for AXFR from these servers on IPv4 and IPv6:
	xfr.lax.dns.icann.org, xfr.cjr.dns.icann.org
*/
/*
zone "." IN {
        type hint;
        file "/etc/namedb/named.root";
};
zone "." {
	type slave;
	file "/etc/namedb/slave/root.slave";
	masters {
		192.5.5.241;	// F.ROOT-SERVERS.NET.
	};
	notify no;
};
zone "arpa" {
	type slave;
	file "/etc/namedb/slave/arpa.slave";
	masters {
		192.5.5.241;	// F.ROOT-SERVERS.NET.
	};
	notify no;
};
*/

/*	Serving the following zones locally will prevent any queries
	for these zones leaving your network and going to the root
	name servers.  This has two significant advantages:
	1. Faster local resolution for your users
	2. No spurious traffic will be sent from your network to the roots
*/
// RFCs 1912, 5735 and 6303 (and BCP 32 for localhost)
	

// RFC 1912-style zone for IPv6 localhost address (RFC 6303)

// "This" Network (RFCs 1912, 5735 and 6303)

// Private Use Networks (RFCs 1918, 5735 and 6303)

// Link-local/APIPA (RFCs 3927, 5735 and 6303)

// IETF protocol assignments (RFCs 5735 and 5736)

// TEST-NET-[1-3] for Documentation (RFCs 5735, 5737 and 6303)

// IPv6 Example Range for Documentation (RFCs 3849 and 6303)

// Domain Names for Documentation and Testing (BCP 32)

// Router Benchmark Testing (RFCs 2544 and 5735)

// IANA Reserved - Old Class E Space (RFC 5735)

// IPv6 Unassigned Addresses (RFC 4291)

// IPv6 ULA (RFCs 4193 and 6303)

// IPv6 Link Local (RFCs 4291 and 6303)

// IPv6 Deprecated Site-Local Addresses (RFCs 3879 and 6303)

// IP6.INT is Deprecated (RFC 4159)

// NB: Do not use the IP addresses below, they are faked, and only
// serve demonstration/documentation purposes!
//
// Example slave zone config entries.  It can be convenient to become
// a slave at least for the zone your own domain is in.  Ask
// your network administrator for the IP address of the responsible
// master name server.
//
// Do not forget to include the reverse lookup zone!
// This is named after the first bytes of the IP address, in reverse
// order, with ".IN-ADDR.ARPA" appended, or ".IP6.ARPA" for IPv6.
//
// Before starting to set up a master zone, make sure you fully
// understand how DNS and BIND work.  There are sometimes
// non-obvious pitfalls.  Setting up a slave zone is usually simpler.
//
// NB: Don't blindly enable the examples below. :-)  Use actual names
// and addresses instead.

/* An example dynamic zone
key "exampleorgkey" {
	algorithm hmac-md5;
	secret "sf87HJqjkqh8ac87a02lla==";
};
zone "example.org" {
	type master;
	allow-update {
		key "exampleorgkey";
	};
	file "/etc/namedb/dynamic/example.org";
};
*/

/* Example of a slave reverse zone
zone "2.168.192.in-addr.arpa" {
	type slave;
	file "/etc/namedb/slave/2.168.192.in-addr.arpa";
	masters {
		192.168.2.2;
	};
};
*/
key rndc-key {
	algorithm hmac-md5;
	secret "n424zZklq7CBOKe5Z4+h5A==";
	};
controls {
	inet 127.0.0.1 port 953 allow { any; } keys { rndc-key; };
	};
server 192.168.2.3 {
	};
zone "0.0.127.in-addr.arpa" {
	type master;
	file "/etc/namedb/working/127.0.0.in-addr.arpa";
	};
zone "localhost" {
	type master;
	file "/etc/namedb/working/localhost.hosts";
	};
zone "2.168.192.in-addr.arpa" {
	type master;
	file "/etc/namedb/working/192.168.2.in-addr.arpa";
	};
zone "collins.net" {
	type master;
	file "/etc/namedb/working/collins.net.hosts";
	allow-query {
		any;
		};
	also-notify {
		192.168.2.3;
		};
	};
zone "hcscolby.org" {
	type master;
	file "/etc/namedb/working/hcscolby.org.hosts";
	};

here is the resolve. conf and hosts files on the dns server.

resolv.conf
Code:
search collins.net
nameserver 192.168.2.2
nameserver 8.8.8.8

hosts
Code:
::1			localhost localhost.collins.net
127.0.0.1		localhost localhost.collins.net
192.168.2.2		ns2.collins.net
 
I figured it out. I feel pretty stupid I missed it.

I figured it out. I can't believe I missed it. In named.conf all I had to do was uncomment //'s for the forward only line and now everything is working.

Code:
// If you've got a DNS server around at your upstream provider, enter
// its IP address here, and enable the line below.  This will make you
// benefit from its cache, thus reduce overall DNS traffic in the Internet.

	forwarders {
		208.84.76.10;
		208.84.76.11;
		8.8.8.8;
		};


// If the 'forwarders' clause is not empty the default is to 'forward first'
// which will fall back to sending a query from your local server if the name
// servers in 'forwarders' do not have the answer.  Alternatively you can
// force your name server to never initiate queries of its own by enabling the
// following line:
[color="Red"]	forward only;[/color]

mamalos said:
Depends on your settings. I think it defaults to /var/log/messages. If not, just:
# grep named /var/log/*
and see where your logs are. Once found, run:

# tail -f /var/log/pathtologfile

and restart named(8) to see what it says.

To be honest, I think that jaxxed is right. Are you sure you can access http or https on your server? Try running telnet against your server for both ports 80 and 443 (follow jaxxed's syntax). If it prompts:

Code:
Trying 192.168.2.4...
Connected to www.collins.net.
Escape character is '^]'.

then everything works fine (which shouldn't, since you're saying you can't connect to it). Otherwise, I am afraid that you may have a problem with your http server settings.
 
gizmowiz,

gizmowiz said:
key "exampleorgkey" {
algorithm hmac-md5;
secret "sf87HJqjkqh8ac87a02lla==";
};
First of all change your secret now that you've made it public :).
gizmowiz said:
server 192.168.2.3 {
};
Secondly, what is that server empty stanza for 192.168.2.3? Maybe you should remove it.
gizmowiz said:
listen-on {127.0.0.1; 192.168/16; };
Thirdly, your listen-on section seems wrong. You should place your IPv4 address there, not your subnet. So you should have something similar to 192.168.168.2; instead of 192.168/16;.

Lastly, you say that if you remove your secondary dns server (google's 8.8.8.8) then resolving Internet addresses is stopped? This shouldn't be happening, and this implies the reason for your problem. It seems that when you clients ask for resolving your fqdn they first try your server, don't find an answer and then ask 8.8.8.8, which gives your real address as a reply (65.161.79.162), which is not easily accessible from inside your lan, which is a totally different conversation with respect to reflection.

Try to tcpdump(1) your traffic on ports 80 and 53 on your client when you give http://www.collins.net on your web browser and see which address it is trying to access. Moreover, with the right tcpdump options (I think -neti if_name is enough) you'll be able to see which server responds to your DNS query and what their answer was. I assume that the address returned must be your real IPv4 (or even IPv6 maybe, which would be my second candidate of your problem) and not your internal, and probably you'll get that answer from your secondary DNS server.

Fix your configuration to work without and secondary DNS server in your /etc/resolv.conf and once you establish it put the secondaries as before.
 
@DD,

How can I turn off the feature of automatically inserting url tags on a uri? I saw that you corrected my last post for this, but I'm unable to do it by myself.

Thanx.
 
Back
Top