Re: DNS vs /etc/hosts - Mailing list pgsql-general

From Michael Fuhr
Subject Re: DNS vs /etc/hosts
Date
Msg-id 20050805002946.GA91570@winnie.fuhr.org
Whole thread Raw
In response to Re: DNS vs /etc/hosts  (Michael Fuhr <mike@fuhr.org>)
Responses Re: DNS vs /etc/hosts  (Michael Fuhr <mike@fuhr.org>)
List pgsql-general
On Thu, Aug 04, 2005 at 04:30:52PM -0600, Michael Fuhr wrote:
> The response to 7.2 has an ANCOUNT (number of records in the answer
> section) of 1 and an NSCOUNT (number of records in the authority
> section) of 2, whereas the response to 8.0 has an ANCOUNT of 0 and
> an NSCOUNT of 1.  That disparity is odd if the DNS queries were
> indeed the same.

I wonder if the use of getaddrinfo() in 8.0 is causing the first
DNS query to be for an AAAA record instead of for an A record.  The
connectDBStart() function in src/interfaces/libpq/fe-connect.c sets
hint.ai_family = AF_UNSPEC, which on some systems might cause the
resolver to try an AAAA query first.  That would explain the above
disparity: the response to the AAAA query would return a response
code of NOERROR, no records in the answer section, and the zone's
SOA record in the authority section (at least that's how BIND 9
responds).  The resolver then makes AAAA queries for the unqualified
name (i.e., the name as a top-level domain) and those queries time
out; finally it makes A queries for the fully-qualified name and
we get success.  This is exactly what the strace output appears to
show.  A packet sniff should be able to confirm or refute.

Anybody know if AAAA queries can be disabled in Linux?  Lowell, if
nobody answers here then you might need to seek help in a different
forum.  Or you could just hack the code and change AF_UNSPEC to
AF_INET ;-)

--
Michael Fuhr

pgsql-general by date:

Previous
From: Frank Miles
Date:
Subject: Re: What causes lock??
Next
From: Michael Fuhr
Date:
Subject: Re: DNS vs /etc/hosts