3 ms·

> Why discord domain verification instead of domain-verifications with a dynamic list on entries? The TXT record itself is already a dynamic list of entries. I

• sandblast 4mo ago
  "Domain-verifications" is an invitation for everyone else that might need it to use the same standard and convention. "Discord-domain-verification" is not, it's what feels like polluting the global namespace with the company name that might cease to exist in a few years. At the very least, it should be "domain-verification-discord", "-google" and so on. Maybe even "-com.discord", "-com.google"? And the first part clearly standardized and registered, instead of one entity using "domain" and another one "site".
  • arcfour 4mo ago
    Why?
    • deleted 4mo ago
      [deleted]
    • deleted 4mo ago
      [deleted]
    • zamadatix 4mo ago
      Why reinvent the wheel differently 50,000 times instead? I'll usually even prefer a badly designed, but standard, format/encoding over a NIH one from each company - it's just less friction in the end. Heck - include a common format for the value too, then it opens up doors to automating generation with new sites & automatically validating this config for any site following the common format.
• deleted 4mo ago
  [deleted]
• bombcar 4mo ago
  Domain verifications leak information that they shouldn't - it should be "random key.domain.com in TXT randomkey"
• teddyh 4mo ago
  Having all those TXT records at the domain apex like that makes the TXT query reply huge, which affects, for instance, every mail recipient who merely wants to check the SPF record. This is a bad pattern to follow.
  • inigyou 4mo ago
    The better pattern is to use an underscore prefix like _discord-verification.domain.com If your site allows user-created subdomains it shouldn't allow leading underscore. This is reserved somehow.
    • quotemstr 4mo ago
      Why would you want a new prefix over using record types as they were meant to be used?
      • teddyh 4mo ago
        Because: 1. Practically, the process for creating a new DNS record type is bureaucratic and slow. 2. New record types have a limited number, but names are unlimited as long as they are unique. 3. If the data you’re storing is perfectly compatible with an existing record type, like TXT, it seems silly to overload semantics into a new, but otherwise identical, record type. You can compare record types to variable types in a programming language. I.e. instead of having name_t x = "foo"; /* C */ x: Name = "foo" # Python x IN NAME "foo" ; DNS you instead have: char *name = "foo"; /* C */ name: str = "foo" # Python _name IN TXT "foo" ; DNS Sure, DNS might not have integer types, but it has host names (PTR), IP addresses (AAAA and A), and strings (TXT, which also can work as an array of strings up to 255 bytes in length if you prefer). These, with added semantics of an underscored name prefixed, will get you quite far without having to invent a new record type to contain your specific semantic meaning to, say, a plain TXT record.
      • inigyou 4mo ago
        because IANA won't allocate a number for discord domain verification
• quotemstr 4mo ago
  Literally the inner platform effect. We have multiple kinds of DNS record. Let's use them instead of creating a key value store inside a key value store.