Consensus on MHAP/v6 Multi-homing

[Jeroen Massar]

On Wed, 2005-04-20 at 17:31 +0200, marcelo bagnulo braun wrote:
> El 20/04/2005, a las 17:14, Jeroen Massar escribió:

> agree
> but i guess that DNS servers won't be using shim to obtain multihoming 
> support, but they will use the DNS protocol redundancy features instead 
> (multiple records with the different addresses available for the 
> server) (besides, doesn't make much sense to run a 4 way handshake to 
> exchange a single packet DNS query i guess)

The whole goal of multihoming is being independent of upstream address
space isn't it ?

Scenario, we are example.com and have 2 upstreams, thus 2x /48 and those
are 2001:db8::/32 from the IPv6-Doc prefix and 3ffe:ffff::/48 out of the
6bone test/play/doc prefix. We have our example.com domain, where our
web&smtp&etc-server resides at our shim6'd addresses. We can't shim6 our
DNS/shim6-directory server because of cyclic redundancy, thus we have in
DNS:

ns1.example.com AAAA 2001:0db8::53
ns1.example.com AAAA 3ffe:ffff::53

It is 6/6/6 and major ISP's filter out 3ffe::/16. Thus one out of two
first-query attempts go into oblivion and that is only for contacting
DNS. When we want to update* the above we need to contact the registrar
etc. Fortunately for some domains there is a 5 minute or so time, but
then still you have cached entries etc.

If people would rely on DNS to be so quick, then they could also do that
for everything else, webservers etc.

Not even mentioning outsourced DNS servers, or having customers hardcode
the DNS servers, eg ns1.example.org AAAA 2001:0db8::53, CNAMEs are not
allowed and they love their own name.

Greets,
 Jeroen

* = Can't we organize a 'kick the .org/.com/.net registrars' event so
that they will start accepting AAAA entries for NS's?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 240 bytes
Desc: This is a digitally signed message part
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20050420/23bcbd8d/attachment.sig>