'cause warren isn't special enough to warrant getting the only copy of this.

/Wm
---------- Forwarded message ----------
From: william manning <chinese.apri...@gmail.com>
Date: Tue, Sep 12, 2017 at 6:53 PM
Subject: Re: [DNSOP] DNSSEC in local networks
To: Warren Kumari <war...@kumari.net>


cry me a river.  in the face of conflicting strings, tie-break by using the
closest enclosing trust anchor. See the "Islands of Trust" RFCs.  Slavish
dependence on a single trust anchor is among the dumber things you can do,
operationally.

/Wm

On Tue, Sep 12, 2017 at 5:03 PM, Warren Kumari <war...@kumari.net> wrote:

> On Mon, Sep 4, 2017 at 4:45 PM, Mark Andrews <ma...@isc.org> wrote:
> >
> > In message <efe320cf9580d4c1bb2b26dd1c294306.1504529...@squirrel.mail>,
> "Walter
> >  H." writes:
> >> On Mon, September 4, 2017 14:22, Mark Andrews wrote:
> >> >
> >> > In message <c0c73dab49c6452c616c86656704ecd0.1504518...@squirrel.mail
> >,
> >> > "Walter H." writes:
> >> >> where there anyone who said: "don't use it", 15 years ago?
> >> >
> >> > Yes.  There were lots that discourage the use of .local, lan,
> >> > .corp etc.  Just becaue you didn't hear from them doesn't mean
> >> > they weren't out there.
> >>
> >> a discourage is not a "don't use" :-)
> >
> > We gave them fair warning that and domain they choose could be
> > allocated in the future.  We told them to the advice you have been
> > getting today.  Use a zone registered to them.  They, like you are
> > today, are ignoring the advice.
> >
>
> Yup, but people continue to ignore the advice, and, as far as I can
> see, will continue to do so - .internal is intended to give people a
> place where they can go do whatever they want without just squatting
> on something.
> I personally believe they should just use something which they have
> registered -- but, I also believe that abstinence is the only way to
> prevent teen pregnancy. Seeing as my believing this doesn't actually
> *stop* teenagers having sex, I'd like them to do so in the least risky
> way possible -- .internal, a condom for the namespace.
>
> >> >> > 'home.arpa' is in the process of being registered so that it
> >> >> > can be used safely in the environment it is designed to be used in.
> >> >>
> >> >> yes, but commonly for residental networks, not company/enterprise
> >> >> networks,
> >> >> they want/need something shorter like ".corp", ".lan", ".local", ...
> >> >
>
> Perhaps corp.arpa, or internal.arpa, or home.arpa is the right answer
> - unfortunately I think that they fail the "looks pretty" property.
>
> >> > Want maybe, need absolutely not.
> >> question: why isn't this the answer of a car dealer?
> >
> > Because the car dealer is trying to take as much money off you as
> > they can.  We on the other hand are trying to save you money by
> > stopping you and everyone else getting into situations that will
> > cost you/them thousands of dollars to rectify in the future.
> >
> >> > Everyone was told to register the domain you want to use, there was
> >> > no exception for active directory.
>
> Sorry, nope. You might have said that, I might have said that, but
> many people remained unaware -- also Microsoft suggested (
> https://support.microsoft.com/en-us/help/296250/the-domain-n
> ame-system-name-recommendations-for-small-business-server
> )
>
> "Three practical methods to name the DNS domain are:
>
> * Make the name a private domain name that is used for name resolution
> on the internal Small Business Server network. This name is usually
> configured with the first-level domain of .local. At the present time,
> the .local domain name is not registered on the Internet.
> * Make the name a sub-domain of a publicly registered domain name. For
> example, if the publicly registered domain name is Contoso.com, a
> sub-domain of Corp.contoso.com can be used.
> * Make the name the same as a publicly registered domain name.
>
> Most Small Business Server customers should use the first method. The
> following list describes some of the advantages when you use a
> separate and private domain name for the local Small Business Server
> network:
>
> The management of the local namespace is controlled by the Small
> Business Server Server. When you use a private FQDN for local DNS name
> resolution, the DNS server becomes the start of authority for the
> local domain. This result means that a query to external DNS root
> servers is not required for local resource name resolution.
>
> The security may be increased for your DNS server by not enabling zone
> transfers by means of the zone transfer properties of the forward
> lookup zone. Because dynamic registration of internal hosts can occur
> with the DNS server, if you disable the zone transfers from external
> clients, you can limit the exposure of internal host names to the
> Internet.
>
> The natural separation of internal and external networks occurs
> because of the use of a separate internal namespace. A client query
> generated from the Internet for www.contoso.local does not return any
> valid domain information because .local, at the present time, is not a
> registered domain name. However, by using the Web Publishing rules in
> Internet Security and Acceleration (ISA) Server, internal Web sites
> can be hosted externally and viewed by using resolvable domain names.
> This hosting still requires a registered domain name as well as the
> appropriate public DNS records that resolve to the external IP address
> of Small Business Server. Refer to "Configuring Publishing" in ISA
> Server Help for more information about Web Publishing rules."
>
>
> Microsoft now recommends that people put stuff under a registered
> name, but a significant number of people heard (and followed) the
> earlier advice.
> Microsoft also used .corp (or contoso.corp) in a large number of
> examples (e.g: https://blogs.technet.microsoft.com/networking/2009/04/16/
> dns-client-name-resolution-behavior-in-windows-vista-vs-windows-xp/:
> , including (IIRC) the step by step walkthrough of how to setup Active
> Directory - and many people followed this --
> http://www.enyo.de/fw/notes/the-great-corp-renaming.html
>
> So, yes, people shouldn't have just used .local, or .corp -- but I
> entirely understand why they did.
>
> Reserving a TLD for internal shenanigans certainly won't fix existing
> deployments. It also won't stop people from sometimes squatting on
> whatever-they-feel-like. However, it will give people who are going to
> do this sort of thing a safe place to do it. As Andrew says, there are
> an almost unlimited number of strings that can be made with 63 octets.
> I think the benefit of giving people a sandbox for this outweighs the
> costs (basically none). Yes, there will be collisions if e.g.
> companies merge, VPNs, and other cases (just like there were with
> RFC1918); I think we need to note that as a disclaimer in the
> document. People choosing to use this should be consenting adults.
>
> >>
> >> not really, at those days only a few TLDs where possible, the many TLDs
> >> came some years later ...
> >
> > People were wanting to deploy more TLDs from the moment the Internet
> > was opened up to the public.
> >
> >> by the way: where is the problem with .home or .corp?
> >> I ask this, because at my hoster I pre-reserved my "local domain" - a
> >> .home, that I have used for many years several zears ago and nothing
> >> happened ...
> >>
> >> > IPv6 would have been deployed a lot sooner. :-)
> >>
> >> not really, my ISP is still IPv4 only ..., my IPv6 connectivity is a
> >> HE-tunnel ...
> >> and the brand new OS from Microsoft still has the bugs inside: TEREDO,
> ...
> >> which I had to deactivate first, before it is usable with IPv6 at all
> ...
> >
> > If you didn't have the relief valve of RFC 1918 addresses then yes
> > IPv6 would have come a lot quicker and stuff like TEREDO wouldn't
> > exist.
> >
> >> > Except such systems exist.  Go look at what a Mac does.  ping for
> >> > test.local and look and port 5353 traffic and compare it to port 53
> >> > traffic.
> >>
> >> I know, this RFC was written by Apple;
> >>
> >> no Apple no problem, I would say :-)
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 <+61%202%209871%204742>
>  INTERNET: ma...@isc.org
> >
> > _______________________________________________
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>    ---maf
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to