parental-agents clause - IP address only ?

[Timothe Litt]

On 06-Dec-22 01:58, Erich Eckner wrote:
>
> [snip]
> 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?
>
> That being said: I'm not saying, it *should* do so, I'm merely 
> curious, why it does not. :-)
>
> regards,
> Erich
>
>
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).

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.

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.)

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.


Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20221206/8c88719f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20221206/8c88719f/attachment.sig>