delegation only, uz. tld

[Paul Vixie]

Florian Weimer <fw at deneb.enyo.de> writes:

> > let's not exclude tld's from delegation-only just because they have
> > in-zone nameservers.
> 
> These aren't just in-zone name servers (I think you mean "glue
> records"), these are in-zone A records for which the SLD servers are
> themselves authoritative.

i see that.  but they're only used for the SLD's own servers.  so, responses
to normal queries are only going to see these records in the additional data
section, and the responses themselves will be "delegations" not "answers" in
the parlance of the delegation-only logic.  one only sees direct queries for
nameserver A RR's if they expire or were not provided in a delegation, and if
that query fails then the failure will trigger a refetch of the original NSRRs.

in other words this is a theoretical not operational problem.

> > the additional data isn't what triggers the syslog, it's the
> > direct-query-for-the-glue, which is usually avoidable.
> 
> Look at the answer section (and the AA flag you didn't quote).  This
> zone is definetely *not* delegation-only.

as the author of the original delegation-only logic (but not the code, mind
you, we have experts for that part), let me remind you that zone operators do
not like being categorized as "delegation-only", because it restricts their
ability to innovate using new features like "wildcards".  a resolver operator
will only exempt a tld from delegation-only if the perceived value to the
resolver operator from allowing the zone to emit non-delegation responses is
higher than the perceived cost.  this was absolutely true of .NAME at the time
the <http://www.isc.org/sw/bind/delegation-only.php> web page was last edited.

candidly, i do not expect this list to change again, since otherwise, a TLD
operator might be able to get their TLD exempted by a large number of resolver
operators, and then abuse their privileged status by adding a wildcard, or
worse.  i also to not expect further changes to our web page to result in any
wide changes in the field.  most of those named.conf files can be considered
be "static" at this point.  that's unfortunate, but is an inevitable result of
cowboy innovation vs. cowboy counter-innovation.  let's be careful out there.
-- 
Paul Vixie