name resolution questions - bad queries

Mark_Andrews at isc.org Mark_Andrews at isc.org
Mon Feb 25 21:53:53 UTC 2002


> 
> Mark_Andrews at isc.org wrote:
> >>hi all,
> >>
> >>playing with ethereal, Ive found that some name queries which should be 
> >>answered by /etc/hosts are trickling into ROOT nameservers.  This 
> >>appears to correct itself after the 1st try, but the whole thing hints 
> >>that my 'private' domain-name is leaking out..
> >>
> >>
> >>#/etc/host.conf
> >>order hosts,bind
> >>
> >>#/etc/hosts
> >>192.168.100.1 groucho.vnet
> >>192.168.100.2 harpo.vnet
> >>192.168.1.1   groucho.dmz
> >>192.168.1.2   harpo.dmz
> >>
> >>#/etc/resolv.conf
> >># dont have dns on localhost
> >># nameserver 127.0.0.1
> >>nameserver 192.168.1.1
> >>nameserver 206.196.128.1
> >>nameserver 204.147.80.5
> >>
> >>
> >>so I capture 'port domain' packets with ethereal,
> >>ssh from harpo.dmz to groucho.dmz,
> >>and get following:
> >>
> >>
> >>[jimc at harpo jimc]$ more name-resolve
> >>     No. Time        Source                Destination 
> >>Protocol Info
> >>       1 0.000000    harpo.dmz             groucho.dmz           DNS 
> >>   Standard query AAAA groucho.vnet
> >>       2 0.002565    10.0.0.3              b.root-servers.net    DNS 
> >>   Standard query AAAA groucho.vnet
> >>       3 0.121574    b.root-servers.net    10.0.0.3              DNS 
> >>   Standard query response, No such name
> >>       4 0.122976    groucho.dmz           harpo.dmz             DNS 
> >>   Standard query response, No such name
> >>       5 0.123412    harpo.dmz             groucho.dmz           DNS 
> >>   Standard query AAAA groucho.vnet.jimc.earth
> >>       6 0.125094    10.0.0.3              a.root-servers.net    DNS 
> >>   Standard query AAAA groucho.vnet.jimc.earth
> >>       7 0.228021    a.root-servers.net    10.0.0.3              DNS 
> >>   Standard query response, No such name
> >>       8 0.229215    groucho.dmz           harpo.dmz             DNS 
> >>   Standard query response, No such name
> >>       9 26.852387   harpo.dmz             groucho.dmz           DNS 
> >>   Standard query AAAA groucho.vnet
> >>      10 26.853501   groucho.dmz           harpo.dmz             DNS 
> >>   Standard query response, No such name
> >>      11 26.853849   harpo.dmz             groucho.dmz           DNS 
> >>   Standard query AAAA groucho.vnet.jimc.earth
> >>      12 26.854840   groucho.dmz           harpo.dmz             DNS 
> >>   Standard query response, No such name
> >>
> >>
> >>so questions are lettered, after line that prompts them
> >>
> >>
> >>line 1.  harpo queries my caching DNS server. (groucho.dmz)
> >>
> >>a- 
> >>harpo queries groucho.dmz (see resolv.conf) for
> >>	(oddly enough) groucho.dmz
> >>b- 
> >>why is it doing IPv6 query ?
> >>
> > 
> > 	Because you have a IPv6 capable OS.
> 
> its linux, so yes, but I dont have it (knowingly) configured
> 
> [jimc at harpo etc]$ ls /proc/sys/net/
> 802         appletalk   core        ethernet    ipv4        ipx 
> token-ring  unix
> 
> doesnt lack of /proc/sys/net/ipv6 mean its not configured / enabled ?

	Just because you havn't enabled it in the kernel doesn't mean that
	the clients don't support IPv6.
 
> but AAAA query would explain why 'order hosts,bind' didnt have the
> (previously) expected result.
> 
> > 
> > 
> >>line 2.  caching DNS server prompts questions
> >>
> >>a- why is a DNS query is run when the answer is in /etc/hosts
> >>
> > 
> > 	But the answer isn't in /etc/hosts. You have no IPv6 addresses
> > 	for these machine in /etc/hosts so the lookup proceeds to use
> > 	the DNS.
> > 
> 
> but it is - perhaps the wierd tab-wrap on my original post obfuscated
> that.  Ive fixed it manually above.

	No it's not.  There are no IPv6 entries above.
 
> > 
> >>b- Im querying b.root-servers.net.  Why wasnt this my nameserver ?
> >>	  did it pass on the query to root for some reason
> >>
> > 
> > 	Well the default resolution path is to ask the root servers and
> > 	work down from there.  If you don't want to query the root servers
> > 	you need to pre-configure your nameservers with knowledge about
> > 	where to get the answers for the domains being looked up.
> >  
> 
> so, that means its not using /etc/resolv.conf at all (for clients only), 
> but going straight to /var/run/named/named.ca ?

	The clients talk to your caching server.  Your caching server in
	turn talks to the root servers and work down from there.
	
> > 
> >>line 5, query is re-tried, after tacking on my 'private' domain name.
> >>
> >>a- 
> >>is re-try due to groucho's /etc/resolv.conf line:
> >>	'search jimc.earth'  - should I remove this line ?
> >>
> > 
> > 	It's due to the search directive.  Removal is up to you but if
> > 	yuo don't remove it you should ensure that your nameserver knows
> > 	how to answer for this zone without going to the root servers.
> > 
> > 	Same with "vnet" and "dmz".
> > 
> 
> its a 3 year leftover, I think Ill remove it.
> 
> As for nameserver handling the vnet and dmz addresses,
> it shouldnt have to, my /etc/hosts should have precluded that.
> But its on the list..

	/etc/hosts stop only 'A' queries when going through the
	get*() library routines.  Not MX, AAAA, A6, TXT, SOA or any
	other type of query.

	I would be setting up vnet and dmz zones.

> > 
> >>line 9.  26 seconds later I do another ssh groucho.dmz
> >>
> >>this time, root-server is not queried - DNS on groucho.dmz
> >>remembers the bad lookup, and doesnt try again..
> >>
> > 
> > 	Well negative caching works.
> > 
> >>The problems seem to start in ssh,
> >>
> >>[jimc at groucho jimc]$ ssh -v
> >>OpenSSH_3.0.2p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
> >>
> >>
> >>have I missed or misinterpreted something ?
> >>any free advice ?
> >>
> >>tia,
> >>jimc
> >>
> >>
> > --
> > Mark Andrews, Internet Software Consortium
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org
> > 
> > 
> 
> 
> thanks Mark.
> 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org


More information about the bind-users mailing list