Subject: Re: [RAM] candidate properties of some new name types

From: Max Tulyev <[email-masked]>
Date: Mon, 26 Feb 2007 11:46:12 +0000

Hi all,

The main idea of FQDN-based multihoming is a patched DNS server with TTL
always 1 in replies. FQDN is not a subject of change, but IP to resolve
to is.

The DNS server resolves host to IP not only using name of this host, but
using other information such as IP of requestor, table of really working
interfaces, current load of interfaces and so.

Disadvantages of this is all currently active sessions will be dropped
when one of channels will go down, and also DNS replies can not be cached.

Advantages is we don't need to alter the world to implement it. We can
do it right now.

There is many implementations of this schema near me, including for
VoIP. All of them working reasonable for real business.

Rui Campos wrote:
> Hi all,
> 
> I have been following the discussions in this list and I just would like to 
> comment this FQDN issue.
> 
> IMHO, even if FQDNs are used as identifiers for hosts things will not work 
> properly, at least without modifying the way FQDN assignment works in the 
> current Internet (probably that's the your idea, I'm not sure).
> 
> Let's consider a host H that attaches itself to different domains along the 
> time. While H is attached to the same domain (e.g., domain1.com.) its FQDN 
> does not change. Then, H can be uniquely identified by a peer host even if its 
> IP address changes, assuming that the mapping FQDN <-> IP address is handled 
> properly. However, when H moves between different domains the FQDN will change 
> at the same pace. For instance, at instant 1 H gets connected to domain1.com 
> and its FQDN is "H.domain1.com.", at instant 2 it connects to domain 2 and its 
> FQDN becomes "H.domain2.com." and, finally, at instant 3 it connects to 
> domain3 and its FQDN becomes "H.domain3.com". Therefore, every session bound 
> to an FQDN will break when the host moves from one domain to the other. On the 
> other hand, how does a peer host will get informed about the current host's 
> FQDN?
> 
> If we consider multi-homed hosts (i.e., hosts with multiple network 
> interfaces) the problem is even exacerbated. In fact, multi-homed hosts may 
> have an FQDN per network interface. Then, what FQDN will a peer host use to 
> contact a multi-homed host? There is not a single FQDN that uniquely 
> identifies the host regardless of its location and number of network 
> interfaces.
> 
> BR,
> Rui Campos

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: "Rui Campos" <[email-masked]>
Date: Mon, 26 Feb 2007 11:10:35 -0000

Hi Max Tulyev,

See my comments inline. Thanks!

BR,
Rui Campos

-----Original Message-----
From: Max Tulyev [mailto:[email-masked]] 
Sent: segunda-feira, 26 de Fevereiro de 2007 11:46
To: [email-masked]
Subject: Re: [RAM] candidate properties of some new name types

Hi all,

The main idea of FQDN-based multihoming is a patched DNS server with TTL
always 1 in replies. FQDN is not a subject of change, but IP to resolve
to is.
[Rui Campos] Are you really considering the scenario I have mentioned in my
e-mail below? I know that the FQDN will not change if a host stays connected
within the same domain. But, what about the scenario where you jump from
domain to domain? This does not seem to be supported by the mechanism you
are talking about, unless I am missing something here ;-)

The DNS server resolves host to IP not only using name of this host, but
using other information such as IP of requestor, table of really working
interfaces, current load of interfaces and so.
[Rui Campos] Doesn't this mean modification of the world? :-) As far as I
know, today DNS servers do not consider all these parameters for resolving
host to IP.

Advantages is we don't need to alter the world to implement it. We can
do it right now.
[Rui Campos] Are you sure you don't need to change the "DNS world" as we
know it today?

There is many implementations of this schema near me, including for
VoIP. All of them working reasonable for real business.
[Rui Campos] I understand that this can work for local scenarios, as I have
mentioned above. But I doubt it would work in a global scope without
modifying the "DNS world" ;-)

-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.441 / Virus Database: 268.18.3/699 - Release Date: 23-02-2007
13:26

---

From: Max Tulyev <[email-masked]>
Date: Mon, 26 Feb 2007 17:39:36 +0200

Hi Rui,

> are talking about, unless I am missing something here ;-)

Yes, your scenario really differs from mine ;)

> know, today DNS servers do not consider all these parameters for resolving

Yes, it means no modification to the world, it is fully compatible with
things running now. You should alter only YOUR DNS servers, not all in
the world. Or even to start up to provide such service to other.
But the main thing - we don't need to alter all the world (i.e. all
routers in the world and so), as if implementing other non-PI
multihoming schemas (as I can understand this).

> [Rui Campos] Are you sure you don't need to change the "DNS world" as we

Really. Only your DNS serving your multihoming domain.

Let's look again. We have www.foo.com with two interfaces, 10.0.0.1 and
192.168.0.1. Let's serve A answer 10.0.0.1 (or both) until it is alive.
If 10.0.0.1 went down (i.e. stop pinging in my case) - we continue serve
 192.168.0.1 in replies instead.
To prevent replies to be cached by caching resolvers (and traffic flow
to unconnected interface), let's set TTL in the domain to 1 sec.
In my case all of that implemented only with Bash scripting and named.

> modifying the "DNS world" ;-)

TTL=1 really helps ;)

-- 
WBR,
Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

---

From: "Rui Campos" <[email-masked]>
Date: Mon, 26 Feb 2007 16:01:39 -0000

Hi Max,

Thanks for your reply! Now I confirm that you were considering a different
scenario. Then, I can agree with your statements ;-)

BR,
Rui Campos 

-----Original Message-----
From: Max Tulyev [mailto:[email-masked]] 
Sent: segunda-feira, 26 de Fevereiro de 2007 15:40
To: Rui Campos
Cc: [email-masked]
Subject: Re: [RAM] candidate properties of some new name types

Hi Rui,

TTL=1 really helps ;)

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 Feb 2007 17:33:09 +0100

It's pretty clear that using DNS in this way is a hack.
The interactions with DNS TTL misimplementation are
pretty likely to break it, and in any case how does it
help TCP session survival?

I think we need to take the discussion up a level.
What's the goal here? If the goal is a dynamic mapping
service with certain characteristics, we can then figure
out if the DNS can do it, or if we need something new.

     Brian

On 2007-02-26 12:10, Rui Campos wrote:
> using other information such as IP of requestor,From [email-masked] Mon Feb 26 12:45:15 2007
Date: Mon, 26 Feb 2007 17:33:09 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Rui Campos <[email-masked]>
Subject: Re: [RAM] candidate properties of some new name types
Cc: [email-masked]

It's pretty clear that using DNS in this way is a hack.
The interactions with DNS TTL misimplementation are
pretty likely to break it, and in any case how does it
help TCP session survival?

I think we need to take the discussion up a level.
What's the goal here? If the goal is a dynamic mapping
service with certain characteristics, we can then figure
out if the DNS can do it, or if we need something new.

     Brian

On 2007-02-26 12:10, Rui Campos wrote:
> ------------------------------------------------------------------------
>