Subject: [DNSOP] Re: getaddrinfo() and searching

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

On 27-sep-2007, at 3:33, Mark Andrews wrote:

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

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.

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

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.

> 	I'm saying we should go back and fix the specification for
> 	getaddrinfo() so that it accounts for searching.

Volunteers...?

> 	We should also add a AI_NOSEARCH flag so that searching is
> 	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
> 	for 6man.

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

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

---

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

Volunteers...?

---

From: Peter Koch <[email-masked]>
Date: Thu, 27 Sep 2007 18:17:45 +0200

> a period behind your FQDNs.

thanks, Iljitsch, for bringing this into dnsop. I think that the problem
of determinism in following the search path is very well worth investigating.
To some extent it's related to RFC 1535 and we've at least had this under
"A.O.B." in one of the recent meetings, if I remember correctly.

> "renumbering" on the ietf discussion list.

The semantics of search paths in mixed or dual stack environments need to
be clear, independent of a particular API, at least as long as the search
path isn't set API specific.  Seems that we should at least have a look into
this, see what implementations do and what operational and maybe security
consequences are.

-Peter

---

From: Peter Koch <[email-masked]>
Date: Thu, 27 Sep 2007 18:17:45 +0200

-Peter

---

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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

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

If need be, yes.

 

	Mark

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 28 Sep 2007 00:47:42 -0400

> this, see what implementations do and what operational and maybe security
Is there any consensus for deprecating searchlists entirely? That would 
simplify the issue.

- Kevin

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 28 Sep 2007 00:47:42 -0400

- Kevin

---

From: Mark Andrews <[email-masked]>
Date: Fri, 28 Sep 2007 15:51:02 +1000

> Is there any consensus for deprecating searchlists entirely? That would 

	It would but I don't think you will find any consensus.

	It would be tough enough to get rid of partially qualified
	names.

	Note: I tried to get this issue addressed years ago and
	couldn't get any traction then.

	http://atm.tut.fi/list-archive/ipng/msg04767.html

---

From: Mark Andrews <[email-masked]>
Date: Fri, 28 Sep 2007 15:51:02 +1000

---

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: John C Klensin <[email-masked]>
Date: Fri, 28 Sep 2007 11:06:17 -0400

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.

---

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

Mark

	

3.3.11. NS RDATA format

where:

where: