Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add reserved testing TLDs from RFC2606 #1537

Closed
dveditz opened this issue Mar 15, 2022 · 5 comments
Closed

Add reserved testing TLDs from RFC2606 #1537

dveditz opened this issue Mar 15, 2022 · 5 comments
Assignees
Labels
❌wontfix Will not be merged. Reason typically included in PR/Issue as to why

Comments

@dveditz
Copy link

dveditz commented Mar 15, 2022

It would be nice if the testing TLDs reserved in RFC 2606 (updated in RFC 6761) behaved like a real TLD for testing purposes (for example, could be counted on to isolate cookies for sibling domains from each other). The following should be added to the PSL:

example
localhost
test

".invalid" is also reserved but it seems unnecessary to add to the PSL since it should return DNS lookup errors.

I'd be happy with just the original RFC 2606 reserved TLDs, but we could also consider adding

  • ".local" (rfc 6762)
  • the IANA-reserved IDN test domains, though that's currently marked "experimental" and I have no feel for how likely those might end up being permanent.
@dveditz
Copy link
Author

dveditz commented Mar 15, 2022

This does not satisfy the desire for a public service as described in #1349, but these TLDs are both reserved for and in common use for internal testing scenarios.

@sleevi
Copy link
Contributor

sleevi commented Mar 16, 2022

@dveditz We've discussed this several times, including with @gerv , and ultimately decided not to.

e.g #2 and https://bugzilla.mozilla.org/show_bug.cgi?id=1161102

The question, I think, is what special behaviour would be granted by adding these, given the extant * rule. Those generally seem to highlight bugs in assumptions - but if there are places in browsers where this distinction now matters, perhaps its worth digging into, because they'll also have issues with new TLDs?

@dnsguru
Copy link
Member

dnsguru commented Mar 16, 2022

We have a good discussion in #1515 on this more recently. The crux of this is there is strong reticense to affectation of status-quo norms and expected behavior widely via PSL change vs allowing application developers to do their own thing.

@dnsguru dnsguru added the ❌wontfix Will not be merged. Reason typically included in PR/Issue as to why label Mar 18, 2022
@dnsguru dnsguru self-assigned this Mar 18, 2022
@dveditz
Copy link
Author

dveditz commented May 17, 2022

@dnsguru I am confused about the state of this issue. I assumed the "wontfix" I saw in mail was the end of it (in bugzilla it closes an issue), and I accept the discussion above that led to that decision. I just realized this still "open". Is it waiting for me to close it? But you assigned it to yourself at the same time as applying the wontfix label so maybe there's some undocumented task spun out of this?

I'm happy to close it or have it closed; this issue seems to have come to an end.

@dveditz
Copy link
Author

dveditz commented May 17, 2022

I'm going to assume the reason is the same as #1515 (comment)

Rather than closing this now, will leave as a wontfix and let discussion or updates happen if they will.
Talk us out of this being a wontfix, basically.

@dveditz dveditz closed this as completed May 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
❌wontfix Will not be merged. Reason typically included in PR/Issue as to why
Projects
None yet
Development

No branches or pull requests

3 participants