Re: (ngtrans) Joint DNSEXT & NGTRANS summary

[Keith Moore <moore@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.

but if the application starts using a new address, and that address doesn't
reach the same peer (same socket on the same host) as before, then switching
to the new address causes premature failure.  the application is always
better off continuing to use the old address, attempting to switch 
addresses only to recover from apparently broken connections.  even then, 
the application has to guess as to whether it's more likely that the 
connection will begin working again or whether the old address is now
permanently invalid.

furthermore, it's always been the case that you could get multiple addresses
in response to a name lookup, and there's no license to assume that those
addresses are interchangable for open connections.  in that case, which 
address does an application choose?

> 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...  

and you'd be foolish to switch while the old address is still working,
for reasons cited above.

> 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).

but this doesn't facilitate renumbering. 

> 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 

no you can't.  just because DNS thinks that a new prefix exists for an
address is no indication that the application on the other end can 
deal with your using the new prefix.

it's hard enough to keep MX records in sync with SMTP servers, and
that's something that should be explicitly managed.  asking applications
to keep track of changes in DNS doesn't strike me as an effective way
to do renumbering.  we need an interrupt mechanism, not a polling one,
and we need something that works at the IP level, not using an application
that is layered on top of IP.

Keith