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

Update suffixes in the usTLD #276

Closed
wants to merge 2 commits into from
Closed

Conversation

pzb
Copy link

@pzb pzb commented Aug 6, 2016

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.

@sleevi
Copy link
Contributor

sleevi commented Aug 6, 2016

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.

@pzb
Copy link
Author

pzb commented Aug 6, 2016

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:

@pzb
Copy link
Author

pzb commented Aug 6, 2016

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.

@pzb
Copy link
Author

pzb commented Aug 7, 2016

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

  • us
  • dni.us
  • fed.us
  • isa.us
  • kids.us
  • nsn.us
  • *.<state>.us (52 rows)
  • 45 fourth level suffixes
  • 1657 exclusions

However this seems a little fragile, as it relies heavily on exclusions.

@pzb
Copy link
Author

pzb commented Mar 23, 2017

Ping? This has been open for months with no feedback.

@pzb
Copy link
Author

pzb commented Jun 17, 2017

Ping again.

@gerv
Copy link
Contributor

gerv commented Jun 20, 2017

@sleevi?

@sleevi
Copy link
Contributor

sleevi commented Jun 20, 2017

@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)

@gerv
Copy link
Contributor

gerv commented Jun 20, 2017

@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 :-)

@sleevi
Copy link
Contributor

sleevi commented Jun 20, 2017

@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.

@gerv
Copy link
Contributor

gerv commented Jun 20, 2017

@sleevi Embrace the fear :-)

@sleevi
Copy link
Contributor

sleevi commented Jun 20, 2017

@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?

@dnsguru
Copy link
Member

dnsguru commented Jun 20, 2017 via email

@weppos
Copy link
Member

weppos commented Jun 21, 2017

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?

@sleevi
Copy link
Contributor

sleevi commented Jun 21, 2017

@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 :)

@pzb
Copy link
Author

pzb commented Jun 21, 2017

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 denver.co.us is not currently in the PSL.

@gerv
Copy link
Contributor

gerv commented Jun 22, 2017

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...

@dnsguru
Copy link
Member

dnsguru commented Feb 26, 2020

Closing for now as wontfix and will ask registry to look at the request and take next steps.
Size of requested section may also be a consideration per #981

@dnsguru dnsguru closed this Feb 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants