Question 1

Which record types can you watch?

Accepted Answer

A, AAAA, CNAME, MX, TXT, NS and SOA are on the form, and CAA, PTR and SRV are accepted as well. The list is deliberately shorter than everything DNS can hold: each one here is a record whose changing is something a customer would notice, which is the only kind worth an alert.

Question 2

What is the difference between NXDOMAIN and SERVFAIL?

Accepted Answer

NXDOMAIN means the name does not exist: a typo, a deleted record, or a delegation that expired. SERVFAIL means the nameservers were asked and none of them gave a usable answer, which is a broken zone or servers that are down. A third case, the name existing with no record of that type, is reported apart from both, because all three have different fixes.

Question 3

Can you tell me whether a change has propagated?

Accepted Answer

Partly, and it is worth being precise about what propagation is: nothing spreads outward, caches simply expire at their own pace. Checks run from three continents, so a change that has landed in one and not another shows up as a disagreement. Name your own authoritative server and you see the change the moment it is made instead.

Question 4

Would this catch a DNS hijack?

Accepted Answer

That is the failure it exists for. A record can resolve quickly, from every resolver, with a healthy TTL, and point at somebody else's address; nothing that asks only whether DNS answered will ever see it. Fill in the answer you expect and a record pointing anywhere else fails within one interval.

Question 5

Do you check the TTL, or validate DNSSEC?

Accepted Answer

No, and we say so rather than implying otherwise. The TTL is whatever your zone says and this does not assert on it, and DNSSEC signatures are not validated. What is checked is the answer that comes back and whether it is still the one you expect, which is the failure the rest of your monitoring cannot see.

Question 6

What does matching exactly do that matching any does not?

Accepted Answer

Any of them passes when your expected value is somewhere in the answer, which is what you want for a name behind a pool of addresses. Exactly these fails when anything has been added, and adding is how the damage usually arrives: an extra A record or an extra MX beside yours is record change detection that nothing else catches.

Question 7

Why not run dig from a script?

Accepted Answer

You can, and for checking one record once it is the right tool. The difficulty is that there is no such thing as the answer: what your resolver returns and what a resolver in Sydney returns can differ for as long as a TTL, and a script on one machine asking one resolver sees one of those. This asks from four continents and can be pointed at a specific resolver, which is what turns a lookup into a comparison.

Question 8

My registrar emails me when a record changes. Is that not enough?

Accepted Answer

Keep it, it is a real check and it is the fastest way to find out that somebody on your own team changed something. What it covers is the case where the change went through your registrar, which is the one you were least worried about. It says nothing when a record is changed at a provider you also use, when a zone transfer goes wrong, or when a resolver somewhere returns something your registrar never published. Those are the failures that look like nothing is wrong.

DNSモニタリング

今すぐ試してください

用途

設定できる内容

質問

どのレコードタイプを監視できますか？

NXDOMAINとSERVFAILの違いは何ですか？

変更が伝播したかどうかを教えてもらえますか？

これでDNSハイジャックを検出できますか？

TTLを確認したり、DNSSECを検証したりしますか？

完全一致が部分一致と異なる点は何ですか？

スクリプトからdigを実行しないのはなぜですか？

レコードが変更されるとレジストラからメールが届きます。それでは不十分ですか？

他のチェック