Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Nov 2008 13:25:42 -0500
From:      "David Horn" <dhorn2000@gmail.com>
To:        mdh_lists@yahoo.com
Cc:        freebsd-questions@freebsd.org
Subject:   Re: host -6 failure
Message-ID:  <25ff90d60811101025j4a787b2esb4bb27c1ac5c3e8c@mail.gmail.com>
In-Reply-To: <419025.2571.qm@web56803.mail.re3.yahoo.com>
References:  <25ff90d60811091734u67775807ma67b6c1de0c59b9e@mail.gmail.com> <419025.2571.qm@web56803.mail.re3.yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Nov 10, 2008 at 10:31 AM, mdh <mdh_lists@yahoo.com> wrote:
> --- On Sun, 11/9/08, David Horn <dhorn2000@gmail.com> wrote:
>> From: David Horn <dhorn2000@gmail.com>
>> Subject: Re: host -6 failure
>> To: mdh_lists@yahoo.com
>> Cc: freebsd-questions@freebsd.org
>> Date: Sunday, November 9, 2008, 8:34 PM
>> On Sun, Nov 9, 2008 at 3:13 AM, mdh
>> <mdh_lists@yahoo.com> wrote:
>> > --- On Sat, 11/8/08, David Horn
>> <dhorn2000@gmail.com> wrote:
>> >> From: David Horn <dhorn2000@gmail.com>
>> >> Subject: Re: host -6 failure
>> >> To: mdh_lists@yahoo.com
>> >> Cc: freebsd-questions@freebsd.org
>> >> Date: Saturday, November 8, 2008, 8:10 PM
>> >> On Sat, Nov 8, 2008 at 7:55 PM, mdh
>> >> <mdh_lists@yahoo.com> wrote:
>> >> > --- On Sat, 11/8/08, David Horn
>> >> <dhorn2000@gmail.com> wrote:
>> >> >> From: David Horn
>> <dhorn2000@gmail.com>
>> >> >> Subject: Re: host -6 failure
>> >> >> To: mdh_lists@yahoo.com
>> >> >> Cc: freebsd-questions@freebsd.org
>> >> >> Date: Saturday, November 8, 2008, 7:25 PM
>> >> >> On Fri, Nov 7, 2008 at 2:18 PM, mdh
>> >> >> <mdh_lists@yahoo.com> wrote:
>> >> >> > Howdy folks,
>> >> >> > I'm having a little trouble
>> understanding
>> >> a
>> >> >> problem that the `host` command in
>> RELENG_7_0
>> >> (very recent)
>> >> >> is having.
>> >> >> The '-6' on the command line for
>> host(1)
>> >> forces an
>> >> >> IPv6 only
>> >> >> connection to your nameserver, not
>> necessarily a
>> >> >> "AAAA" query for the
>> >> >> hostname in question.  In this case, your
>> >> nameservers
>> >> >> listed in the
>> >> >> warnings are IPv4 nameservers that
>> host(1) is
>> >> attempting to
>> >> >> connect to
>> >> >> using an ipv4 mapped ipv6 address (which
>> by
>> >> default is
>> >> >> disabled in the
>> >> >> kernel) In other words, don't use
>> host -6 for
>> >> this
>> >> >> scenario.
>> >> >
>> >> > Yet as I pointed out, the second nameserver
>> in my
>> >> resolv.conf is ::1 - so shouldn't it work with
>> that?
>> >> It's clearly trying to contact the first and
>> third
>> >> nameservers listed.  If the behavior I'm
>> experiencing is
>> >> the proper behavior, then let me pose this
>> question: when
>> >> would anyone conceivably want to use the -6
>> option, and why
>> >> does it exist?  My intent was to force a query to
>> hit the
>> >> nameserver on ::1 rather than 127.0.0.1.
>> >> >> >
>> >> >> > domain          mydomain
>> >> >> > search          mydomain
>> >> >> > nameserver      127.0.0.1
>> >> >> > nameserver      ::1
>> >> >> > nameserver      IP.IP.IP.8
>> >> >> >
>> >> >> > The DNS server running on localhost
>> is
>> >> authoritative
>> >> >> for mydomain.  I can ping it via
>> localhost using
>> >> both v4 and
>> >> >> v6, and I can also ping the external v4
>> and v6
>> >> addresses
>> >> >> just fine remotely.
>> >> >> >
>> >> >> > As I said, I'm new to IPv6, but
>> this
>> >> behavior
>> >> >> seems to be counterintuitive.  Am I just
>> doing it
>> >> wrong?
>> >> >> >
>> >> >>
>> >> >> For diagnosing your own nameservers, you
>> are
>> >> better off
>> >> >> using the
>> >> >> dig(1) utility.
>> >> >>
>> >> >> Example:
>> >> >>
>> >> >>  dig ipv6.google.com AAAA @::1
>> >> >>
>> >> >> This causes a dns query for an IPv6
>> address (aka
>> >> >> "AAAA" query) for the
>> >> >> hostname of "ipv6.google.com"
>> using the
>> >> >> nameserver on the IPv6
>> >> >> localhost loopback address (::1), and
>> will give a
>> >> very nice
>> >> >> verbose
>> >> >> output.  man dig for more details.
>> >> >
>> >> > That is more useful, but still doesn't
>> stifle my
>> >> desire to stomp a potential bug in the base
>> system.
>> >>
>> >> Right after sending, I realized that I did not
>> tell you all
>> >> of the answer....
>> >>
>> >> host(1) will successfully query ::1 when named is
>> setup to
>> >> listen on
>> >> ::1 in named.conf, and ::1 is listed in
>> /etc/resolv.conf (I
>> >> just ran a
>> >> test on my box to be sure that it works this way
>> with the
>> >> -6 switch)
>> >>
>> >> Example line from /etc/namedb/named.conf:
>> >>
>> >> listen-on-v6    { ::1; any; };
>> >>
>> >> And of course you need to restart named after the
>> config
>> >> change(
>> >> /etc/rc.d/named restart)
>> >>
>> >> To make sure that it is listening on the IPv6
>> loopback
>> >> address:
>> >>
>> >> netstat -anW -f inet6
>> >>
>> >> I do not remember the minimum version of bind (aka
>> named)
>> >> required for
>> >> IPv6 off the top of my head, but I am running
>> 9.4.2-P2 on
>> >> my IPv6
>> >> machine.
>> >
>> > All of the conditions for success are true, however it
>> fails.  My DNS server software is responsing on ::1 port 53
>> (tcp and udp), and ::1 is the second nameserver listed in
>> resolv.conf.  Still, host -6 fails as previously stated...
>> According to what you've said so far, this leads me to
>> believe that it ought to work as expected, and not error out
>> in the way I'm seeing.
>> >
>> > Am I missing something here?  Is my lack of general
>> IPv6 knowledge causing me to blindly assume something
>> incorrectly?
>>
>> If all of the conditions for success were true, you would
>> *not* be
>> having a problem.  You are likely missing something simple.
>> I suggest that you read about about general IPv6 network
>> troubleshooting, and bind.  The handbook has some good
>> information
>> here:
>>
>> http://www.freebsd.org/doc/en/books/handbook/network-dns.html
>> http://www.freebsd.org/doc/en/books/handbook/network-ipv6.html
>> http://www.freebsd.org/doc/en/books/developers-handbook/ipv6.html
>>
>> You have yet to provide any new diagnostic output.  What
>> was the result of:
>>
>>  netstat -anW -f inet6
>
> Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
> tcp6       0      0  *.53                                          *.*                                           LISTEN
> tcp6       0      0  *.22                                          *.*                                           LISTEN
> tcp6       0      0  *.113                                         *.*                                           LISTEN
> udp6       0      0  *.64039                                       *.*
> udp6       0      0  *.53                                          *.*
>
>>  dig ipv6.google.com AAAA @::1
>
> ;; QUESTION SECTION:
> ;ipv6.google.com.               IN      AAAA
>
> ;; ANSWER SECTION:
> ipv6.google.com.        10800   IN      CNAME   ipv6.l.google.com.
> ipv6.l.google.com.      300     IN      AAAA    2001:4860:0:2001::68
>
> ;; AUTHORITY SECTION:
> l.google.com.           86400   IN      NS      c.l.google.com.
> l.google.com.           86400   IN      NS      b.l.google.com.
> l.google.com.           86400   IN      NS      e.l.google.com.
> l.google.com.           86400   IN      NS      a.l.google.com.
> l.google.com.           86400   IN      NS      g.l.google.com.
> l.google.com.           86400   IN      NS      f.l.google.com.
> l.google.com.           86400   IN      NS      d.l.google.com.
>
> ;; Query time: 426 msec
> ;; SERVER: ::1#53(::1)
> ;; WHEN: Mon Nov 10 06:46:57 2008
> ;; MSG SIZE  rcvd: 194
>
>
>>  named -version
>
> I am running bind 9.4.2 which is part of the FreeBSD base system from RELENG_7_0 (very recent).
>
>>
>> Do not get hung up on the output of host(1) without trying
>> to diagnose
>> the root problem (your nameserver working properly on
>> ipv6).  Once you
>> fix the root problem, the other problems will go away.
>
> I think that the host output may be the problem.  Based on what some others have said, I am more firm in the belief that this is true.  One individual noted that the -6 and -4 options are virtually useless, in that they cause it to only query on the v6 or v4 addr respectively, however if resolv.conf contains v4 addrs it will cause errors with the -6 option, even if it also contains v6 addrs.  I believe this to be a bug, as creating virtually-useless command line options is silly.

Repeating your *belief* does not make it true.  The -4 and -6 command
line parameters work exactly as they are supposed to, but not
necessarily how you think they *should*.  -6 forces IPv6 ONLY for
transport of the dns query/response packets, but much of the worldwide
DNS system is not fully IPv6 enabled (including IPv6 glue records
missing from the majority of registrars, and the majority of the root
namservers still not IPv6 enabled) Using the -6 parameter would cause
a failure once it hit the first nameserver that does not have an IPv6
address.  Depending on the type of query, and application code, this
can be a transient warning, or a failure that will stop processing.
Do NOT rely on just IPv6 for DNS at this point in time "unless you
really know what you are doing(tm)".

First things first.  If you are truly running bind 9.4.2 and NOT
9.4.2-P2, you should keep your software updated using
freebsd-update(8), and portupgrade(1), or other mechanisms available
in FreeBSD.  If you are going to be running a public nameserver
(authoritative or recursive), this is especially true.
http://www.freebsd.org/doc/en/books/handbook/updating-freebsdupdate.html

OK, now back to the original question.

Since you have shown that your nameserver is indeed answering queries
on the IPv6 loopback interface, then the only likely thing left is
bind configuration.  I would say that your zone file or named.conf is
missing something, but unfortunately I can not hazard a guess right
now.

In your original example (host -6 x1.mydomain), have you ever tried
the "-v" parameter to get verbose output ?

I still strongly suggest using dig(1) rather than host, but you can do
what you will.  host(1) does *several* queries, not just a single
forward or reverse lookup, and can confuse those that do not know the
innards of dns.

what happens when you do a:

dig x1.mydomain A @::1
dig x1.mydomain AAAA @::1
dig x1.mydomain A @127.0.0.1
dig x1.mydomain AAAA @127.0.0.1

also, you can look at dig +trace +nofail x1.mydomain AAAA @::1

But again, do *NOT* use the -6 switch with dig either, as if it needs
to contact an upstream or root dns server that does not have IPv6
enabled, it will fail.



>
>>
>> If in doubt, run a tcpdump or wireshark trace, and make
>> sure that your
>> firewall is not getting in the way.

Wireshark and/or tcpdump trace will still help you if you want to
understand what is going on at the network layer.

--Dave

>
> There is no firewall.  IPFW is configured, but has only one rule - the default accept rule.  I plan to use it primarily to auto-block ssh brute-force sources.
>
> - mdh
>
>
>
>
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25ff90d60811101025j4a787b2esb4bb27c1ac5c3e8c>