<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<div class="moz-cite-prefix">On 16-Dec-20 13:52, Tim Daneliuk wrote:<br>
</div>
<blockquote type="cite"
cite="mid:fbd3733c-ec04-e8c7-82a7-af86289acde8@tundraware.com">
<pre class="moz-quote-pre" wrap="">On 12/16/20 12:25 PM, Timothe Litt wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">On 16-Dec-20 11:37, Tim Daneliuk wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">I ran into a situation yesterday which got me pondering something about bind.
In this case, a single line in a zone file was bad. The devops automation
had inserted a space in the hostname field of a PTR record.
What was interesting was that - at startup - bind absolutely refused
to load the zone file at all. I would have expected it to complain
about the bad record and ignore it, but load the rest of the
good records.
Can someone please explain the rationale or logic for this? Not complaining,
just trying to understand for future reference.
TIA,
Tim
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
DNS is complicated. The scope of an error in a zonefile is hard to determine.
To avoid this, your automation should use named-checkzone before releasing a zone file.
This will perform all the checks that named will when it is loaded.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Kind of what I thought. Whoever build the environment in question
really didn't understand DNS very well and hacked together a kludge
that I am still trying to get my head around.
</pre>
</blockquote>
<p>For a simple example of why it's complicated - what if the typo
you had was for a host that sends e-mail?</p>
<p>You'll see intermittent delivery errors when remote hosts can't
resolve the host's address; some require that a reverse lookup
resolve to the host as an anti-spoofing measure. Others won't.
You'll spend a long time diagnosing.<br>
</p>
<p>named can't tell this case from a typo for a local printer's PTR
- where it's unlikely that a reverse lookup failure will matter.
Of course, this means it could go undetected for years - until it
IS needed.</p>
<p>Or the typo is in a NS record - which you probably won't detect
until the other NS goes down...</p>
<p>And, any errors are cached for their TTL by resolvers. The TTL
may (hopefully for query rate reduction) be large. In your case,
it would be the negative TTL (meaning that even adding the record
later wouldn't have immediate effect).<br>
</p>
<p>The bottom line is that named must assume that anything placed in
a zone file is important, and that the external impact - either
sin of omission or commission - might be large.</p>
<p>Thus, while named can't detect all (or even most) errors, those
that it does detect cause immediate failure to load. That
prevents caching and propagation as well as getting human
attention.<br>
</p>
<p>When something's wrong, it's best to stop and fix it. Error
recovery is a very good thing - but only when you can demonstrate
that the cure is better than the disease. Skipping format errors
in a zone file would not satisfy that constraint.<br>
</p>
<pre class="moz-signature" cols="72">Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
</pre>
<br>
<blockquote type="cite"
cite="mid:fbd3733c-ec04-e8c7-82a7-af86289acde8@tundraware.com">
</blockquote>
</body>
</html>