Re: [dane] Behavior in the face of no answer?

[Ondrej Mikle <[e-mail]>]

On 05/08/2012 09:46 PM, Tony Finch wrote:
> Ondrej Mikle <[e-mail]> wrote:
>>
>> From the ongoing scan, out of 70M currently finished .com domains,
>> SERVFAILs appeared for ~8.6M distinct domains.
> 
> We're running validating resolvers and we haven't noticed that level of
> failure. What proportion of authoritative servers with working DNSSEC
> return SERVFAIL for what QTYPEs?

The scans finished, here is a breakdown of what those SERVFAILs represented.
Short summary: As I expected, most of the domains are most likely
parked/unmaintained/speculative (by some whois queries, still SERVFAIL etc.)
Thus no reason for admin to care about them - that also means users won't ask
for them either.

Total amount of .com domains scanned: ~102M

1. SERVFAILS due to NS fetch failed and other RRs failed (disjunct)
     10114651 - NS fetch failed - the scanner skips the domain altogether
      2373284 - unique count of domains with SERVFAIL for at least one other RR
     12487935 total

2. NS fails on FQDNs contained in Alexa/Quantcast TOP 1M
      19574 alexa
      26087 quantcast

3. Unique domain count with at least one SERVFAIL for non-NS RR present in
Alexa/Quantcast TOP 1M
     18977 alexa
      6017 quantcast

The errors from "valuable/important" domains seemed transient (just bad time to
ask, probably). We'll still redo the SERVFAILs once/twice more.

Other (maybe interesting) common "weird pattern" is using 127.0.0.1 or 0.0.0.0
for A targets. I'm guessing those are domains used for development (so that it
connects to developer's machine). Can anyone think of other reason?

Apart from the above, there is definitely more brokenness. Mostly various
corner cases not explicitly/exhaustively covered by RFCs (tough rare in numbers).

Ondrej Mikle