> > >> 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. > > > Well, let's be fair. Search creates lots of problems other than this > one. Right now there's not really any way to unambiguously specify a > FQDN that works across all applications, has the same meaning across all > applications, and has the same meaning independent of what host the > query is being made from. That's a real problem. > > Yes, users like search, but it's arguably a Bad Idea, particularly in > the absence of a universal syntax that says "don't subject this name to > search". > > IMHO the stopping criterion should be that if there are _any_ RRs > matching the name in a particular zone, the search should terminate. We need a new DNS rcode or universal deployment of DNSSEC to support that in the DNS or make ANY queries on NODATA. A NODATA response does *not* indicate some rdata. Stoping on NODATA might be feasible but you need to look at all the possible backends. > > 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. > > > The "usual use scenario" is broken, and it's based on a previous > poorly-designed API. > > 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. > > > I think you're grossly overgeneralizing here. Email is far from the > only application that needs for DNS names to be unambiguous. And users > would benefit from having DNS names being used consistently from one app > to another, even though they may not realize this. MTA's get FQHN from MX records. They don't need to search. It's the MUA's job to qualify mail domains. The MTA should be being given FQMD's. I'm sure there are other applications that only take fully qualified names, however most applications take unqalified names. > >>> 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. > > > Maybe the equivalent of air bags in the case of DNS lookups would be > having an API that refused to search any name containing a ".". I can hear the screams now. However it would make the implementations simpler. I don't think any vendor will stop supporting partially qualified names without a RFC prohibiting it. Mark > Keith > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@xxxxxxxx > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- 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