Hi list,
this is my first post, so be nice. 
Wondering about IPv6 deployments to end-users, imagine we deploy a full /48
address to each client.
How is the reverse DNS for each possible IPv6 address going to be?
Nowadays I'm used to do IPv4 reverse using old Class C, which has (up to)
256 entries. Are we really going to make reverse DNS entries for each of
those 2^80 addresses? Or going to deploy rDNS only at the PtP links and
relevant servers?
Kind regards,
Felipe
Windows will just populate the reverse zone as needed, if you let
it, using dynamic update. If you have properly deployed BCP 39
and have anti-spoofing ingres filtering then you can just let any
address from the /48 add/remove PTR records. Other OS's will
follow suite.
Alternatively you can delegate the reverse for the /48 to servers
run by the customers.
Mark
Windows will just populate the reverse zone as needed, if you let
it, using dynamic update. If you have properly deployed BCP 39
and have anti-spoofing ingres filtering then you can just let any
address from the /48 add/remove PTR records. Other OS's will
follow suite.
Is DDNS really considered to be the end-all answer for this? It seems we're putting an awful lot of trust in the user when doing this.. I'd rather see some sort of macro expansion in bind/tinydns/etc that would allow a range of addresses to be added.
Alternatively you can delegate the reverse for the /48 to servers
run by the customers.
This works for commercial customers, but I'm not sure I'd want to delegate this to a residential customer.
Naïve question: If you used macro expansion, wouldn't you end up
providing responses for a lot of addresses that aren't in use? Maybe
that's not a problem?
Presumably the op would only use macros where needed, ie dynamically assigned addresses. So, for a pool of addresses assigned for DSL/Cable/FIOS subscribers, that pool would have forward/reverse set up.
Note: I am definitely not up on my IPv6 knowledge, so there may be a Really Good Reason(tm) that one should not do this.. However, I was under the impression that having both forward and reverse for dynamic IPs was a best practice..
Windows will just populate the reverse zone as needed, if you let
it, using dynamic update. If you have properly deployed BCP 39
and have anti-spoofing ingres filtering then you can just let any
address from the /48 add/remove PTR records. Other OS's will
follow suite.Is DDNS really considered to be the end-all answer for this?
Seems it is that or not bothering with reverse anymore.
It seems we're putting an awful lot of trust in the user when doing this.. I'd rather see some sort of macro expansion in bind/tinydns/etc that would allow a range of addresses to be added.
Hmm. A macro expansion for a /48 would mean 1,208,925,819,614,629,174,706,176 leaves. An interesting stress test for name servers... :-).
Slightly more seriously, there have been discussions in the past about doing dynamic synthesis of v6 reverses, but that gets icky (particularly if you invoke the dreaded "DNSSEC" curse) and I don't know any production server that actually does this now. Dynamic DNS is probably the least offensive solution if you really want reverses for your v6 nodes.
Regards,
-drc
Hmm. A macro expansion for a /48 would mean 1,208,925,819,614,629,174,706,176 leaves. An interesting stress test for name servers... :-).
Um.. sure. 
Your computer can't handle that?
How about a programmatic expansion? Only create the necessary record when asked for it.
Slightly more seriously, there have been discussions in the past about doing dynamic synthesis of v6 reverses, but that gets icky (particularly if you invoke the dreaded "DNSSEC" curse) and I don't know any production server that actually does this now. Dynamic DNS is probably the least offensive solution if you really want reverses for your v6 nodes.
DNSSEC does seem to throw the proverbial wrench in the works.. At least, from what I understand.. I'm still not sold on DNSSEC and that, partly, has to do with a lack of knowledge..
If you allow a client to set their own reverse, don't you run into issues where the client can spoof their identity? ie, set their reverse to whitehouse.gov or bankofamerica.com ? Or is it possible to configure DDNS in such a way as to only allow subdomain names where the domain is tacked on automagically?
There are other solutions, which has become a major focus of mine based
on some of the results I've gathered from my little test.
About 50% (currently 50.59%) of all successful visits to my site do not
have rDNS configured for their IPv6...
That is a problem that needs a solution.
The OP has a great question here.
Steve
If you get a request, you will have to respond in any case.
I have a theory about data-base lookups--finding something is always
faster than not finding anything, unless you are using a human brain.
(A human brain can respond "I don't know that" without an inventory of
everything it does know.)
(That may be to only truly unique thing about humans. And no, I have
not kept up with neural networks work.)
<off-topic>
<IANADBExpert>
Interesting theory, but seems kind of wrong. Wouldn't the time to
look up or fail be tied to the complexity of how the key space is
populated? In any case, it seems like the time to succeed or fail
will usually be about the same, since you'll try to access the value
for a key and either find something there or fail.
How about a programmatic expansion? Only create the necessary record when asked for it.
The downsides I know of (off the top of my head) with dynamic synthesis are (a) challenges if you want DNSSEC and (b) increased susceptibility to D(D)oS attack. There are probably others.
At some point, one has to ask if the ability to map the address into a name is worth the effort...
If you allow a client to set their own reverse, don't you run into issues where the client can spoof their identity? ie, set their reverse to whitehouse.gov or bankofamerica.com ?
Yep, but those are boring examples. I've seen (typically University computer science) networks with some truly fascinating (in scatological, religious and/or reproductive senses) reverse names. Since anyone who relies on the reverse for anything other than a hint that the address might be part of a managed network deserves what they get, the names were good for a chuckle.
Or is it possible to configure DDNS in such a way as to only allow subdomain names where the domain is tacked on automagically?
Most DDNS servers support some form of filtering. However, the better way, at least in IPv4, is to have the DHCP server do the dynamic updates, not the client. However, since some view DHCPv6 as Evil Pure and Simple by way of the Eighth Dimension(tm), this may not be an option.
Regards,
-drc
Presumably, if you've already got a script that's provisioning reverse
results, you could amend it to add name constraints. No idea if this
is possible with current DynDNS software, though.
--Richard
The theory is based on the notion that if you find something you stop
looking for it. If what you are looking for is not there, you have to
search all of the key-space, regardless of the index method.
In message <268EBCE2-9D47-488E-8223-29B5A6323CEB@godshell.com>, "Jason 'XenoPhage' Frisvold" wri
tes:
> Windows will just populate the reverse zone as needed, if you let
> it, using dynamic update. If you have properly deployed BCP 39
> and have anti-spoofing ingres filtering then you can just let any
> address from the /48 add/remove PTR records. Other OS's will
> follow suite.Is DDNS really considered to be the end-all answer for this?
It works if you let it.
It seems =
we're putting an awful lot of trust in the user when doing this.
What trust? The OS just does it. The user doesn't need to think about
this.
I'd =
rather see some sort of macro expansion in bind/tinydns/etc that would =
allow a range of addresses to be added.
Macro expansion won't work. 1208925819614629174706176 PTR records is
a hell of a lot of records and that's just 1 /48.
> Alternatively you can delegate the reverse for the /48 to servers
> run by the customers.This works for commercial customers, but I'm not sure I'd want to =
delegate this to a residential customer.
Some will be capable others won't. I would leave it as a option
but not the default. Some thing that the account's control panel
can turn on and off.
I would however use a different set of servers for the /48's to
that of serving the /32 (or whatever) as you can just change the
delegation without having to also add and remove zones which you
would if they are on the same servers.
I would also provide customers with forward zones that they can
populate again using the /48 to control access.
e.g.
<hex>.customer.isp.com.
<hex> is the hexadecimal representation of the /48.
<machine>.<hex>.customer.isp.com. AAAA <hex>:<client>
They don't need to use it but it should be there to provide complete
the loop.
If HE was following this schema then bsdi would default to:
bsdi.200104701f00.customer.he.net AAAA 2001:470:1f00:ffff::5a1
bsdi.200104701f00.customer.he.net AAAA 2001:470:1f00:820:2e0:29ff:fe19:c02d
But as I care about the name of the machine it is:
bsdi.dv.isc.org. AAAA 2001:470:1f00:ffff::5a1
bsdi.dv.isc.org. AAAA 2001:470:1f00:820:2e0:29ff:fe19:c02d
Mark
That is why, when I was actively designing (or supervising the design)
of data-bases, we tried to make the most likely hits at the beginning of
the key-space. In general, easier to say than to do. And not as
intuitive as you might think.
(In the old days, there was the closely related entertainment of
predicting which benefited most from cached-disc systems, random files
or sequential files.)
Hmm. A macro expansion for a /48 would mean
1,208,925,819,614,629,174,706,176 leaves. An interesting stress test
for name servers... :-).
My inclination would be to use a wildcard that returns something like
not-in-service.some-network.net, and let the clients add records for
the addresses they use.
For spoof resistance, how about doing a forward lookup on the
purported name and only installing it if it gets a matching AAAA
record?
R's,
John
Hmm. A macro expansion for a /48 would mean
1,208,925,819,614,629,174,706,176 leaves. An interesting stress test
for name servers... :-).My inclination would be to use a wildcard that returns something like
not-in-service.some-network.net, and let the clients add records for
the addresses they use.
While better than 1 septillion zone entries, you still have the problem of how to let the clients add the records. DDNS is one approach. Manual intervention (e.g., as part of a customer provisioning system) is another as long as you don't use privacy extensions.
For spoof resistance, how about doing a forward lookup on the
purported name and only installing it if it gets a matching AAAA
record?
Sounds like a reasonable DDNS filtering approach.
Regards,
-drc
> For spoof resistance, how about doing a forward lookup on the
> purported name and only installing it if it gets a matching AAAA
> record?Sounds like a reasonable DDNS filtering approach.
On controlled environments it might work. Don't know how larger ISPs would
set AAAA records before for bazillion possible combinations of
computer.subnet.customer.isp.tld.
If going dynamic, are you willing to lower your DNS TTL to handle that?
Maybe doing wildchar evatulation for /64 subnets? "Everything under this
subnet is my-subnet.customer.isp.tld".
Regards,
-drc
Kindly,
Felipe
Perhaps we should back up a bit and delete 'how' from the subject line
of this thread, and first ask 'Will it be done?' and where will RDNS
be implemented?
It is best practice within IPv4 networks. The IPv6 internet is a new
network, and prevalent practices will not necessarily turn out to be
what we consider best from V4. 'Best practice' is going to have
to meet with administrative necessity in some form at some point.
A reality may be that not all hosts necessarily have a meaningful
hostname that they should be addressed by, or that the 'operator'
(web browser user) wants to be known; Useful RDNS records may become
more confined to hosts that actually provide a globally accessible
service.
Residential subscribers of ISP you-are-not-allowed-to-run-a-server
level of DSL/Cable service will likely not have their own domain
name, providing RDNS delegation would be mostly a waste of resources.
Providing DDNS updates to RDNS is likely to be abused in various
ways, even if it can be secured (malware would love this -- instant
fully RDNS-cognizant mail server).
The prevalent practice is almost certainly going to be for res. ISPs
to provide a NXDOMAIN response to RDNS queries, or a generic
response like is common with V4.
Probably "custom RDNS" would be considered a business service, and
like all business services, have its own pricing schedule, and
involve subscriber providing IP addresses of DNS servers to delegate
to.
If Res. subscribers are lucky the big ISPs might provide a
proprietary app to run on their PC to magically register it with
RDNS, and enable for connectivity.
With the downside that there can now be an enforced per-PC surcharge.
Consumer DSL providers would probably love this.... $60/month,
connectivity for one PC to the internet at X/speed included..... .
$1/day extra for each additional PC registered with the DNS,
$0.10/hour for each Xbox/gaming console/HTPC/Media streaming device
registered for internet access.
*zip bang voom* 4 years later... IPv6 NAT, the prevalent
technology present in every $50 IPv6 router, an unofficial hack that
might some day get an RFC made about it....
Bloom filters work that way.
Tony (on his iPod).