Can you change this:
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

to

hosts: files dns mdns4_minimal [NOTFOUND=return]

May be this can help, because everything else exactly what I have.
And can you tell, how many programs really use IPv6 dns query?

I changed /etc/nsswitch.conf to:and now things break. Here's on example:I was looking through the backup history of another machine. I made full backups of that machine at every step along the way of installing Ubuntu, upgrading it, adding packages, and so on. I found that the initial contents for /etc/nsswitch.conf was different and got changed at some point. I do not remember exactly what I did at that point, but if needed, I could examine the backup contents and try to figure out what had been done:So I replaced /etc/nsswitch.conf with that old contents:But even this does not change anything:

You know, right now I boot to Fedora 12, where I have IPv6 and IPv4 enabled. And have done the same things:
telnet www.yandex.ru 80

18:22:11.020068 IP 192.168.2.5.44803 > 192.168.2.1.53: 51293+ A? www.yandex.ru. (31)
18:22:11.020078 IP 192.168.2.5.44803 > 192.168.2.1.53: 12001+ AAAA? www.yandex.ru. (31)

I use local cache/dns, but it doesn't make any difference. My telnet sends first A and then AAAA request.

So, I think, you have found new and one more bug.

About single-request:

It's a feature added in glibc 2.10 and it's supposed to improve dns resolution by selecting whichever protocol (ipv4 or ipv6) works better.

Regards

I've tried various options on BIND to see if I could change the order of the A versus AAAA queries (or eliminate it altogether), and never saw anything other than the default behavior. One cannot completely disable AAAA queries, even if you compile a kernel without it, IPv6 code is embedded in glib as I recall. Unless you are actually running a DNS server, the options aren't going to do anything. You mention a version of bind, but are you using the associated libraries that are probably needed for name resolution, or are you running a DNS server? (don't bother answering that -- I actually *read* the thread this time) I've got Ubuntu 9.10 running, and see various bind9 libraries installed, but the bind server itself isn't. I do have that exact version of bind installed on a laptop that I used for testing on a Slackware system, however.

If one wants to spend some time sifting through the joys of IPv6 and BIND behavior, they should read this:

http://www.linuxquestions.org/questi...e-13.0-775376/

The last 2.5 pages are a little more informative. That situation was one where a DSL modem/wireless device was defective, but the underlying troubleshooting would suit this situation well enough.

Although we couldn't prove it outright, it appeared that when AAAA records were requested first, the response was always 1.0.0.0 for the A record. It was pretty bizarre.

Skaperen, is there an actual issue with this? I have seen the AAAA record request being sent first on my systems, and never perceived any performance degradation. It seldom happens on my systems, however.

If you find a solution for forcing A record requests first, I'd appreciate that info. It's not as if I need it, but it's more of a curiosity thing.

***EDIT -- I just read your post a little more closely, bathory, and see now that it was intended for resolv.conf, rather than the bind configuration file, where there was a similar option I tried. I'll give that a try to see if there is any difference in my queries.

Be sure to see UPDATE at the end of this post.

I don't believe I need to disable IPv6. If a "solution" does that, I don't consider it viable. It would break what I want to do with local hosts on IPv6.

I am running a DNS caching server. It's on two other machines, soon to be three. Other machines, such as my laptop, which I did the various commands on in this thread, and monitored the DNS queries from headed over to the DNS server, may or may not run local DNS caching servers.

I gave the version of bind in belief that the matching library version is what is operating as the resolver. The command "dpkg -l | grep bind9" showed a few packages with the same version.

Looks like something I might use at home when I convert my Slackware 12 system to Slackware 13 while upgrading it to 64-bit.

That sounds more bizarre than my problem.

Yes, there is. If a hostname has both AAAA and A records, the lookup will favor the AAAA record, causing applications like telnet, and presumably Firefox, to try to connect to the IPv6 address. Because there is no working IPv6 route to the internet from my LAN, that connection will not succeed, and the application will stall until the timeout period ends and all connection retries are exhausted.

At that point, if the application is coded to do so, it could presume that it's just an IPv6 failure and make a specific request to the resolver to get ONLY an A record and try to make the IPv4 connection. I don't know how many applications know to do this. I'm not even sure the resolver library has the means to be asked for just A records or just the inet4 family address.

Anyway, the problem (when dealing with hosts that have both A and AAAA records) at best will be a time delay making connections, and at worst no connection at all.

There will be a problem with the reverse, too. Consider a user on a network some day in the future that provides ONLY IPv6 connectivity ... why? ... because IPv4 will have run out and newer networks will be limited to just IPv6. If a query is made for a host that does have both A records and AAAA records, and that query asks for the A record first, the application will have a similar timeout trying to make an IPv4 connection.

UPDATE

I am at home now, where I have a spare netbook I can reboot as desired without work loss, and even re-install without data loss, if needed. I just booted up Ubuntu 9.10 desktop in Live mode (from a USB memory stick written using dd with an image I created). I supplied my WLAN credentials to it to get net access. I ran tcpdump to watch the port 53 traffic, and ran the same "telnet www.ham.org 99" command as earlier at work. There were two queries instead of three, without the one that had the local domain appended (there isn't one on the Live Ubuntu). The query for AAAA came first and the query for A came second.

So it appears to be something Ubuntu or maybe Debian did.

And you could probably reproduce this without having to install Ubuntu.

I had posted this same issue on the ubuntuforums.org site, which so far has 59 views and 0 responses. I suppose I will need to file a bug report, and check the 10.04 Alpha to see if it also does the same thing.

FYI, I don't care what the default is. But there needs to be an administrative control knob to change whether it is "A then AAAA" or "AAAA then A" since both ways have failure scenarios. It would have been better if the DNS protocol had added a special record type just for queries that means "give me both A and AAAA" that would have behaved different than the "ANY" (which is the wrong way to get both A and AAAA since if partial data is cached, it only gives what is cached and does not go to the authoritative server for the other records).

Maybe I should have a look at Fedora. I used it at my previous job, and aside from an occasional severe hosing of yum, I was happy with it. That was Fedora 8, and hopefully that issue has been corrected by now. But I'll probably have to figure out a different way to build a bootable flash memory stick or memory card drive image than I did with Ubuntu and Easypeasy which was based on casper (note, this was a process to build an image, NOT copy files to a FAT drive that unetbootin does).

I have just checked it you, on Fedora 12. Please, look at my post: #18 on this page

I've been capturing the DNS traffic from my Ubuntu 9.10 laptop to the Vyatta firewall/router that has dnsmasq set up, and does the querying for the network here.

I've seen one AAAA record query in the last 2.5 hours, out of how many total, I am not sure. The file I am dumping tcpdump into is around 400K, although it is a little more detailed a capture, it's still singularly port 53 though.

Hmmnn...my environment doesn't quite match yours, obviously, as I do not have IPv6 addresses assigned. Perhaps I'll set up the dhcp server for IPv6, but that probably won't be until tomorrow. I'm almost out to the door to go hang out with some friends at the bar.

I've got another vyatta router set up that I might use for testing. I have zero experience with IPv6, but what the hell. I also have another laptop with Ubuntu 9.10 installed too, so I can somewhat emulate your environment.

devwatchdog...

I have noticed that if I unconfigure all the Scope:Global IPv6 addresses from all interfaces, I don't see queries for AAAA records ... at least on installed systems. The live CD system was an exception. Try manually configuring a static temporary ULA IPv6 address:nimnul22...

Yes, I saw that. That's why I may have a look at Fedora. As things are going, it would not be Fedora everywhere. But maybe on my desktop.

I did set up an address (ifconfig command you provided didn't work for me) that I found on Linux IPv6 HOWTO that provided this:

And you'll never guess what is happening, Skaperen! All the DNS qeuries are sending AAAA records first. This thing is a freak o' nature I tell ya!

heh.

Not terribly surprising I suppose. At least we're consistent. I did add the option that bathory suggested to resolv.conf, and I'm still seeing the same behavior.

After more or less going down this road in that other thread I posted, where trying to figure out how to force the A record query first proved to be futile. I'll take another spin through documentation and see if I can find something that works.

I'm not so sure that these are actual bugs per se. The inability to dictate the order is a PITA, but I would think it would take a spin through the RFC documents to determine if the behavior we see is outside of the standards.

I might set up some IPv6 networking here as well to gain some knowledge. I'll be working with it at one point or another, and potentially soon. After reading through some of the documentation, I'll admit I have plenty to learn about it. Something that I found curious was that there is no longer arp traffic in IPv6.

Anyhow, I'll see if I can find something to solve the ordering issue.

If you don't have internet IPv6 connectivity, then hope that your router will at least give you a network unreachable return packet so the application will quickly revert to IPv4.

My read of the RFCs was that administrative control was required. If it isn't the default, having "options inet6" in /etc/resolv.conf would satisfy that requirement. Making it the default without an option to change it would not.

It looks like the "something" that solves the ordering issue is Fedora or Slackware. I'm sure a few others will, too.

Despite all this thread, it really isn't that big of an issue. I can manage my own network to make sure IPv6 to undeployed and unrouted networks gets the appropriate negative response. I'm NOT annoyed that Ubuntu or Debian packagers decided to alter this (eventually everyone needs to do this). Instead, I am annoyed that a way to set it to IPv4 (how about "options inet4" or "options noinet6") was not also added in when they changed the default. Better, yet, I'd prefer to see "options inet4-only" and "options inet6-only" and "options inet4-inet6" and "options inet6-inet4".

I see this as a bug and see adding the options as the best fix.