Please see some remarks attached. I went into as a first time reader. My global remark is that it tells me where the problems are rather than how to solve them (subjective global feeling). When you compare with Postel/Mokapetris texts, there are less real practical examples. I would suggest to describe a configuration with all the possible cases and to use it to document each point. I know it is complex but couldbe usefull.
Thank you.
jfc morfin



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.

   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



Durand, et al.            Expires July 1, 2004                  [Page 3]

Internet-Draft    Considerations and Issues with IPv6 DNS       Jan 2004


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?

...

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 ?

...

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.


7.1 Applicability of Reverse DNS


   Today, some applications use reverse DNS to either look up some hints
   about the topological information associated with an address (e.g.
   resolving web server access logs), or as a weak form of a security
   check, to get a feel whether the user's network administrator has
   "authorized" the use of the address (on the premises that adding a
   reverse record for an address would signal some form of
   authorization).

   One additional, maybe slightly more useful usage is ensuring the
   reverse and forward DNS contents match and correspond to a configured
   name or domain.  As a security check, it is typically accompanied by
   other mechanisms, such as a user/password login; the main purpose of
   the DNS check is to weed out the majority of unauthorized users, and
   if someone managed to bypass the checks, he would still need to
   authenticate "properly".

   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?

....

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"?

   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.

   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.

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

Reply via email to