>>>>> On Mon, 19 Apr 2004 22:09:23 +0300 (EEST),
>>>>> Pekka Savola <[EMAIL PROTECTED]> said:
> 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.
Okay, so I guess my position is not so different than yours...but one
thing I'd like to emphasize is that the application (the SMTP server
in this case) should not assume anything in the additional section,
and should basically have the ability to fetch missing additional
data. In that sense, I disagree on your saying that "the SMTP servers
should not have to have any such code at all".
But at the same time, it's okay for me to mention that it may help if
we use the same TTL for A and AAAA RRsets in this type of case. It's
just a tip that may optimize the thing, though; I think
"recommendation" is a strong word for this.
>> 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..
Okay.
>> 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.
Hmm, the sense was not really clear at least to me with the literal
meaning of "impartial". But I'm not an expert on English wording and
I don't have a better suggestion, so I'd leave this to you (I mean
it's okay if you want to keep it). (Note that the latest version of
05pre still has this term in Section 4.4, which has been Sect. 4.5 so
far).
The following is my comment on the latest 05pre revision of the draft
(MD5 fingerprint is d59264c3f988a8fc132bc88c6c3de557). Notice that I
only read Sections 4.4 and 4.5.
4.4 Behaviour of Additional Data in IPv4/IPv6 Environments
Consider thes case where the query name is so long, the number of the
s/thes/the/
additional records (originated from "glue") is so high, or for other
reasons that the response must either be truncated (leading to a
retry with TCP) or some of the additional data removed from the
reply.
It's hard to parse the part "or some of the...from the reply". Do you
mean:
...or for other reasons that the response must be truncated (leading
to a retry with TCP) or some of the additional data must be removed
from the reply.
?
In the last paragraph,
... The operational fix
for this is having the DNS server implementations return a warning
when the administrators create the zones which would result in too
much additional data being returned.
I think this statement is too strong, since it sounds like this is the
only operational fix. I'd suggest to reword this e.g., "An
operational fix for this", etc.
4.5 The Use of TTL for IPv4 and IPv6 RRs
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.
s/next/previous/ ?
As a more essential comment, it's still not clear to me what the
problem described in the previous section is...are you particularly
referring to the 3rd paragraph of Section 4.4, that is, (e.g.)
returning A records to an IPv6-only node?
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).
This paragraph seems to have several problems:
1. it's not clear to me why this paragraph begins with "So,". Do you
mean something like this?
"In order to discuss the case where we have both A and AAAA
records, let's assume we get back both records of foo.example.com,
or the resolver explicitly asks, in two separate queries, both A
and AAAA records."
2. in this paragraph, you used the term "resolver". But I'm not sure
what it exactly specifies, partly because you also used the term
"caching resolver" in this section...does the "resolver" mean the
"caching resolver" or the (so-called) "stub resolver"? Similarly,
if you mean the "caching resolver" in "It would be useful for the
cache to..." (I believe you do), then I'd suggest to reword it as
"It would be useful for the caching resolver to...".
3. it might be controversial whether "it would be useful for the cache
to re-query the AAAA record". This behavior is similar to BIND8's
"fetch-glue" feature (though the caching server with fetch-glue
being on does not return the missing additional data to the stub
resolver during re-fetching it). But ISC has deprecated the
feature in BIND9: (from BIND9 ARM) "This is now considered a bad
idea and BIND 9 never does it." I don't know the full detail of
this discussion, but there should be a clear reason for this.
[going to the last paragraph of Section 4.5]
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.
As I already said, "recommended" is too a strong word, IMO. I'd also
like to add a note that applications should not make or depend on a
particular assumption on the content of the additional section. So,
I'd revise this part like this:
To simplify the situation, it might help to use the same TTL for
all the resource record sets referring to the same name, unless
there is a particular reason for not doing so. However, there are
some scenarios (e.g., when renumbering IPv6 but keeping IPv4
intact) where a different strategy is preferable.
Thus, applications that use the response should not rely on a
particular TTL configuration. For example, even if an application
gets a response that only has the A record in the example described
above, it should not assume there is no AAAA record for
"foo.example.com". Instead, the application should try to fetch
the missing records by itself if it needs the record.
(Note that I use "resource record set(s)" instead of just "record(s)"
where I think more appropriate).
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
