Subject: [dnsop] Questions about IPv4 or IPv6 DNS server

From: Blue <[email-masked]>
Date: Tue, 31 Oct 2006 15:10:42 +0800

Hi, all:

Currently a dual-stack device could get both IPv4 and IPv6 DNS server
list from either manually configuration or DHCPv4/v6. Is there any
regulation about the querying sequence when a DNS client wants to invoke
a query? I have dug into the RFC database and could not find any
documents concerning about the question. Or it's just an implementation
issue?

Best regards,

Yi-Wen
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 31 Oct 2006 16:34:21 +0000

> documents concerning about the question. Or it's just an implementation

Like any IPv4 -> IPv6 transition mechanism: first try IPv6, then try IPv4.

At least that is how the RFC's specify it (don't ask me which one, but
one of them does ;)

There is one problem with this though: lets take a dual stacked host A,
it has IPv4 and IPv6 connectivity, but IPv6 is broken, the host wants to
go to a dual-stacked webserver, it tries to connect over IPv6, it times
out (no icmp coming back for whatever reason), and tries IPv4. Thus it
does reach the server, but after a timeout. If you thus have a user,
they will percieve it as a crappy network and might go somewhere else.
As such, depending on the application and where it will be deployed it
might be smarter to have an option of enabling IPv6 later. IMHO it would
still have been good to have a OS/user-global way to specify this. Some
dns-resolver libraries support this actually.

The real solution to this problem is of course to simply turn of IPv6 or
to fix the network ("ip -6 ro add <prefix>/32 dev lo" helps ;). Of
course it might also happen the other way around: broken IPv4 but
working IPv6. But at the moment there are IPv6 'networks' which are very
crappily maintained and then those circumstances happen, the user will
then only say one thing: IPv6 sucks... as that is how they perceive it.
Can't blame them for that now can we. When thus having an IPv6 enabled
network, also make sure one actually manages it, the same as IPv4.

Note that several browsers have for that exact reason an option to have
IPv4 go first and then do IPv6 later. The default Mac OS X browser does
that for instance, and Opera also has afaik at least the option.

DNS uses round-robin and server selection in quite some implementations
anyway, as such in the case of DNS this should not give a big problem.
Giving the user the option to choose is always a good thing.

Greets,
 Jeroen

---

From: Edward Lewis <[email-masked]>
Date: Tue, 31 Oct 2006 11:41:11 -0500

>documents concerning about the question. Or it's just an implementation

It's mostly an implementation issue.  There are some conventions 
though - like not flooding servers with queries while waiting.

As far as whether to prefer IPv6 or IPv4, that's a "personal" 
decision.  One popular belief is try IPv6 first because that's the 
new thing in town, but there can be some bad experiences doing that. 
For instance, you may have IPv6 locally and at the server, but the 
IPv6 routing is not complete between the two.

As far as the protocol and system are concerned, it is customary to 
have a time out of a few seconds to allow a server to respond to a 
first query before assuming the query has gotten lost.  You want to 
avoid having a server get a query twice if the first response 
eventually does get back to the client because the second query and 
it's handling is pure bad overhead.

A good strategy for query management can improve performance.  There 
might be a tradeoff of what is an improvement - sometimes what is 
good for a client is not good for the servers.  It's not always clear 
what is the best thing for all involved.

I have seen bad clients cause problems for the network.  Even though 
a deficient design can cause problems, trying to reach a consensus of 
what is the right thing to do is not easy.  This is why there is no 
regulation, no standard.

You might look at RFC 1034, section 6.3.1 for a sort-of standard 
mention of how a client (resolver) should behave.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Secrets of Success #107: Why arrive at 7am for the good parking space?
Come in at 11am while the early birds drive out to lunch.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Edward Lewis <[email-masked]>
Date: Tue, 31 Oct 2006 13:55:37 -0500

>Like any IPv4 -> IPv6 transition mechanism: first try IPv6, then try IPv4.

There is the option to try both simultaneously.  A query for the A RR 
can be sent in parallel to the AAAA RR.  This is better from the 
point of view of the application user, there isn't a need to wait for 
a time out.  On the other hand, this makes the application 
developer's job harder - having to juggle two potential answers and 
connections starting up (assuming TCP).

If you try IPv6 first, if IPv6 is available then the new technology 
will be used.  However, there have been recommendations  (I found a 
few just by googling for "disable ipv6") saying that to improve 
performance, disable IPv6.  Then you will fall back to the more 
deployed and tested technology.

I can attest that there have been times in which disabling IPv6 at 
some conferences led to better networking performance.  (Yes, I know 
I could reported this to the conference NOC, but my mission was to 
get some information, not play with a new technology.)  Only because 
of that experience do I no longer agree that one should always try 
IPv6 (or any new technology) first.

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 01 Nov 2006 03:38:17 +0000

Edward Lewis wrote:
> can be sent in parallel to the AAAA RR.

That depends if you are talking about asking for A + AAAA records or
talking about using IPv4 or IPv6 as a transport to ask these questions.
Both can be done in parallel of course, but that would cause quite some
unnecessary traffic and also most likely when everything is working fine
, dupes.

[..]
> I can attest that there have been times in which disabling IPv6 at some
> conferences led to better networking performance.  (Yes, I know I could
> reported this to the conference NOC, but my mission was to get some
> information, not play with a new technology.)  Only because of that
> experience do I no longer agree that one should always try IPv6 (or any
> new technology) first.

Which is why I noted that one should nullroute crappy networks on the
local host to easily resolve this issue ;)

Greets,
 Jeroen