Re: getaddrinfo() and searching

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On 25-sep-2007, at 2:18, Mark Andrews wrote:
> 
> >> You are comingling way too many things here. Let me simply conclude
> >> that foo.example.org is the first name that is tried and since it
> >> exists what comes back for that name is what's going to be used.
> 
> > 	Actually it isn't specified what should happen.
> 
> > 	If you don't make AAAA queries most(all?) existing search
> > 	algorithms will continue to foo.example.net.  Remember, in
> > 	the DNS, a name can exist yet have not records associated
> > 	with it (rcode=NOERROR ancount=0 is returned for all types).
> 
> Looks like you're right, at least as far as my Mac is concerned.
> 
> I set up two subdomains test1 and test2 with each the hosts a, b, c  
> and d with the following addresses:
> 
>            IPv6   IPv4
> a.test1     X      X
> b.test1     X      -
> c.test1     -      X
> d.test1     -      -
> a.test2     -      -
> b.test2     -      X
> c.test2     X      -
> d.test2     X      X
> 
> Then I set up test1.runningipv6.net, test2.runningipv6.net up as my  
> search domains. (Info is still in there, feel free to try for  
> yourself. TTL is 20 seconds.) Results on my Mac running the latest  
> updates with both IPv4 and IPv6 connectivity:
> 
> (host talks directly to the DNS and looks for both A and AAAA)
> 
> $ host a
> a.test1.runningipv6.net has address 192.0.2.101
> a.test1.runningipv6.net has IPv6 address 2001:db8:1::a
> $ host b
> b.test1.runningipv6.net has IPv6 address 2001:db8:1::b
> $ host c
> c.test1.runningipv6.net has address 192.0.2.103
> $ host d
> d.test2.runningipv6.net has address 192.0.2.204
> d.test2.runningipv6.net has IPv6 address 2001:db8:2::d
> 
> (traceroute only does IPv4)
> 
> $ traceroute a
> traceroute to a.test1.runningipv6.net (192.0.2.101), 64 hops max, 40  
> byte packets
> $ traceroute b
> traceroute to b.test2.runningipv6.net (192.0.2.202), 64 hops max, 40  
> byte packets
> $ traceroute c
> traceroute to c.test1.runningipv6.net (192.0.2.103), 64 hops max, 40  
> byte packets
> $ traceroute d
> traceroute to d.test2.runningipv6.net (192.0.2.204), 64 hops max, 40  
> byte packets
> 
> (traceroute6 only does IPv6)
> 
> $ traceroute6 a
> traceroute6 to a.test1.runningipv6.net (2001:db8:1::a) from
> $ traceroute6 b
> traceroute6 to b.test1.runningipv6.net (2001:db8:1::b) from
> $ traceroute6 c
> traceroute6 to c.test2.runningipv6.net (2001:db8:2::c) from
> $ traceroute6 d
> traceroute6 to d.test2.runningipv6.net (2001:db8:2::d) from
> 
> (telnet does both IPv4 and IPv6)
> 
> $ telnet a
> Trying 2001:db8:1::a...
> $ telnet b
> Trying 2001:db8:1::b...
> $ telnet c
> Trying 2001:db8:2::c...
> $ telnet d
> Trying 2001:db8:2::d...
> 
> So your issue that the results are inconsistent is certainly real.
> 
> I'd say that the best way to avoid this is not having a search domain  
> at all, or at the very least not several.

	Which is a totally unreasonable suggestion.

	The problem here is not the search but different stoping
	critera depending apon the address families supported by
	the host or requested by the application.

	We wrote a API that failed to account for the usual use
	senario.  In fact the guidance in there is the direct
	opposite of what should be done with the usual use senario.

	It perfectly fine for a MTA which get fully qualified names
	in MX records then looks up the addresses.  MTA's should
	be disabling name searching in the resolver.  That however
	is not how most application work nor how the users of those
	applications want them to work. They want to be able to
	search.  I've actually had requests to extend the number
	if domains that can be in the search list.

> If someone wants to spend  
> time to come up with a reasonable guideline of how to behave that  
> gives the same results regardless of the type of connectivity that's  
> available, that would be good but probably extremely hard to do.

 
> > 	People like to use unqualified *and* partially qualified hostnames.
> 
> People also like to drive without seat belts. We don't let them do  
> that either... Or at least, we don't listen to their complaints when  
> the results are inferior to those obtained while driving _with_ a  
> seatbelt.

	We also put air bags in cars to help those that don't use
	saftey belts.

	I'm saying we should go back and fix the specification for
	getaddrinfo() so that it accounts for searching.  Make the
	optimisation of not looking for A/AAAA record only occur
	when searching is disabled.  Make the queries for both types
	manditory when searching.

	This will cause getaddinfo() to return consistant results.

	We should also add a AI_NOSEARCH flag so that searching is
	controlled directly rather than indirectly.  The lack of a
	AI_NOSEARCH define would mean the application would use the
	indirect method.
 
	Mark

	I've set Reply-To to ipv6@xxxxxxxx as this is more approriate
	for 6man.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@xxxxxxx

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]