Update .bd TLD entries

[brian-peter-dickson]

• Description of Organization

• Reason for PSL Inclusion

• DNS verification via dig

• Run Syntax Checker (make test)

• Each domain listed in the PRIVATE section has and shall maintain at least two years remaining on registration, and we shall keep the _PSL txt record in place

Submitter affirms the following:

• We are listing any third party limits that we seek to work around in our rationale such as those between IOS 14.5+ and Facebook (see Issue #1245 as a well-documented example)
• This request was not submitted with the objective of working around other third party limits
• The Guidelines were carefully read and understood, and this request conforms
• The submission follows the guidelines on formatting

---

For Private section requests that are submitting entries for domains that match their organization website's primary domain:

Seriously, carefully read the downline flow of the PSL and the guidelines.
Your request could very likely alter the cookie and certificate (as well as other) behaviours on your 
core domain name in ways that could be problematic for your business.

Rollback is really not predicatable, as those who use or incorporate the PSL do what they do, and when.
It is not within the PSL volunteers' control to do anything about that.  

The volunteers are busy with new requests, and rollbacks are lowest priority, so if something gets broken 
it will stay that way for an indefinitely long while.

(Link: about propogation/expectations)

• Yes, I understand. I could break my organization's website cookies etc. and the rollback timing, etc is acceptable. Proceed.

---

Description of Organization

Organization Website:

Individual.
DNS architect at GoDaddy.
Acting in public interest only

Reason for PSL Inclusion

Enumerating entries otherwise only matched via wildcard.
Use cases for this include Response Policy Zones (RPZ) build from PSL entries.
E.g. RPZ is a regular dns zone, and things of the form "foo.*.bd" do not work, while "foo.co.bd" as a result of enumerating the real second-level entries in the BD ccTLD do work.

DNS Verification via dig

Done using a script. Script is included for reference.

bd-ns.anycast.pch.net is an authority server for bd. TLD

echo "Querying authority server for bd. for specific SLD and 3LD names"
dig +noall +ans @bd-ns.anycast.pch.net NS ac.bd
dig +noall +ans @bd-ns.anycast.pch.net NS co.bd
dig +noall +ans @bd-ns.anycast.pch.net NS com.bd
dig +noall +ans @bd-ns.anycast.pch.net NS edu.bd
dig +noall +ans @bd-ns.anycast.pch.net NS gov.bd
dig +noall +ans @bd-ns.anycast.pch.net NS info.bd
dig +noall +ans @bd-ns.anycast.pch.net NS mil.bd
dig +noall +ans @bd-ns.anycast.pch.net NS net.bd
dig +noall +ans @bd-ns.anycast.pch.net NS org.bd
dig +noall +ans @bd-ns.anycast.pch.net NS sw.bd
dig +noall +ans @bd-ns.anycast.pch.net NS tv.bd
dig +noall +ans @bd-ns.anycast.pch.net NS judiciary.org.bd

Querying authority server for bd. for specific SLD and 3LD names
ac.bd. 86400 IN NS dns.bd.
ac.bd. 86400 IN NS bd-ns.anycast.pch.net.
ac.bd. 86400 IN NS surma.btcl.net.bd.
ac.bd. 86400 IN NS jamuna.btcl.net.bd.
co.bd. 86400 IN NS surma.btcl.net.bd.
co.bd. 86400 IN NS bd-ns.anycast.pch.net.
co.bd. 86400 IN NS dns.bd.
co.bd. 86400 IN NS jamuna.btcl.net.bd.
com.bd. 86400 IN NS jamuna.btcl.net.bd.
com.bd. 86400 IN NS bd-ns.anycast.pch.net.
com.bd. 86400 IN NS dns.bd.
com.bd. 86400 IN NS surma.btcl.net.bd.
edu.bd. 86400 IN NS surma.btcl.net.bd.
edu.bd. 86400 IN NS jamuna.btcl.net.bd.
edu.bd. 86400 IN NS dns.bd.
edu.bd. 86400 IN NS bd-ns.anycast.pch.net.
gov.bd. 86400 IN NS bd-ns.anycast.pch.net.
gov.bd. 86400 IN NS surma.btcl.net.bd.
gov.bd. 86400 IN NS jamuna.btcl.net.bd.
gov.bd. 86400 IN NS dns.bd.
info.bd. 86400 IN NS jamuna.btcl.net.bd.
info.bd. 86400 IN NS dns.bd.
info.bd. 86400 IN NS bd-ns.anycast.pch.net.
info.bd. 86400 IN NS surma.btcl.net.bd.
mil.bd. 86400 IN NS dns.bd.
mil.bd. 86400 IN NS bd-ns.anycast.pch.net.
mil.bd. 86400 IN NS surma.btcl.net.bd.
mil.bd. 86400 IN NS jamuna.btcl.net.bd.
net.bd. 86400 IN NS surma.btcl.net.bd.
net.bd. 86400 IN NS jamuna.btcl.net.bd.
net.bd. 86400 IN NS dns.bd.
net.bd. 86400 IN NS bd-ns.anycast.pch.net.
org.bd. 86400 IN NS dns.bd.
org.bd. 86400 IN NS bd-ns.anycast.pch.net.
org.bd. 86400 IN NS surma.btcl.net.bd.
org.bd. 86400 IN NS jamuna.btcl.net.bd.
tv.bd. 86400 IN NS dns.bd.
tv.bd. 86400 IN NS bd-ns.anycast.pch.net.
tv.bd. 86400 IN NS surma.btcl.net.bd.
tv.bd. 86400 IN NS jamuna.btcl.net.bd.

make test

Yes. Pass = 5.

[dnsguru]

Guidelines ars Sort tld, sld, 3ld each ascending so judicial.org.bd needs to move up under org.bd

[dnsguru]

Know @brian-peter-dickson, and trust him.

That said, we still would need the _psl txt verification to be publicly resolvable before thos could proceed.

This ensures the primaries publishing zone are confirming a deliberate change to cookie handling and other things.

[brian-peter-dickson]

I think the judicial.org.bd might not be legit. And to clarify, I don’t think any of the others change the policy for bd since the wildcard is still present. One other question: I am planning to do similar PRs for almost all of the other CCTLDs which have wildcards, for the same reasons. Would it be preferable to submit a single PR, or do a separate PR for each? Thanks, Brian P.S. the intent is to facilitate RPZ sets for autodiscover immediately below every etld from the PSL’s ICANN section. Not sure if you know of anyone publishing or interested in coordinating something like that. We will be using an RPZ set like this internally only, but there may be more widespread interest in the tools to do this and/or an automated publication point for that. Having the publicsuffix folks do some sort of attestation might be a way of ensuring it is trustworthy. Making the RPZ a zone that is open for AXFR and which has a zonemd plus is DNSSEC signed would be the ideal combination. I am willing to help set it up, but it is the kind of thing that needs a real home and commitment…

…

Sent from my iPhone

On Sep 24, 2021, at 11:19 PM, Jothan Frakes ***@***.***> wrote:  @dnsguru requested changes on this pull request. Guidelines ars Sort tld, sld, 3ld each ascending so judicial.org.bd needs to move up under org.bd — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[dnsguru]

The challenge is that without the cctld placing txt records to validate, it might end up being disposible labor, as much as it is appreciated On Sat, Sep 25, 2021, 1:59 AM Brian Dickson ***@***.***> wrote:

…

I think the judicial.org.bd might not be legit. And to clarify, I don’t think any of the others change the policy for bd since the wildcard is still present. One other question: I am planning to do similar PRs for almost all of the other CCTLDs which have wildcards, for the same reasons. Would it be preferable to submit a single PR, or do a separate PR for each? Thanks, Brian P.S. the intent is to facilitate RPZ sets for autodiscover immediately below every etld from the PSL’s ICANN section. Not sure if you know of anyone publishing or interested in coordinating something like that. We will be using an RPZ set like this internally only, but there may be more widespread interest in the tools to do this and/or an automated publication point for that. Having the publicsuffix folks do some sort of attestation might be a way of ensuring it is trustworthy. Making the RPZ a zone that is open for AXFR and which has a zonemd plus is DNSSEC signed would be the ideal combination. I am willing to help set it up, but it is the kind of thing that needs a real home and commitment… Sent from my iPhone > On Sep 24, 2021, at 11:19 PM, Jothan Frakes ***@***.***> wrote: > >  > @dnsguru requested changes on this pull request. > > Guidelines ars Sort tld, sld, 3ld each ascending so judicial.org.bd needs to move up under org.bd > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub, or unsubscribe. > Triage notifications on the go with GitHub Mobile for iOS or Android. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1432 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACQTJN7DXHHH5FIX4NCWMDUDWFOHANCNFSM5EW32G3Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[dnsguru]

Closing, see #1439 - the DNS Validation portion of this is crucial to any changes in the 'ICANN section'. The time and focus / attention are appreciated @brian-peter-dickson - these can be re-opened if the NIC adds validation entries into the DNS so these can be verified.

[dnsguru]

P.S. the intent is to facilitate RPZ sets for autodiscover immediately below every etld from the PSL’s ICANN section. Not sure if you know of anyone publishing or interested in coordinating something like that. We will be using an RPZ set like this internally only, but there may be more widespread interest in the tools to do this and/or an automated publication point for that. Having the publicsuffix folks do some sort of attestation might be a way of ensuring it is trustworthy.

A lot of the 'consumers' / 'integrators' of the PSL do their own 'secret-sauce' adds/removes on the PSL before repackaging or purposing the list... see htttps://tranco-list.eu as an example of security use.

Making the RPZ a zone that is open for AXFR and which has a zonemd plus is DNSSEC signed would be the ideal combination. I am willing to help set it up, but it is the kind of thing that needs a real home and commitment…

Reach out to John Levine from the ICANN community about this idea, he's possibly 5-6 chess moves ahead on such a gambit.