On Wed, 20 Sep 2000, Harald Alvestrand wrote:
> While we are in the area of making semi-perverse ideas:
> What about replacing
>
> > > 4.3.2.1.in-addr.arpa IPTR en "english yahoo.com in utf8"
> > > IPTR de "german jahu.com in utf8"
> > > IPTR fr "french iaou.com in utf8"
>
> with
>
> lang-en.4.3.2.1.in-addr.arpa PTR "yahoo.com"
> lang-de.4.3.2.1.in-addr.arpa PTR "j�hu.com" (ACE encoded)
> lang-fr.4.3.2.1.in-addr.arpa PTR "iaou.com"
> *.4.3.2.1.in-addr.arpa PTR "anylanguage.yahoo.com"
> 4.3.2.1.in-addr.arpa PTR "yahoo.com" (normal clients)
>
> Disadvantage is that you don't get lang-cn and lang-jp as answers to one query.
how about a axfr of the zone 4.3.2.1.in-addr.arpa? :)
OK, I am not too serious.
This was actually one of the first approaches we thought
about. One of the reasons why we took the current approach
is for subnetting on a non-octet boundary.
When a network has small subnets (e.g. 133.23.12.0/26) system admins usually
like to chain PTR with CNAMEs. (DNS & BIND book edition 3 page 217 solution 3).
1.9.9.9.in-addr.arpa. IN CNAME 1.0-63.9.9.9.in-addr.arpa.
2.9.9.9.in-addr.arpa. IN CNAME 2.0-63.9.9.9.in-addr.arpa.
3.9.9.9.in-addr.arpa. IN CNAME 3.0-63.9.9.9.in-addr.arpa.
...
63.9.9.9.in-addr.arpa. IN CNAME 63.0-63.9.9.9.in-addr.arpa.
0-63.9.9.9.in-addr.arpa. IN NS ns1.foo.com
Harald's approach along this line will result in,
1. too many cname entries.( here we have 63 * n, n is the number of languages).
2. sysadmin at ns1.foo.com needs apriori knowledge, i.e. if there is no
"lang-fr.1.9.9.9.in-addr.arpa. IN CNAME lang-fr.1.0-63.9.9.9.in-addr.arpa."
at 9.9.9.in-addr.arpa. there is nothing I can do at ns1.foo.com.
solution 2 mentioned in the BIND book(pg 216) will actually solve this 2
problems. (and that is how we can do a axfr of the zone 4.3.2.1.in-addr.arpa).
I still feel IPTR is a cleaner approach, thou I do see the many benifits in
Harald's suggestion.
Thanks!!
Mingliang
