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

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.