2. Defining problem is half the solution
• is WHOIS registration for the domain correct?
#whois yurisk.info
- Verify EXPIRY date is in the future
- Make sure NAMESERVERS are set to the right ones
- Something wrong?: contact your registrar
• Verify that ALL nameservers from WHOIS answer the query:
#dig A yurisk.info @ns-286.awsdns-35.com
- No answer? Wrong answer?: fix the nameservers
Yuri Slobodyanyuk, https://yurisk.info
3. Defining problem is half the solution (cont.)
• You get answers OK but still got complains?
- Query the domain from different places on the Net
#dig A yurisk.info @8.8.8.8 // Google DNS
http://dnscheck.pingdom.com/
• From some places works, from others doesn’t?
- Either datacenter where the nameservers are located blocks some
networks or an intermediate party on the way (ISP, uplink provider)
does: check logs of the nameserver, if no queries from problematic
sources – work with datacenter to verify they do not block it.
Yuri Slobodyanyuk, https://yurisk.info
4. Location, location, location
• Works from anywhere but the complaining client’s network?
- Work with client to locate where it breaks:
Does changing DNS resolvers help (use 8.8.8.8, 209.244.0.3) ?
Are there any drops on UDP port 53 in the client’s firewall?
Is by chance the same domain present in Active Directory?
Can the client traceroute to your nameservers? If not, where fails?
Yuri Slobodyanyuk, https://yurisk.info
5. An ounce of prevention …
• Monitor your domain DNS records for availability and changes non
stop, even Nagios can do it
• Back up DNS zone file regularly
• Have dedicated and actively monitored email in WHOIS details
• Use secure measures at WHOIS registrar – 2FA, transfer lock, alerts of
nameservers change
• Have DR/contingency plan – if your DNS goes down/under attack,
how quickly can you switch to a working one?
• Exercise your Disaster Recovery (DR) plan regularly
Yuri Slobodyanyuk, https://yurisk.info