Wrong thread, so I changed the subject.. Thanks for feedback; most of
these seem to be caused by confusion that this would be a normative
reference for implementors, managers and users; it is not. Maybe this
needs to be strengthened in the Introduction..
On Tue, 23 Mar 2004, J-F C. (Jefsey) Morfin wrote:
> 1.2 Independence of DNS Transport and DNS Records
>
> DNS has been designed to present a single, globally unique name space
> [6]. This property should be maintained, as described here and in
> Section 1.3.
>
> | the meaning of the word "global" differs in American and in English.
> | the reference to RFC 2826 is inadequate. The reason why is that RFC 2826
> | is for information, is ambiguous and over disputed. RFC 883 says the
> | same thing better - even if contradicted by RFC 882 at the time.
>
> | When introducing a tool of globality such as IPv6, it is inappropriate
> | to refer to obsolete documents. RFC 2826 is obsoleted by ICP-3 which
> | considers that future (IPv6?) might lead to a non unique authoritative
> | root file.
>
> | the DNS has not been designed to present "a" single unique name space.
> | The current use of the only "IN" RR leads to that. As an example the
> | preparation of the 2005 WSIS in Tunis considers the demand of the users
> | as the defintion of "Tunnet". The use of a "TN" RR would permit to
> | test them without disrupting the current Internet. This kind of
> | experimentation, under these terms, is what is called for by ICP-3.
> | The experiementation of new IPv6 features should be proposed under
> | an experimentatal name space, for example "I6". This RFC should
> | document it as a way to transition and safely experimenting.
This document represent current practice and understanding, not what
might be or could be, (or what some others may hope will never be).
Thus I do not see a need to make changes here.
> In DNS, the IP version used to transport the queries and responses is
> independent of the records being queried: AAAA records can be queried
> 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.
>
> However, there is some debate whether the addresses in Additional
> section could be selected or filtered using hints obtained from which
> transport was being used; this has some obvious problems because in
> many cases the transport protocol does not correlate with the
> requests, and because a "bad" answer is in a way worse than no answer
> at all (consider the case where the client is led to believe that a
> name received in the additional record does not have any AAAA records
> to begin with).
>
> | this leads to accept a layer violation as a legitimate consideration.
> | the DNS is about resolving 0-Z strings into IP adresses. External issues
> | such as used protocols are orthogonal, except when a part of the
> | query - like for mail services and "MX". Phrasing should underline this?
Note that the latter paragraph only describes that there has been
debate about a subject, and states why this is a bad idea. If you
think this is insufficient (and as there was some other pushback about
changes), could you propose text you'd like to see changed (and how)?
> 2.1 Limited-scope Addresses
>
> The IPv6 addressing architecture [5] includes two kinds of local-use
> addresses: link-local (fe80::/10) and site-local (fec0::/10). The
> site-local addresses are being deprecated [7], and are only discussed
> in Appendix A.
>
> Link-local addresses should never be published in DNS, because they
> have only local (to the connected link) significance [8].
>
> | "should" ? Should it not be possible to enforce this in writing codes
> | voiding the concerned RRs if entered ?
Enforcing anything is beyond the scope of this document. It may give
hints to implementers and the DNS spec writers, but that's all about
it.
> 5.2 Recursive DNS Resolver Discovery
>
> Recursive IPv6 DNS resolver discovery is a subject of active debate
> at the moment: the main proposed mechanisms include the use of
> well-known addresses [21], the use of Router Advertisements to convey
> the information [22], and using DHCPv6 (or the stateless subset of it
> [23]) for DNS resolver configuration. No consensus has been reached
> yet.
>
> Note that IPv6 DNS resolver discovery, while an important topic, is
> not required for dual-stack nodes in dual-stack networks: IPv6 DNS
> records can very well be queried over IPv4 as well.
>
> | it seems inadequate to publish a comprehensive document with such a
> | lack of consensus. Or to mention that as a point for a further RFC.
This subject is out of scope for this work, and is being solved
separately. I think the question is which is better, publishing a
document describing current understanding or waiting for long time to
get consensus so that every issue has already been decided. For
informational purposes, I think publishing (even if still raw) results
is appropriate.
However, there is work in progress to describe this at more length
before the next IETF -- but that's a separate topic.
> 7.1 Applicability of Reverse DNS
[...]
> It is not clear whether it makes sense to require or recommend that
> reverse DNS records be updated. In many cases, it would just make
> more sense to use proper mechanisms for security (or topological
> information lookup) in the first place. At minimum, the applications
> which use it as a generic authorization (in the sense that a record
> exists at all) should be modified as soon as possible to avoid such
> lookups completely.
>
> | wording seems unadequate for an RFC? Should it not be afirmative?
> | Saying "there are diferent positions" : as a developper or a
> | manager, I cannot make any sense out of this?
That's as it should be, in this case: this document is not trying to
be *normative* reference on how things must be done, but to point out
different arguments (if there are more than one) to give the reader
the opportunity to judge on his own.
> 7.3 DDNS with Stateless Address Autoconfiguration
>
> Dynamic DNS with SLAAC is a bit complicated, but manageable with a
> rather low form of security with some implementation.
>
> | quite subjective, unprecise and uninformative "a bit", "rather low"?
Yes, but this is explained at more length below. Other suggestions?
Note that anything is likely to be subjective here :-)
> Every node on a link must then be allowed to insert its own reverse
> DNS record in the reverse zone. However, in the typical case, there
> can be no stronger form of authentication between the nodes and the
> server than the source IP address (the user may roam to other
> administrative domains as well, requiring updates to foreign DNS
> servers), which might make attacks more lucrative.
>
> | "lucrative" seems subjective :-). It does not tell the kind of risk.
> | As a user I want to understand what I am to do and why.
It is intended to point out that attacking is eas(y/ier) if you just
use IP addresses as a form of authentication. I agree that this
wording should be better. Maybe along the lines of:
. In this case the attacker would only need to be able to
spoof the source address to be able to hijack a DDNS-managed
name -- compared to obtaining breaking cryptographic keys if a
more secure form of DDNS management was used.
sound good enough? other suggestions?
> Moreover, the reverse zones must be cleaned up by some janitorial
> process: the node does not typically know a priori that it will be
> disconnected, and cannot send a DNS update using the correct source
> address to remove a record.
>
> | "some" ? Janitorial ? What is the process to specifically carry ?
> | I should understand what I am to develop.
This document is not meant to be normative, so the details are left as
an exercise of the reader; I don't think it is useful to try to
specify the exact steps here, but if you have suggestions what to add
here...?
--
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
