[dns-operations] Concerns regarding the ICANN/IANA DNS vulnerability checker

[Mohsen Souissi]

 On 19 Aug, Roy Arends wrote:
 | On Aug 19, 2008, at 1:25 PM, Simon Waters wrote:
 | 
 | >On Tuesday 19 August 2008 11:30:26 Mohsen Souissi wrote:
 | >>
 | >>For example:
 | >>
 | >>- "dig @[fz].nic.de de ns"
 | >>- "dig @ca0[1-6].cira.ca ca ns"
 | >>- "dig @[a-m].gtld-servers.net net ns"
 | >>
 | >>all have the same behavior as a.nic.fr (if I'm not wrong) as they are
 | >>not authoritative for the child zone in which sits the NS. The list  
 | >>of
 | >>examples may be quite long I guess, that's not the point.
 | >

[...]

 | >>Is that considered a bad idea?
 | >>
 | >>Please justify whether the answer is YES or NO.

[...]

 | Some statements wrt the protocol:
 | 
 | The AA bit does NOT apply to the additional section, therefor, data in  
 | the additional section can't be treated as authoritative data.
 | 
 | Glue records in the additional section is at times needed to get to  
 | the proper authoritative server.
 | 
 | Authoritative servers might get those glue records on load, in which  
 | case you won't see the TTL decrease.
 | 
 | Authoritative servers might get those glue records from cache.
 | 
 | In that case it is important to realize why there records were cached.
 | 
 | One reason might be that the server is configured to allow recursion,  
 | which I think is not wise.
 | 
 | Another reason, and this is not that known, is that the authoritative  
 | server needs to notify others at times, and needs to resolve and cache  
 | those addresses, despite its configuration.
 | 
 | Hope this helps,

==> Thanks Roy. It helps. But, I still don't have any answer to my
question above (of course, I'm not asking you specifically to
answer it! :-)). So, let me try to reword it:

========================================================================
Recalling that the NS's in question are for actually within the domain
queried for (so they cannot be ignored by caches), and assuming that
these data get into the ADNS cache by any sort of configuration or
side effect (notify resolution...) *except* enabling recursion (this
is not the case and is not supposed to happen for a "reasonable" TLD
server):

Is the behavior I mentioned deemed a bad one?

If so, are there any BCP (or good practices if many) dealing with it
and recommending typical kinds of configuration (such as
"allow-query-cache { none; };" for instance)?
========================================================================

Otoh, one may force those servers to be also authoritative for the
child zone, so that the become also authoritative for that data they
serve in additional section. However, this may lead to other issues
such as glue inconsistency across zone cuts (this issue was recently
discussed on dnsext mailing-list, on cache poisoning and on
AXFR-clarify topics). And IIRC, this sort of configuration has been
discouraged so far.

Btw, some TLDs have such configuration currently running (that's to
say, at least one NS is authoritative for both nic.tld and tld zones)
and that does not bother me, so I'm not picking on those TLDs :-)

Mohsen.