Subject: RE: mboned: Re: using DNS as a means of indirection

From: "Manfredi, Albert E" <[email-masked]>
Date: Sat, 26 Feb 2005 18:24:57 -0500

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]]
> Sent: Saturday, February 26, 2005 1:21 PM
> To: Marshall Eubanks
> Cc: John Kristoff; [email-masked]
> Subject: mboned: Re: using DNS as a means of indirection
> 
> 
> On Sat, 26 Feb 2005, Marshall Eubanks wrote:
> > Suppose I started a very popular program update service 
> using multicast called, say, Marshall's
> > Goblin. Now, if I picked and hardcoded an address for this 
> to use, this could be bad.
> >
> > Instead, we set up a new top-level domain, called 
> multicast, and goblin would be associated with
> > goblin.multicast or maybe goblin.marshall.multicast.
> 
> Sure, though this does not improve the situation much -- IANA would 
> still assign a global address because otherwise the DNS name would 
> point nowhere by default?

Yes, for global scope. And this provides a mechanism for clients to discover the global scope Class D address easily. But also, the ISP or enterprise admin can automatically reduce the scope of the multicast, while providing a good Class D address, if the DNS record remains in the local DNS only. For example, perhaps a particular multicast app, which was originally global scope, is reduced in scope at some point.

So it solves the problem that was first articulated in this thread, i.e. how to keep multicast app writers from picking Class D addresses out of the blue, no? Implicit in this is that the multicast app writer will contact the local net admin, or the IANA, when first developing the application, to see what scope is appropriate. But not to be given a fixed address at that time.

> Taking this up a notch, I don't quickly see what benefit there would 
> be in goblin.marshall.multicast to begin with (instead of requiring 
> one to use goblin.marshall.com or .name).  Or would this just be a 
> convenience for IANA so they would have a zone to administer (for 
> free) or that multicast app developers wouldn't have to pay 20USD/yr 
> to register their own domain name?

I'm not clear on this point either, except maybe just to differentiate explicitly between unicast and multicast bindings in the DNS. Is there a down side to doing it this way?

Bert

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: "Marshall Eubanks" <[email-masked]>
Date: Sun, 27 Feb 2005 08:55:30 -0500

Hello, All;

On Sat, 26 Feb 2005 18:24:57 -0500
 "Manfredi, Albert E" <[email-masked]> wrote:
> Yes, for global scope. And this provides a mechanism for clients to discover the global scope
> Class D address easily. But also, the ISP or enterprise admin can automatically reduce the scope
> of the multicast, while providing a good Class D address, if the DNS record remains in the local
> DNS only. For example, perhaps a particular multicast app, which was originally global scope, is
> reduced in scope at some point.
> 

Exactly

> So it solves the problem that was first articulated in this thread, i.e. how to keep multicast
> app writers from picking Class D addresses out of the blue, no? Implicit in this is that the
> multicast app writer will contact the local net admin, or the IANA, when first developing the
> application, to see what scope is appropriate. But not to be given a fixed address at that time.
> 
> I'm not clear on this point either, except maybe just to differentiate explicitly between unicast
> and multicast bindings in the DNS. Is there a down side to doing it this way?
> 

Yes, to create a perceptual distinction. There is nothing to stop an app writer from doing this
now - I can just have goblin.multicast.marshall.nt resolve to 239.123.123.123 now if I want.

But

- Would an administrator out there know that goblin.multicast.marshall.nt resolve this way? How
are they to find out ? (Supposed they missed my SuperBowl ads, but a user put up the service.)
With an actual domain (which does not necessarily have to be a TLD), you could do (enforce) 
inverse mappings.

- It would be impossible to enforce any sort of uniformity - you might creat a competing
"Ghoul" service, and use
multicast.ghoul.albert.nt

- Because there is no perceptible difference, admins will make mistakes that will map into
futher errors - maybe they will map all of ghoul.albert.nt to 239.10.1.1 instead of 
multicast.ghoul.albert.nt, and so no one on their site
will be able to go to your help page, but instead 
their browers will create weird multicast traffic that
may not be squelched properly.

Whatever is done (whether this or some other scheme) should be as bullet proof and
cook book as possible, so that both application developers and system admins can
be told, you do this in this way, it will work, and you don't really have to think about it.

Regards
Marshall

---

From: Pekka Savola <[email-masked]>
Date: Mon, 28 Feb 2005 15:23:56 +0200 (EET)

> With an actual domain (which does not necessarily have to be a TLD), you could do (enforce)

The same way that the administrator would find 
goblin.marshall.multicast.net?  It's not really obvious how the admin 
would find that out either.

I didn't really understand the difference in the following bullet 
points either, and I don't really understand how inverse mappings come 
into this picture.

As Jeroen proposed, a different DNS namespace could be used to make it 
easier for the local admins to re-define a new address for a 
particular application, BUT:
  - that for each application, there would also have to be a global
    IANA-assigned address; this would not reduce the need for multicast
    addresses.
  - IANA (or someone they delegate to) should manage the preconfigured
    DNS entries in a secure manner
  - For DNS "hijacking" to work, you'll have to ensure that every
    client in the site uses your authorative DNS server for queries,
    i.e., doesn't implement a stub resolver on their own.
  - application writers gain nothing over just using an IANA-assigned
    global address -- why would they bother to implement this
    complexity?
  - I don't this would not reduce the amount of apps that "just pick a
    number".

It's an interesting idea, but it does have problems, and it is not 
clear how exactly it would improve the situation we have now :-(

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 28 Feb 2005 14:55:58 +0100

>    IANA-assigned address; this would not reduce the need for multicast

True, one _could_ still hardcode the address itself. But wouldn't it be
better to move away from hardcoded addresses altogether?
Yes, you will have an extra lookup, Yes if the DNS server is not there
it will fail, but if the DNS server is not there most of the current
things people use will be broken anyway, thus would it matter?

Additionally to solve the 'local' and 'global' problem, maybe we could
do something like:

dogfight.multicast.local.service A 222.6.6.6
dogfight.multicast.service A 224.0.4.2

Thus dogfight first tries to resolve 'dogfight.multicast.local.service',
which if it does not exist, aka no local dogfight service, it can try
the normal 'dogfight.multicast.service' label.
This also avoids the cases where an ISP does not want to define all
labels, or forgets to update new entries.

My favourite use is still 'status.www.local.service' which would show
you the status page of the ISP you are connected to at that moment.

>    DNS entries in a secure manner

See the mcast.net domain as mentioned by Brian.

>    i.e., doesn't implement a stub resolver on their own.

This is actually a good part. If somebody wants to configure their host
themselves let them, they will do it anyway.
These are only meant for the people who do not want to configure a host.
If you still want to then you can and it is your fault that you do it
wrong.

It can be solved by the way by not hardcoding the root-servers any more
into the example configs but the .service DNS server anycasted IP
address. Which thus also will pick the most local server on it's path.
Saves on configuration and makes a lot of people, especially
administrators happy.

>    global address -- why would they bother to implement this

What is the difference of having:

getaddrinfo(...., argn > 1 ? argv[1] :
"dogfight.multicast.service",...);

and:

getaddrinfo(...., argn > 1 ? argv[1] : "224.0.0.1",...);

?

>  - I don't this would not reduce the amount of apps that "just pick a

Of course, just like anybody can 'just pick an IP/port/resource' and use
that. But that is inevitable, people are still people fortunately.
Anyone remember the IPv9/IPv7/IPv16 proposals ? :)

Greets,
 Jeroen