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

[Roy Arends]

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.
>
> The TTL for the additional results from A.NIC.FR decrease.
>
> The TTL for the additional results from f.nic.de don't (although I get
> different results at different times from f.nic.de, so I assume it  
> is more
> than one servers - version queries suggest something similar).
>
> So I doubt the configurations are identical.
>
> Let us call them superficially similar ;)
>
>> Is that considered a bad idea?
>>
>> Please justify whether the answer is YES or NO.
>
> Can your cached data be corrupted by spoofing?
>
> If "yes" then it is a bad idea.
>
> As to whether supplying additional answers that are "nothing to do  
> with you"
> is a good idea; I'd think most are ignored (burning bandwidth to no  
> avail,
> and when they aren't being ignored they risk being wrong). I think a  
> lean DNS
> config is probably the thing.
>
> I note my DNS servers serve additional data from other zones they are
> authoritative for, so I probably ought to stop that as well for  
> similar
> reasons.


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,

Roy