V novi izdaji Ubuntu distribucije Linuxa 9.10 operira resolver library kot da bi imel v /etc/resolv.conf zapisano “options inet6”, kar pomeni da resolver vpraša DNS najprej po AAAA zapisih, potem pa šele za A zapisi…

Kaj to natančno pomeni? Resolver ponavadi ne izvede vprašanja ANY, ker bi to pomenilo da dobi samo odgovore iz cache-a, ampak tipično izvede dva query-ja, A in AAAA. V Ubuntu distribuciji ni možnosti povrniti “legacy” način delovanja, da bi najprej vprašal za A in nato za AAAA, ni opcije “options inet4” ali “options inet”, zaradi česar so nekateri zelo nesrečni.

Če imamo urejeno IPv6 povezavo, potem je to ok in nam ne povzroča problemov, če je pa nimamo in dobimo od resolverja vrnjen AAAA zapis, hkrati pa nimamo IPv6 povezljivosti, se pojavijo dolgi premori, preden sistem preklopi na IPv4 in A zapise. O tem so se razpisali na Linked-IN IPv6 grupi, ker verjamem da niste vsi vanjo včlanjeni bom tu naredil copy/paste:

Ubuntu DNS queries default to AAAA before A records.

In Ubuntu 9.10, the resolver library operates as if “options inet6” were specified in “/etc /resolv.conf “, even though it isn’t. In Fedora and Slackware, it operates as expected, querying A records before AAAA records.

So what’s the problem with that?

The problem is, the resolver library lacks a way to revert the configuration. There is no “options inet4” or “options inet” that could cause the legacy behavior. Since DNS has no specific way to query “either AAAA or A records” in one query (the ANY query cannot do this because it would deliver only what is cached, if anything is cached), one has to make separate queries for AAAA records and A records to be sure of getting them.

Either order of query poses problems. Which problems you get depends on whether you need to have IPv6 and whether you have full connectivity. If, for example, you only have a small thin tunnel to serve a large organization that is using an OC-3 for IPv4 traffic, you don’t want to prefer IPv6 over IPv4 for everyone (the network admins might be the exception). What you would want is control over whether the queries are “AAAA before A” or “A before AAAA”. Normally you’d start with “A before AAAA” then transition to “AAAA before A” (and some day in the future maybe “AAAA only”).

The point is, you need administrative control. The resolver library (in the BIND package) does this based on using “options inet6” or not. Ubuntu 9.10 breaks this and takes away administrative control. The only way to undo the mess is to disable IPv6 completely. And that’s not a good idea. That’s certainly not a way to smooth out the transition.

I don’t have any internet IPv6 connectivity, yet. In the mean time I’m making sure as much IPv6 works as I can make work within my LAN using a /64 subnet of a /48 slice of ULA addresses. But every Ubuntu desktop and server we have (all are on 9.10 right now) is querying for AAAA before A because of this. Almost nothing has AAAA records, so the queries generally quickly fail (it does TWO such queries, appending the search domain the 2nd time, and failing that, too) and the A record is tried.

Now if some site has AAAA records, then we have a problem. The AAAA lookup succeeds, and a connection attempt is made for the IPv6 address. It just hangs without a response because there is no router that supports IPv6 (our core router is a Sonicwall E6500 firewall which has no IPv6 support … shame, shame, shame … I will recommend something else when we get to the point of needing something more). The gateway is a Cisco 2851 which has no stock IPv6 support. I’ve been told it can be added, but am still in the process of trying to figure that one out (but it won’t help right now because IPv6 traffic doesn’t even get to that router, yet).

If I get a tunnel, all traffic that can be done via IPv6 will be done via IPv6 (because Ubuntu gives us no option to not do so), and we’d have to make sure the tunnel can handle that. Hopefully we’ll have real IPv6 routability before there are too many AAAA-record enabled sites that would exceed what load we can reasonably put on a tunnel.

The question:

Anyone know a workaround for Ubuntu’s goof on the resolver default? So far the only suggestion I’ve gotten is to completely disable IPv6 in the Linux kernel boot command line arguments. I’ll pass on that.

Vaš IP naslov (ali ste na IPv6 ?):
52.14.1.136

Comments(0)