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
