<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<div class="moz-cite-prefix">On 06-Dec-22 01:58, Erich Eckner wrote:<br>
</div>
<blockquote type="cite"
cite="mid:a958f687-2d8f-a3fc-0508-b6fd6c5719d1@eckner.net">
<br>
[snip]<br>
This made me curious: Is there some design rule forbidding bind to
use the system resolver to resolve names it does not know about?
I.e. why does it not query any resolvers in /etc/resolv.conf
(probably via some system interface - sry, I have no idea, how
"normal" programs resolve names) if it encounters an unknown name
at a place where only an ip address is allowed so far?
<br>
<br>
That being said: I'm not saying, it *should* do so, I'm merely
curious, why it does not. :-)
<br>
<br>
regards,
<br>
Erich
<br>
<br>
<br>
</blockquote>
<p>See man 3 getnameinfo and gataddrinfo for the current way of
resolving DNS names via the standard library. gethostbyname and
gethostbyaddr are the older functions (overall less functional,
harder to deal with IPv6 - but can deal with multiple names for a
host).</p>
<p>Resolving names in a resolver can be complicated. Especially
when recovering from an outage - if you are the first resolver
back, who do you ask? Additionally, resolving names is slow - not
a big problem for configuration data, unless you are operating a
really large server. (Which many named operators are...) But you
don't want unnecessary resolution on live code paths. Which
creates the question: if a name is in, say an ACL: does that mean
"whatever the name resolved to when the server started", or
"whatever the name resolves to when the ACL is used"? The latter
might be expected, but performance would crater. Then there are
the security issues: if someone can fool you into using their
server for name resolution, they can get whatever configuration
items to do what they want. So, if allow-update is supposed to be
your management host, they might supply an IP address that allows
them to update your DNS. Of course, there's DNSSEC - but that
requires more infrastructure to be up when you boot that first
server after a blackout.</p>
<p>None are insurmountable technical problems, but it's a lot of
complexity (hence room for bugs). The consensus is that it's not
worth it for the return. As noted earlier in the thread, most
places where IP addresses are used are fairly static. That lends
itself to an external solution. (As examples, I have a root hints
file from the 80s - while a couple of addresses have changed, it's
still good enough today. The root DNSSEC key has only changed
once. Server IP addresses change on a timescale of years - when
hardware is replaced - maybe. And when a corporate merger
renumbers networks. Or if you're a small operator and don't own
your IP addresses, when you change ISPs.)<br>
</p>
<p>This is also why I emphasized "TRUSTED" in selecting a suitable
resolver for an external process. In any case, using "include" in
configurations can help to modularize/isolate the places where IP
addresses are used.<br>
</p>
<p><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>
<p></p>
<div id="grammalecte_menu_main_button_shadow_host" style="width:
0px; height: 0px;"></div>
</body>
</html>