> On Mon, 9 Jul 2007, Jeroen Massar wrote:
> > Roger Jorgensen wrote:
> <snip>
> >> - anyone can, IF the ULA-C/G holder want to, resolve the IP in any given
> >> ULA-C/G block through the global DNS system (a very very nice thing for
> >> everyone that hate the pain split-DNS give you...additional administration
> )
> >
> > Please explain me how you are going to do *forward DNS* also. You know,
> > most people type www.google.com, not the ip6.arpa ones and without the
> > first, the latter is useless. You have to connect the forward zones
> > anyway, so why not connect the reverse ones also. This has to be split
> > DNS anyway, as a lot of companies are not willing to connect their
> > internal systems in ANY way to the global Internet or let alone, expose
> > those hostnames to that global Internet thing. Of course it is a lot of
> > fun to be able to resolve big-red-button.oval-room.whitehouse.gov and at
> > least know where to look for.
>
> think most enterprises are willing to take that chance and only use _one_
> forward zone no mather if it will be internal or external.
>
> I personal dont like to expose internal thing to internet but I've
> realized that the it is quite harmless from a security point of view.
>
>
> > Hint for security control freaks: DNS tunneling, you know it is fun :)
> > And when you are able from your local (ULA) host to resolve a global DNS
> > name you can do exactly that and more. Also what happens when a local
> > guy types "www.google.com", do they get routed into oblivion or do you
> > think they will not want to connect to that or to Wikipedia and a lot of
> > resources on the Internet? Or are you going to use 2 IP addresses or
> > more per host and create even a bigger management hell?
>
> heard about proxy-servers? or http-relay, or transparent proxies ? They
>
>
> > Stuffing *LOCAL* reverse DNS in the *GLOBAL* DNS doesn't make any sense.
> > Either keep it totally local or keep it totally global (thus UA).
>
> where exactly will this extra load on the GLOBAL DNS be? maybe a how is
> better to ask. I only see one place where there will be additional
> workload and thats for the root-servers. Most of the usage of ULA-C/G are
> said to be local so the highest usage will be on the far-bottom of the
> dns-structure. Just a few cases where network interconnect will there be
> created load on the root-servers.
Wrong. The load will not be on the root servers. It will
however be on the C.F.IP6.INT servers for all the active
ULA-C blocks that do not have nameservers configured for
them.
There will still be leaked packets going to the root servers
but that will be much less than the traffic going to the
C.F.IP6.INT if there arn't delegations made.
We know from the AS112 expriences with RFC 1918 address
that queries will be emitted if there arn't internal zones
configured. We also know that the aggregate traffic will
be large.
The point of requesting that globally reachable nameservers
exist is to absorb that traffic. I expect that in most
cases there will be multi-homed nameservers which answer
both internal and external queries. Once you have to setup
a nameserver you may as well allow the zone to be populated.
Any queries that come out of the site will get referrals
back to these, presumably, on site nameservers. Not that
efficient but also not a large impact on the infrastucture
servers.
If the site chooses to out source the servers then I expect
the out sourcing providers will have a variable scale
depending upon the query load. If a site chooses to let
queries for on site addresses leave the site it will be
reflected in query load and presumably price.
> This suggest is just for "scaring" off people and to make it less easy to
> get global DNS for ULA-C/G, nothing else.
> What if we made the system so that getting global DNS for your ULA-C/G
> prefix become optional and it will have to be requested seperatly from
> the regular way of getting those prefixes? In practice, when you request
> a ULA-C/G you dont get asked for reverse DNS servers, you will have to do
> that somewhere else...
>
>
> > So how exactly is this ULA thing different from the UA (PI&PA) space
> > that is already available? Why bother with ULA when one day you might
> > most likely want to connect to the Internet anyway and cause pain then?
> > Why lay that pain unto people?
>
> what pain? I fail to see that except for the extra load mention furter up.
>
>
> > The only real difference I see is that it is a well known block that
> > people can force to not route, thus making a 2nd kind of Internet
> > Citizen and a monopoly situation for the folks who can and the ones who
> > can't get UA space.
>
> It is NOT supposed to be routed so no one should be forced to not route
> it. The real solution to this whole DMZ issue is to make PI so easy to get
> that everyone that need it can get it. Could even make the cost exactly
> the same and use the above mention not-mention-DNS during request of
> ULA-C/G to... just that alone could create that little extra touch to
> the thing whole thing and send them towards PI instead of ULA-C/G except
> for those that really really want ULA-C/G.
>
>
> ...
>
> > Now I do see another use for this kind of address space, but then it
> > should not be called this way. It could be used for ID/LOC solutions,
> > where these kind of addresses are Explicit-non-DFZ addresses. But if
> > that is the reason for what folks want to use them, as that is what I am
> > sort of reading between the lines as actual real usage has still not
> > been identified, then please just state that.
>
> well, let ULA-C/G be the first step on this ID/LOC solution path? We will
> need it one way or another anyway...
>
>
>
> --
>
> ------------------------------
> Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID
> [EMAIL PROTECTED] | - IPv6 is The Key!
> -------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
