Quickdns 4.6.1

Re: Quickdns 4.6.1

From:

Date:

Time:

Hello list,
having followed this thread this needs to be said:
We upgraded to 4.6.1 as soon as it was available
Installed primary and secondary on 800 Mhz OSX 1.2.8
Macs (type cheap)
and as before kept DNS deactivated in our I Ghz X-Serve
The system has been working fast and with no downtime
regardless of browser used.
Only faults due to our own DNS configuration mistakes.
And - only graphical user interface used, ever.

Congratulations Men and Mice for a superb achievement.

Kaj Hjorth

PS. Please, convert the last bits and pieces into a GUI, too.
Just in case.

On 28.10.2004, at 23:00, QuickDNS Talk wrote:

> Quickdns-Talk Digest #1767 - Fimmtudagur, 28. oktober 2004
>
> Re: Problems resolving (my case is similar)
> by <dns@monsoft.com>
> Re: Problems resolving (my case is similar)
> by "Alan Ordway" <aordway@ihmc.us>
> Re: Rndc and misc
> by "Men & Mice Support" <cbuxton@menandmice.com>
> Re: Possible bug with QDNS admin and logging
> by "Men & Mice Support" <cbuxton@menandmice.com>
> Re: recursion available: denied
> by "Men & Mice Support" <cbuxton@menandmice.com>
>
>
> ----------------------------------------------------------------------
>
> Subject: Re: Problems resolving (my case is similar)
> From: <dns@monsoft.com>
> Date: Thu, 28 Oct 2004 16:31:49 +0200
>
> Hello all,
>
> I also have this problem since upgrading to 4.6.
> I actually have QDNS 3.5.3 running on MacOS 9 and QDNS 4.6 on Xserve
> 10.3.5 on our LAN. Never had this problem with 3.5.3
> Have it with 4.6 in Prefs/TCP/IP and all browsers, not only Safari:
> first hit on a new host fails, second one succeeds
> Have NOT with 3.5.3 or external in Prefs/TCP/IP
>
> My project is to migrate all my machines to MacOS X, DNS server
> included...
>
> Laurent Wallard
>
> Le 28 oct. 04, =E0 15:27, Simon Wright a =E9crit :
>
>> I and my OS X users and some Windows users are having this same
>> problem: first hit on a new host fails, second one succeeds. I'm =
using
>> Firefox so it's not just Safari.
>>
>> I hope that M&M are researching this - it's been happening on and off
>> for me for months/years. It seems to come and go with no discernible
>> pattern. Restarting clients or DNS does not seem to make a =
difference.
>> It feels like a timing issue: clients not being patient enough for =
the
>> response or the response is not completing in some way. Right now =
it's
>> very reproducible: try to go to any web site we've not visited before
>> and the first hit always fails. The second hit almost always =
succeeds.
>>
>> I think I've found a short-term work around: enter your DNS twice in
>> your network preferences.
>>
>> Reply here if it seems to work for you.
>>
>> Simon
>>
>> On Oct 27, 2004, at 10:18 PM, Scott Haneda wrote:
>>
>>> on 10/27/04 5:15 PM, Scott Haneda at lists@newgeo.com wrote:
>>>
>>>> I am having the exact same issue, and it is driving me nuts. I
>>>> don't know
>>>> where to go to troubleshoot this either.
>>>
>>> Well, I have run the gamut of tests on this case and I am getting
>>> pretty
>>> stuck. Installed a demo copy of QDNS on a new machine on my same=20
>>> colo
>>> network and am still having no luck getting lookups to resolve on =
the
>>> first
>>> try in Safari.
>>>
>>> I am about to buy another copy of QDNS just to get the 30 days
>>> support on
>>> this issue, about to take this to the bind mailing list as well,
>>> hopefully
>>> they are nice to me :-)
>>>
>>> So far I have installed QDNS on a new machine, the problem persists,
>>> the
>>> problem also happens inside my colo network viewing over TB2. I
>>> don't seem
>>> to have any problems resolving local domains for which I am serving
>>> DNS on
>>> my colo network. I think I am working locally just fine, I think=20
>>> that
>>> getting out seems to be my problem.
>>>
>>> I only just learned about the +trace option for dig, and I sure hope
>>> this is
>>> promising, here is what I get when I look up a domain while ssh'd
>>> into a
>>> machine on the same subnet as my DNS machine: (several attempts,
>>> comments
>>> interspersed)
>>>
>>> crfg.org is a domain my DNS server has more than likely not seen
>>> before:
>>>
>>> dig crfg.org +trace
>>>
>>> ; <<>> DiG 9.2.2 <<>> crfg.org +trace
>>> ;; global options: printcmd
>>> .. 513866 IN NS D.ROOT-SERVERS.NET.
>>> .. 513866 IN NS E.ROOT-SERVERS.NET.
>>> .. 513866 IN NS F.ROOT-SERVERS.NET.
>>> .. 513866 IN NS G.ROOT-SERVERS.NET.
>>> .. 513866 IN NS H.ROOT-SERVERS.NET.
>>> .. 513866 IN NS I.ROOT-SERVERS.NET.
>>> .. 513866 IN NS J.ROOT-SERVERS.NET.
>>> .. 513866 IN NS K.ROOT-SERVERS.NET.
>>> .. 513866 IN NS L.ROOT-SERVERS.NET.
>>> .. 513866 IN NS M.ROOT-SERVERS.NET.
>>> .. 513866 IN NS A.ROOT-SERVERS.NET.
>>> .. 513866 IN NS B.ROOT-SERVERS.NET.
>>> .. 513866 IN NS C.ROOT-SERVERS.NET.
>>> ;; Received 244 bytes from 64.84.37.40#53(64.84.37.40) in 8 ms
>>>
>>> dig: Couldn't find server 'D.ROOT-SERVERS.NET': No address =
associated
>>> with
>>> nodename
>>>
>>>
>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> So there were 1 errors in that first one, something about the D =
root.
>>> Next try was equally bad:
>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>
>>> dig crfg.org +trace
>>>
>>> ; <<>> DiG 9.2.2 <<>> crfg.org +trace
>>> ;; global options: printcmd
>>> .. 513853 IN NS I.ROOT-SERVERS.NET.
>>> .. 513853 IN NS J.ROOT-SERVERS.NET.
>>> .. 513853 IN NS K.ROOT-SERVERS.NET.
>>> .. 513853 IN NS L.ROOT-SERVERS.NET.
>>> .. 513853 IN NS M.ROOT-SERVERS.NET.
>>> .. 513853 IN NS A.ROOT-SERVERS.NET.
>>> .. 513853 IN NS B.ROOT-SERVERS.NET.
>>> .. 513853 IN NS C.ROOT-SERVERS.NET.
>>> .. 513853 IN NS D.ROOT-SERVERS.NET.
>>> .. 513853 IN NS E.ROOT-SERVERS.NET.
>>> .. 513853 IN NS F.ROOT-SERVERS.NET.
>>> .. 513853 IN NS G.ROOT-SERVERS.NET.
>>> .. 513853 IN NS H.ROOT-SERVERS.NET.
>>> ;; Received 260 bytes from 64.84.37.40#53(64.84.37.40) in 3 ms
>>>
>>> org. 172800 IN NS TLD1.ULTRADNS.NET.
>>> org. 172800 IN NS TLD2.ULTRADNS.NET.
>>> ;; Received 108 bytes from 192.36.148.17#53(I.ROOT-SERVERS.NET) in
>>> 103 ms
>>>
>>> crfg.org. 86400 IN NS ns2.fastdns.net.
>>> crfg.org. 86400 IN NS ns1.fastdns.net.
>>> ;; Received 73 bytes from 204.74.112.1#53(TLD1.ULTRADNS.NET) in 6 ms
>>>
>>> dig: Couldn't find server 'ns2.fastdns.net': No address associated
>>> with
>>> nodename
>>>
>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> Now I find that I can not get to the fastdns.net server in the =
above,
>>> the
>>> below one seems to work:
>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>
>>> dig crfg.org +trace
>>>
>>> ; <<>> DiG 9.2.2 <<>> crfg.org +trace
>>> ;; global options: printcmd
>>> .. 513841 IN NS B.ROOT-SERVERS.NET.
>>> .. 513841 IN NS C.ROOT-SERVERS.NET.
>>> .. 513841 IN NS D.ROOT-SERVERS.NET.
>>> .. 513841 IN NS E.ROOT-SERVERS.NET.
>>> .. 513841 IN NS F.ROOT-SERVERS.NET.
>>> .. 513841 IN NS G.ROOT-SERVERS.NET.
>>> .. 513841 IN NS H.ROOT-SERVERS.NET.
>>> .. 513841 IN NS I.ROOT-SERVERS.NET.
>>> .. 513841 IN NS J.ROOT-SERVERS.NET.
>>> .. 513841 IN NS K.ROOT-SERVERS.NET.
>>> .. 513841 IN NS L.ROOT-SERVERS.NET.
>>> .. 513841 IN NS M.ROOT-SERVERS.NET.
>>> .. 513841 IN NS A.ROOT-SERVERS.NET.
>>> ;; Received 276 bytes from 64.84.37.40#53(64.84.37.40) in 4 ms
>>>
>>> org. 172800 IN NS TLD1.ULTRADNS.NET.
>>> org. 172800 IN NS TLD2.ULTRADNS.NET.
>>> ;; Received 108 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in
>>> 16 ms
>>>
>>> crfg.org. 86400 IN NS ns2.fastdns.net.
>>> crfg.org. 86400 IN NS ns1.fastdns.net.
>>> ;; Received 73 bytes from 204.74.112.1#53(TLD1.ULTRADNS.NET) in 5 ms
>>>
>>> crfg.org. 86400 IN A 66.70.253.166
>>> crfg.org. 86400 IN NS ns2.fastdns.net.
>>> crfg.org. 86400 IN NS ns1.fastdns.net.
>>> ;; Received 121 bytes from 64.33.120.76#53(ns2.fastdns.net) in 83 ms
>>>
>>>
>>> Can someone help me translate what this means and possibly offer =
some
>>> insight as to why it may be happening.
>>>
>>>
>>>
>>>
>>> --=20
>>> -------------------------------------------------------------
>>> Scott Haneda Tel: 415.898.2602
>>> <http://www.newgeo.com> Fax: 313.557.5052
>>> <scott@newgeo.com> Novato, CA U.S.A.
>>>
>>>
>>>
>>>
>>>
>> --
>>> Simon J Wright - Chief Systems Architect
>>>> Knowledge Sharing Systems, Inc.
>>> NCSU Centennial Campus
>>> 940 Main Campus Drive, Suite 150
>>> Raleigh, NC 27606
>> Tel: 919-790-9895x104 <> Fax: 919-850-0851
>>>>> http://www.knowledgesharing.com <<<
>>
>>
>
>
> ----------------------------------------------------------------------
>
> Subject: Re: Problems resolving (my case is similar)
> From: "Alan Ordway" <aordway@ihmc.us>
> Date: Thu, 28 Oct 2004 10:28:41 -0500
>
> I was using etherpeek to capture the network data.
>
> --
> Alan Ordway
>
> On Oct 27, 2004, at 7:15 PM, Scott Haneda wrote:
>
>> I am having the exact same issue, and it is driving me nuts. I don't
>> know
>> where to go to troubleshoot this either.
>>
>> What did you use to get the status output where you were able to see
>> what
>> safari was up to?
>
>
> ----------------------------------------------------------------------
>
> Subject: Re: Rndc and misc
> From: "Men & Mice Support" <cbuxton@menandmice.com>
> Date: Thu, 28 Oct 2004 11:53:43 -0700
>
> At 12:12 AM -0700 10/28/04, Scott Haneda wrote:
>> In trying to deal with troubleshooting my DNS, I see mention to run=20=

>> rndc,
>> which gets me a error when run :rndc status
>> rndc: neither /private/etc/rndc.conf nor /private/etc/rndc.key was=20
>> found
>>
>> Is there something I have to do to make that command work?
>
> Yes. Mac OS X doesn't come with rndc preconfigured, so the QuickDNS
> installer must configure it. However, since QuickDNS Remote doesn't
> use the actual rndc command - it has this functionality built in -
> there's no need to create the configuration files for the rndc
> command. All the configuration is in the named configuration files.
>
> You can correct this so that rndc will work using the following shell=20=

> commands:
>
> sudo -s
> tail -n4 /var/named/conf/user_before > /etc/rndc.key
> exit
>
> The reason you can't put 'sudo' on the front of the 'tail' command
> is, that doesn't cover the redirect into rndc.key. So you must
> actually become root first, and then exit root after.
>
>> I also see mention of many other logging options, like a client.log=20=

>> and well
>> as database dumps, how, with qdns installed, can I get this to behave=20=

>> more
>> inline with what I am reading about bind 9?
>
> You can edit the logging settings, setting up additional channels
> such as a client.log file, in /var/named/conf/logging.
>
> The path of the database dump can be configured in
> /var/named/conf/options, but you don't have to configure it to get a
> dump. Just use 'rndc dumpdb' and it will create a dump of everything
> it has in cache. The default location is /var/named/named_dump.db.
> Despite the extension, this a simple text file.
>
> Chris Buxton
> Men & Mice - Making DNS Easy
> Customer Service and Sales Engineer
>
> ----------------------------------------------------------------------
>
> Subject: Re: Possible bug with QDNS admin and logging
> From: "Men & Mice Support" <cbuxton@menandmice.com>
> Date: Thu, 28 Oct 2004 12:08:43 -0700
>
> At 9:56 PM -0700 10/27/04, Scott Haneda wrote:
>> on 10/27/04 11:47 AM, Men & Mice Support at cbuxton@menandmice.com=20
>> wrote:
>>
>>> This is a behavior of BIND 9. If you specify a max log file size,
>>> then every time you tell it to reconfig (which happens anytime you
>>> change the server options), it starts a new log file. If you have =
it
>>> keeping multiple copies of the log file, you can find the old one =
as
>>> quickdns.log.0.
>>
>> I don't have a logging max size set, is there any way to get this=20
>> behavior
>> to stop?
>
> I don't think you can. It's hard-coded into BIND 9.
>
> Note that if you have the log window open in QuickDNS Manager when it
> does this, you won't see new log entries until you close and re-open
> the window (after which you won't see the old ones anymore).
>
>> Also, whats the best course to get rid of these log lines?
>> Oct 27 21:55:10.966 config: error: /var/named/conf/logging:33: =
unknown
>> logging category 'statistics' ignored
>
> There are a bunch of BIND 8 logging categories listed in your logging
> file, /var/named/conf/logging. You can go in and remove them. (If you
> don't want to figure out which ones, you can simply remove all the
> category lines in the logging file, then open the server's Options
> window in QuickDNS Manager and turn on whatever logging categories
> you want.)
>
> Logging is complicated in BIND. You can have multiple logging
> channels (QuickDNS by default sets up two), and each channel has what
> is basically a completely independent set of categories, severity,
> etc. When an even happens in named, it checks whether any channels
> want to log it, and then logs it or not as indicated. So a given
> event can be logged multiple times, to different channels.
>
> Each log message has a category and a severity. Severity ranges from
> "Debug" and "Info" at the low end to "Error" and "Critical" at the
> high end. "Debug" level is further divided numerically between 0 and
> 100.
>
> QuickDNS lets you manage all of this. In the logging settings in a
> server's options window, the first thing to notice is the channel
> selector, at the top. This allows you to choose which channel you're
> looking at - it isn't a way to choose which channel is actually in
> use by the DNS service, since they're all in use at the same time.
>
> For any given channel, you can choose what categories to log and what
> severity to restrict it to. If you set the severity to "info", then
> every message of "info" or higher severity (including "notice",
> "warning", "error", and "critical") will be logged, assuming its
> category is selected.
>
> Chris Buxton
> Men & Mice - Making DNS Easy
> Customer Service and Sales Engineer
>
> ----------------------------------------------------------------------
>
> Subject: Re: recursion available: denied
> From: "Men & Mice Support" <cbuxton@menandmice.com>
> Date: Thu, 28 Oct 2004 12:13:15 -0700
>
> You've got the logging level set to debug. Debug messages are always
> mysterious - they're not documented, as near as I can tell, anywhere.
> The only way to figure them out is to look at the source code, and
> with BIND 9, that's reportedly no fun even if you're a programmer.
>
> In this case, if I had to guess, I would say that this message simply
> says that your server is not putting the "ra" flag on a reply packet
> sent to the address in question.
>
> Chris Buxton
> Men & Mice - Making DNS Easy
> Customer Service and Sales Engineer
>
> At 10:19 PM -0700 10/27/04, Scott Haneda wrote:
>> I set me querry restrictions to only allow a few select known hosts,=20=

>> in my
>> logs I see a lot of stuff like this:
>> Oct 27 22:17:36.481 security: debug 1: client 212.199.164.175#53:=20
>> recursion
>> available: denied
>>
>> There are hundreds of those lines, any idea where they are coming=20
>> from, did
>> I block some normal DNS activity on accident? I thought this setting=20=

>> would
>> only prevent people from using me as a local dns resolver. I find it=20=

>> pretty
>> hard to believe that there are that many people with my DNS ip in=20
>> their
>> tcp/ip settings.
>> --
>> -------------------------------------------------------------
>> Scott Haneda Tel: 415.898.2602
>> <http://www.newgeo.com> Fax: 313.557.5052
>> <scott@newgeo.com> Novato, CA U.S.A.
>
>
> ----------------------------------------------------------------------
> End of Quickdns-Talk Digest
>

Sales:
888/4-DPOINT

Support:
858/452-3696