Re: (ngtrans) Joint DNSEXT & NGTRANS summary

[Robert Elz <kre@munnari.OZ.AU>]

    Date:        Wed, 08 Aug 2001 11:01:07 -0400
    From:        Keith Moore <moore@cs.utk.edu>
    Message-ID:  <200108081501.LAA13833@astro.cs.utk.edu>

  | that's insane.  you've just decreased the reliability of applications by
  | at least two nines.

That makes no sense at all.

If an application goes and checks the DNS, and gets no answer back, or
anything else to indicate that communications should fail, it can simply
ignore that, and just keep on using the address it has.  That is,
until/unless that address stops working.

On the other hand, if the DNS tells you that the entity you're connecting
to has been renumbered, then if you were willing to trust the address the
DNS gave you initially, you'd be foolish to ignore it now...  Using the
updated address just has to be better than simply having things fail because
the old address is no longer available.

Of course, there are truly dumb ways to use addresses that can be
imagined (and are probably even used) where you see changing addresses
from what is really load balancing or similar.   Implemented sanely those
cause no problems (you see all the addresses, as long as the one you're
using is still there, carry on, even if it isn't the one you'd pick
if you were starting again now).

And even there, using A6 as the DNS mechanism allows much better
heuristics, if you have an A6 record that says "this is my address, and
it relies on this other A6 for its prefix", and later you get the same
result, but the value of the prefix has changed, then you can be fairly
sure that a renumbering has happened - as distinct from simply getting
back a different address, which gives you no clue as to why the address
is no longer the same (and you can't really just compare bits, because
from afar, you have no idea what is prefix and what isn't).

kre