-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Update suffixes in the usTLD #276
Conversation
I'm inclined to think that if these should be added at all, they should simply be added at the wildcard level. That is, *.al.us I'm not sure there is any concrete value, but there is significant harm, in enumerating these when the follow a common pattern. |
There is not a shared pattern. The usTLD has varying registration levels. There are at least 2387 names in the form ..us which have IP addresses assigned. For example, the following are all websites: |
I just ran a count -- there are over 3000 records in the us zone file of NS type that have three name labels where the second label is two characters. |
Looking at the us zone file again, there are 52 suffixes that are two characters + ".us" (fifty two letter state abbreviations plus "dc" and "pr"). There are zero records for one or two character SLDs. There are 5578 suffixes or domains at the third level. 3271 of these are delegations; the remaining 2307 are only suffixes. Additionally there are 45 suffixes at the forth level. Of the third level domains that are delegated, 1657 have associated A or AAAA records (including one which returns a CNAME with a valid target). Given this, it is might be possible to restructure the us section to be
However this seems a little fragile, as it relies heavily on exclusions. |
Ping? This has been open for months with no feedback. |
Ping again. |
@gerv Is there a question or otherwise specific action you're requesting? This seems to share many of the similar issues as #277 , and similarly, a question of whether some of these domains are 'shared infrastructure without distinct control' (thus not needing PSL separation), as we've seen with some of these domains (especially around US libraries) |
@sleevi Well, someone needs to make a call on whether this should be merged (or an alternative patch which improves things without adding 2000+ lines to the PSL). If you think No, I'm happy to accept your call :-) |
@gerv Well, that's a question about the share understanding about what an acceptable reason to decline is. If I get to say no, then sure, I'll say no - but I'm also terrified by being the sole person to determine. |
@sleevi Embrace the fear :-) |
@gerv My concern is to ensure we're consistent and clear on the policies. Right now, the outstanding question is whether there is an upper bound to the number of entries (for a given TLD) we'll accept, and if we reach that limit, how we deconflict. For example, 2000 entries for .name operated by a single entity arguably seems unreasonable. 2000 entries for .com operated by independent entities seem reasonable. In the question of finding where that limit is, perhaps it's worthwhile to explore the current usage (per TLD) and try to derive some number from it. As a second-order effect though, we also see the variety of dynamic-DNS services, in which they may represent names under a variety of TLDs, but collectively exceed some 'reasonable' limit. That is, imagine a dynamic DNS service with 2000+ 'service' domains - is that a reasonable PR? |
I seem to recall that .us had an RFC https://tools.ietf.org/html/rfc1480 if
it is at all helpful.
Later, .us was liberalized and opened up to second level registrations, so
we have legacy RFC1480 and new style co-existing.
…On Jun 20, 2017 5:29 AM, "sleevi" ***@***.***> wrote:
@gerv <https://github.com/gerv> My concern is to ensure we're consistent
and clear on the policies. Right now, the outstanding question is whether
there is an upper bound to the number of entries (for a given TLD) we'll
accept, and if we reach that limit, how we deconflict.
For example, 2000 entries for .name operated by a single entity arguably
seems unreasonable. 2000 entries for .com operated by independent entities
seem reasonable.
In the question of finding where that limit is, perhaps it's worthwhile to
explore the current usage (per TLD) and try to derive some number from it.
As a second-order effect though, we also see the variety of dynamic-DNS
services, in which they may represent names under a variety of TLDs, but
collectively exceed some 'reasonable' limit. That is, imagine a dynamic DNS
service with 2000+ 'service' domains - is that a reasonable PR?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#276 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAUJpdibrdnva-4-8-pPdJ18YlC33pOMks5sF7sVgaJpZM4JeUsf>
.
|
It's worth to remember that the .JP has ~1700 entries in the list so far, and .IT also has quite a large number. Hence my question: why did we allow .JP, and we instead consider the number of entries to be too large for US? |
@weppos Best I can suggest is "first come, first serve" and "we didn't think principled at the time about the growth rate relative to the value/need" Hence my unease of just saying no, but also my unease of saying yes, and the desire to find principles we can reliably use :) |
I just pulled the .us zone info for 2017-06-21. The number of registry controlled suffixes has not notably changed. The current count is 2397. As @dnsguru pointed out, many of the "registered" domains are actually delegations to a subordinate registry. The 2397 count ignores this and only looks at suffixes that have registrations in the .us zone file. The top 20 suffixes by Neustar (registry) registered domains are: .us. 2543127
.k12.ca.us. 812
.tx.us. 364
.il.us. 262
.k12.ny.us. 229
.ca.us. 204
.oh.us. 172
.sc.us. 168
.k12.co.us. 153
.k12.va.us. 128
.ma.us. 121
.denver.co.us. 116
.wa.us. 112
.state.ny.us. 112
.pa.us. 107
.nd.us. 107
.mo.us. 99
.ia.us. 98
.in.us. 90
.nh.us. 88 As you can see, one of the most popular |
If we were able to consistently get hold of zonefiles, we might adopt a "popular" policy in these cases, but that would require rerunning the tests every so often, which is a bit of an administrative burden... |
Closing for now as wontfix and will ask registry to look at the request and take next steps. |
The usTLD has "locality-based" suffixes which are not currently in the list. The list also includes some items that are purported to be suffixes but simply don't exist.