Hiya,
On 14/08/2022 03:59, rubensk=40nic...@dmarc.ietf.org wrote:
On Kerberos, we need to note that one use case of Kerberos is Microsoft Active Directory; MS AD is behind a number of name collisions that happened in the 2012 root zone expansion, including one string that will likely never show the light of day in the root (.corp). So, this might be the telltale sign, not the good fortune ahead one.
I'd interpret that as a positive still - despite the fact that kerberos naming is so widely deployed, and has been for decades, the impact on the DNS isn't serious - one or so of the labels from the huge namespace of potential new tlds wasn't usable when ICANN ran their gTLDs-via-money process, but otherwise stuff works fine even if it can sometimes be confusing as to how kerberos realms and DNS domains do or don't map to one another. Cheers, S.
We also could think into this in terms of what we can do; .alt, .arpa and .internal all look feasible and could alleviate potential collisions(.arpa already succeeded in .home.arpa). Will blockchain start-ups adopt them ? Likely not, because they just want the end run around ICANN and couldn't care less about interoperability. But by providing those that do care with options, we get more friends and less foes. RubensOn 13 Aug 2022, at 23:27, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: Signed PGP part So I think this discussion might benefit from also remembering that we have a decades-long and widely deployed history of IETF standardname forms that use the same name syntax as domain names that may or may not be related to names used in the DNS.Kerberos [1] does exactly that. And the sky never fell, nor has anyone had to pay large numbers of currency units to pick a kerberos realm name afaik. I'm not saying this solves the conundrum, but I do assert that this fact invalidates some arguments to the effect that the IETF cannot standardise another "global" name form using the same syntaxbecause of problems that may or may not be caused by overlaps in the name spaces - we've not had critical problems with doing justthat for nearly 30 years. (Since RFC1510.) Cheers, S.[1] https://www.rfc-editor.org/rfc/rfc4120#page-55 <OpenPGP_0x5AB2FAF17B172BEA.asc>_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
