On Mon, 19 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] [EMAIL PROTECTED]@C#:H wrote:
> 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...
OK.
> > 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?
Yes, this is clear now.
However, I think I have to disagree with the last paragraph a bit. I
don't think it's feasible to require you to do special queries in case
you have IPv6 connectivity, just in case there would be IPv6 records
which had been omitted from the caches. The SMTP servers should not
have to have any such code at all; they should just take whatever they
are given when they send a MX query and be happy with it. Forcing any
IPv6-capable SMTP server to perform a mostly useless AAAA query seems
like a waste of time and bits.
But as this is the current specification situation, there's not much
one can do about it. If you want to be positively sure that you
always get all the records, you have to query them explicitly
yourself, with the record type you're interested in getting.
The things that would help here, though, are at least:
1) if the DNS servers/caches/etc. either sent all the records or no
additional records unless they can send everything,
2.a) if the DNS servers/caches/etc. would have identical TTLs for all
the protocol versions, or
2.b) if the caches would expire all the records under a hostname
(above, foo.example.com) when the first of A/AAAA records expired.
This would actually seem to make sense..
To get out of this situation without explicit queries, we'd seemingly
have to do 1) and either 2.a) and 2.b). My own personal preference is
1), recommending 2.a) but not requiring it, and requiring/recommending
2.b) as caching implementation technique.
> 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).
True, I've reworded that.
> 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.
I think it might be useful to try to describe these TTL issues
explicitly, as I their impact hasn't been clearly spelled out wrt.
records of different types..
> 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?)
See above for my belief that we should not have to burden all the SMTP
servers in the world to make unnecessary queries just to confirm there
was no IPv6 address for the MX record; the steps described in here go
a long way in that direction.
I've reworded impartial here. As RRsets can't be broken up, it was
used to refer to "both A and AAAA records exists, but a cache returned
only one kind of them". I couldn't find a better word (suggestions?)
but I've reworded it out of these now.
I also changed the order of sections 4.4 and 4.5, as TTL appears to be
a more specific issue than "impartial" additional data.
The text now is:
======
4.5 The Use of TTL for IPv4 and IPv6 RRs
In the previous section, we discussed a danger with queries,
potentially leading to omitting records information from the
additional section. This section describes another problem leading
to omitting records in cached data, highlighted in the IPv4/IPv6
environment.
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 then 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 (the only way to ensure that is to send a
AAAA query for the name after getting the cached reply); however,
one could try to work in the direction to try to ensure it as far
as possible.
3. We only get back A or AAAA records even if both existed: 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. It would be useful for the cache to
re-query the AAAA record or discard the A record when the shorter TTL
(in this case, for the AAAA record) expires; this would avoid the
situation where there would be a window of 200 seconds when
incomplete information is returned from the cache. However, this is
not mandated or mentioned by the specification(s).
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.
========
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
