Hi,

It seems that nobody has responded to this problem in quite a while. I ran into the same problem. First I thought it has to do with installation problem or missing some library, but I tried reinstalling the DNS Server module and still got the same problem. All of my other features are working OK. Can anyone at least suggest the nature of this problem?

I have read on other thread about some other issues with DNS server so obviously the module is working for some people.

Thanks.

@hoba:

Is it only the DNS-forwarder that is not synced over or other settings as well?

Other settings are synced flawlessly. (the only thing I have to manually sync are the PPTP server/user settings as there is no option to sync that piece of information)

I had another post that seems to have disappeared… odd...

Anyway, found that if we use a non-existent address (as others have mentioned) such as 192.168.1.0 (I'm using 192.168.1.x network) then domain-level blocking works.

So, 0.0.0.0 works for host-level blocking only, even though it used to work for both.

Maybe I should rename myself to wiki?  ;D

I'm afraid not just because the notebook owner said that at home he uses his adsl modem via ethernet adapter; he said that at his or his girlfriend home the network adapter works fine; I would say the same if he didnt said that for me, just because I did a lot of tests, with more than one operational system (I did with linux because I trust in its results, cant say the same about win) and could not work.

@jan:

@hoba:

Time to sniff to find out where the traffic goes.

I replicated the same issue on another machine with a different set of NIC's , is this a bug? Anyways I went back to /24 and to serve the other machines I installed a router.

I reinstalled for the nth time and did some test regarding network addresses, if network address is 10.10.10.x/24 it works but if 10.10.10.x/23, bottom half of the subnet cannot connect to the internet. If network address is 192.168.x.x series whether it's /24 or /23 , all clients can connect to the net. I wonder why, it's just simple routing.

I wouldn't think so unless ipcop supports CARP (which it doesn't afaik).

Turn off tinyDNS – you don't need it's functionality just for local name resolution. In the DNS forwarded select "Register DHCP leases in DNS forwarder" and "Register DHCP static mappings in DNS forwarder," then set your DHCP server to assign your routers IP for a dns server.

My installation was bad, new install fixed this one right up! ;D

If you have set a large enough DHCP range you could set the lease to something like 1-2 to months. Or you could use the Status->DHCP leases and use the '+' button to add static reservations so that they do not expire.

I've been having a similar problem recently that seems to be getting worse. Sometimes DNS resolution for a domain will simply stop working. I have to cycle dnsmasq and it works again. I'm going to try and hardcode the dns servers as nianderson suggested and see if that works.

@nianderson:

I recently installed a pfsense box with the intention of doing dual wan. Unfortunatly I had so many issues I had to back down to single wan for the time being. Even after going down to single wan and ensuring my upstream dns is set correctly I am experiencing many timeouts. All of the sudden all the pcs will start timing out on their requests. Cycling dnsmasq seems to temporarily resolve the issue. Has anyone else experienced these issues? Any idea where I should be looking for a resolution?

Thanks

Ok, thank you very much

:)

nitrus,

Any possiblity of a patch or hack on 1.2 release?

look like it worked after all…i have other bug but its not pfsense and/or dhcp related

thanks a lot

:-pfsense :- for life !!!!!!

:)

Did you clean /var/dhcpd/var/db/dhcpd.leases~  and /var/dhcpd/var/db/dhcpd.leases  as suggested in the linked thread?
The problem should go away then.

Great and thanks again for the quick response.
After some searches, I believe the message is harmless as you've pointed out.

In our case, we set our dhcp lease to a very short period  (600 sec - 10min), so the client machine may be in sleep mode/power save mode and wake up trying to use the previous assigned IP and hence the system rejects it.

The livecd has a dhcp server running at lan by default. This is not a problem. It must have been something welse but I'm glad you got it working somehow.

Set this one up in the lab and banged on it (I was pretty sure I wasn't just doing it wrong).
Here's what I found:
The advskew check only goes wrong when there are type 'other' VIPs on the box.
I have several 'other' VIPs on the WAN, and when I deleted these, the DHCP config on the backup unit correctly set itself to secondary.
This is however, a bad solution for the production system, as the 'other' VIPs are used to failover IPs that are on additional subnets assigned to the customer (that's the subject of another rambling post).

Thanks, commited.

In the future please submit patches through this process http://devwiki.pfsense.org/SubmittingPatches