(I've changed the subject since I'm going to this particular issue
only).
>>>>> On Wed, 7 Apr 2004 11:38:34 +0300 (EEST),
>>>>> Pekka Savola <[EMAIL PROTECTED]> said:
>> 3. Section 4.4 (The Use of TTL for IPv4 and IPv6 RRs)
>>
>> example.com. 300 IN MX foo.example.com.
>> foo.example.com. 300 IN A 192.0.2.1
>> foo.example.com. 100 IN AAAA 2001:db8::1
>> ...
>> ... So,
>> in this particular case, there is a window of 200 seconds when
>> incomplete information is returned from the cache.
>>
>> I don't see what's wrong with this. In this case, the lost
>> information would be "additional" one (returned in the additional
>> section) after all. If the client (probably an SMTP server in this
>> case) needs the missing AAAA, it can ask for the missing RR(s)
>> separately (otherwise, I'd call this a bug in the client).
> You raise a good point. I seem to have been slightly confused here,
> thinking that the clients would do somekind of "ANY" or "give me
> everything you have about 'name'" queries.
> You can do "ANY" query, but that does not give you the right answer
> unless the caching resolvers on the path have also queried for both v4
> and v6 records. So, practically, you have to perform explicit queries
> for both A and AAAA records. However, there is a case where you do
> not need explicit queries but where you could be led astray: querying
> for MX record, as the caches may give you nothing (this leads you to
> query both records explicitly), full results, or impartial results.
> Here I'm worried of impartial results.
> Or am I missing something and is there some kind of real application
> of "ANY" queries? Does anyone use them e.g. on DNS server or stub
> resolver implementations?
As a matter of fact, I don't know any DNS server implementations or
stub resolvers that rely on "ANY" (or QTYPE=*) queries. I'm even not
sure if this is crucial for this discussion...
> Let me try to understand your bug example. Would you consider it a
> bug that a DNS cache would have cached both A and AAAA records with
> different TTLs, and when the first-to-expire expires, the DNS cache
> does not re-query the one that expired?
No, I don't think it's a bug unless the caching server is the "real
client" of the records. This is the case when it tries to send a
query to other authoritative servers.
> Should it re-query that?
No, it doesn't have to re-query.
> I mean, if the cache would return records in an additional section
> (e.g., when queried for MX record), but would not return all of them
> (because some of them had expired), would you consider this a bug?
No, I'd call a bug in this case if the "real client" asking a caching
DNS server does not re-query for the missing A or AAAA record.
To be more specific, consider an SMTP server and a DNS caching server.
Also assume there is an outside zone "example.com" to which the SMTP
server would want to send e-mail messages and we have different TTLs
for the A and AAAA RRs of the host name pointed by MX in the
example.com zone:
example.com. 300 IN MX foo.example.com.
foo.example.com. 300 IN A 192.0.2.1
foo.example.com. 100 IN AAAA 2001:db8::1
When the SMTP server first tries to send an e-mail message to
example.com, it asks the caching server for an MX record of
"example.com". The caching server receives all the three RRs, caches
the RRs, and returns them to the SMTP server (MX in the answer
section, and A/AAAA in the additional section).
100 seconds later, the AAAA records expires at the caching server.
As I already said, the caching server does not have to re-query for
the expired recored (and I don't call it a bug of the caching server
if it does not re-query).
Then suppose the SMTP server tries to send another message to
example.com (before the A and MX RRs expire). It asks the caching
server for an MX record of example.com, and the caching server would
return the MX (in the answer section) and A (in the additional
section) RRs in the cache (but not the AAAA RR).
If the SMTP server has IPv6 connectivity and wants to establish an
SMTP connection over IPv6 to example.com, then it should make another
query for the AAAA RR of "foo.example.com" and send it to the caching
server. Otherwise, I'd call the SMTP server buggy.
Am I clear enough?
> (See below for text update.)
>> So,
>>
>> Therefore, when the same name refers to both A and AAAA records,
>> these records should have the same TTL.
>>
>> I don't see a valid reason for this either. Moreover, I can even
>> think of a case we want to use different TTLs for A and AAAA RRsets.
>> For example, if I'm going to renumber an IPv6 address of a host while
>> keeping IPv4 addresses on that host, I might want to use a shorter TTL
>> for the AAAA RRset but a longer, stable TTL for the A RRset.
> I think it should be reasonable to suggest that the TTL should be the
> same (because that simplifies the operations for those servers
> which have to handle the both) unless there are valid reasons (like
> the ones you cite) for handling them differently.
> As for the current wording I've adopted (this probably requires more
> tuning still):
I don't see anything obviously wrong in the planned text below (except
the paragraph beginning with "So, we assume", since this is not what I
meant to say). However, I still don't understand why we should
mention this in the first place. Actually, as explained in item 2,
"it is impossible to guarantee that in fact we would always get back
all the records". Even if we use the same TTL for the A and AAAA RRs
in this example, the caching server can still have a "partial" result,
e.g., due to packet size issues. On the other hand, we may even want
to use different TTL intentionally, as I explained in my first
message.
Finally, I don't see why the third case below is problematic (BTW: I'm
now confused with the wording of "impartial" there. What does this
actually mean?)
So, at the moment, I don't see the need for this subsection at all.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
> 4.4 The Use of TTL for IPv4 and IPv6 RRs
> The behaviour of DNS caching when different TTL values are used for
> different records of the same name requires explicit discussion. For
> example, let's consider a part of a zone:
> example.com. 300 IN MX foo.example.com.
> foo.example.com. 300 IN A 192.0.2.1
> foo.example.com. 100 IN AAAA 2001:db8::1
> When a caching resolver asks for the MX record of example.com, it
> gets back "foo.example.com". It may also get back either one or both
> of the A and AAAA records in the additional section. So, there are
> three cases about returning records for the MX in the additional
> section:
> 1. We get back no A or AAAA records: this is the simplest case,
> because the we have to query which information is required
> explicitly, guaranteeing that we get all the information we're
> interested in.
> 2. We get back all the records: this is an optimization as there is
> no need to perform more queries, causing lower latency. However,
> it is impossible to guarantee that in fact we would always get
> back all the records; however, one could try to work in the
> direction to try to ensure it as far as possible.
> 3. We get impartial results: this is indistinguishable from the
> previous case, and problematic as described in the next section.
> So, we assume we get back both A and AAAA records of foo.example.com,
> or the resolver explicitly asks, in two separate queries, both A and
> AAAA records. After 100 seconds, the AAAA record is removed from the
> cache because its TTL expired. The cache must re-query the AAAA
> record when its TTL expires to avoid the situation where there would
> be a window of 200 seconds when incomplete information is returned
> from the cache. XXX: if this is not done, is it a bug?
> To simplify the situation, it is recommended to use the same TTL for
> all the records referring to the same name. However, there are some
> scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where
> a different strategy is preferable.
> More issues with caching and A/AAAA records is presented in the next
> section.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
