> ask yourself how many DNS admins are going to go pull out
> the "-delegation" stanzas from their configs? Or that
> will use them to lie about other delegations that use wildcards
> as long as that code is still available? ...
And what possible problems are you expecting with leaving
zone "com" { type delegation-only; };
zone "net" { type delegation-only; };
in the configuration?
They should be delegation-only in any case, shouldn't they?
well, thats up to the zone admin. 
my concern is mostly along the lines of folks who will do things like:
zone "waw.pl" { type delegation-only; };
to random zones that they think -SHOULD- be delegation-only, regardless
of what the zone admin specifies.
> And what possible problems are you expecting with leaving
> zone "com" { type delegation-only; };
> zone "net" { type delegation-only; };
> in the configuration?
>
> They should be delegation-only in any case, shouldn't they?
that was the basis of the enhanced version of the feature, which is spelled
"root-delegation-only". non-delegation data in root or toplevel domains is
possibly useful (like www.$TLD) but not necessary (an NS can be put in to
achieve the same effect with an extra "hop".)
well, thats up to the zone admin.
my concern is mostly along the lines of folks who will do things like:
zone "waw.pl" { type delegation-only; };
to random zones that they think -SHOULD- be delegation-only, regardless
of what the zone admin specifies.
"and remember, kids, all power tools can kill."
> zone "com" { type delegation-only; };
> zone "net" { type delegation-only; };
well, thats up to the zone admin.
Everything is.
my concern is mostly along the lines of folks who will do things like:
zone "waw.pl" { type delegation-only; };
to random zones that they think -SHOULD- be delegation-only, regardless
of what the zone admin specifies.
So you are questioning the "type delegation-only" functionality? Then
it's a wrong address, stupidity will always be the biggest problem in
the universe.
However, Verisign hijacking "com" and "net" made few things clear. Most
important: these domains are public, not theirs, hence they should not
do arbitrary changes to them. Marking "com" and "net" as delegation-only
is not harming anything. (At least until ICANN changes its mind.)
p.
Paul, I would not call "root-delegation-only" an enhancement. With "type
delegation-only", you had to specifically name these and only these zones
you wanted restricted. With the latter, you need to be alert all the time,
keep an eye on all TLDs, whether they are legally using delegations. If I
am not mistaken, "exclude" statement to this option had four revisions
already.
p.
Paul, I would not call "root-delegation-only" an enhancement.
it's an enhancement in the sense that it's more complicated and it's more
code and it came later in response to complaints about the earlier feature.
With "type delegation-only", you had to specifically name these and only
these zones you wanted restricted. With the latter, you need to be alert
all the time, keep an eye on all TLDs, whether they are legally using
delegations. If I am not mistaken, "exclude" statement to this option had
four revisions already.
Four revisions in the first two days, none since.
* chopin@sgh.waw.pl (Piotr KUCHARSKI) [Sat 04 Oct 2003, 20:51 CEST]:
[..]
do arbitrary changes to them. Marking "com" and "net" as delegation-only
is not harming anything. (At least until ICANN changes its mind.)
According to this mail:
http://gnso.icann.org/mailing-lists/archives/registrars/msg00532.html
... apparently it breaks IDN resolution. Does anybody have the definite
word on that?
Regards,
-- Niels.
It would seem to do so, yes - removal of the wildcard would also imply that Verisign's IDN stopgap (between applications which use the xn-- encoding and applications which do 8-bit dns) will now break.
Hm. And how would it suppose to break IDN resolution? Client encodes
the hostname, then asks the DNS about already encoded name. So the
bind receives the request about, say, "xn--szkoagwnahandlowa-lyb21mca.pl".
How would that fail with "delegation-only"?
p.
I don't think Niels was referring to the "proper" IDN solution, but more the stopgap implementation which Verisign pushed into service. It actually resembles Sitefinder in many ways 
j
x
* joel@jml.net (Joel Rowbottom) [Mon 06 Oct 2003, 22:34 CEST]:
do arbitrary changes to them. Marking "com" and "net" as
delegation-only is not harming anything. (At least until ICANN changes
its mind.)
According to this mail:
http://gnso.icann.org/mailing-lists/archives/registrars/msg00532.html
... apparently it breaks IDN resolution. Does anybody have the
definite word on that?
Hm. And how would it suppose to break IDN resolution? Client encodes
the hostname, then asks the DNS about already encoded name. So the bind
receives the request about, say, "xn--szkoagwnahandlowa-lyb21mca.pl".
I don't think Niels was referring to the "proper" IDN solution, but
more the stopgap implementation which Verisign pushed into service.
It actually resembles Sitefinder in many ways
I only referred to the archived registrars mailing list posting; I'm not
following IDN much as, even though it's nice to see actual work being
done in that area, it does smell of VeriSign landgrab.
I'm interested in what has also broken due to the rash wildcard addition
by Verisign. If anybody has any more technical information on this,
please step forward.
Regards,
-- Niels.