- G. Brown
Abstract
Questo documento specifica un'estensione del Protocollo di accesso ai dati di registrazione (RDAP), che consente di includere i valori Time-to-Live (TTL) per i tipi di record DNS pertinenti nelle risposte RDAP.¶
Stato di questo memo
Questo è un documento della serie Internet Standards Track.¶
Questo documento è un prodotto del Task Force per l'Ingegneria del Internet (IETF). Rappresenta il consenso della comunità IETF. Ha ricevuto una revisione pubblica ed è stato approvato per la pubblicazione dal Gruppo di Direzione per l'Ingegneria del Internet (IESG). Ulteriori informazioni sugli Standard Internet sono disponibili nella Sezione 2 del RFC 7841.¶
Informazioni sullo stato attuale di questo documento, eventuali errori e su come fornire feedback possono essere ottenute a:https://www.rfc-editor.org/info/rfc10037.¶
Nota sui diritti d'autore
Copyright (c) 2026 IETF Trust e le persone identificate come autori del documento. Tutti i diritti sono riservati.¶
Questo documento è soggetto a BCP 78 e alle disposizioni legali dell'IETF Trust relative ai documenti IETF (https://trustee.ietf.org/license-info) in vigore alla data di pubblicazione di questo documento. Si prega di esaminare attentamente questi documenti, poiché descrivono i propri diritti e restrizioni con riguardo a questo documento. I componenti del codice estratti da questo documento devono includere il testo della licenza BSD revisionata come descritto nella Sezione 4.e delle disposizioni legali del Trust e sono forniti senza garanzia come descritto nella licenza BSD revisionata.¶
1. Introduzione
Il Protocollo di accesso ai dati di registrazione (RDAP)[STD95]fornisce l'accesso alle informazioni sui risorse Internet (nomi di dominio, numeri di sistemi autonomi e indirizzi IP).RFC 9083 [STD95]consente agli operatori dei server RDAP di fornire informazioni sul contenuto delNS", "DS - DS", "A - A, and " - ", eAAAA - AAAA" RRset(s) (see - "Insiemi RR (vedere)Section 5 - Sezione 5of [ - di [RFC9499 - RFC9499]), che sono pubblicati nel DNS per un oggetto di registro specifico (dominio o oggetto host),Sezione 5di [RFC9499]) di quei set RR per essere inclusi nelle risposte.¶
Questo documento descrive come le informazioni TTL possono essere incluse negli oggetti di dominio e server DNS nelle risposte RDAP. SecondoSezione 5.2di [RFC2181]I valori TTL si applicano ai set di recordi RR piuttosto che ai singoli recordi.¶
2. Convenzioni utilizzate in questo documento
Le parole chiave "DEVE", "NON DEVE", "OBBLIGATORIO", "DEVE ESSERE", "NON DEVE", "DEVE", "NON DEVE", "CONSIGLIATO", "NON CONSIGLIATO", "PUÒ, eFACOLTATIVOIn questo documento, le informazioni devono essere interpretate come descritto nel BCP 14.[RFC2119] [RFC 8174]Quando, e solo quando, appaiono in maiuscolo, come mostrato qui.¶
Questo documento utilizza termini definiti nella Sezione1.1Di diRFC 9083 [Testo: STD95].¶
3. Specificazione della risposta RDAP
Server che supportano questa estensioneMAGGIOincludere un "dati_ttl0" membro in qualsiasi dominio (Sezione5.3diRFC 9083 [STD95]e nome del server (Section5.2diRFC 9083 [STD95]) oggetti inclusi nelle risposte RDAP.2.1diRFC 9083 [STD95]clienti che non implementano questa specificazioneSI DEVEignorare il "ttl0_data" membro.¶
The "ttl0_data"Un membro è un oggetto che ha i seguenti membri:¶
- Un 'oggetto
valori"Un membro, che è un oggetto che mappa i tipi di record DNS mnemonici ai valori TTL; e¶ - Opzionalenote "
(vedi Sezione"Un membro, che è un array di note (vedi Sezione4.3diRFC 9083 [STD95]).¶
Come specificato inSezione 8di [RFC2181], un valore TTL è "un numero non firmato, con un valore minimo di 0 e un valore massimo di 2147483647. Cioè, un massimo di 2^31 - 1". Valori TTLDEVEIl testo: "sarà rappresentato come numeri JSON senza componenti decimali e senza notazione esponenziale."¶
I valori TTL inclusi in "Dati TTL0membriDEVEIl testo riflette i valori TTL come provisionati nel database del registro, non il TTL rimanente dei record DNS come osservato dalle query DNS in tempo reale.¶
Un esempio di oggetto di dominio con un valido "dati ttl0"Il membro è fornito di seguito. I lettori dovrebbero fare riferimento aRFC 9083 [STD95]per una descrizione degli altri oggetti elencati nell'esempio.¶
{Un esempio di oggetto server di nomi con un "dati ttl0Il membro è fornito di seguito.¶
"{3.1. Tipi di record DNS e valori TTL
Le mnemoniche dei tipi di record DNS che appaiono come nomi dei membri in'oggettidevono essere in maiuscolo.DEVOREessere in maiuscolo in tutti i casi.DEVEessere registrato con l'IANA in[IANA-RRTYPES].DEVEessere interi non firmati nell'intervallo 0-2147483647 come perSezione 8di [RFC2181].¶
3.2. Conformità RDAP
I server restituiscono risposte contenenti valori TTLDEVEincludere la stringa "ttl0nella sezionerdapConformanceArray.¶
4. Considerazioni operative
4.1. Server RDAP
Questa specifica è complementare al Protocollo di Provisioning Estensibile (EPP)[RFC5730]e alla Mappatura EPP per i Valori Time-to-Live (TTL) DNS[RFC9803], ma gli operatori di registri non devono implementare quella estensione nei loro server EPP per implementare questa estensione RDAP.¶
4.2. Clienti RDAP
Molti clienti RDAP utilizzano framework che "idratano" automaticamente gli oggetti utilizzando i dati JSON ricevuti nelle risposte RDAP. Di conseguenza, i clienti RDAP che utilizzano questi framework dovrebbero specificare esplicitamente la "parte dei valoriall'interno dellattl0_dati".¶
Poiché l'elenco dei tipi di record che appaiono in "ttl0_dati"I membri possono cambiare nel tempo, i clienti che implementano questa estensione DEVONODEVEaccettareSI CONSIGLIAdi aggiornare periodicamente l'elenco dei tipi di record DNS validi per allinearsi con[IANA-RRTYPES], per evitare di scartare un tipo di record recentemente aggiunto.¶
5. Considerazioni IANA"
L'IANA ha registrato il seguente valore nel registro "RDAP Extensions"[IANA-RDAP-ESTensioni]:¶
Identificatore dell'estensione:ttl0¶Operatore del registro:¶Specificazione:¶Contatto:<mailto:iesg@ietf.org>¶**Utilizzo previsto:** Questa estensione descrive come i valori TTL del DNS possono essere inclusi nelle risposte RDAP.¶
6. **Considerazioni sulla sicurezza**
**I servizi di sicurezza per l'estensione specificata in questo documento sono descritti in:** RFC 7481**STD95** [Testo: STD95].¶
**Le implicazioni di sicurezza su come tali valori TTL sono determinati, assegnati o modificati all'interno di un sistema di registro sono al di fuori dello scopo. I lettori sono rimandati a:**Sezione 6di [RFC9803]per ulteriori discussioni.¶
7. Riferimenti
7.1. Riferimenti normativi
[ESTESI DI IANA-RDAP-ESTENSIONI]IANA, Estensioni RDAP, <https://www.iana.org/assignments/rdap-extensions>.IANA, Tipi di Record di Risorse (RR), <https://www.iana.org/assignments/dns-parameters>.Bradner, S., Parole chiave da utilizzare nei RFC per indicare i livelli di requisito, BCP 14, RFC 2119, DOI 10.17487/RFC2119Marzo 1997,<https://www.rfc-editor.org/info/rfc2119>.Elz, R.eR. Bush, Chiarimenti sulla specificazione DNS, RFC 2181, DOI 10.17487/RFC2181, Luglio 1997,<https://www.rfc-editor.org/info/rfc2181>.Leiba, B., Ambiguità tra Maiuscole e Minuscole nei Termini Chiave di RFC 2119, BCP 14, RFC 8174, DOI 10.17487/RFC8174, Maggio 2017,<https://www.rfc-editor.org/info/rfc8174> (Il simbolo ">" indica l'inizio di una citazione o di un'intestazione)(Punto, indica una pausa o una lista)Hoffman, P. (Preserva il nome proprio)e (Parola "e" in italiano)K. Fujiwara (Preserva il nome proprio), "DNS Terminology" (Titolo in italiano), BCP 219 (Preserva la sigla), RFC 9499 (Preserva la sigla), DOI 10.17487/RFC9499, Marzo 2024,<https://www.rfc-editor.org/info/rfc9499>.Al momento della stesura, questo STD comprende quanto segue:
7.2. Riferimenti informativi
[RFC5730]Hollenbeck, S., Protocollo di provisioning estensibile (EPP), STD 69, RFC 5730, DOI 10.17487/RFC5730Agosto 2009,<https://www.rfc-editor.org/info/rfc5730>.Brown, G., Mappatura del Protocollo di Provvisione Estensibile (EPP) per i Valori di Time-to-Live (TTL) DNS, RFC 9803, DOI 10.17487/RFC9803, Giugno 2025,<https://www.rfc-editor.org/info/rfc9803>.Riconoscenti
L'autore desidera ringraziare i seguenti per i loro preziosi contributi e consigli durante lo sviluppo di questo documento:Andy Newton, Pawel Kowalik, Maarten Wullink, Mohamed Boucadair, Vijay K. Gurbani, Di Ma, Nabeel Cocker, Ketan Talaulikar, Ralf Weber, Mike Bishop, Mahesh JethanandanieÉric Vyncke.¶