upvote

points

by jvuygbbkuurx11 hours ago |
comments
upvoteby reddalo11 hours ago|
next
[-]
Your own spec wouldn't be used by anyone else.

The password-reset well-known endpoint is used by password managers to show a "Change password..." button in their interface, which magically links to the password change page described in that well-known file.

reply
upvoteby jvuygbbkuurx11 hours ago|
parent|
[-]
If the website implements it. What about email preferences? Removing account links? There are many use-cases you might want to redirect a user to, but having to make their own well known for it seems dumb instead of using a more generic one. I guess the more flexible it is, the harder adoption becomes as the usage within a spec might diverge, or it grows outside of the spec and becomes unofficial. So maybe password-reset is correct level of specification.

Anyway discord domain verification can tell in their onboarding docs to put it anywhere. It being well known does nothing. If there was a root level domain verification, then you might as well put it under that. But otherwise why go through a process?

reply
upvoteby notpushkin10 hours ago|
parent|
[-]
It’s just easier for everybody to implement. Password manager opens https://<some-website>/.well-known/change-password in the user’s browser, it gets redirected to the actual page where password change form is located. You could make the password manager look it up in a link tree and then open a correct page, yes, but...

> I guess the more flexible it is, the harder adoption becomes

Yeah. If there is one account management related URL that password managers care about, it’s the change password page. You don’t really need to change email on your account that often, but it is probably a good idea to rotate your password once in a while. So I guess it’s a good idea to make it as easy as possible to adopt – which means just a single URL redirecting to another.

> If the website implements it.

That’s a good catch, though. I guess right now password managers would still have to make a “preflight” request just to see if /.well-known/change-password is implemented before showing it to the user. (But that can go away if most websites adopt it.)

reply
upvoteby masklinn10 hours ago|
parent|
next
[-]
> That’s a good catch, though. I guess right now password managers would still have to make a “preflight” request just to see if /.well-known/change-password is implemented before showing it to the user. (But that can go away if most websites adopt it.)

It’s not really a catch? Like robots.txt it’s just something you probe if you have the capabilities to use it. You can just cache the info afterwards.

reply
upvoteby arcfour11 hours ago|
prev|
next
[-]
> 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. It's far simpler and easier to iterate through the list and compare the start of each value with your search string until you find "discord domain verification" directly than it would be to do anything else.

Example:

    ;; ANSWER SECTION:
    ycombinator.com.        300     IN      TXT     "openai-domain-verification=dv-QbhxxK0G0JK0dnyZ4YTsNAfw"
    ycombinator.com.        300     IN      TXT     "v=spf1 include:_spf.google.com include:mailgun.org a:rsweb1-36.investorflow.com include:_spf.createsend.com include:servers.mcsv.net -all"
    ycombinator.com.        300     IN      TXT     "MS=ms37374900"
    ycombinator.com.        300     IN      TXT     "anthropic-domain-verification-0qe2ww=yK576oHdDgyTcXgkPfj1KXgGt"
    ycombinator.com.        300     IN      TXT     "ZOOM_verify_2ndw8KZxSRa8PT8NmdyXvw"
    ycombinator.com.        300     IN      TXT     "google-site-verification=KsI69Y_jEVkp4eXqSQ9R9gwxjIpZznvuvrus6UolB9Y"
    ycombinator.com.        300     IN      TXT     "ca3-4861b957e83847c188e45d04ec314ee3"
    ycombinator.com.        300     IN      TXT     "apple-domain-verification=WG0sP5Alm7N6h1Te"
    ycombinator.com.        300     IN      TXT     "dropbox-domain-verification=asc63coma4mv"
    ycombinator.com.        300     IN      TXT     "google-site-verification=GJKdQskycEclAGPua3yXB9m_nVhxbrsVps_y-t9SXV0"
    ycombinator.com.        300     IN      TXT     "Wayback verify for support request 741082"
    ycombinator.com.        300     IN      TXT     "google-site-verification=rivq8jKu6AADGtbbEzJhmOpcqq08B7QxIzXxYV8DtyU"
    ycombinator.com.        300     IN      TXT     "rippling-domain-verification=a660f7a4ab77a3de"
reply
upvoteby teddyh8 hours ago|
parent|
next
[-]
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.
reply
upvoteby Bender4 hours ago|
parent|
next
[-]
The domains with large numbers of TXT records are also used in DNS DDoS amplification attacks. Spoofed UDP requests to domains that have a large number of TXT records are used to slam other sites. In the past I would transparently strip the TXT records when I ran public DNS recursive resolvers nobody noticed except the botters but some here may be activated. Some domains with a lot of dangling records:

    for i in $(echo "ycombinator.com 500px.com box.com ebay.com google.com hm.com lenovo.com nordstrom.com realtor.com tmz.com wired.com");do echo -en "${i}:  ";dig +short +nocookie -t TXT "${i}"|wc -l;done|sort -rn -k2
    nordstrom.com:  39
    lenovo.com:  38
    realtor.com:  36
    ebay.com:  36
    hm.com:  34
    box.com:  28
    wired.com:  27
    tmz.com:  22
    500px.com:  17
    ycombinator.com:  13
    google.com:  13
Ebay used to be in first place, not sure what changed.

In unbound.conf:

    local-zone: ycombinator.com typetransparent
    local-data: 'ycombinator.com. TXT "[ddos redacted]"'
after the changes:

    dig +short +nocookie -t txt ycombinator.com
    "[ddos redacted]"
reply
upvoteby somat3 hours ago|
parent|
[-]
Whee, my chance to be the useless use of cat asshole.

Why the echo? "for" should handle a list of terms just fine.

Pedantic assholery aside, genuine question. Is this some sort of shell expansion injection countermeasure of which I am unfamiliar?

And for the record I quite enjoy employing the useless use of cat. It turns pumping a file into a pipeline from a screwball shell meta command into a command isometric to any other command. I sort of wish tee had a "suppress stdout flag" so it could be used more naturally as cat's counterpart.

reply
upvoteby Bender2 hours ago|
parent|
[-]
Whee, my chance to be the useless use of cat asshole.

Would it be mean if I said I do that to expose cat rectum? I used to cat to tac to cat but that was too on the nose. Another fun one is mixed case HtMl elements. I miss that old dokimos site from 2001.

Here's [1] something to play with. not my repo

[1] - https://github.com/bashfuscator/bashfuscator

reply
upvoteby inigyou5 hours ago|
parent|
prev|
[-]
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.

reply
upvoteby quotemstr2 hours ago|
parent|
[-]
Why would you want a new prefix over using record types as they were meant to be used?
reply
upvoteby sandblast11 hours ago|
parent|
prev|
next
[-]
"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".

reply
upvoteby arcfour11 hours ago|
parent|
[-]
Why?
reply
upvoteby zamadatix9 hours ago|
parent|
next
[-]
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.
reply
upvoteby 9 hours ago|
parent|
prev|
next
[-]
deleted
reply
upvoteby 9 hours ago|
parent|
prev|
[-]
deleted
reply
upvoteby bombcar8 hours ago|
parent|
prev|
next
[-]
Domain verifications leak information that they shouldn't - it should be "random key.domain.com in TXT randomkey"
reply
upvoteby 11 hours ago|
parent|
prev|
next
[-]
deleted
reply
upvoteby quotemstr2 hours ago|
parent|
prev|
[-]
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.
reply
upvoteby notpushkin11 hours ago|
prev|
[-]
> discord domain verification

That’s on Discord. They’re not in the registry: https://www.iana.org/assignments/well-known-uris/well-known-...

> Why password-reset instead of a more generic link tree?

[edit: answered in more detail in a sibling thread https://news.ycombinator.com/item?id=48596286]

reply