'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