Operational Considerations and Issues with IPv6 DNS
draft-ietf-dnsop-ipv6-dns-issues-12

[Ballot discuss]
Most of the problems listed in the last discuss have been fixed, but the following issues have not yet been addressed:


>    If the implementation decides to keep as much data (whether
>    "critical" or "courtesy") as possible in the UDP responses, it might

The "whether" adds confusion. You always need to keep the
critical data -- that's not an implementaion choice...

>    That is, leaving in some intelligently selected critical additional
>    data is a tradeoff between creating an optimization for those
>    resolvers which ignore the "should discard" recommendation, and a
>    causing a protocol problem by propagating inconsistent information
>    about "critical" records in the caches.

I don't  understand this (or the context). With critical data, one must
include it all, or one sets the TC. Why talk about selectively
omitting critical data?

>    If an implementation would look at the transport used for the query,
>    it is worth remembering that often the host using the records is
...snip...
>    is not feasible, return no misleading information but rather leave it
>    to the client to query again.

A big premise of all of section 4.4 seemed to (originally) be that
there were times when "inconsisent" data could be  in some caches,
leading to "correctness" problems. I believe we are in agreement that
this premise is false. Right?

The above text still seems to be written from the older
perspective. I.e., I'm not sure what point the above is trying to make
or why it needs making.

>    Additionally, to avoid the case where an application would not get an
>    address at all due to some of "courtesy" additional ...
...snip...
>... specific records
>    of the desired protocol, not just rely on getting all the required
>    RRsets in the additional section.

This text suggests a "fix" for a "problem",
but that problem could only result from broken implementations. But
the wording isn't written that way. Is it in fact known that there are
broken implementations in this regard? And are such broken
implementation only a probly for IPv6?

[Ballot discuss]
I am holding a discuss for the issues that Thomas Narten raised in his original discuss (see comment log).  Thomas was asked if his discuss was addressed and sent the message below on 6/13 indicating that they had not all been resolved.  There hasn't been any response to Thomas' message (as of 6/21).

To: Pekka Savola
cc: Rob Austein
Subject: Re-review of draft-ietf-dnsop-ipv6-dns-issues-10.txt
From: Thomas Narten

Looking at the current draft, I have the following comments on the
revised text.

>    conjunction of MX records is shown in Section 4.5; an example of the

s/is shown/as shown/

>    An example of the "courtesy" additional data is A/AAAA records in
>    conjunction of MX records is shown in Section 4.5; an ...
...snip...
>... IN  NS ns.child.example.com.
>      ns.child.example.com. IN    A 192.0.2.1
>      ns.child.example.com. IN AAAA 2001:db8::1

Better wording:

    an example of the "critical" additional data is shown below (where
    getting both the A and AAAA RRsets is critical w.r.t. to the NS
    RR):

>    Failing to discard the response with TC bit set leads to a protocol
>    problem.  Omitting only some of the RRsets if all would not fit leads
>    to a performance problem.  These are discussed in Section 4.4.3.

not being clear above in terms of what is critical and what is
not. The middle sentence is only true in the context of noncritical
data.

> 4.4.2  Which Additional Data to Keep, If Any?

Is this section now (only) about "courtesy" data? If so, better to say
so.

>    If the implementation decides to keep as much data (whether
>    "critical" or "courtesy") as possible in the UDP responses, it might

seems the "whether" adds confusion. You always need to keep the
critical data -- that's not an implemenation choice...

>    complete.  Removing all the RRsets if some would not fit obviates a
>    performance problem, which would require the users to issue second
>    queries to obtain consistent information.

wording could be better...

perhaps:

  Omitting all the RRsets (when removing only some would suffice) may
  create a performance penalty, whereby the client may be need to
  issue one or more additional queries to obtain necessary
  information.

> 4.4.2  Which Additional Data to Keep, If Any?

shouldn't this be focused solely on courtesy data?

>    That is, leaving in some intelligently selected critical additional
>    data is a tradeoff between creating an optimization for those
>    resolvers which ignore the "should discard" recommendation, and a
>    causing a protocol problem by propagating inconsistent information
>    about "critical" records in the caches.

don't  understand this (or the context). With critical data, one must
include it all, or one sets the TC. Why talk about selectively
omitting critical data?

> 4.4.3  Discussion of the Problems
>
>
>    As noted above, the temptation for omitting only some of the
>    additional data based on the transport of the query could be
>    problematic.  In particular, there appears to be little justification
>    for doing so in the case of "courtesy" data.

Don't  understand the first sentence. Even second one is suspect.

>    If an implementation would look at the transport used for the query,
>    it is worth remembering that often the host using the records is
...snip...
>    is not feasible, return no misleading information but rather leave it
>    to the client to query again.

A big premise of all of section 4.4 seemed to (originally) be that
there were times when "inconsisent" data could be  in some caches,
leading to "correctness" problems. I believe we are in agreement that
this premise is false. Right?

The above text still seems to be written from the older
perspective. I.e., I'm not sure what point the above is trying to make
or why it needs making.

>    Additionally, to avoid the case where an application would not get an
>    address at all due to some of "courtesy" additional ...
...snip...
>... specific records
>    of the desired protocol, not just rely on getting all the required
>    RRsets in the additional section.

This text is also bogus, IMO. It suggests a "fix" for a "problem",
but that problem could only result from broken implementations. But
the wording isn't written that way. Is it in fact known that there are
broken implementations in this regard? And are such broken
implementation only a probly for IPv6?

> 4.5  The Use of TTL for IPv4 and IPv6 RRs

I had comments on this from previous reviews. Rereading this section,
I don't know that it ha schanged. I'm not at all sure what the point
of this section is. having different TTLs on different RRsets poses no
correctness problems.

Indeed, in general, one doesn't know what a caching servers'
reclaimation policy is. So, one can always run into situations where a
server discards one RRset but not another, leading to the described
problem. So, this "problem" is not fixiable anyway. Good, since its
not really an actual problem AFAIK.

And yeah, sure if applications don't query the DNS for RRs they are
supposed to (e.g, by the definition of the MX record), that will lead
to problems. But if implementors don't follow the specs, they get what
they deserve.

If all section 4.5 says is the above, I'm not sure why this section is
needed.

I have only  re-reviewed section 4.4 and 4.5.

[Ballot comment]
Michael Patton notes:

My major concern is with the number of references that are still ID.
Are these IDs really close enough to completion?  Actually, in the
process of doing the review I had reason to want to refer to several
of the IDs for further info and crosschecking, all the ones that I
tried to look up were expired.  It's probably of enough importance to
get this draft out as an RFC that holding it up for another draft
still being revised would be unfortunate.  But even some of the
informative references are fairly important, so I'm not sure where to
go on this...

[Ballot discuss]
Overall, there is some useful stuff in this document, but it seems
overly long, and not very crisp in what it is trying to say.

>    over IPv4, and A records over IPv6.  The DNS servers must not make
>    any assumptions about what data to return for Answer and Authority
>    sections.

add "based on the underlying transport used in a query".

Actually, after having read the entire document, I wonder about his
must; is should good enough? As I point out later, the document has
not made a compelling case that the above is required for protocol
correctness, vs. just as an optimization. And I might add, if the DNS
server has to discard  some additional section stuff because the
packet will be too big, using the transport as a hint might be better
than just flipping a coin...

>    Temporary addresses defined in RFC3041 [10] (sometimes called
>    "privacy addresses") use a random number as the interface identifier.
>    Publishing DNS records relating to such addresses would defeat the
>    purpose of the mechanism and is not recommended.  If absolutely
>    necessary, a mapping could be made to some non-identifiable name, as
>    described in [10]."

Actually, registering names of the form "ipv6 address in hex" would be
just fine, as it would provide no new information.

>    Note that it does not seem feasible to provide reverse DNS with the
>    other automatic tunneling mechanism, Teredo [12]; this is because the

Please don't refer to Teredo as "the other ... mechanism", as it makes
it sound like there are only two. Surely, there are many possible.


>    [14]  Bush, R. and J. Damas, "Delegation of 2.0.0.2.ip6.arpa",
>          draft-ymbk-6to4-arpa-delegation-00 (work in progress), February
>          2003.
>

Hmm. what is status of this? ID tracker says dead...

> 4.1  Use of Service Names instead of Node Names
>
>
>    When a node includes multiple services, one should keep them
>    logically separate in the DNS.  This can be done by the use of
>    service names instead of node names (or, "hostnames").  This
>    operational technique is not specific to IPv6, but required to
>    understand the considerations described in Section 4.2 and Section
>    4.3.

This document should not be making such a general
recommendation. Especially not without some context about when/why one
might do this. I just asserts "one should".  "should" is completely
misplaced and lacks context.

> 4.2  Separate vs the Same Service Names for IPv4 and IPv6
>
>
>    The service naming can be achieved in basically two ways: when a
>    service is named "service.example.com" for IPv4, the IPv6-enabled
>    service could be either added to "service.example.com", or added
>    separately to a sub-domain, like, "service.ipv6.example.com".

Requirment is to use a different name. NOt sure why a subdomain should
be the (only) example. At least make clear that the requirment is to
use a different name. But this also means that IPv6 vs. IPv4 is not
transparent to applications/users, which is a disadvantage.

Oh, maybe you want to use a subdomain so you can use a search path???
This seems like a narrow solution, not a general one.


> 4.4  Behaviour of Additional Data in IPv4/IPv6 Environments
>
>
>    Consider the case where the query name is so long, the number of the
>    additional records is so high, or for other reasons that the entire
>    response would not fit in a single UDP packet.  In some cases, the
>    responder truncates the response with the TC bit being set (leading
>    to a retry with TCP), in order for the querier to get the entire
>    response later.

does one set the T bit if one can't include the additional sections?
or if critical info was truncated?

>    2.  "courtesy" additional data; this could be sent in full, with only
>        a few RRsets, or with no RRsets, and can be fetched separately as
>        well but could lead to non-optimal results.

better: "... as well, but at the cost of additional queries".


>    This temptation would have significant problems in multiple areas.

this needs to be justified. It is not clear to me what the
"significant problem" is. Indeed, is it just poor performance, or
incorrectness of result? Please be very clear on this point!

Section 4.4 could be more clear that when it starts talking about
problems, it is only talking about data in the additional
section. Presumably the answer section contains a correct answer.

Section distinguishes between "critical" and "courtesy" data (which is
good), but then later when talking about problems doesn't make clear
which of these two cause problems. Omitting "courtesy" data by
definition is never a problem (from a corrrectness perspective).

>    In the case of too much additional data (whether courtesy or
>    critical), it might be tempting to not return the AAAA records if the
>    transport for DNS query was IPv4, or not return the A records, if the
>    transport was IPv6.  However, this breaks the model of independence
>    of DNS transport and resource records, as noted in Section 1.2.
>

At this point, the doc is not clear about whether the above problem
ocurrs only with critical data.

Also, using the transport as a hint seems like it might be better than
just flipping a coin...

>    This temptation would have significant problems in multiple areas.
>    Remember that often the end-node, which will be using the records, is
>    not the same one as the node requesting them from the authoritative
>    DNS server (or even a caching resolver).  So, whichever version the
>    requestor ("the middleman") uses makes no difference to the ultimate
>    user of the records.  This might result in e.g., inappropriately
>    returning A records to an IPv6-only node, going through a
>    translation, or opening up another IP-level session (e.g., a PDP
>    context [20]).

Don't follow. For non-critical Additional Section, one can delete
whatever. That shouldn't impact correctness (just performance). Also,
don't follow the last part of second paragraph.


>    The problem of too much additional data seems to be an operational
>    one: the zone administrator entering too many records which will be
>    returned either truncated or missing some RRsets to the users.  A
>    protocol fix for this is using EDNS0 [40] to signal the capacity for

The operator configures what gets put into additional section? Is this
really the case?

>    Additionally, to avoid the case where an application would not get an
>    address at all due to non-critical additional data being omitted, the
>    applications should be able to query the specific records of the
>    desired protocol, not just rely on getting all the required RRsets in
>    the additional section.

This section has not explained clearly how not including
"non-critical" (please use the term you defined earlier, actually) can
cause an actual correctness problem.

> 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 RRsets from the additional section;
>    this could happen to both critical and "courtesy" additional data.

The above is again really unclear. Is the above a protocol issue, or
an implementation issue?

>    1.  We get back no A or AAAA RRsets: 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.

Don't know if this is true. If I do an MX query, and don't get back
either A or AAAA records, a subsequent query (by the application) may
only ask for A records. Thus, at the end of the day, you can't
guarantee that both A and AAAA will be in the cache at the same time.


>    2.  We get back all the RRsets: 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.

Again, not true. The only way to ensure you got all the RRsets is to
separately query for both A and AAAA (not just AAAA).

>    3.  We only get back A or AAAA RRsets even if both existed: this is
>        indistinguishable from the previous case, and problematic as
>        described in the previous section.

I haven't been entirely convinced by the previous section, actually.

>    After 100 seconds, the AAAA record is removed from the cache(s)
>    because its TTL expired.  It would be useful for the caching
>    resolvers to 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 recommendation seems broken. I also don't understand what the
problem is.

>    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.

the above seems to make assumptions about what  applications do. Yet
those assumptions directly contradict correct DNS behavior. Is this in
fact a real problem (i.e, that apps don't implement the spec correctly
in this context)?

>    The problems are serious because when looking up a DNS name, typical
>    getaddrinfo() implementations, with AF_UNSPEC hint given, first try

provide reference?

>    configuration.  The only (minor) twist is that with SLAAC, the DNS
>    server cannot tie the authentication of the user to the IP address,
>    and stronger mechanisms must be used [32].  As relying on IP
>

Don't understand this sentence.

>    Dynamic DNS with SLAAC simpler than forward DNS updates in some
>    regard, while being more difficult in another.

s/simpler/is simpler/??

actuall, I don't understand what this sentence is trying to say...

>    The address space administrator decides whether the hosts are trusted
>    to update their reverse DNS records or not.  If they are, a simple
>    address-based authorization is typically sufficient (i.e., check that
>    the DNS update is done from the same IP address as the record being
>    updated); stronger security can also be used [32].  If they aren't
>    allowed to update the reverses, no update can occur.

I am surprised to see this recommended, given the ease of address
spoofing attacks.

>    However, it is worth noting that in particular with Dynamic DNS
>    Updates, security models based on the source address validation are
>    very weak and cannot be recommended.  On the other hand, it should be

Actually, earlier text seemed to say this was OK in some
circumstances... Which is it?


>    To re-emphasize which was already stated, reverse DNS checks provide
>    very weak security at best, and the only (questionable)
>    security-related use for them may be in conjunction with other
>    mechanisms when authenticating a user.

Actually, this document hasn't done a very good job of defining just
what the "reverse DNS check" is. There are several variants, and I
thought the one that is actually used in practice is the one in BSD
that requires both a reverse and forward lookup, with the _forward_
lookup providing the "security", whereas the revers lookup only
provides the name to be used in the forward lookup and is by itself
meaningless.

> 11.  References

There are a lot of references to IDs here. Even though many are
"informative", I suspect that this document would be most useful if it
were not published until a good number of those IDs are RFCs (so they
can be  referenced). It would be good to think hard about which
references are like that and whether those documents are ever going to
be published.

[Ballot discuss]
4.1 advocates service names in the DNS.  Is this our official position, as opposed to SRV records?  I thought we wanted to discourage such things.  If SRV records are meant, this should be clarified.  (This is similar to one of my comments on draft-ietf-v6ops-application-transition, and should be resolved in the same way.)

[Ballot comment]
Feedback from gen-art (Spencer and Brian): generally useful document; would benefit mentioning that not all transition mechanisms considered by v6ops or
generally possible are under consideration and why. An editing pass would help
eliminate things like:

  Dynamic DNS with SLAAC simpler than forward DNS updates in some
  regard, while being more difficult in another.

[Ballot comment]
In 3.1, the draft says:

The solution is to fix or retire those misbehaving implementations,
  but that is likely not going to be effective.  There are some
  possible ways to mitigate the problem, e.g.  by performing the
  lookups somewhat in parallel and reducing the timeout as long as at
  least one answer has been received; but such methods remain to be
  investigated; slightly more on this is included in Section 5.

I note that in the recent MARID interim folks who use DNS lookups
as part of related spam abatement procedures talked about using
parallel lookups for a variety of RRs (including A and AAAA) as though
it were common practice for them.  In particular,they seem to use
a set of mechanisms for information sharing between query threads
that may be more generally useful.  The loosely parallel mechanism
looks like an attempt to game a race condition, and that seems
like it is unlikely to give consistent results.