framapiaf.org est l'un des nombreux serveurs Mastodon indépendants que vous pouvez utiliser pour participer au fédiverse.
Un service Mastodon fourni par l'association d’éducation populaire Framasoft.

Administré par :

Statistiques du serveur :

1,4K
comptes actifs

Good morning, Brisbane! Today is the third day of #IETF119.

For me, working group regext (Registry Extensions, things like EPP and RDAP, remember that whois died many years ago).

And a session on LLM because there is no meeting without something about LLM.

The draft about Internationalized email addresses (stéphane@café.fr) in EPP has been sent to the IESG. Soon, domain name registrants and contacts will be able to use them :-)

The working group regext is not just about #EPP. #RDAP is important, too, and has several drafts. Also, "registry" is not just domain name registry, RIR exist, too. (Current draft: IP and ASN search in RDAP)

Currently, most registration domains use the same TTL for everyone. An EPP draft adds the ability for the registrar to ask for a different TTL, per domain.

Interesting discussion: when something can be set through EPP, should it also always be queryable via RDAP? (Today, it is the case for NS, DS and glue; what about the future TTL extension?)

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

@pmevzek Well, the discussion was more about data that appear in the DNS (NS, DS, glue, TTL…)

Patrick Mevzek

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

@pmevzek My use case (others may have different use cases) is double-checking. Many things can go wrong in the DNS from initial publication to synchronization of authoritative name servers to problems in the resolver, so, when something in the DNS is strange, I check with RDAP.

@bortzmeyer And RDAP can be wrong as well, with either the same wrong data than DNS or another set of wrong data :-) As I said, I am not convinced in general the benefits being greater than the drawbacks. Specially among people not understanding that the DNS is authoritative and not the RDS, when there is a discrepancy. The only case I would maybe agree is for specific thing like `.de` NSEntry that does appear in whois (would need an extension in RDAP). But is visible in DNS too by no NS records

@pmevzek The path from database to the RDAP client is much shorter and simpler than the path from database to the DNS client and have way less opportunities of trouble. (Neither RDAP nor the DNS are authoritative, the database is.)

@bortzmeyer "The path from database to the RDAP client is much shorter and simpler than the path from database to the DNS client" I fail to see where. RDAP query is one HTTPS call from any client to an RDAP server managed by registry (which can be outsourced, which can be load balanced, which can be anycasted, etc. etc.), and a DNS query to authoritative registry nameserver is also a single call (server can be outsourced, anycasted, etc.).RDAP can have lots of troubles with variations in format.

@bortzmeyer I personally never have seen the case of using RDAP to solve a DNS problem (except looking at serverhold/clientHold statuses), but I guess if it helps others, then so be it. But duplication between DNS, RDAP and EPP does not look to me healthy (it may have its uses but I still believe the drawbacks outweigh the meager benefits).