Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt
John Levine wrote on 2023-07-19 14:43: It appears that Paul Wouters said: On Jul 17, 2023, at 22:50, Paul Vixie wrote: ... RFC 4408 was folly. ... The IETF did make a mistake there for sure. I wouldn't disagree, but you can barely see the spots in the dirt where the barn was before the horse left. Viz the pile of junk at the apex of any domain of any organization of any size. If performance or token collisions were a practical problem, surely someone would have noticed by now. that's false in several ways. we do notice. we cope, at some cost. we ought to learn a lesson from each mistake, and gradually turn ship. your fatalism is unbecoming. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-02.txt
It appears that Paul Wouters said: >On Jul 17, 2023, at 22:50, Paul Vixie >wrote: >> >> >> >>> Agreed, but that horse had already left the barn when we published the >>> first SPF RFC 4408. >> RFC 4408 was folly. TXT in a subdomain (RFC 5507 s3.2) would suit domain >> verification well (wildcards aren't a >factor) and would in no way be precluded by the SPF design. > >The IETF did make a mistake there for sure. I wouldn't disagree, but you can barely see the spots in the dirt where the barn was before the horse left. Viz the pile of junk at the apex of any domain of any organization of any size. If performance or token collisions were a practical problem, surely someone would have noticed by now. In any event, per Shumon's message there are plenty of administrative reasons to encourage people to put their tokens at _name without reference to how much stuff there is or isn't at the apex. R's, John PS: Let's visit the Ivy League! $ host -t txt harvard.edu harvard.edu descriptive text "globalsign-domain-verification=9ff12eafbeebb02a0f2b0383aef9d1fa" harvard.edu descriptive text "globalsign-domain-verification=5A1F4E0081852ECB9015E837384121AD" harvard.edu descriptive text "fastly-domain-delgation-vdnblsdg768nm-21052021" harvard.edu descriptive text "v=spf1 redirect=_spf.harvard.edu" harvard.edu descriptive text "ciscocidomainverification=41ce9827e3fbbca9ce75d5dbb5a6bc7b089dc4e239c1b56ba828216d1214480" harvard.edu descriptive text "MS=ms35192554" harvard.edu descriptive text "globalsign-domain-verification=87677a19ae97bfbeec25ff1510a80420" harvard.edu descriptive text "google-site-verification=xqg8LPF_v_QMEIST789q8xhRDqUEX4_8lQjAvV6YykY" harvard.edu descriptive text "google-site-verification=pWvLuNePLYxAbafZw2a95vnBhvcj12DzM9NulT9ujSY" harvard.edu descriptive text "xIGeuA0e5B1BOjTE4IBO806ziFX9G1m2dVJ8zO7CMkmKwZ6MEkMXC0P7n5SRCGOdS9jbceH/7gKYgD4h9FBGKA==" harvard.edu descriptive text "heroku-domain-verification=1qfmzz9vp3kexf4fr5zuliwvpieih2ffz4gexo7tlh4" harvard.edu descriptive text "jAykGnWytyLeBseMa8x2/MBve6/yQqana4yrAc1ROoei7uZHUkM2FU0Xx4qI/rm+kOGdImZdoq0fdodgLEw1dg==" harvard.edu descriptive text "pardot962443=9098884472c5cb29a2e20700b41411cb4aa5ebcf340360e71b2cd8464d8864b6" harvard.edu descriptive text "globalsign-domain-verification=dcc2e5d0d67efc32044ae679c7cf19e6" harvard.edu descriptive text "pardot679353=f93ea3588d69483bf48dbf587511f51d43ddadaae52b8bac6856c8428559a06d" harvard.edu descriptive text "airtable-verification=a92cef30671587a4f6deb7951c1c3f1a" harvard.edu descriptive text "status-page-domain-verification=p83gt91wpxms" harvard.edu descriptive text "status-page-domain-verification=b4j4g69th3vv" harvard.edu descriptive text "google-site-verification=DzhZyP8pu0M1-RFghfTcSN-9poidboYRNdfn2Rf2hCQ" harvard.edu descriptive text "pardot378242=7001579db574e062735763ba81b54da111abc31facf16bbfa653ab6b8a770988" harvard.edu descriptive text "pardot_378242_*=8b485d5cd9114869cff8f307da5fa9287434ebec11621d88c07ce97a7fee06e0" harvard.edu descriptive text "globalsign-domain-verification=1C94E0FFAAE95796F597427644D90C03" harvard.edu descriptive text "smartsheet-site-validation=jfLh_IkQNJXuKKpTn7RydwiiaAOLy4CR" harvard.edu descriptive text "pardot679353=3cc5e124c5020a1e160f01981f45be33a467a1c802711e0e5654184ef56d18c9" harvard.edu descriptive text "google-site-verification=lY-T8NneGQX1RGXeaoBJjSmT_lx3dLRKDq1xY44ZI5w" harvard.edu descriptive text "adobe-idp-site-verification=66e813947c764d98330002232f383a68df8ad609065abb9482f3805dd2a1902c" harvard.edu descriptive text "atlassian-domain-verification=Z8oUd5brL6/RGUMCkxs4U0P/RyhpiNJEIVx9HXJLr3uqEQ1eDmTnj1eq1ObCgY1i" harvard.edu descriptive text "Peh2GHoW8uiAzwS9tTZKlGBn9cMq6Y+XUFtrqmLtqFh1WvloPkzGczPsZcSdDfin4hZ7QiL9J7SM8yr7Yyzi8w==" $ host -t txt yale.edu yale.edu descriptive text "airtable-verification=5faa4d445f2f11d5a2e0d2dff8c4d287" yale.edu descriptive text "amazonses:9Ya8iDYeN700mkvk/yE/JXHlH/zQjYAA6+XyWlnms+E=" yale.edu descriptive text "atlassian-domain-verification=d6trxstBXPKZ-Fn96brt+2GuIbtk29HYhBAdLyXwH1GGOd5OqEaoeX1j7Iako4Y8" yale.edu descriptive text "d365mktkey=Nf1xniLZCW9LJtMAKbxJ4QluH18K7RKSYYw5ndrkxlox" yale.edu descriptive text "d365mktkey=qXRmZD4AqCPHhxJWI7EnhD5InEkYOsYQ6eidVZHnCyAx" yale.edu descriptive text "docusign=a560f5e1-1b15-42e8-9630-f9f375c0d326" yale.edu descriptive text "docusign=e8f08e07-8b40-4ae4-a8cf-7ce972d4b382" yale.edu descriptive text "dropbox-domain-verification=y270qicvbi7s" yale.edu descriptive text "e2ma-verification=tmfcb" yale.edu descriptive text "facebook-domain-verification=4b2v2cdl4pnhet6qnrtzuof73xy5ic" yale.edu descriptive text "google-site-verification=fUwYVutFF-kUCTqnDZg7s4lWZSUTOO2k2zHogw_1qYw" yale.edu descriptive text "google-site-verification=wAcIxfMZtLARxIU3MA82C9ywf-MODgjwuP2JdcSvs3E" yale.edu descriptive text "google-site-verification=wLNdYe7PcFN1GTfpDeWAT-aPFTWpa_fMn7ZWDw07cuc" yale.edu descriptive text
Re: [DNSOP] should all ccTLD be on the Public Suffix list?
On Jul 19, 2023, at 01:54, Paul Vixie wrote: > > > > George Michaelson wrote on 2023-07-18 22:41: >> ... >> my concerns with the PSL governance aren't relevant either. I am sure >> it was purposeful. I don't have to like things for them to provide >> upsides. > > when we've tried to talk about solving the PSL's original problem > differently, we've run into the brick wall of "well it's just for web cookie > same-origin policy, let's let the browser makers decide what to do." > > it's not. (not just a web thing.) yes the web also needs it. but every > dns-aware application also needs it. we just can't get those people to > represent themselves as well as the browser makers can. > > some friends and i are working on something. but if we can't get someone > not-from-the-web to say why something-like-PSL is important, it will not > matter. see also attached image. Didn’t we re-open dbound to give this another try ? https://datatracker.ietf.org/wg/dbound2/about/ https://datatracker.ietf.org/doc/draft-tjw-dbound2-problem-statement/ Paul W___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] should all ccTLD be on the Public Suffix list?
Why is this discussion here and not on the PSL mailing list (https://groups.google.com/g/publicsuffix-discuss)? Having it there would greatly increase the chance that the discussion would actually help the PSL. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] should all ccTLD be on the Public Suffix list?
On 7/19/23 02:42, George Michaelson wrote: So, given it exists, systems are coded to behave against it, and not having SOME ccTLD (and I would posit gTLD) on it, means they don't match as "first class citizens" the behaviour the PSL brings. Actually, the PSL matching algorithm is such that all TLDs are considered public suffixes: | Match domain against all rules and take note of the matching ones. | If no rules match, the prevailing rule is "*". https://github.com/publicsuffix/list/wiki/Format#algorithm Thus, absent a negative rule that would declare a TLD a private suffix, the algorithm labels TLD suffixes public. However, there are no top-level exemptions defined: $ grep '^!' public_suffix_list.dat !www.ck !city.kawasaki.jp !city.kitakyushu.jp !city.kobe.jp !city.nagoya.jp !city.sapporo.jp !city.sendai.jp !city.yokohama.jp Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] should all ccTLD be on the Public Suffix list?
What you also missed (in the original post (not quoted any longer)) is that there is a distinction between the ISO "list" and the list of delegations. I agree that there should be a delegation corresponding to EVERY 2 Letter Code Element but that is not the case (and I don't see that changing soon). And while I also agree that all delegated TLDs (g and cc) should be in the PSL (with their internal policy organization, if relevant), ICANN has nothing to do with the PSL and will not play any role here. greetings, el On 19/07/2023 11:50, George Michaelson wrote: > Joe, it's clear I didn't understand and I've been hit with quite enough > cluesticks for today. > > I missed the wildcards in my parse and having accounted for them I now > see reality as it is. > > George [...] -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist e...@lisse.na / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 Bachbrecht \ / If this email is signed with GPG/PGP 10007, Namibia ;/ Sect 20 of Act No. 4 of 2019 may apply ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] should all ccTLD be on the Public Suffix list?
Joe, it's clear I didn't understand and I've been hit with quite enough cluesticks for today. I missed the wildcards in my parse and having accounted for them I now see reality as it is. George On Wed, 19 July 2023, 19:26 Joe Abley, wrote: > On Wed, Jul 19, 2023 at 02:42, George Michaelson > wrote: > > I know, I could submit these to the PSL website directly. > > > I think anybody can submit anything they want, but the PSL volunteers have > quite a strict set of internal guidelines for what they will accept. See > https://publicsuffix.org/submit/ for some details. I have helped some > TLDs with the github dancing required to maintain their data before and my > experience is that these guidelines are taken seriously. > > The following ccTLD are in ISO3166 but not in the PSL: > > > Many of the domains you mention are in fact included in the PSL but the > policy boundary is not directly below the top-level label. There's a policy > boundary below com.bd and net.bd, for example, but not directly below bd, > and this is reflected in the current list. Not all TLDs have the same > kind of policy boundary (if they did, arguably we would need the PSL). > > Of the remaining domains most are not active, which means in practical > terms there is no policy to publish, so the gap in the PSL seems entirely > accurate. For example bq is present on iso 3166-2 but is not delegated from > the root zone. > > The only TLD from your list that is delegated and doesn't seem to publish > a policy in the PSL is er. It seems hard to find definitive policy about > registration under er in general, not just on the PSL, so again perhaps the > PSL is reflecting reality quite accurately. > > Operationally, much though I dislike the PSL (for entirely subjective > reasons I might add,mostly around governance and ancient history) it > exists, no matter what I think about it. So, given it exists, systems > are coded to behave against it, and not having SOME ccTLD (and I would > posit gTLD) on it, means they don't match as "first class citizens" > the behaviour the PSL brings. > > > Checking the list you included in this message seems to suggest that all > ccTLDs that have policy to publish have already done so. Unless I > misunderstand you, it doesn't seem like there is a problem here to solve. > > > Joe > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] should all ccTLD be on the Public Suffix list?
On Wed, Jul 19, 2023 at 11:26, Joe Abley <[jab...@strandkip.nl](mailto:On Wed, Jul 19, 2023 at 11:26, Joe Abley < wrote: > Not all TLDs have the same kind of policy boundary (if they did, arguably we > would not > need the PSL). Whoops. Joe___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] should all ccTLD be on the Public Suffix list?
On Wed, Jul 19, 2023 at 02:42, George Michaelson <[g...@algebras.org](mailto:On Wed, Jul 19, 2023 at 02:42, George Michaelson < wrote: > I know, I could submit these to the PSL website directly. I think anybody can submit anything they want, but the PSL volunteers have quite a strict set of internal guidelines for what they will accept. See https://publicsuffix.org/submit/ for some details. I have helped some TLDs with the github dancing required to maintain their data before and my experience is that these guidelines are taken seriously. > The following ccTLD are in ISO3166 but not in the PSL: Many of the domains you mention are in fact included in the PSL but the policy boundary is not directly below the top-level label. There's a policy boundary below com.bd and net.bd, for example, but not directly below bd, and this is reflected in the current list. Not all TLDs have the same kind of policy boundary (if they did, arguably we would need the PSL). Of the remaining domains most are not active, which means in practical terms there is no policy to publish, so the gap in the PSL seems entirely accurate. For example bq is present on iso 3166-2 but is not delegated from the root zone. The only TLD from your list that is delegated and doesn't seem to publish a policy in the PSL is er. It seems hard to find definitive policy about registration under er in general, not just on the PSL, so again perhaps the PSL is reflecting reality quite accurately. > Operationally, much though I dislike the PSL (for entirely subjective > reasons I might add,mostly around governance and ancient history) it > exists, no matter what I think about it. So, given it exists, systems > are coded to behave against it, and not having SOME ccTLD (and I would > posit gTLD) on it, means they don't match as "first class citizens" > the behaviour the PSL brings. Checking the list you included in this message seems to suggest that all ccTLDs that have policy to publish have already done so. Unless I misunderstand you, it doesn't seem like there is a problem here to solve. Joe___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
