What am I missing?
Kevin Darcy
kcd at daimlerchrysler.com
Fri Jul 1 01:33:43 UTC 2005
You said that you saw "3 attempts to resolve AAAA hostnames". Was that 3
attempts to resolve the *same* AAAA hostname, or was it trying to
resolve *different* hostnames, e.g. machine1 versus machine1.domain.com
versus machine1.test.domain.com versus something else? That's what I was
getting at when I asked "What is the difference between the names that
are being queried from the slave nameservers versus from the master?".
I'm trying to determine if your shortname lookup is generating a query
*outside* of the authoritative domain.com zone, that maybe the master
server knows how to resolve, but the slaves do not...
- Kevin
Chris Zimmerman wrote:
> All the names (A records) can be queried and will have the 10 sec
> delay if I use the short name:
>
> machine1.test.domain.com:
> ns1.domain.com: instant
> dns1.test.domain.com: instant
> dns2.test.domain.com: instant
>
> Using machine only (resolv.conf search domain set to test.domain.com):
> ns1.domain.com: instant
> dns1.test.domain.com: 10 sec
> dns2.test.domain.com: 10 sec
>
> It doesn't matter which host I use, they all do the same thing.
>
> Kevin Darcy wrote:
>
>> Querylogging == good. What happens if you try querying each of those
>> searchlisted names explicitly against the slave nameservers? Is there
>> one in particular that's taking an excessive amount of time to
>> resolve? What is the difference between the names that are being
>> queried from the slave nameservers versus from the master? The fact
>> that there is a difference in the number of queries suggests either
>> that one type of server is able to resolve a name that the other type
>> of server cannot, or that there is a timeout/retry occurring.
>>
>>
>> -
>> Kevin
>>
>> Chris Zimmerman wrote:
>>
>>
>>
>>> My apologies. That's what I get for posting late in the work day
>>> with no brain cycles left...
>>>
>>> ns1.domain.com
>>> named.conf:
>>>
>>> options {
>>> directory "/var/named.data"; // directory for named
>>> forwarders {
>>> 2.2.2.2;
>>> 1.1.1.1;
>>> };
>>> query-source address * port 53;
>>> recursive-clients 5000;
>>> tcp-clients 5000;
>>> };
>>>
>>> zone "domain.com" {
>>> type master;
>>> file "db.domain";
>>> };
>>>
>>> ... and so on...
>>>
>>> domain.com zone file:
>>>
>>> @ IN SOA ns1.domain.com. root.ns1.domain.com. (
>>> 999912979 ; Serial
>>> 10800 ; Refresh every 3 hours
>>> 3600 ; Retry every hour
>>> 604800 ; Expire after 1 week
>>> 60 ) ; Minimum ttl of 1 day
>>> ; Name Servers
>>> IN NS ns1.domain.com.
>>> ; IN NS ns2.domain.com.
>>> ;
>>> ;
>>> ; *********** MAIL SYSTEMS **************************************
>>> domain.com. IN MX 10 mail.domain.com.
>>> ; ******* DIVISIONAL PRINTERS *********************************
>>> ;
>>> blah IN A 172.31.142.244
>>> ....and so on to the subdomain in the same zone file....
>>> ;**************************************************
>>> $ORIGIN test.domain.com.
>>> machine1 IN A 10.247.0.20
>>>
>>>
>>>
>>> ns2.domain.com
>>> named.conf (same options as above)
>>>
>>> zone "domain.com" {
>>> type slave;
>>> file "db.domain";
>>> masters { 172.29.3.11;} ;
>>> };
>>>
>>>
>>> dns1.test.domain.com
>>> dns2.test.domain.com
>>> Both are setup just like ns2.domain.com.
>>> The difference is in the /etc/resolv.conf. ns1 and ns2 have
>>> domain.com for their search domain, where dns1 and dns2 have
>>> test.domain.com. Nslookup works fine from all machines. I'm
>>> running into an issue with things like FTP clients and ssh from one
>>> machine to another. If the resolv.conf points to a slave server
>>> then the ssh or ftp will take 10 seconds to resolve the hostname and
>>> start the connection. I've watched it with the querylogging turned
>>> on and I see 3 attempts to resolve AAAA hostnames (I know it's ipv6,
>>> but I'm not using it nor is it enabled on the machines), then a
>>> final attempt at an A record which works and the connection is
>>> made. If I point at the master server, then I see 2 attempts at
>>> AAAA records VERY quickly, then one A attempt which works. This is
>>> only if I use the short names to connect. If I use the FQDN,
>>> everything works as expected. I have compiled bind with the
>>> --disable-ipv6 option to no avail. I have turned on the option in
>>> ssh that forces ipv4 which makes that work everytime (short names or
>>> not), but FTP still suffers even when compiled to turn off ipv6.
>>> The host is SLES 9 with kernel 2.6.5 and all ipv6 use has been removed.
>>>
>>> Where I'm confused is why the master works with short names or not
>>> in either the main domain.com or with the test.domain.com sub domain
>>> but the slaves don't?
>>>
>>> Hope this helps to clarify things.
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
More information about the bind-users
mailing list