Skip to Content.
Sympa Menu

public-l - Re: [public-l] Minimum TTL nach RfC 2308

public-l AT list.denic.de

Subject: Public DENIC mailinglist

List archive

Re: [public-l] Minimum TTL nach RfC 2308


Chronological Thread 
  • From: lutz AT iks-jena.de (Lutz Donnerhacke)
  • To: public-l AT denic.de
  • Subject: Re: [public-l] Minimum TTL nach RfC 2308
  • Date: 20 Feb 2001 09:53:28 GMT
  • Newsgroups: iks.lists.ripe.de
  • Organization: IKS GmbH Jena

* Peter Koch wrote:
>Lutz Donnerhacke schrieb:
>> negative TTL [RFC 2308], which would call for a lower value. We are
>> in a transition phase now with software implementing either of both
>> meanings, so the TTL of one hour is recommended for the SOA itself,
>> which will lead to nearly the same effect.
>>
>> Ich lese das so, dass RIPE den TTL Wert im SOA-RR als minimum TTL ansehen
>> moechte, aber den TTL Wert des SOA-RR selbst als negative caching TTL
>> ansieht. Damit stellt man sich gegen den zitierten RfC 2308. Und es ist
>
>das ist so nicht ganz korrekt interpretiert. Mit dem Erscheinen von RFC2308
>wurde nicht schlagartig ueberall die Bedeutung des MinTTL-Feldes veraendert,
>sondern diese haengt in der Interpretation in der Flaeche davon ab, wieweit
>2308 implementiert und im Feld verbreitet ist.

Dem ist nicht so. Das minimum TTL Feld hatte drei Bedeutungen:
1 Kein RR der Zone darf eine niedrigere TTL von einem NS bekommen.
2 Alle RR einer Zone, die keinen TTL Eintrag haben, bekommen diesen Wert.
3 Negative Antworten sollen solange nicht wiederholt werden.

Bedeutung eins wurde nie umgesetzt. RfC 2308 entfernt sie komplett.

Bedeutung zwei ist nur beim Einlesen von Zone-Files beim Master interessant
und schon länger durch $TTL bei BIND oder anderen Mechanismen ersetzt. Schon
bei der Übertragung vom SOA zu den NS werden alle RR mit TTLs versehen. Es
besteht also kein Bedarf, dieses Feld länger in dem Sinne zu nutzen. RfC
2308 entfernt diese Bedeutung komplett.

Bedeutung drei ist die, die übrigbleibt. Die empfohlenen Werte liegen bei
einigen Stunden.

>Darum spricht das Dokument auch von "transition phase", was zum Zeitpunkt
>des Erscheinens voellig korrekt war und auch heute noch nicht voellig
>falsch ist.

Ziemlich irrelevant, wenn man deswegen die Eintragung der neuen Bedeutung
verhindert.

>> logisch widerspruechlich, da in diesem Fall der SOA-RR selbst eine zu
>> kleine TTL haben wuerde. Abegesehen davon soll ja nicht der SOA-RR
>> verfallen,
>
>Doch, soll er. RFC 2308, section 3:
>
> This is required so that the response may be cached. The TTL of this
> record is set from the minimum of the MINIMUM field of the SOA record
> and the TTL of the SOA itself, and indicates how long a resolver may
> cache the negative answer. [...]

Falsch intepretiert: Abschnitt drei befaßt sich mit dem Negatvbescheid eines
authorisierten NS. Dieser hat einen SOA-RR mitzusenden und in _dieser_
Antwort die TTL für _diesen_ SOA-RR auf den Wert der minimum TTL aus dem SOA
Record zu übernehmen, es sei denn, die TTL des SOA Records war noch kleiner.

Diese Behandlung stellt Abwärtskompatibilität sicher.





Archive powered by MHonArc 2.6.19.

Top of Page