[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[dnsop] comments about draft-huston-6to4-reverse-dns (fwd)
FYI --
it's a nice to see a realistic, deployable proposal out which would
provide 6to4 reverse DNS.
My gut feeling is that the right place for this is the DNSOP WG, but
this might be interesting to those not subscribed to dnsop as well.
---------- Forwarded message ----------
Date: Sun, 29 Feb 2004 07:34:28 +0200 (EET)
From: Pekka Savola <pekkas@netcore.fi>
To: gih@telstra.com
Cc: dnsop@lists.uoregon.edu
Subject: [dnsop] comments about draft-huston-6to4-reverse-dns
Thanks for this document. I think this should be implemented ASAP.
What should be the forum for advancement of this specification? DNSOP? I
don't recall it being on agenda, at least. Maybe it could still be
introduced there (5+ mins) if that's the right venue? If not, a
presentation at v6ops session is also fine by me.
substantial comments
--------------------
1) The memo has some language which seems to indicate that the author
believes 6to4 using DHCP-learned IPv4 addresses may be inappropriate. I
completely disagree with this, and I think more justification is needed, or
this text should be removed. In:
o IPv4 DHCP-based 6to4 sites could inherit nonsense reverse entries.
It is not clear that using 6to4 services in such environments is
entirely appropriate. In any case the client site could request
delegation of the reverse zone as required.
and:
It is envisaged that scenarios that would motive this
concern would include when the IPv4 provider is also offering an IPv6
service, and native IPv6 should be deployed instead of 6to4, or when
the service provider has dynamically allocated (via DHCP) IPv4 and
wishes to block customers' ability to use this scheme on those
addresses.
2) The memo states that the service should only be available over IPv6
(except for the instructions), from the 6to4 addresses which associate to
the the prefix. However, I see no technical reason for this restriction.
For security purposes, it is sufficient that the user is presented with the
6to4 reverse delegation set-up screen which corresponds to the IPv4 address
used.
However, if the 6to4 address usage is desirable for other purposes (for
example, not allowing the editing for those which haven't even activated
6to4), this should be stated explicitly as a goal ("make your 6to4 active
first, and get an IPv6 enabled web browser before coming here..").
3) Similarly, the memo states that the management service should have local
access to a 6to4 relay. Actually, it would be best if the service was
available at: 1) an IPv4 address, 2) a native IPv6 address, and 3) a 6to4
address. By adding 3), the 6to4 users wouldn't have to use the service
through the relay, and the traffic would be optimized. This would seem to
be desirable to me.
4) The memo allows (or doesn't specify it as a matter of fact), when
editing the authoritative DNS server information, to insert any IP
address as the DNS server. This would seem to assume that the threat
related to users putting bogus information there, i.e., making the
management DNS servers send DNS queries to any address they want, is not a
significant risk. Except for something like multicast addresses, I probably
agree with this -- but this issue should probably be called out explicitly,
here and in security considerations. In:
When accessed by a 6to4 source address, the interface presented by
the delegation server is a standard DNS delegation interface,
allowing the client to enter the details of a number of DNS servers
for the corresponding reverse domain. The servers are checked by the
delegation manager to ensure that they are responding, [...].
5) The memo does not specify or discuss at all how the TTL information of
the DNS records should be added. Obviously, this should not be too long..
6) The memo does not discuss how old information is scrubbed out of the
database. That is, the user enters information -- and when his IP address
for whatever reason changes, we can't any longer remove it, exploding the
database after some time! :-)
I have a proposal for this: the management system must check periodically
(e.g., 1/day or 1/week, depending on how long stale information is
acceptable to hang around) from the configured DNS servers that they still
remain authoritative for the zone. If they fail, the delegation is
automatically removed, and the servers are no longer tried. A warning
message can also be sent if this is deemed necessary (to the SOA email
address).
This keeps the reverses moderately "clean" and removes dangling reverse
pointers associated with e.g. DHCP IPv4 addresses.
This method does not address the case where the administrator of the DNS
server is willfully trying to spoof the reverses it no longer should own.
That is, consider a dynamically changing IP address which is delegated to a
server. When the IP address changes, the DNS server admin changes the zone
information as well, removing the old, unnecessary one. The DNS
administrator gets no joy of polluting his own DNS server by keeping old
zones hanging around :-).
One additional consideration are the wildcard records. Should the DNS
consistency check try to figure out whether the pesky administrator would
have configured itself autorative for all of 2.0.0.2.ip6.arpa (or a subset
of it). For example, if a user uses DHCP from a block 1.1.0.0/16, configure
all of the reverses there to point to his personal reverses -- to avoid ever
having to rig the zone files, just update the pointer to the authorative
DNS servers in the management tool?
7) I believe IANA considerations was already done by an already-published
BCP document by Randy -- or were I misremembering something?
IANA is instructed to delegate the zone 2.0.0.2.ipv6.arpa to the
Number Resource Organization, the cooperative operational entity that
the Regional Internet Registries use for coordinated common
activities.
editorial comments:
-------------------
6to4 Reverse DNS
==> a slightly more descriptive title might be preferable :)
the 6 to4 reverse zone file. The proposed mechanism is a conventional
==> s/6 to4/6to4/
Some assumptions have been concerning the nature of deployment of
6to4 gateways and comment relating to the validity of these
==> something missing after "have been concerning" ?
Internet-Draft 6to4rev January 2004
==> now this is the place where something terse as "6to4 Reverse DNS" might
fit in... :-)
There are a number of approaches to this problem, ranging from a
conventional explicit delegation structure through to various forms
of modified server behaviours that attempt to guess the location of
==> isn't "through" there redundant?
IPv6 space the upstream is not using Ipv6 and therefore would not be
==> s/Ipv6/IPv6/
A 6to4 client network is an isolated V6 network composed as a set of
V6 hosts and a dual stack (V4 and V6) local gateway connected to the
local V6 network and the external V4 network.
==> s/V4/IPv4/, s/V6/IPv6/ (everywhere :-)
+-------------+
6over4 packets (A)| | v6 packets
-------------------| 6to4gateway |--------------------------
| | | | | | |
+-------------+ local V6 clients
==> you should use something like "v6-over-v4" or "IPv6-in-IPv4"
instead of "6over4" because that's another transition mechanism altogether
:)
--
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