Notices by Patrick Mevzek (pmevzek@framapiaf.org)

@sahil Depends authoritative on what kind of zones :-) If "critical" and you need 99.9999% reliability, then no. Otherwise, maybe. Theoretically, you need either solid anycast, OR at least 2 separate IP blocks in separate AS in separate datacenters with separate routing (+ ideally different OS and nameservers software). Plus the usual (power source, monitoring, etc.). But to do it at home on some toy zones, absolutely, to learn things!

@sahil "If I understand correctly, NS for aws.amazon.com is a chain of CNAME(s) to actual NS domain?". No. It tells you `aws.amazon.com` has NO `NS` records, because it is a CNAME, and CNAME can not coexist with anything else. It then tells you the final destination of the CNAME, as there are 2, aka `dr49lng3n1n2s.cloudfront.net.` and then tells you that this name is delegated because it has `NS` records. So `aws.amazon.com` is not delegated (has no NS records), just pointed out externally.

@audiodude @sindarina Never invent TLDs. You will get burn and get others burn. If you just need examples, see the `.dev` or `.box` fiasco. News at 11: new gTLD round in 2026, so you can expect new TLDs in 2030 or so, and `.fake`, or any other, can certainly be there, and suddenly all your documentation and setups have a big problem!

@bortzmeyer @lanodan Générer un UUID, le renvoyer de suite dans la réponse DNS, attendre en tâche de fond la réponse du service distant, et après la rendre accessible via requêtes DNS sur un enregistrement nommé par cet UUID?

@bortzmeyer @lanodan Plus vicieux et pas nécessairement efficace dans tous les cas: en guise de première réponse attendre "un peu" et retourner un CNAME, qui pointe vers nouvel enregistrement pour lequel on attend "un peu" et on retourne un CNAME, etc. jusqu'à ce que séparément on ait récupéré la réponse et alors on peut arrêter le chaîne de CNAME. Mais un client peut se lasser avant, par expiration du temps total entre toutes les requêtes ou du nombre de CNAME. L''état peut être encodé.

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