Transcript APNIC LAME NS measurements Overview • • • • • Methodology Initial outcomes from 128 days runtime How bad is the problem? LAME-ness trends Proposals for dealing with LAME NS.

APNIC LAME NS measurements
Overview
•
•
•
•
•
Methodology
Initial outcomes from 128 days runtime
How bad is the problem?
LAME-ness trends
Proposals for dealing with LAME NS
Methodology
• Forked tree of perl processes
– Implemented on Net::DNS package
– Searches source:APNIC domain objects
– For each listed object, checks nserver(s)
– 20 parallel tasks
• Very low server impact, circa 3 queries/sec
• Completes scan of 45,000 objects in in under
5 hours
• Status is either OK, partially or fully lame
• Daily run
Initial outcomes from 128 days of data
• 20% to 30% of domains have problems
– One or more NS not visible
– SOA serial mismatches
• 10% to 15% fully lame
– No functional NS in set of nserver
– Zone file may have other (valid) NS
• (checks on SOA listed NS future work)
How bad is the problem?
• During sample period
– 33% of domains all ns visible, all the time
• 43% better than 99% visible
– 11% of domains all ns lame, all the time
• 18% have a semi-persistant problem
• Caveats: only one point of probe
– Need to correlate with other query points
– Coordination with RIPE, ARIN sweeps
Full and Partial LAME-ness trend
LAME-ness is all good or all bad
No lame
All lame
LAME-ness is consistent
Proposals for APNIC SIG-DB
• APNIC to send out 'reminders' to
tech-c of domain objects with
consistently LAME ns
– Need to set threshold correctly
• Target the persistantly lame cases
• After <to be defined> time, if still
lame:
– APNIC disables DNS
• By marking domain: object with
special data
– Causes DNS generation to be
skipped
• Tech-c (real data owner) can un-mark
the domain object at any time