Subject: Re: getaddrinfo() and searching

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Sep 2007 11:33:56 +1000

> 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 [email-masked] as this is more approriate
	for 6man.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 27 Sep 2007 17:42:38 +0200

> 	Which is a totally unreasonable suggestion.

It's not. Even without IPv6, having search domains means you can get  
unexpected results. If that's not acceptable, don't complain, but put  
a period behind your FQDNs.

> 	opposite of what should be done with the usual use senario.

I thought the solution would be hard or would be suboptimal in the  
common case, but I think that doesn't have to be so.

In my example, MacOS would go through the search domains and keep  
going until it found AAAA records for IPv6 or IPv4+IPv6 applications  
(and presumably look for A records if there were no AAAA records and  
IPv4 was present/requested also).

So basically, both the "answers = 0, noerror" and "nxdomain"  
responses trigger trying the next search domain. If we change this to  
"answers = 0, noerror" means try the same FQDN again for an A record,  
and "nxdomain" means move on to the next search domain, the results  
for different permutations of IP version availability would all  
result in connecting to the same FQDN = the first one with an address  
that's compatible with current connectivity, rather than the first  
one with an AAAA record if there is IPv6 connectivity.

> 	getaddrinfo() so that it accounts for searching.

Volunteers...?

> 	controlled directly rather than indirectly.

That's what the period terminating a domain name is for.

> 	I've set Reply-To to [email-masked] as this is more approriate

No, it's a DNS issue, so it should go to dnsop. dnsop people: see  
discussion between Mark, Keith and me that started under the subject  
"renumbering" on the ietf discussion list.

Everyone: feel free to prune some lists when you respond.  :-)

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Sep 2007 12:44:01 -0400

> 	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.
> 	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.
> 	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.
> 	We also put air bags in cars to help those that don't use
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 ".".

Keith

---

From: Mark Andrews <[email-masked]>
Date: Fri, 28 Sep 2007 09:48:38 +1000

> a period behind your FQDNs.

	Please state were in RFC 952 a final period is legal in
	a hostname. 

	Remember applications take HOSTNAMES not DOMAIN NAMES.
	There are HOSTNAMES that you cannot store in the DNS.
	There are DOMAIN NAMES that are not legal HOSTNAMES.

> > 	getaddrinfo() so that it accounts for searching.

	If need be, yes.
 
> That's what the period terminating a domain name is for.

	Again you confuse domain names and hostname.
 
> "renumbering" on the ietf discussion list.

	I chose [email-masked] (or it predecessor) because [email-masked]
	was where getaddrinfo()s behaviour was spec'd out.  We need to
	at least give the 6man a chance to address it.
 
	Mark

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dnsop

---

From: Mark Andrews <[email-masked]>
Date: Fri, 28 Sep 2007 10:14:55 +1000

> 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.

> 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.

> 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

---

From: John C Klensin <[email-masked]>
Date: Fri, 28 Sep 2007 11:06:17 -0400

--On Friday, 28 September, 2007 09:48 +1000 Mark Andrews
<[email-masked]> wrote:

>...
>> It's not. Even without IPv6, having search domains means you
>> can get   unexpected results. If that's not acceptable, don't
>> complain, but put   a period behind your FQDNs.
> 

Mark, your recollection and understanding of history and
vocabulary may be different from mine (and probably is), but I
think you are getting confused by some informal terminology and
risking confusing others even further.

RFC 952 in fact prohibits trailing periods in domain names used
as host names, but 952 is a very early document, superceded by
all sorts of things both formally and informally.  I note, for
example, that it has been a rather long time since every
boundary router on the network (a "gateway") had a name ending
in "-GW" or "-GATEWAY".  Please don't read sentences of 952 out
of context and consider them binding.

You will not find the "hostname" versus "domain" distinction
made in RFC 1034.   1034 and its conceptual predecessors
discusses the domain name system as a replacement for the
hostname one and even notes (correctly) that different
applications have different syntax rules for names for hosts.
To make the ambiguity worse, when the term "host" or "hostname"
is used in applications in conjunction with the DNS, that term
often refers to the leaf-note label and not to the FQDN.  See,
for example, section 3.7 of RFC 821, which describes
"Fred.Cambridge.UK" as a possible "host-and-domain identifier".
However, the familiar "mailbox" is defined as
     <mailbox> ::= <local-part> "@" <domain>
Note that it is not 
          <local-part> "@" <hostname>
or
          <local-part> "@" <host-and-domain>

RFC 1034 also seems to believe that all fully-qualified (aka
"absolute") domains names, including those used to refer to
hosts, end in a period, even if that period is typographically
omitted for convenience.  Of course, it also contains a
masterwork of apparently-circular definition: "A domain is
identified by a domain name, and consists of that part of the
domain name space that is at or below the domain name which
specifies the domain."

While 1034 suggests that the trailing period is always
permitted, even if it is implied, Section 2.3.1 of 1035 gives a
syntax that doesn't permit them.   But it does so without trying
to distinguish between a "host" and a "domain".   In particular,
it says that [all of] "The labels must follow the rules for
ARPANET host names", which is ultimately a reference to 952
although 1035 repeats the rule.  That rule is applied to all
labels, not just the leaf one or ones identifying hosts.

As an indirect illustration of this, note that 1035 Section 3.5
describes IN-ADDR.ARPA as supporting "host address to host name
mapping".  That mapping is to an FQDN, not a label or "hostname"
as you use the term above.

RFC 1123 makes explicit provision for trailing dots in
application interfaces to domain names ("hosts") while noting
that RFC 822 (and 821) do not permit that syntax in the
protocols.  Nothing has ever permitted a UI designer, even for a
mail-related program, from accepting the trailing dot as long as
it is removed (and any searching or aliases resolved) before the
name goes out on the wire.

So I believe the distinction you are trying to make is not
historically supported, not particularly helpful, ambiguous, and
probably just plain wrong.

regards,
    john

---

From: Mark Andrews <[email-masked]>
Date: Sat, 29 Sep 2007 10:54:51 +1000

> made in RFC 1034.

	Actually will find the distinction made.
	Please go re-read RFC 1034 and RFC 1035.

	Mark

3.5. Preferred name syntax

The DNS specifications attempt to be as general as possible in the rules
for constructing domain names.  The idea is that the name of any
existing object can be expressed as a domain name with minimal changes.
However, when assigning a domain name for an object, the prudent user
will select a name which satisfies both the rules of the domain system
and any existing rules for the object, whether these rules are published
or implied by existing programs.

For example, when naming a mail domain, the user should satisfy both the
rules of this memo and those in RFC-822.  When creating a new host name,
the old rules for HOSTS.TXT should be followed.  This avoids problems
when old software is converted to use domain names.
	
	Note: NS specifies a HOST.

3.3.11. NS RDATA format

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                   NSDNAME                     /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:

NSDNAME         A <domain-name> which specifies a host which should be
                authoritative for the specified class and domain.

	Note: CNAME is a general DOMAIN.

3.3.1. CNAME RDATA format

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                     CNAME                     /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:

CNAME           A <domain-name> which specifies the canonical or primary
                name for the owner.  The owner name is an alias.

>   1034 and its conceptual predecessors
> omitted for convenience.

> Of course, it also contains a

	It does for almost all possible hostnames.  Maximum length
	hostnames can't fit into the DNS.  For that mapping to be
	valid the data encoded in the FQDN must map back to a valid
	hostname.

	If I put "!@#@#$%%^&^&*$%^.example.net" in that
	PTR record would you claim that it is a valid hostname?

	The DNS is much more than a distributed HOST <-> ADDRESS
	mapping mechinism.  It was designed to be general.  This
	was a good thing.  However that does mean that you need to
	be aware of what is valid and what is invalid as the DNS
	itself does protect you when you get it wrong.

> name goes out on the wire.

	But forcing people to put the period in when we have stuffed
	up the API is just stupid.  RFC 1535 also shows that RFC 1123
	was wrong in this respect.  An absolute name should always
	match without having to remember to put periods at the end.
	The common search strategy didn't do this along with
	automatically created search lists lead to the *.EDU.COM
	fiasco.

	The search strategy was modified as reaction to RFC 1535.
	It however need to be modified further.  I've been arguing
	this for years.  Getting others to see the issue has been
	a problem.

	Remember when RFC 1123 and RFC 1535 were written the search
	strategy was to try the entered name last.  That also ment
	you often needed to skip across wildcard MX records so the
	search didn't stop on a NODATA response.

	If we had though to stop on NODATA as well as trying the
	name as entered first when it had multiple labels than I
	suspect there wouldn't be a issue now.  However the changes
	in response to RFC 1535 didn't do that and we need a RFC
	that describes how to do searching correctly.