Re: [dns-operations] Current thinking on internal corporate/campus domain names
These are my favorites: corp.verio.net. 0 IN NS 10.254.241.250. corp.verio.net. 0 IN NS 198.104.179.227. There's a non-zero amount of traffic sent to the root servers from such behavior. On 2014-06-24, 13:03, Jared Mauch ja...@puck.nether.net wrote: On Jun 24, 2014, at 12:53 PM, Phil Regnauld regna...@nsrc.org wrote: Jared Mauch (jared) writes: On Jun 24, 2014, at 9:01 AM, Kelly Setzer kelly.set...@wnco.com wrote: * Most respondents agreed that a registered domain for internal DNS was the way to go. Beware the mistakes of others as well, check out 'corp.verio.net' as an example of a poorly operated sub-domain. corp.verio.net is indeed a subdomain, and not a registered domain: Sorry, you seem to need more data to observe what i was trying to point out.. ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;corp.verio.net. IN NS ;; ANSWER SECTION: corp.verio.net.0 IN NS 10.254.241.250. corp.verio.net.0 IN NS stngva1-dc05.wpm.corp.verio.net. corp.verio.net.0 IN NS frnkde1-dc03.corp.verio.net. corp.verio.net.0 IN NS ns1.secure.net. corp.verio.net.0 IN NS stngva1-dc03.corp.verio.net. corp.verio.net.0 IN NS w3scva02.win.smewh.net. corp.verio.net.0 IN NS w3scva00.win.smewh.net. corp.verio.net.0 IN NS neutde1-dc00.corp.verio.net. corp.verio.net.0 IN NS stngva1-dc06.wpm.corp.verio.net. corp.verio.net.0 IN NS w3scca01.win.smewh.net. corp.verio.net.0 IN NS oremut1-dc03.corp.verio.net. corp.verio.net.0 IN NS w3dwin01.win.smewh.net. corp.verio.net.0 IN NS iad-wprd-cordc1.corp.verio.net. corp.verio.net.0 IN NS w3scva03.win.smewh.net. corp.verio.net.0 IN NS s.ns.verio.net. corp.verio.net.0 IN NS a.ns.verio.net. corp.verio.net.0 IN NS stngva1-dc01.corp.verio.net. corp.verio.net.0 IN NS bcrtfl1-fdc00.corp.verio.net. corp.verio.net.0 IN NS ns2.secure.net. corp.verio.net.0 IN NS 198.104.179.227. corp.verio.net.0 IN NS neutde1-dc03. corp.verio.net.0 IN NS iad-wprd-cordc2.corp.verio.net. corp.verio.net.0 IN NS frnkde1-dc00.corp.verio.net. corp.verio.net.0 IN NS w3scca00.win.smewh.net. corp.verio.net.0 IN NS stngva1-dc04.corp.verio.net. corp.verio.net.0 IN NS w3scsp01.win.smewh.net. corp.verio.net.0 IN NS bcrtfl3-pdevdc1.pdev.verio.net. corp.verio.net.0 IN NS w3scde01.win.smewh.net. corp.verio.net.0 IN NS w3dwin00.win.smewh.net. corp.verio.net.0 IN NS w3scca02.win.smewh.net. corp.verio.net.0 IN NS oremut1-dc00.corp.verio.net. corp.verio.net.0 IN NS neutde1-dc03.corp.verio.net. corp.verio.net.0 IN NS w3scga01.win.smewh.net. corp.verio.net.0 IN NS stngva1-dc02.corp.verio.net. corp.verio.net.0 IN NS bcrtfl1-fdc01.corp.verio.net. corp.verio.net.0 IN NS bcrtfl3-pdevdc2.pdev.verio.net. corp.verio.net.0 IN NS bcrtfl1-dc04.corp.verio.net. corp.verio.net.0 IN NS neutde1-dc00. Please point out the trouble with this in one sentence or less. - jared ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Current thinking on internal corporate/campus domain names
On Jun 26 2014, Barber, Piet wrote: These are my favorites: corp.verio.net. 0 IN NS 10.254.241.250. corp.verio.net. 0 IN NS 198.104.179.227. There's a non-zero amount of traffic sent to the root servers from such behavior. Maybe the 256 TLDs 0 .. 255 could be usefully black-holed by DNAME'ing them to EMPTY.AS112.ARPA once we have http://tools.ietf.org/html/draft-ietf-dnsop-as112-dname-03 deployed? -- Chris Thompson University of Cambridge Information Services, Email: c...@uis.cam.ac.ukRoger Needham Building, 7 JJ Thomson Avenue, Phone: +44 1223 334715 Cambridge CB3 0RB, United Kingdom. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Current thinking on internal corporate/campus domain names
On Jun 24 2014, Robert Edmonds wrote: Jared Mauch wrote: Sorry, you seem to need more data to observe what i was trying to point out.. ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;corp.verio.net.IN NS ;; ANSWER SECTION: corp.verio.net. 0 IN NS 10.254.241.250. [... far too much omitted ...] corp.verio.net. 0 IN NS neutde1-dc00. Please point out the trouble with this in one sentence or less. Oh my god. Only appropriate if your god is a particularly vengeful one, liable to inflict fire and brimstone on the perpetrators, with wailing and gnashing of teeth ... [oops, some sort of mixup with Luis Suarez there] -- Chris Thompson University of Cambridge Information Services, Email: c...@uis.cam.ac.ukRoger Needham Building, 7 JJ Thomson Avenue, Phone: +44 1223 334715 Cambridge CB3 0RB, United Kingdom. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Current thinking on internal corporate/campus domain names
Summary: Thank you all very much. There were seven respondents. Here are the key points. * There is a fourth option for internal DNS, that being use of a subdomain of the corporate domain, e.g., int.mycorp.com. * Several reiterated that use of a fantasy TLD could collide with current or future TLDs. * One respondent made several great points that I would summarize as, ³Plan ahead. Factor Internet connectivity into the plan.² * .local is no longer viable, Microsoft no longer recommends it. * I received this specific, interesting suggestion: Register a domain, but delegate it to DNS servers that are not in your network and always contains a null-zone. * It is not possible to obtain SSL certs (from commercial CAs) unless the internal domain is registered. This makes .corp potentially unusable. * Most respondents agreed that a registered domain for internal DNS was the way to go. As a result of your input and related research, I¹ll be recommending the use of a registered domain for internal DNS for the project I¹m working on. Cheers, Kelly *** CONFIDENTIALITY NOTICE *** This e-mail message and all attachments transmitted with it may contain legally privileged and confidential information intended solely for the use of the addressee. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message from your system. Thank you. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Current thinking on internal corporate/campus domain names
Am Dienstag, 24. Juni 2014, 15:01:09 schrieb Kelly Setzer: Summary: As a result of your input and related research, I¹ll be recommending the use of a registered domain for internal DNS for the project I¹m working on. Hi, for your project right now that's propably the best solution to go. And I know for most participants of this list this is also the best solution, but I still want to argue for the other way: If you have (for example for security reasons) a completly seperated internal network (only connected through DMZ/proxy/firewall but not directly routed) then there should be a general solution for this problem like it is there on layer three: For IPv4 everybody know, the range 10/8 is for internal use and such a thing should exist (defined via RFC) for DNS as well, no matter if the name is corp or local or internal or whatever as long as there is one. The argument, that you won't get a certificate for these names from someone who is regognized by your browser isn't valid: As you only would use such a internal domain for your internal network, you would have to create a internal CA anyway (and put it in your browsers). This way you would have a clean split between internal world and the outside internet. The only situation where this wouldn't be advisable is if you face the possibility that the internal network at some point in time will be merged with the outside world. In my opinion it's a pity that there is no reserved domainname for the private use. Robert. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Current thinking on internal corporate/campus domain names
On Jun 24, 2014, at 9:01 AM, Kelly Setzer kelly.set...@wnco.com wrote: * Most respondents agreed that a registered domain for internal DNS was the way to go. Beware the mistakes of others as well, check out 'corp.verio.net' as an example of a poorly operated sub-domain. - Jared ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Current thinking on internal corporate/campus domain names
On Jun 24, 2014, at 12:53 PM, Phil Regnauld regna...@nsrc.org wrote: Jared Mauch (jared) writes: On Jun 24, 2014, at 9:01 AM, Kelly Setzer kelly.set...@wnco.com wrote: * Most respondents agreed that a registered domain for internal DNS was the way to go. Beware the mistakes of others as well, check out 'corp.verio.net' as an example of a poorly operated sub-domain. corp.verio.net is indeed a subdomain, and not a registered domain: Sorry, you seem to need more data to observe what i was trying to point out.. ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;corp.verio.net.IN NS ;; ANSWER SECTION: corp.verio.net. 0 IN NS 10.254.241.250. corp.verio.net. 0 IN NS stngva1-dc05.wpm.corp.verio.net. corp.verio.net. 0 IN NS frnkde1-dc03.corp.verio.net. corp.verio.net. 0 IN NS ns1.secure.net. corp.verio.net. 0 IN NS stngva1-dc03.corp.verio.net. corp.verio.net. 0 IN NS w3scva02.win.smewh.net. corp.verio.net. 0 IN NS w3scva00.win.smewh.net. corp.verio.net. 0 IN NS neutde1-dc00.corp.verio.net. corp.verio.net. 0 IN NS stngva1-dc06.wpm.corp.verio.net. corp.verio.net. 0 IN NS w3scca01.win.smewh.net. corp.verio.net. 0 IN NS oremut1-dc03.corp.verio.net. corp.verio.net. 0 IN NS w3dwin01.win.smewh.net. corp.verio.net. 0 IN NS iad-wprd-cordc1.corp.verio.net. corp.verio.net. 0 IN NS w3scva03.win.smewh.net. corp.verio.net. 0 IN NS s.ns.verio.net. corp.verio.net. 0 IN NS a.ns.verio.net. corp.verio.net. 0 IN NS stngva1-dc01.corp.verio.net. corp.verio.net. 0 IN NS bcrtfl1-fdc00.corp.verio.net. corp.verio.net. 0 IN NS ns2.secure.net. corp.verio.net. 0 IN NS 198.104.179.227. corp.verio.net. 0 IN NS neutde1-dc03. corp.verio.net. 0 IN NS iad-wprd-cordc2.corp.verio.net. corp.verio.net. 0 IN NS frnkde1-dc00.corp.verio.net. corp.verio.net. 0 IN NS w3scca00.win.smewh.net. corp.verio.net. 0 IN NS stngva1-dc04.corp.verio.net. corp.verio.net. 0 IN NS w3scsp01.win.smewh.net. corp.verio.net. 0 IN NS bcrtfl3-pdevdc1.pdev.verio.net. corp.verio.net. 0 IN NS w3scde01.win.smewh.net. corp.verio.net. 0 IN NS w3dwin00.win.smewh.net. corp.verio.net. 0 IN NS w3scca02.win.smewh.net. corp.verio.net. 0 IN NS oremut1-dc00.corp.verio.net. corp.verio.net. 0 IN NS neutde1-dc03.corp.verio.net. corp.verio.net. 0 IN NS w3scga01.win.smewh.net. corp.verio.net. 0 IN NS stngva1-dc02.corp.verio.net. corp.verio.net. 0 IN NS bcrtfl1-fdc01.corp.verio.net. corp.verio.net. 0 IN NS bcrtfl3-pdevdc2.pdev.verio.net. corp.verio.net. 0 IN NS bcrtfl1-dc04.corp.verio.net. corp.verio.net. 0 IN NS neutde1-dc00. Please point out the trouble with this in one sentence or less. - jared ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Current thinking on internal corporate/campus domain names
On Mon, Jun 23, 2014 at 5:41 PM, Phillip Hallam-Baker ph...@hallambaker.com wrote: As a practical matter .corp is already used for this purpose and ICANN has been forced to accept the practice. So that would be a good choice. One of the problems with .corp is what happens when companies, universities or other organisations (and their networks) merge. There is definitely a case for uniqueness. It would be interesting to have a registry for a TLD that can manage uniqueness, but also guarantee that the TLD will never have active public nameservers (talk about cheap to run!). -- Colm ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Current thinking on internal corporate/campus domain names
On Jun 24, 2014, at 12:29 PM, Robert Willmann robert.willm...@gordito.de wrote: The only situation where this wouldn't be advisable is if you face the possibility that the internal network at some point in time will be merged with the outside world. It is never to engineer a solution based on predicting management behavior. Your internal/external network relationship may change at the whim of company ownership/management policy. Real registered and assigned names and addresses helps insulate your network (and you) from such caprice. signature.asc Description: Message signed with OpenPGP using GPGMail ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Current thinking on internal corporate/campus domain names
Well you could use ADQ2EW-H5BLYG-JSUJEZX-S6QT3I-ZSA.corp But no public CA could issue you any certificates which would mean you can't do IMAP over TLS and many other things you would likely want to do. But there could be a .crypt or .ppe top level domain in which there was no registration fee. People would simply generate a master public key pair, generated the phingerprint (Base64s of the SHA-512-128 hash of the DER KeyInfo encoding of the public key), this would be their second level domain. ADQ2EW-H5BLYG-JSUJEZX-S6QT3I-ZSA.crypt Entries in the zone would naturally be DNSSEC signed and TRANS logged. The DNSSEC KSK would be signed by the master public key corresponding to the zone. You would probably not want to present a zone of that type to end users but you might well use it as the target of a CNAME. Or the binding might be made through a certificate. If you ever lost your Master Key or it was disclosed you would be utterly and totally screwed. On Tue, Jun 24, 2014 at 1:11 PM, Colm MacCárthaigh c...@stdlib.net wrote: On Mon, Jun 23, 2014 at 5:41 PM, Phillip Hallam-Baker ph...@hallambaker.com wrote: As a practical matter .corp is already used for this purpose and ICANN has been forced to accept the practice. So that would be a good choice. One of the problems with .corp is what happens when companies, universities or other organisations (and their networks) merge. There is definitely a case for uniqueness. It would be interesting to have a registry for a TLD that can manage uniqueness, but also guarantee that the TLD will never have active public nameservers (talk about cheap to run!). -- Colm ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Current thinking on internal corporate/campus domain names
On Jun 24, 2014, at 9:29 AM, Robert Willmann robert.willm...@gordito.de wrote: The argument, that you won't get a certificate for these names from someone who is regognized by your browser isn't valid: As you only would use such a internal domain for your internal network, you would have to create a internal CA anyway (and put it in your browsers). You may be much smarter than me, but I have found that establishing and maintaining a full internal PKI is a bit more complicated than purchasing a certificate. Unless you're talking about half-assing it, in which case I'd wonder what the value of the eventual leaf certificates actually are, besides security theater. Is there a use case I am missing where certificates of unknown provenance would be beneficial to operational security? Matt smime.p7s Description: S/MIME cryptographic signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Current thinking on internal corporate/campus domain names
Hi PHB- I'm curious when this scheme would be simpler to implement or less expensive to operate as opposed to using a delegated internal subdomain of an existing parent domain registration (see corp.verio.net modulo the psychopathic NS rrset). I'm certainly no authority but everyone seems to have a much more complicated solution to what I've always found to be a simple problem. Is it the old never expose 1918 addresses in public DNS fetish, or the related must not expose secret internal names via DNS paranoia? Matt On Jun 24, 2014, at 12:05 PM, Phillip Hallam-Baker ph...@hallambaker.com wrote: Well you could use ADQ2EW-H5BLYG-JSUJEZX-S6QT3I-ZSA.corp But no public CA could issue you any certificates which would mean you can't do IMAP over TLS and many other things you would likely want to do. But there could be a .crypt or .ppe top level domain in which there was no registration fee. People would simply generate a master public key pair, generated the phingerprint (Base64s of the SHA-512-128 hash of the DER KeyInfo encoding of the public key), this would be their second level domain. ADQ2EW-H5BLYG-JSUJEZX-S6QT3I-ZSA.crypt Entries in the zone would naturally be DNSSEC signed and TRANS logged. The DNSSEC KSK would be signed by the master public key corresponding to the zone. You would probably not want to present a zone of that type to end users but you might well use it as the target of a CNAME. Or the binding might be made through a certificate. If you ever lost your Master Key or it was disclosed you would be utterly and totally screwed. On Tue, Jun 24, 2014 at 1:11 PM, Colm MacCárthaigh c...@stdlib.net wrote: On Mon, Jun 23, 2014 at 5:41 PM, Phillip Hallam-Baker ph...@hallambaker.com wrote: As a practical matter .corp is already used for this purpose and ICANN has been forced to accept the practice. So that would be a good choice. One of the problems with .corp is what happens when companies, universities or other organisations (and their networks) merge. There is definitely a case for uniqueness. It would be interesting to have a registry for a TLD that can manage uniqueness, but also guarantee that the TLD will never have active public nameservers (talk about cheap to run!). -- Colm ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs smime.p7s Description: S/MIME cryptographic signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Current thinking on internal corporate/campus domain names
On Jun 24, 2014, at 4:29 PM, Matthew Ghali mgh...@snark.net wrote: Hi PHB- I'm curious when this scheme would be simpler to implement or less expensive to operate as opposed to using a delegated internal subdomain of an existing parent domain registration (see corp.verio.net modulo the psychopathic NS rrset). I'm certainly no authority but everyone seems to have a much more complicated solution to what I've always found to be a simple problem. Is it the old never expose 1918 addresses in public DNS fetish, or the related must not expose secret internal names via DNS paranoia? It's possible to have an 'internally' visible zone, but the 'corp.verio.net' example I provided is somewhat like the worst of both worlds. You detail a lot about your zone and internal server IPs without any security benefit at all. One should (ideally) not respond with ULA or 1918 addresses in your or A responses as the behavior can be undefined. What you don't want is to be delegating everything so far that you may have a host querying for an internal resource sending everyone talking to their own local 10.x DNS server because of the way you established NS records. Your VPN and internal resolvers can be an authority on corp.example.com without exposing that to the broader internet. - jared ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Current thinking on internal corporate/campus domain names
Yes, that's very poorly done. The proper way to do that would have been to make the zone authoritative on their internal resolvers, and skipped the delegation records in the parent altogether. Doug On 06/24/2014 01:38 PM, Jared Mauch wrote: On Jun 24, 2014, at 4:29 PM, Matthew Ghali mgh...@snark.net wrote: Hi PHB- I'm curious when this scheme would be simpler to implement or less expensive to operate as opposed to using a delegated internal subdomain of an existing parent domain registration (see corp.verio.net modulo the psychopathic NS rrset). I'm certainly no authority but everyone seems to have a much more complicated solution to what I've always found to be a simple problem. Is it the old never expose 1918 addresses in public DNS fetish, or the related must not expose secret internal names via DNS paranoia? It's possible to have an 'internally' visible zone, but the 'corp.verio.net' example I provided is somewhat like the worst of both worlds. You detail a lot about your zone and internal server IPs without any security benefit at all. One should (ideally) not respond with ULA or 1918 addresses in your or A responses as the behavior can be undefined. What you don't want is to be delegating everything so far that you may have a host querying for an internal resource sending everyone talking to their own local 10.x DNS server because of the way you established NS records. Your VPN and internal resolvers can be an authority on corp.example.com without exposing that to the broader internet. - jared ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Current thinking on internal corporate/campus domain names
Jared Mauch (jared) writes: Beware the mistakes of others as well, check out 'corp.verio.net' as an example of a poorly operated sub-domain. corp.verio.net is indeed a subdomain, and not a registered domain: Sorry, you seem to need more data to observe what i was trying to point out.. No, I agree with you - the sub-domain is mis managed, I was just pointing out that a sub-domain of an existing domain isn't the same as a registered domain. Those are two different options, as far as the original poster is concerned. Please point out the trouble with this in one sentence or less. % dig @10.1.2.1 @corp.XXX.XX ns |grep -w NS | wc -l 91 (another site I've managed) It was fun the day the list of NSes exceeded 512 bytes and they had blocked TCP/53 in the firewalls (and EDNS0 wasn't supported of course). Anyway, back to the topic :) ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Current thinking on internal corporate/campus domain names
RFC 2606 seems to suggest using a registered domain. That¹s great except that split-brain inevitably creeps into the equation. Is this a case of choosing the ³least worst² option? Register a domain, but delegate it to DNS servers that are not in your network and always contains a null-zone. Most registrars will provide you such service for free. Rubens ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Current thinking on internal corporate/campus domain names
Kelly, The “fantasy tld” is a really bad idea. There are several hundred new tld’s coming online and the topic of “collisions” between a fake internal and real external TLD has been the topic of much discussion (Google “icann name collisions”). I definitely vote for the registered name. If you are worried about split brain, most DNS software supports the concept of zones so you can ensure that only your internal network sees your internal naming.. Wayne On Jun 23, 2014, at 1:28 PM, Kelly Setzer kelly.set...@wnco.com wrote: What is current thinking/accepted practice for internal domain names? * Registered domain name (e.g., somecompany.com) * Fantasy tld (e.g., .mycorp) * .local (collides zeroconf/mDNS) This is for use within a corporate/campus setting. In times past, I have taken the fantasy approach. However, colleagues have pointed out that the growing list of new gTLDs and branded TLDs could collide with a fantasy TLD. RFC 2606 seems to suggest using a registered domain. That¹s great except that split-brain inevitably creeps into the equation. Is this a case of choosing the ³least worst² option? Thanks, Kelly *** CONFIDENTIALITY NOTICE *** This e-mail message and all attachments transmitted with it may contain legally privileged and confidential information intended solely for the use of the addressee. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message from your system. Thank you. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs signature.asc Description: Message signed with OpenPGP using GPGMail ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Current thinking on internal corporate/campus domain names
On 23 Jun 2014, at 21:28, Kelly Setzer kelly.set...@wnco.com wrote: What is current thinking/accepted practice for internal domain names? RFC 2606 seems to suggest using a registered domain. That¹s great except that split-brain inevitably creeps into the equation. Is this a case of choosing the ³least worst² option? IMO split DNS using a properly registered domain name is the way to go. That way, you can be *sure* the name won't get hi-jacked for something else in a way that seriously disrupts things for your organisation. [Just like you wouldn't pluck IP addresses out of the air to number your network and hope nobody else will ever use the same prefix.] ICANN policy on TLD naming is subject to change. As is IETF thinking on which domain names are OK for private use. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
[dns-operations] Current thinking on internal corporate/campus domain names
What is current thinking/accepted practice for internal domain names? * Registered domain name (e.g., somecompany.com) * Fantasy tld (e.g., .mycorp) * .local (collides zeroconf/mDNS) This is for use within a corporate/campus setting. In times past, I have taken the fantasy approach. However, colleagues have pointed out that the growing list of new gTLDs and branded TLDs could collide with a fantasy TLD. RFC 2606 seems to suggest using a registered domain. That¹s great except that split-brain inevitably creeps into the equation. Is this a case of choosing the ³least worst² option? Thanks, Kelly *** CONFIDENTIALITY NOTICE *** This e-mail message and all attachments transmitted with it may contain legally privileged and confidential information intended solely for the use of the addressee. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message from your system. Thank you. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Current thinking on internal corporate/campus domain names
On Jun 23, 2014, at 4:28 PM, Kelly Setzer kelly.set...@wnco.com wrote: What is current thinking/accepted practice for internal domain names? * Registered domain name (e.g., somecompany.com) * Fantasy tld (e.g., .mycorp) * .local (collides zeroconf/mDNS) This is for use within a corporate/campus setting. Recipe for Success: 1. Design your DNS namespace as if your network is intimately connected to the Internet. 2. Use internal subdomains for general end systems if needed. 3. Don’t serve the zones for internal subdomains to the Internet at large. 4. Keep in mind that DNS resolution .ne. reachability. 5. Last, but not least, expect policy change from your management about connectivity. Ingredient 1 is key here. signature.asc Description: Message signed with OpenPGP using GPGMail ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Current thinking on internal corporate/campus domain names
On 6/23/2014 1:28 PM, Kelly Setzer wrote: What is current thinking/accepted practice for internal domain names? * Registered domain name (e.g., somecompany.com) * Fantasy tld (e.g., .mycorp) * .local (collides zeroconf/mDNS) You missed a fourth option, which is generally my preference. Use a subdomain of an existing registered domain. I generally like is.example.com, where IS stands for Internal Systems, but feel free to be creative there. Generally a good idea to keep it short though. Numerous advantages, including not having to register/maintain a new name, you control the delegation, etc. hth, Doug ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Current thinking on internal corporate/campus domain names
Doug Barton (dougb) writes: * Registered domain name (e.g., somecompany.com) * Fantasy tld (e.g., .mycorp) * .local (collides zeroconf/mDNS) You missed a fourth option, which is generally my preference. Use a subdomain of an existing registered domain. I generally like is.example.com, where IS stands for Internal Systems, but feel free to be creative there. Generally a good idea to keep it short though. +1. Microsoft has made this their recommended way as well (after years of getting lambasted for suggesting .local and .corp). For Jim suggesting split DNS: please, no. It's troubleshooting hell trying to figure out what the user on the phone is seeing, etc. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Current thinking on internal corporate/campus domain names
As a practical matter .corp is already used for this purpose and ICANN has been forced to accept the practice. So that would be a good choice. But you can't get a CA issued certificate for .corp any more. So you will find that a large number of applications that have embedded assumptions about the use of WebPKI certs will cause headaches. Many companies I have dealt with have a separate corporate domain [e.g. paypal-inc.com] Split horizon DNS is very common and causes a pain because there is no way to know what view of the DNS a particular machine is seeing for a given resolution. This is one of the issues I have looked to clear up in my Private DNS proposal. It is clearly undesirable for internal machine names to be publicly visible or for a particular user or machine/user to have a view of the Internet that varies according to where or how they connect. VPNs are abominable to debug and use. Each machine or user/machine combo should have the same view of the Internet regardless of where it is accessing the net from. This is not possible with traditional DNS but putting in an encryption and authentication layer clears the whole situation up. I don't know if there is a strong privacy case for Encrypting DNS traffic or not. The big problem is that the leverage you get from encrypting the traffic tends to be small if the adversary can perform traffic analysis. But I can make a very strong case that Private DNS makes network admin a lot easier. On Mon, Jun 23, 2014 at 5:37 PM, Phil Regnauld regna...@nsrc.org wrote: Doug Barton (dougb) writes: * Registered domain name (e.g., somecompany.com) * Fantasy tld (e.g., .mycorp) * .local (collides zeroconf/mDNS) You missed a fourth option, which is generally my preference. Use a subdomain of an existing registered domain. I generally like is.example.com, where IS stands for Internal Systems, but feel free to be creative there. Generally a good idea to keep it short though. +1. Microsoft has made this their recommended way as well (after years of getting lambasted for suggesting .local and .corp). For Jim suggesting split DNS: please, no. It's troubleshooting hell trying to figure out what the user on the phone is seeing, etc. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
