Re: Stupid NAT tricks and how to stop them.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



it would be okay if the only apps you needed to run were
two-party apps.  in other words, it's not just users and hosts
that need addresses to be the same from everywhere in the
network - apps need stable addressing so that a process on host
A can say to a process on host B, "contact this process on host
C at address X and port Y"

Isn't this the kind of stuff the DNS was invented for?

not really. and even to the extent DNS was invented for this, it doesn't work well in practice.

Since when is that any kind of argument? The real questions are
whether it CAN work well for this and whether there's something else
that can do it better/easier.

- DNS is often out of sync with reality

Dynamic DNS updates are your friend.

From an app developer's point-of-view, DDNS is worthless.  DDNS is far
from universally implemented, and when it is implemented, it's often
implemented badly. DDNS can actually makes DNS a less reliable source of information about the host.

- DNS is slow and unreliable.

It doesn't have to be, running a decent DNS service isn't rocket
science.

Sometimes DNS is slow and unreliable because of poor server administration; sometimes it's slow and unreliable for other reasons. The very design of DNS is starting to look like an anachronism.

- many networks use other ways of doing name to address mapping for
 local hosts.

Not sure what you mean here.

Let me put it another way - lots of hosts that need to participate in distributed apps aren't listed in public DNS.

- there's no good way for hosts to know their own DNS names

Again, dynamic DNS updates.

Doesn't solve the problem, especially when DDNS is done by some DHCP server rather than the host itself.

- more generally, there's no good way for a host or an app to know
 what a DNS name means.

This one can be problematic but it's not a fundamental problem but rather a local management problem: apps should be able to obtain the
 local hostname that they can use for referral purposes.

There's no standard way to do this - and the right name can vary from
one app to another on the same host.

IMHO, DNS is best used as a sort of bootstrapping mechanism - a way
 for an app to get an initial contact point for some service.
After that initial contact is made, DNS is contraindicated.

I wouldn't have a problem with that except that people somehow think
that IP addresses DO fulfill all the requirements for being stable references.

Using DNS names as identifiers for referrals has problems.

Using IP addresses as identifiers for referrals has a different set of
problems.  But IP addresses are a lot closer than DNS names.

In traditional IPv4 they did to a large degree, but then NAT came
along. With IPv6 a single host routinely has multiple addresses (of more than one scope), and with MIP and shim those addresses change
from time to time. IP addresses are what get the packets from point A
to point B. That's hard enough. Stable identity needs to happen at a
higher level, and rejecting DNS names for this because of a few
simple operational difficulties is a bad idea.

I wasn't talking about stable references - I was talking about references that are valid, for a short time, from anywhere
in the network.  Stable references are a different problem.
But even in that case, it's not clear how to fix DNS to be reliable. Protocol quality issues aside, there's not anything like a consensus on how DNS should be used.

Keith


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]