Painfully slow AAAA DNS

M

mart

Hello all. I'm trying to simplify my desktop requirements by moving to Xfce/Opera (vs Gnome/Firefox).

For the most part, things are going very well. However, I get approx 40-second delays on each new page request in Opera, and tcpdump shows this delay to be 'AAAA+' DNS requests (which I understand are ipv6). As soon as an 'A+' request is made, the response is immediate, and the page loads perfectly fine. I'm not a networking guy, and am new to the BSDs, so I apologize if my terminology is all wrong.

I can't find a way to disable ipv6 requests from within Opera (unlike Firefox), so am looking for an alternate way, ideally disabling ipv6 system-wide (nothing on my system or network requires it, or benefits from it).

I've tried building a custom kernel with the ipv6 option disabled, but doing so causes compile errors (from stock 7.0-RELEASE-p6). I block regular ipv6 traffic in pf, but obviously these DNS requests bypass that rule and my pf-fu isn't strong enough to detect an ipv6-specific DNS request.

I'm loving the simplicity of FreeBSD, everything so far has been very intuitive. This is one of the few remaining issues I have to getting a lean and mean desktop.

Can anyone help?
 
You could try:

Code: 
block return out quick on $ext_if proto ipv6

Not sure if it will catch AAAA+ requests, which may, of course, be done using IPv4 anyway ...
 
mart said:
I've tried building a custom kernel with the ipv6 option disabled, but doing so causes compile errors (from stock 7.0-RELEASE-p6).
Click to expand...

I'm almost sure that this works. Could you please let me know how exactly you tried to disable the ipv6 option, and what build error have you triggered?
 
Thanks DD, but as I said, I'm already blocking regular ipv6 traffic in my pf.conf, but it doesn't catch these requests (I assume because they're ipv4 DNS requests for a ipv6 address).

I'm not sure if pf can easily distinguish between the two. If it can, then that would work, although it wouldn't be optimal. As I said, I'd love to just avoid the issues of ipv6 altogether.

Sadly, disabling support in the kernel by commenting out the ipv6 'option' causes compile errors. Is there any sysctl magic that could help here? Failing that, is there a simple way of setting up a local DNS that would strip out these requests completely, or change them to ipv4 requests? Ugly, I know...

Like I said, I'm only a couple of days into using the BSDs, but everything so far has been solved logically, so I still have hope for a clean solution. My lack of networking knowledge isn't helping though, hence the requests for help...
 
I'm almost sure that this works. Could you please let me know how exactly you tried to disable the ipv6 option, and what build error have you triggered?
Click to expand...

I was hoping so too. It would certainly be the preferred solution. Here's some more info...

Code: 
[root@me /usr/home/mart]# uname -a
FreeBSD me.local 7.0-RELEASE-p6 FreeBSD 7.0-RELEASE-p6 #5: Wed Dec  3 01:41:46 PST 2008     mart@me.local:/usr/obj/usr/src/sys/ME  i386

Code: 
[root@me /usr/home/mart]# diff /root/kernels/GENERIC /root/kernels/ME
21,22d20
< cpu		I486_CPU
< cpu		I586_CPU
24c22,24
< ident		GENERIC
---
> ident		ME-5
> options       VESA
> options       SC_PIXEL_MODE
34c34
< options 	INET6			# IPv6 communications protocols
---
> #options 	INET6			# IPv6 communications protocols

The build chugs along quite happily for a while, then...

Code: 
MAKE=make sh /usr/src/sys/conf/newvers.sh ME-5
cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000  -mno-align-long-strings -mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror  vers.c
linking kernel.debug
uipc_syscalls.o(.text+0x3c1): In function `sctp_generic_recvmsg':
/usr/src/sys/kern/uipc_syscalls.c:2608: undefined reference to `sctp_sorecvmsg'
uipc_syscalls.o(.text+0x21a2): In function `sctp_generic_sendmsg_iov':
/usr/src/sys/kern/uipc_syscalls.c:2486: undefined reference to `sctp_lower_sosend'
uipc_syscalls.o(.text+0x249d): In function `sctp_generic_sendmsg':
/usr/src/sys/kern/uipc_syscalls.c:2379: undefined reference to `sctp_lower_sosend'
uipc_syscalls.o(.text+0x266c): In function `sctp_peeloff':
/usr/src/sys/kern/uipc_syscalls.c:2246: undefined reference to `sctp_can_peel_off'
uipc_syscalls.o(.text+0x28e6):/usr/src/sys/kern/uipc_syscalls.c:2287: undefined reference to `sctp_do_peeloff'
rtsock.o(.text+0xb7d): In function `rt_newaddrmsg':
/usr/src/sys/net/rtsock.c:897: undefined reference to `sctp_addr_change'
in_proto.o(.data+0xa8): undefined reference to `sctp_input'
in_proto.o(.data+0xb0): undefined reference to `sctp_ctlinput'
in_proto.o(.data+0xb4): undefined reference to `sctp_ctloutput'
in_proto.o(.data+0xbc): undefined reference to `sctp_init'
in_proto.o(.data+0xc8): undefined reference to `sctp_drain'
in_proto.o(.data+0xcc): undefined reference to `sctp_usrreqs'
in_proto.o(.data+0xdc): undefined reference to `sctp_input'
in_proto.o(.data+0xe4): undefined reference to `sctp_ctlinput'
in_proto.o(.data+0xe8): undefined reference to `sctp_ctloutput'
in_proto.o(.data+0xfc): undefined reference to `sctp_drain'
in_proto.o(.data+0x100): undefined reference to `sctp_usrreqs'
in_proto.o(.data+0x110): undefined reference to `sctp_input'
in_proto.o(.data+0x118): undefined reference to `sctp_ctlinput'
in_proto.o(.data+0x11c): undefined reference to `sctp_ctloutput'
in_proto.o(.data+0x130): undefined reference to `sctp_drain'
in_proto.o(.data+0x134): undefined reference to `sctp_usrreqs'
*** Error code 1

Stop in /usr/obj/usr/src/sys/ME.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
[root@me /usr/src]#

The build completes, and works, fine if I leave in the INET6 option. But then I have the other issues.

If you need more info let me know (and thanks!)
 
remove options SCTP as well, you probably don't need that, or try updating your source to RELENG_7_1, I think that issue has been fixed there already.
 
danger@ said:
remove options SCTP as well, you probably don't need that, or try updating your source to RELENG_7_1, I think that issue has been fixed there already.
Click to expand...

Thanks, I didn't know about that dependency!

Kernel now recompiles fine, and everything works. tcpdump shows no more AAAA+ DNS requests, and Opera works like a dream. Wonderful stuff, thank you both.

Even better, this also solved issue #2 on my list. At boot there was a ~60 second pause prior to login while sendmail (I'm guessing) tried to resolve my hostname. I don't have a true domain, so my hostname is just 'me.local'. So a couple of more questions if you don't mind...

1. What is the recommended way to specify hostname is you're not part of a real domain?

2. Sendmail inbound daemon is disabled in /etc/defaults/rc.conf, but I'm assuming this is outbound, correct? If so, then I'd like to stop the requests going external (seemingly all the way to my ISP) if possible. I'd have thought my /etc/hosts would have solved that - no?

3. Is there a real need to have a sendmail daemon running at all?
 
mart said:
1. What is the recommended way to specify hostname is you're not part of a real domain?
Click to expand...
Specify it in /etc/hosts, though some mailservers will not trust that source. In that case, enable a local resolver and make named authoritative for name.local. Many tutorials for that on the web and has additional advantages.

]
2. Sendmail inbound daemon is disabled in /etc/defaults/rc.conf, but I'm assuming this is outbound, correct? If so, then I'd like to stop the requests going external (seemingly all the way to my ISP) if possible. I'd have thought my /etc/hosts would have solved that - no?
Click to expand...
Which requests do you mean? sendmail is used to send mail from your machine to the address the mail is sent to.
Search the web for smart-relay or smart-host + sendmail if you want to relay via your ISP.

3. Is there a real need to have a sendmail daemon running at all?
Click to expand...
To receive reports sent by cron(8) and periodic(7).
 
In the case of 3, that is the local daemon that only handles outbound email. it runs on 127.0.0.1 only.
 
Thanks for your replies, but I should have been clearer. I'll try again with some more info, and a large dose of speculation... :)


My machine (on 192.168.0.192) sits directly behind a router (on 192.168.0.1).

$ cat '/etc/hosts' # (as defined by sysinstall)
Code: 
::1                     localhost localhost.local
127.0.0.1               localhost localhost.local
192.168.0.192           me.local me
192.168.0.192           me.local.

$ hostname
Code: 
me.local

$ cat /etc/resolv # (as defined by sysinstall)
Code: 
domain     local
nameserver 192.168.0.1

$ sockstat -4 # (switched to openntpd)
Code: 
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS      
root     Xorg       1391  1  tcp4   *:6000                *:*
root     sendmail   895   4  tcp4   127.0.0.1:25          *:*
_ntp     ntpd       787   3  udp4   192.168.0.192:55647   142.201.7.148:123
_ntp     ntpd       787   5  udp4   192.168.0.192:52187   216.46.29.98:123
_ntp     ntpd       787   6  udp4   192.168.0.192:51446   24.215.0.24:123
_ntp     ntpd       787   7  udp4   192.168.0.192:52337   99.230.209.186:123
_ntp     ntpd       787   8  udp4   192.168.0.192:65502   72.51.27.50:123
root     syslogd    682   6  udp4   *:514                 *:*


I had two issues that were resolved by removing ipv6 from the kernel.

  • Opera requested AAAA+ DNS for all pages, before eventually falling back to A+, leading to long delays.
  • Sendmail had a long delay prior to login, that I had to Ctrl-c out of.
This leads me to speculate that sendmail was also using ipv6, and was failing to resolve my hostname internally and either timing-out, or going external (me->router->ISP), causing the long delay.

Now, if I understand correctly, my hosts file has a ipv6-style address for 'localhost', but not 'me' or 'me.local'. Is this what was screwing sendmail up? If so, that's bad. This is from a new install, and I'd imagine others would be running into similar issues.

So, back to my questions (and my attempts at answering them myself, please correct if you can...)

  • What is the recommended way to specify hostname (i.e 'name your machine') if you're not part of a real domain? i.e foo, foo.local, foo.myisp, foo.made.up.domain ...?

    ME: It doesn't really matter, so long as they can resolve internally for both ipv4 and ipv6.
For me, the issue was that ipv6 couldn't resolve internally. This is a BadThing. (Yes/No?)

  • How do I stop these requests making it out of my network?

    ME: Specify them correctly in /etc/hosts.
    Mel_Flynn: Better, enable a local resolver and make named authoritative for name.local
I see I have some more research to do...

  • If I'm not using this machine as a mail server (or ever planning on using sendmail for external mail), is there a real need to have a sendmail daemon running at all?

    ME: Yes, it's needed for admin, and only listens on localhost. Assuming you set up hostnames correctly (!) it shouldn't do anything outside the local network.

Corrections or insights, anyone? Go easy, as you can tell, I'm new to all this :)
 
For giggles, I reinstalled this test machine from scratch again. Practice makes perfect.

I kept everything simple, selecting default options etc. I selected 'yes' for ipv6 setup and DCHP. I left domain blank this time, and set hostname to 'bsddesktop'. I updated the kernel, but skipped pf config and openntpd for now (no real fear, it's a throw-away install and I'm behind a router). Xorg/Xfce/Opera etc installed through 'pkg_add -r'.

Ok. This is the new info (I'm still 192.168.0.192, router is still 192.168.0.1) ...

Code: 
[mart@bsddesktop /usr/home/mart]$ uname -a
FreeBSD bsddesktop 7.0-RELEASE-p6 FreeBSD 7.0-RELEASE-p6 #0: Mon Nov 24 06:43:33 UTC 2008     root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  i386

[mart@bsddesktop /usr/home/mart]$ sockstat -4
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS      
root     Xorg       934   3  tcp4   *:6000                *:*
root     syslogd    716   7  udp4   *:514                 *:*

[mart@bsddesktop /usr/home/mart]$ hostname
bsddesktop

[mart@bsddesktop /usr/home/mart]$ cat /etc/hosts
# comments snipped for brevity...
::1                     localhost localhost.my.domain
127.0.0.1               localhost localhost.my.domain

[mart@bsddesktop /usr/home/mart]$ cat /etc/resolv.conf
search MYISPNAME.net
nameserver 192.168.0.1
With this, sendmail initialization at login failed forever. The reason it's missing from sockstat is that I had to ctrl-c to actually login.

Code: 
[mart@bsddesktop /usr/home/mart]$ ping bsddesktop
ping: cannot resolve bsddesktop: Host name lookup failure
Ok, so I assume the correct solution is to add it hosts.

Code: 
[mart@bsddesktop /usr/home/mart]$ cat /etc/hosts
# comments snipped for brevity...
::1                     localhost localhost.my.domain
127.0.0.1               localhost localhost.my.domain
127.0.0.1               bsddesktop

[mart@bsddesktop /usr/home/mart]$ ping bsddesktop
PING bsddesktop (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.054 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.029 ms
...
Reboot to see if this resolves the sendmail issue... Nope, but at least we eventually time-out now, with a different result - 'My unqualified host name (bsddesktop) unknown; sleeping for retry'.
Code: 
[mart@bsddesktop /usr/home/mart]$ cat /var/log/maillog 
Dec  4 16:47:47 bsddesktop newsyslog[657]: logfile first created
Dec  4 16:48:48 bsddesktop sm-mta[790]: gethostbyaddr(192.168.0.192) failed: 2
Dec  4 16:48:48 bsddesktop sm-mta[791]: starting daemon (8.14.2): SMTP+queueing@00:30:00
Dec  4 16:49:33 bsddesktop sm-msp-queue[795]: starting daemon (8.14.2): queueing@00:30:00
Dec  4 16:58:16 bsddesktop sm-mta[797]: gethostbyaddr(192.168.0.192) failed: 2
Dec  4 16:58:16 bsddesktop sm-mta[798]: starting daemon (8.14.2): SMTP+queueing@00:30:00
Dec  4 16:59:01 bsddesktop sm-msp-queue[802]: starting daemon (8.14.2): queueing@00:30:00
Dec  4 17:28:48 bsddesktop sm-mta[817]: My unqualified host name (bsddesktop) unknown; sleeping for retry
Dec  4 17:36:53 bsddesktop sm-mta[830]: My unqualified host name (bsddesktop) unknown; sleeping for retry
So, with the default install it failed on 'gethostbyaddress'. Understandable, I guess. After adding my hostname to /etc/hosts we get a long timeout, followed by 'unqualified host name; sleeping for retry'. Which is semi-understandable. I don't have a qualifed hostname to give it, just what this machine is known as on the local network, i.e. my hostname. That's as far as I've gotten with sendmail, but wanted to capture the info before I go blindly changing things.

Now, back to the main issue - AAAA DNS woes. Remember this is a default install, unmodified kernel (i.e. with ipv6)...

Here's a log of DNS traffic, trying to go to 'www.itv-f1.com' from within Opera, deperately trying to find out why Honda are leaving F1...

Code: 
[mart@bsddesktop /usr/home/mart]$ sudo tcpdump -i sk0 port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on sk0, link-type EN10MB (Ethernet), capture size 96 bytes
18:30:46.891332 IP 192.168.0.192.51563 > 192.168.0.1.domain: 50324+ AAAA? www.itv-f1.com. (32)
18:30:47.082641 IP 192.168.0.1.domain > 192.168.0.192.51563: 50324 0/1/0 (95)
18:30:47.083064 IP 192.168.0.192.50071 > 192.168.0.1.domain: 50325+ AAAA? www.itv-f1.com.MYISPNAME.net. (45)
18:30:47.134871 IP 192.168.0.192.58585 > 192.168.0.1.domain: 39899+ PTR? 1.0.168.192.in-addr.arpa. (42)
18:30:52.082367 IP 192.168.0.192.64824 > 192.168.0.1.domain: 50325+ AAAA? www.itv-f1.com.MYISPNAME.net. (45)
18:30:52.135242 IP 192.168.0.192.58585 > 192.168.0.1.domain: 39899+ PTR? 1.0.168.192.in-addr.arpa. (42)
18:31:02.082368 IP 192.168.0.192.53352 > 192.168.0.1.domain: 50325+ AAAA? www.itv-f1.com.MYISPNAME.net. (45)
18:31:02.136393 IP 192.168.0.192.60036 > 192.168.0.1.domain: 39900+ PTR? 192.0.168.192.in-addr.arpa. (44)
18:31:07.137264 IP 192.168.0.192.60036 > 192.168.0.1.domain: 39900+ PTR? 192.0.168.192.in-addr.arpa. (44)
18:31:08.082647 IP 192.168.0.1.domain > 192.168.0.192.50071: 50325 NXDomain 0/1/0 (96)
18:31:08.134669 IP 192.168.0.1.domain > 192.168.0.192.58585: 39899 NXDomain* 0/1/0 (105)
18:31:22.083323 IP 192.168.0.192.52809 > 192.168.0.1.domain: 50325+ AAAA? www.itv-f1.com.MYISPNAME.net. (45)
18:31:23.135471 IP 192.168.0.1.domain > 192.168.0.192.60036: 39900 NXDomain* 0/1/0 (107)
18:31:43.083113 IP 192.168.0.1.domain > 192.168.0.192.52809: 50325 NXDomain 0/1/0 (96)
18:31:43.083521 IP 192.168.0.192.52350 > 192.168.0.1.domain: 50326+ A? www.itv-f1.com. (32)
18:31:43.302093 IP 192.168.0.1.domain > 192.168.0.192.52350: 50326 1/2/0 A 83.98.74.146 (98)
18:31:44.138457 IP 192.168.0.192.60690 > 192.168.0.1.domain: 39901+ PTR? 146.74.98.83.in-addr.arpa. (43)
18:31:44.248550 IP 192.168.0.192.59758 > 192.168.0.1.domain: 50327+ AAAA? www.itv.com. (29)
18:31:44.408492 IP 192.168.0.1.domain > 192.168.0.192.59758: 50327 2/1/0 CNAME[|domain]
18:31:44.408745 IP 192.168.0.192.60731 > 192.168.0.1.domain: 50328+ A? www.itv.com. (29)
18:31:44.413778 IP 192.168.0.1.domain > 192.168.0.192.60731: 50328 4/9/0 CNAME[|domain]

... SNIP ...

18:33:56.850337 IP 192.168.0.192.63654 > 192.168.0.1.domain: 50356+ A? pix04.revsci.net. (34)
18:33:57.005251 IP 192.168.0.1.domain > 192.168.0.192.63654: 50356 2/4/0 CNAME[|domain]
^C
92 packets captured
2162 packets received by filter
0 packets dropped by kernel
Ugh, an epic 3mins to load the main page. The AAAA requests take an age, but after they've failed, the A requests fill quickly as expected. The 1st request alone takes a full minute. The 'websitename.myispname.net' requests look really odd to my uneducated eye, as in 'I couldn't find AAAA websitename, so trying the searchpath listed in resolv.conf, i.e 'websitename.MYISPNAME.net'. Which seems about as wrong as can be, but that's what is set up from a default install. I'm pretty sure that If I bypass DHCP like in my 1st install (where resolv.conf had 'domain local'), it would have been asking for 'websitename.local' through my router->ISP - i.e. equally wrong).

So. It seems like I have two distinct issues, that are both 'fixed' by removing ipv6 from the kernel. I'm sure this is all rather obvious to the network-savvy, but I can't explain why. That bugs me, and goes against the very reason I arrived at the BSDs in the first place :)

I'm going to go learn how to decipher the tcpdump report correctly now (rather than assuming), but if anyone has any insights in the meantime I'd love to hear them...
 
Your issue is not with your local machine, but with your nameserver.
Even with IPv4 stack only, you will still do IPv6 lookups, because ISC thinks people should get with the program and fix their broken nameserver (you can talk semantics about why this is good or bad, but it boils down to this).
There's extensive threads about this issue all over the net, dating back from the 4.x days.
 
Mel_Flynn said:
Your issue is not with your local machine, but with your nameserver.
Click to expand...

Thanks Mel. I'm sure you know more about this stuff than I ever will, but I'm convinced something must be wrong with the way I'm doing things.

Within the last week I've connected to the same ISP, through the same router, with the same router->ISP config, from OSX (Tiger & Leopard, wired & wireless), Fedora (9 & 10, wired & wireless) and Ubuntu (8.04 & 8.10, wireless). All without issue. I've been playing with FreeBSD for a couple of days, learning as I'm going, but am far from confident about my configuration.

Code: 
Even with IPv4 stack only, you will still do IPv6 lookups
Again, I'm sure you're right, but when I tried it (see earlier in the thread), it fixed my issues. tcpdump showed no more IPv6 lookups. It's an ugly solution though, and I'd prefer to play by the new rules (hence trying again), I just need to understand them a bit better :)

What bugs me more than anything is the current lookups feel like I'm spamming my ISP with names it could never hope to resolve. It's ugly, and surely something I should be able to configure correctly on my side, ideally without having to setup and maintain a local DNS - this is a single desktop.

Thanks again. I'll add the posts you mention to my ever growing reading list...
 
If I recall correctly, the issue is that FreeBSD implements an unmodified ISC resolver into libc. Firefox overrides it with it's own implementation.
It's possible linux has a different implementation, that like Firefox does no IPv6 lookups unless requested.
For a resolver, 'maintaining a local nameserver' sounds far more invasive then it really is. Since it's likely your ISP's nameservers are buggy, it's really easy to set it up and let it query nameservers around the world itself. Once configured, there's no maintenance, only if you keep a local domain and add/remove machines, which is edit 2 lines in a file, save and /etc/rc.d/named reload.
The initial setup consists of:
  • add named_enable="YES" to /etc/rc.conf
  • in /etc/namedb/named.conf, setup the correct listen-on option
  • remove a multi-line comment as indicated with "To use this mechanism, uncomment the entries below, and comment the hint zone above."
  • save named.conf
  • /etc/rc.d/named start

It does puzzle me though, why it did work for a while, but not enough to dig into it. IPv6 is inevitable, just not as fast as ISC wants us to believe.
 
Mel_Flynn said:
For a resolver, 'maintaining a local nameserver' sounds far more invasive then it really is.
Click to expand...

Thanks again Mel, your replies are really helping - giving enough clues for me to dig into things with a bit more confidence. Your initial mail already had me looking into a local resolver, and the more I read, the more benefit I see in doing so. It just seemed odd to have run into such a basic issue, so early. The other issues I've run into have, touch wood, been a joy to resolve (no pun intended). But these two were icky, and had me convinced I'd done something fundamentally wrong. Perhaps I have, but I'll try setting up a local resolver now to work around it. Maybe doing so will highlight what I did wrong in the first place :)

So, from a quick read around, everything's already built-in and ready to go (named/bind). Or, I could go directly to something (perhaps) more useful to me on a single-user desktop - something like dnsmasq that appears to cache queries. The tcpdump output I've been looking at has made me queezy. Cutting down on that spam at the same time seems worthwhile.

More reading to do, then I'll dive in.

BTW:

Code: 
It does puzzle me though, why it did work for a while, but not enough to dig into it.
If you mean why things started working for me, then it wasn't 'for a while' - it was permanently. I had that custom 'no-ipv6' kernel running for a full day or so, and didn't see a single AAAA request. It also fixed the sendmail issue, although I'm less sure as to exactly 'why' with that one. It only stopped working when I did a clean install, and kept a generic 'with-ipv6' kernel. Having a custom kernel felt like I was cheating, so here I am trying to fix things the right way... :)
 
sendmail would have been waiting to complete a reverse lookup on your IP address. sendmail wants to know what the world believes your machine is called.

These two commands should provide answers quickly. If not, then we need to fix them.
host `hostname`
host (the ip address returned by the above)
Setting up a hosts file should fix this, but dhclient is overwriting resolf.conf, preventing (I think) the system from checking the hosts file. Here's a tip, though: Put this in /etc/dhclient.conf. Your machine will them send it's hostname to the modem/router, which will put it into its dns server, and things will start happening:
Code: 
 send host-name "bsddesktop";
(Note to others: It seems that the ip6-broken dns server is in his modem-router. Those things are pretty random in their behavior!)
 
robbak said:
These two commands should provide answers quickly. If not, then we need to fix them.
host `hostname`
host (the ip address returned by the above)
Click to expand...

Thanks robbak, here goes...

Code: 
[mart@bsddesktop /usr/home/mart]$ hostname
bsddesktop
[mart@bsddesktop /usr/home/mart]$ host -v `hostname`
Trying "bsddesktop.MYISPNAME.net"
;; connection timed out; no servers could be reached
[mart@bsddesktop /usr/home/mart]$ host -v bsddesktop    
Trying "bsddesktop.MYISPNAME.net"
;; connection timed out; no servers could be reached
[mart@bsddesktop /usr/home/mart]$ host -v localhost
Trying "localhost.MYISPNAME.net"
;; connection timed out; no servers could be reached
[mart@bsddesktop /usr/home/mart]$ host www.google.com
www.google.com is an alias for www.l.google.com.
www.l.google.com has address 209.85.173.104
www.l.google.com has address 209.85.173.147
www.l.google.com has address 209.85.173.99
www.l.google.com has address 209.85.173.103
[mart@bsddesktop /usr/home/mart]$ host ipv6.google.com
ipv6.google.com is an alias for ipv6.l.google.com.
ipv6.l.google.com has IPv6 address 2001:4860:0:2001::68
Oooh, a new toy to play with!

After making your dhclient change and rebooting I get this...
Code: 
[mart@bsddesktop /usr/home/mart]$ cat /etc/dhclient.conf 
# $FreeBSD: src/etc/dhclient.conf,v 1.3 2001/10/27 03:14:37 rwatson Exp $
#
#       This file is required by the ISC DHCP client.
#       See ``man 5 dhclient.conf'' for details.
#
#       In most cases an empty file is sufficient for most people as the
#       defaults are usually fine.
#

send host-name "bsddesktop";

[mart@bsddesktop /usr/home/mart]$ hostname
bsddesktop
[mart@bsddesktop /usr/home/mart]$ host -v `hostname`
Trying "bsddesktop.MYISPNAME.net"
;; connection timed out; no servers could be reached
[mart@bsddesktop /usr/home/mart]$ host -v bsddesktop
Trying "bsddesktop.MYISPNAME.net"
;; connection timed out; no servers could be reached
[mart@bsddesktop /usr/home/mart]$ host -v localhost
Trying "localhost.MYISPNAME.net"
;; connection timed out; no servers could be reached
[mart@bsddesktop /usr/home/mart]$ host www.google.com
www.google.com is an alias for www.l.google.com.
www.l.google.com has address 209.85.173.147
www.l.google.com has address 209.85.173.99
www.l.google.com has address 209.85.173.103
www.l.google.com has address 209.85.173.104
[mart@bsddesktop /usr/home/mart]$ host ipv6.google.com
ipv6.google.com is an alias for ipv6.l.google.com.
ipv6.l.google.com has IPv6 address 2001:4860:0:2001::68
[mart@bsddesktop /usr/home/mart]$
So, no fix I'm afraid, but hopefully getting closer. As for ordering, isn't that determined by nsswitch.conf and host.conf?

Code: 
[mart@bsddesktop /usr/home/mart]$ more /etc/nsswitch.conf 
#
# nsswitch.conf(5) - name service switch configuration file
# $FreeBSD: src/etc/nsswitch.conf,v 1.1 2006/05/03 15:14:47 ume Exp $
#
group: compat
group_compat: nis
hosts: files dns
networks: files
passwd: compat
passwd_compat: nis
shells: files
services: compat
services_compat: nis
protocols: files
rpc: files

[mart@bsddesktop /usr/home/mart]$ more /etc/host.conf
# Auto-generated from nsswitch.conf
hosts
dns

(Note to others: It seems that the ip6-broken dns server is in his modem-router. Those things are pretty random in their behavior!)
Click to expand...

Wired, GigE connection, to Dlink-655, latest firmware (1.21). I haven't changed the config in a long time, but let me know if there's anything you think I should try. Willing to be a guinea pig, it's a throw-away install and I have the time and interest to get to the bottom of this...

Thanks for the extra clues btw.


Edit: I didn't try the address by IP (because I didn't get one), but here's what I get for 127.0.0.1 and 192.168.0.192 (my assigned IP according to ifconfig)...
Code: 
[mart@bsddesktop /usr/home/mart]$ host -v 127.0.0.1
Trying "1.0.0.127.in-addr.arpa"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47652
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;1.0.0.127.in-addr.arpa.                IN      PTR

;; ANSWER SECTION:
1.0.0.127.in-addr.arpa. 43200   IN      PTR     localhost.

;; AUTHORITY SECTION:
0.0.127.in-addr.arpa.   43200   IN      NS      ns1.MYISPNAME.com.

Received 97 bytes from 192.168.0.1#53 in 25 ms
[mart@bsddesktop /usr/home/mart]$ host -v 192.168.0.192
Trying "192.0.168.192.in-addr.arpa"
;; connection timed out; no servers could be reached
 
robbak said:
Your machine will them send it's hostname to the modem/router, which will put it into its dns server, and things will start happening:
Code: 
 send host-name "bsddesktop";
Click to expand...
If you want a local resolver and have no control over your DHCP server, then you need this in /etc/dhclient.conf:
Code: 
interface "bfe0" {
        prepend domain-name-servers 127.0.0.1;
        supersede domain-name "example.com";
}
 
Update: I now have everything working perfectly.

Issue #1 -- Sendmail. This was fixed by changing the order of the names in /etc/hosts set by the default install. I don't feel very comfortable changing the way the default install does something, but it seems like a logical change to me. The default install has localhost.my.domain listed as an alias for the 'official host name' localhost, the opposite of what you'd expect, and the opposite of it's own example for an 'imaginary network'. An alias should be interchangeable, but perhaps sendmail is extra fussy.

My hosts file now looks like this
Code: 
::1          localhost.localdomain localhost bsddesktop
127.0.0.1    localhost.localdomain localhost bsddesktop
Notice the change in order for localhost. Changing the order, and adding my hostname 'bsddesktop' as an additional alias fixed things. Sendmail doesn't pause/hang/retry any more, and /var/log/maillog shows all is fine. Local mail is now being delivered and can be read via mail/mutt. All other apps seem to respect this change - no knock-on issues at all. I'm confused as to why others haven't run into this.

Issue #2 -- AAAA DNS. robbak's hint that my router was the likely fail point got me thinking, searching and reading again. I swapped out the dlink for an older linksys router, and what do you know, no more AAAA DNS delays. The dlink was a replacement router sent after my old one died, and it came preloaded with the latest firmware. I did a full wipe of all settings, reinstalled the firmware from scratch, and reconfigured to the same settings. No more issues. Grrrr.

So, both issues fixed without needing to disable ipv6, or make custom kernels. My rc.conf even proudly states 'ipv6_enable="YES"'. I also installed dnsmasq and configured it as a local DNS cache (modifying my dhclient to prepend 127.0.0.1 before trying my ISP's nameservers). The logs are _much_ cleaner now, and safari seems snappier. Oh wait, wrong OS, wrong forum :)

The irony? After I got my network issues fixed I ended up going back to firefox3 anyway. After updating my system to the latest ports I realized firefox3 would only pull in one or two additional dependencies.

Thanks to all who helped me through this. I learnt a lot, and ended up with a nicer system because of it. Now to figure out what's up with my soundcard. And jails. And ZFS. And Geli. And Jails in Geli ZFS's.
 
You must log in or register to reply here.
Back
Top