Eric Shubert wrote:
> Maxwell Smart wrote:
>>
>> Eric Shubert wrote:
>>> Maxwell Smart wrote:
>>>> Eric,
>>>>
>>>> Eric Shubert wrote:
>>>>> Maxwell Smart wrote:
>>>>>> Eric,
>>>>>>
>>>>>> Yes, they are there and constant with 127.0.0.1 in the first
>>>>>> position of
>>>>>> my resolv.conf file.  If I move it back to the last position it's
>>>>>> ok.
>>>>> It's not really ok. It's just that the DNS server(s) before it in the
>>>>> list are handling the requests, so it never gets to 127.0.0.1, which
>>>>> is your localhost DNS server.
>>>>>
>>>> OK, but it's then going through the ISP's servers anyways just in a
>>>> round about way. 
>>> Not unless you deliberately set it up that way. With a typical
>>> caching/resolving nameserver, DNS requests will not hit the ISP's
>>> server at all.
>>>
>> Where does it resolve to then?  How does it resolve addresses?
>
> The root authoritative servers by default.
>
>>>>> The dig command (man dig) is handy for troubleshooting DNS problems.
>>>>>
>>>>> You might try:
>>>>> # dig @127.0.0.1 google.com
>>>>> and see what you get. I'm guessing that you'll get an error of some
>>>>> sort (the command will work, but the result of the lookup will fail).
>>>>>
>>>> Dig worked fine, no error.
>>> Did it return an answer section with a result in it? dig won't show a
>>> glaring error. You need to know what to look for.
>>>
>> [r...@laetitia smtp]# dig 127.0.0.1 google.com
>> ;; Got answer:                               ;; ->>HEADER<<- opcode:
>> QUERY, status: NXDOMAIN, id: 24685
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>>
>> ;; QUESTION SECTION:
>> ;127.0.0.1.                     IN      A
>>                                                                              
>>                                                                              
>>   
>>
>> ;; AUTHORITY
>> SECTION:                                                                     
>>                                                                   
>>
>> .                       1457    IN      SOA     A.ROOT-SERVERS.NET.
>> NSTLD.VERISIGN-GRS.COM. 2009092201 1800 900 604800
>> 86400                                
>> ;; Query time: 143 msec
>> ;; SERVER: 206.13.30.12#53(206.13.30.12)
>> ;; WHEN: Tue Sep 22 15:01:29 2009      ;; MSG SIZE  rcvd:
>> 102                
>>
>> ; <<>> DiG 9.3.4-P1 <<>> 127.0.0.1 google.com
>> ;; global options:  printcmd                ;; Got
>> answer:                              ;; ->>HEADER<<- opcode: QUERY,
>> status: NOERROR, id: 61092
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
>>
>> ;; QUESTION SECTION:
>> ;google.com.                    IN      A
>>
>> ;; ANSWER SECTION:
>> google.com.             17      IN      A       74.125.127.100
>> google.com.             17      IN      A       74.125.67.100
>> google.com.             17      IN      A       74.125.45.100
>>
>> ;; Query time: 145 msec
>> ;; SERVER: 206.13.30.12#53(206.13.30.12)
>> ;; WHEN: Tue Sep 22 15:01:29 2009      ;; MSG SIZE  rcvd: 76  
>
> That command was:
> # dig @127.0.0.1 google.com
> The @127.0.0.1 tells dig to use 127.0.0.1 as the resolver, bypassing
> what you have in the /etc/resolv.conf file.
>
> Your command did succeed, but it was resolved by 206.13.30.12, not the
> nameserver on your toaster (127.0.0.1).
>
>>>>>> Ideas on how to begin to troubleshoot?  I remember someone on the
>>>>>> list a
>>>>>> few days ago experiencing the same issue, but paid little attention
>>>>>> then.
>>>>> IIRC you said earlier that this is a secondary to your authoritative
>>>>> server. It's generally considered a bad practice to have a DNS server
>>>>> configured to handle both authoritative and resolver requests. It can
>>>>> be done, but you'd better know what you're doing.
>>>>>
>>>>> If it's ok to blow away your secondary DNS, I would:
>>>>> # yum remove bind
>>>>> # yum install chroot-bind caching-nameserver
>>>>> then try moving 127.0.0.1 to the top of /etc/resolv.conf again.
>>>> I have a master DNS server (ns1) which is authoritative and a slave
>>>> (ns2) which is also a web and e mail server.  
>>> It'd be better to have a caching/resolving DNS server on the web/email
>>> host. The email server will use the resolving DNS server fairly
>>> heavily.  Better to put the slave DNS on a different host.
>>>
>>>> So remove the nameserver 64.168.70.132 entry in the resolve.conf file? 
>>> Absolutely. Authoritative servers should never be listed in the
>>> resolv.conf file.
>>>
>> OK, I've removed these from the file.
>>>> The other problem is this was all working just fine until about a week
>>>> or so ago.  I don't know why I would have to start changing my DNS
>>>> when
>>>> it was working fine.  There is no reason this should have changed.  I
>>>> did however update my toaster.
>>> I don't know what all changed, but updating the toaster should not
>>> have caused this problem. I think that is coincidental.
>>>
>>> Best guess at this point is that your ISP's DNS was/is having
>>> problems. We've recommended using a caching nameserver on the toaster,
>>> which will keep your ISP's DNS from detrimentally affecting your
>>> toaster. Unfortunately, you already had a secondary DNS server running
>>> on your toaster, which is not a recommended configuration. It is
>>> possible to configure bind on your toaster to do both secondary
>>> authoritative and resolving, but that's beyond what we can do for you
>>> here.
>>>
>> OK,  are you saying to not use it as my secondary DNS server?
>
> That would be best.

Is it OK to use this as my primary DNS server?
>
>> CJ
>>
>> ---------------------------------------------------------------------------------
>>
>> Qmailtoaster is sponsored by Vickers Consulting Group
>> (www.vickersconsulting.com)
>>     Vickers Consulting Group offers Qmailtoaster support and
>> installations.
>>       If you need professional help with your setup, contact them today!
>> ---------------------------------------------------------------------------------
>>
>>      Please visit qmailtoaster.com for the latest news, updates, and
>> packages.
>>            To unsubscribe, e-mail:
>> qmailtoaster-list-unsubscr...@qmailtoaster.com
>>      For additional commands, e-mail:
>> qmailtoaster-list-h...@qmailtoaster.com
>>
>>
>>
>
>

---------------------------------------------------------------------------------
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
    Vickers Consulting Group offers Qmailtoaster support and installations.
      If you need professional help with your setup, contact them today!
---------------------------------------------------------------------------------
     Please visit qmailtoaster.com for the latest news, updates, and packages.
     
      To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
     For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com


Reply via email to