Date: Fri, 19 Jul 2002 10:37:29 +1000
From: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
| Robert, I mentioned that this was a issue several years ago
| (on namedroppers / bind-workers) with respect to MX vs A
| and said that the search should stop on a NODATA response.
| You were quite happy for MX and A to hit different fqdn at
| the time. It looks like AAAA vs A has changed your opinion.
Sorry, I don't remember the context, but the two cases aren't the same
at all. If I am looking for an MX record, I am looking for an MX
record. And if I want the MX record for "foo" that's what I want to
find. Only if there is no MX record for "foo" should a A lookup
even be attempted.
On the other hand, when I want "the address of foo" (which is what
getaddrinfo() without a specific address type hint does), then I am
expressly asking for either an A or an AAAA (or even an A6...)
| Agreed, however changing *default* resolver behaviour is
| difficult as it ends up breaking things. "localhost"
| lookups is what tends to break if you disable this.
Only for badly configured zones - the name "localhost" should be
configured in every zone that is in a search list (if it doesn't
exist in a zone that is on the search list means that there is no
"localhost" existing, and the lookup should fail, going on to,
or locally configuring "localhost." isn't what should be being done.
Because of the way the decision was made to ground FQDN's in a trailing dot,
but almost never actually represent it, there's no way for the PTR record
for 127.0.0.1 to actually return the FQDN "localhost." (or rather, that
could be done, but it never is). What's always returned is the
unqualified name, "localhost"
| It's not only if the kernel is capable. It's also if there
| are interfaces configured.
Sure, there should be a simple API for "should I attempt this AF?"
I'd also be somewhat cautious about advising people to run non-standard
DNS setups. There are things that people who know what they're doing
can safely do - but which aren't really practical to advise for the
world to attempt to copy (and everyone snarfing the root zone probably
doesn't scale, even if it isn't one of the more dangerous things).
kre
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
