Notices by Patrick Mevzek (pmevzek@framapiaf.org)

@feld "And does this mean we can blame ICANN for causing our domain prices to keep increasing?" "ICANN tax" of $0.18 in gTLD hasn't changed. And prices go up in ccTLDs as well I think (who can give $0 to ICANN), so… I don't think most registries could explain their prices go up only because of ICANN. Which doesn't mean it is necessarily a good idea for a "regulator" to manage multi hundreds millions of dollars without maybe the needed oversight.

@feld ICANN has lots of constituencies/stakeholders (registries, registrars, LEA, IP, etc.) but barely registrants and even less software developers or open source ones. Aka: that specific funding will never happen.

@feld Their PR: https://www.icann.org/en/blogs/details/icann-sets-expected-evaluation-fee-for-new-gtld-applications-in-the-next-round-25-09-2024-en#main ; Fee is said to be "just" to cover the cost to be revenue-neutral (seems in domain names there are no economy at scale… as more gTLDs are expected at this round than previous). As for previous money (gTLDs auctions, etc.) not used a decade after, there is a grant program to see how to dispose of $217 millions :-) https://domainincite.com/29692-icann-opens-217-million-grant-program

ICANN: "I'm happy to report that the Internet Corporation for Assigned Names and Numbers (ICANN) has set the expected evaluation fee for the next round of new generic top-level domain (gTLD) applications. The expected fee will be USD $227,000."

@bortzmeyer Contacts can be sent through EPP, but publicly redacted by registry so not appearing through (public) RDAP as they were through EPP.

@bortzmeyer It is already dubious, if it appears (and is authoritative there) in DNS, why it has to be in RDAP, as this seems to have more drawbacks (DNS and RDS have no reason to be publishing updates synchronously and at same frequency) than benefits. I doubt the TTL extension will be offered by lots of registries (probably none I would bet - there are already parts of secDNS extension about signature lifetimes NOT offered by any registry), so the point will be mostly solved that way.

@shaft @bortzmeyer Aka `pass` en Python ou `...` en Perl?

@sebsauvage Je pense que ca rentre dans le cas du contrat trop long que personne ne lit (qui déposant un nom en `.ai` a lu le point 12 de http://whois.ai/faq.html précisément et en particulier le sous-point 10.4?), couplé au fait que le fonctionnement (ici sur les aspects gouvernance plus que technique) du DNS est très peu connu (et brouillé par du marketing "discutable"), d'où les régulières "surprises"/(re)découvertes comme ".me" est le Monténegro, ou ".tv" les îles Tuvalu…

@shaft @bortzmeyer @Framasoft ... quand la décision sort de l'équipe marketing, et qu'après elle arrive dans l'équipe technique qui doit alors, étrangement, elle, faire un bilan coût/bénéfice et justifier les dépenses à sa hiérarchie. Il y a des modes. Par le passé tout le monde voulait son serveur racine. Puis on a entretenu l'idée que ca serait pas mal que tout le monde ait son TLD, etc.

@shaft Et c'est débile dans les deux cas, mais ca découle de ce positionnement incorrect de dire "secure DNS = DOH". Alors que pour avoir ECH correctement, il faut DNSSEC, sinon c'est contournable. Les états et gestionnaires de réseau ne vont pas se priver de filtrer ces enregistrements DNS et personne ne verra l'attaque par repli... vu que la majorité des domaines n'utilise pas DNSSEC.

@bortzmeyer @shaft Un train (SNCF) c'est comme un paquet UDP: on a une vague idée quand il part, mais jamais aucune idée de quand il arrive en vrai.

@lanodan @shaft This thread might be of interest to you: https://mailarchive.ietf.org/arch/msg/dnsop/3hzGyV9LGnUpw0ncFudWdQ2sZvc/ My understanding of the current trends and global points of view is that after RSA 2048 it is better to focus energy on switching to elliptic curves based algorithms and just shield away from RSA completely. For both reasons on size consequences of what is exchanged as DNS packets, and for fears of strength against quantum computing.

@bortzmeyer @shaft @lanodan Page introduction de ietf.org: "All IETF participants are considered volunteers and expected to participate as individuals, including those paid to participate."

@shaft @lanodan C'est touchy les TLDs... Techniquement sous giron IETF, géré en pratique par l'IANA qui reçoit demandes de l'IETF pour maintenir des registres mais qui aussi donne son avis (review) sur les RFCs, et l'ICANN pour la gouvernance, qui fait officier le service IANA par PTI, filiale de l'ICANN. Il falloir que l'ICANN mette à jour son guide pour le round 2026(?) et explicitement lister le `.alt` comme hors limites. Etc.

@shaft @lanodan "1 personne = 1 voix" à l'IETF est un mythe à ranger dans la même boiîte que "les startups qui naissent dans un garage avec 2 écus et une miche de pain pour voir 1 milliard 2 ans après". Ca semble superficiellement vrai, mais ne tient pas une analyse approfondie. Pour QUIC, ca a aidé "un peu" que ca vienne de Google :-)

@lanodan @bortzmeyer @duponin All nameservers have test suites . There is https://github.com/dns-violations/dns-violations/ that can give list of edge cases/common problems. There are tools to parse and replay DNS packets and more at https://www.dns-oarc.net/oarc/software (see dnscap, dnsjit, drool, bad-packets projects)

@duponin @bortzmeyer "I can't work out how to make sure the query is well-formed, neither find a validation tool anywhere" That part should be easy. Any good DNS library should have the equivalent of `to_wire/from_wire` methods (they are called like that in DNSPython), which allows to either pass a buffer of bytes as captured in theory from network and see how they are parsed, or the opposite.

@duponin @bortzmeyer But then how can you compare/validate your results (from need X to bytes ABCDE...)? With just the RFC? tough luck, there are 1) too many of them for DNS 2) contradictory between themselves or ambiguous at times and 3) just impossible to draw a concise exhaustive view of what is "the DNS". Hence my suggestions to use external existing libraries (at least Python and Go ones are very good DNS wise) to help building you own case. But YMMV.