Re: parental-agents clause - IP address only ?
Hi, On Mon, 5 Dec 2022, Matthijs Mekking wrote: 'parental-agents' work the same as 'primaries'. It only supports addresses. Listing them as domain names would technically be possible to implement, but it requires an authoritative server to act as an resolver. Adding resolver code to the path of an authoritative server is like crossing the streams. It adds security risks that are unnecessary for an authoritative server, so I'd rather not add such functionality. 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. :-) Best regards, Matthijs regards, Erich -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: parental-agents clause - IP address only ?
On 05-Dec-22 11:17, vom513 wrote: On Dec 5, 2022, at 4:06 AM, Matthijs Mekking wrote: 'parental-agents' work the same as 'primaries'. It only supports addresses. Listing them as domain names would technically be possible to implement, but it requires an authoritative server to act as an resolver. Adding resolver code to the path of an authoritative server is like crossing the streams. It adds security risks that are unnecessary for an authoritative server, so I'd rather not add such functionality. Thanks for the confirmation - and yes makes sense. Also thanks to Timothe in this thread for the script inspiration. I cooked my own up and tested it - works brilliant. I also added some logic to email me if there is a diff from the last run. Will be interesting to see how often there actually is. I'm glad it was helpful. Rather than do it yourself diffs/email, I'd suggest simply committing changes to git (or another source control system). A commit hook can handle the diff and/or e-mail. And having your configuration under source control can be very helpful when things go wrong. It's trivial to roll back or forward, visualize history, and (sometimes) bisect. And it enforces documenting why changes are made. Plus, of course, it's easy to replicate changes to a local backup with a push... If you've developed something that's generally useful - or could be made generally useful - I encourage you to share it. Here, or especially if larger, a pointer to one of the usual platforms. (GitHub, GitLab, sourceforge, etc). The community works best when everyone contributes what they can. Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. OpenPGP_signature Description: OpenPGP digital signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: TIL: Restricting DiG to UDP only with +ignore
Hello Petr: On 12/5/22 4:35 AM, Petr Špaček wrote: > On 05. 12. 22 3:49, Fred Morris wrote: >> If the UDP query returns TC=1 DiG retries with TCP. I want to see the >> UDP results and am unable to. Specifying +notcp makes no difference. >> The correct option is +ignore: >> >> # dig @127.0.0.1 >> 'web_client\;*\;athena\;*.keys.redis.sophia.m3047' txt +notcp | tail >> [...] >> ;; SERVER: 127.0.0.1#53(127.0.0.1) (TCP) >> >> # dig @127.0.0.1 >> 'web_client\;*\;athena\;*.keys.redis.sophia.m3047' txt +ignore | tail >> [...] >> ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) >> >> The "tell" is that on the footer SERVER line it reports the protocol. >> Note that in the first case it's TCP, even though +notcp was >> specified. (The MSG SIZE is also a clue.) >> > If you have a specific proposal for docs we would be happy to improve > the dig man page. First off, the parenthetical reflecting the protocol would appear to be relatively new (that's DiG 9.18.9). It's not in 9.12. So props for that. (That's what reminded me of why I was reflexively firing up tcpdump during testing and made me go looking. Unfortunately it's a little bit late to choose a different mnemonic than "ignore". Most concepts are more readily accessible if they are part of a mythology or story. I don't have a good story for what is being ignored, doesn't seem to me that if I expect UDP and don't get it because TCP=1 that I'm in any manner trying to "ignore" it. I note that there is no +udp option.) Are you aware that if +tcp is specified along with +ignore, then +ignore is ignored? This behavior is not dependent on the ordering of the options on the command line. The behavior of these two options is demonstrably not orthogonal (not sure how it could be, although maybe it should have been). What is the expected behavior of DiG when conflicting directives are given? Regarding the manpage specifically, once someone realizes there is no such thing as +udp, they're likely to fixate on +tcp / +notcp. > +ignore, +noignore > This option ignores [or does not ignore] truncation in > UDP responses instead of retrying with TCP. By default, TCP > retries are performed. This is relatively straightforward. Doesn't say that +tcp invalidates it, but I'm not sure that would add clarity. I suppose what's being "ignored" here is TC=1. Might as well say so: "...ignores that the intent of TC=1 in the DNS protocol is to force retry over TCP, which is what DiG will do under normal circumstances.". You could add "Do not use with +tcp, this applies strictly to the (default) UDP query mode." but that sacrifices brevity. To me, talking about the intent makes context the DNS protocol rather than making this about DiG. > +tcp, +notcp > This option indicates whether to use TCP when querying > name servers. The default behavior is to use UDP unless a > type any or ixfr=N query is requested, in which case the > default is TCP. AXFR queries always use TCP. I think this needs to be expanded to indicate that if you don't want TCP, use +ignore rather than +notcp: "To prevent retry over TCP when TC=1 is returned from a UDP query, use +ignore." Actually dig -h fares better, with even more brevity: > +[no]ignore (Don't revert to TCP for TC > responses.) Apologies in advance if I've generated more heat than light... -- Fred -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: parental-agents clause - IP address only ?
> On Dec 5, 2022, at 4:06 AM, Matthijs Mekking wrote: > > 'parental-agents' work the same as 'primaries'. It only supports addresses. > > Listing them as domain names would technically be possible to implement, but > it requires an authoritative server to act as an resolver. Adding resolver > code to the path of an authoritative server is like crossing the streams. It > adds security risks that are unnecessary for an authoritative server, so I'd > rather not add such functionality. > Thanks for the confirmation - and yes makes sense. Also thanks to Timothe in this thread for the script inspiration. I cooked my own up and tested it - works brilliant. I also added some logic to email me if there is a diff from the last run. Will be interesting to see how often there actually is. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: TIL: Restricting DiG to UDP only with +ignore
On 05. 12. 22 3:49, Fred Morris wrote: If the UDP query returns TC=1 DiG retries with TCP. I want to see the UDP results and am unable to. Specifying +notcp makes no difference. The correct option is +ignore: # dig @127.0.0.1 'web_client\;*\;athena\;*.keys.redis.sophia.m3047' txt +notcp | tail web_client\;*\;athena\;*.keys.redis.sophia.m3047. 30 IN TXT "web_client;194.55.186.216,404;athena;1670154435" web_client\;*\;athena\;*.keys.redis.sophia.m3047. 30 IN TXT "web_client;43.134.92.151,400;athena;1670132664" web_client\;*\;athena\;*.keys.redis.sophia.m3047. 30 IN TXT "web_client;35.162.155.28,200;athena;1670132664" web_client\;*\;athena\;*.keys.redis.sophia.m3047. 30 IN TXT "web_client;159.89.118.246,200;athena;1670132664" ;; Query time: 9 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (TCP) ;; WHEN: Sun Dec 04 18:42:19 PST 2022 ;; MSG SIZE rcvd: 7500 # dig @127.0.0.1 'web_client\;*\;athena\;*.keys.redis.sophia.m3047' txt +ignore | tail web_client\;*\;athena\;*.keys.redis.sophia.m3047. 30 IN TXT "web_client;80.94.92.40,200;athena;1670111034" web_client\;*\;athena\;*.keys.redis.sophia.m3047. 30 IN TXT "web_client;161.35.213.88,200;athena;1670154435" web_client\;*\;athena\;*.keys.redis.sophia.m3047. 30 IN TXT "web_client;103.10.62.92,404;athena;1670176114" web_client\;*\;athena\;*.keys.redis.sophia.m3047. 30 IN TXT "web_client;54.185.160.223,200;athena;1670154435" ;; Query time: 16 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Sun Dec 04 18:42:26 PST 2022 ;; MSG SIZE rcvd: 1193 The "tell" is that on the footer SERVER line it reports the protocol. Note that in the first case it's TCP, even though +notcp was specified. (The MSG SIZE is also a clue.) Searching the intertubes wasn't much help. When I tried to search the list archives I got a Gateway Timeout. :-( Anyway, it's been a minor personal annoyance for a while; hopefully this helps somebody else with a problem they didn't know they had. If you have a specific proposal for docs we would be happy to improve the dig man page. -- Petr Špaček -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: parental-agents clause - IP address only ?
On 04-Dec-22 21:34, vom513 wrote:
Hello all,
So I set up parental-agents lists for my zones, and actually got to see it work
(awesome !). bind detected the parent DS records and acted accordingly.
However, I currently have these lists configured using the IP (v4 only at the
moment) addresses of the parent NS’es. I tried inputting hostnames, and I got
errors (i.e. syntax) every time.
I would prefer to put these in as hostnames. While at a certain level in the
tree these don’t change very often, they can and do. I’d rather not have to
keep track of these in this manner.
So my question - am I just mangling the syntax - or does this clause really
only support IPs ? I was thinking if so - perhaps the reason is some chicken
vs. egg / security reason ? I.e. not trusting the name (which would have to be
itself resolved) ?
Thanks in advance for clue++
Let the computer do the work.
Assuming you have a TRUSTED resolver, a work-around for this sort of
issue is to replace the definition with a 'include'.
Run a cron job that queries your resolver & writes the resolved IP
address . You can template the include file. (Or the entire config, but
I get confused when the main .conf file is modified frequently.)
e.g. I use something like this in other cases. Season to taste. Don't
use 8.8.8.8...
include "myagents.conf"
|myagents.conf.template|
|parental-agents port 99 { %host.example.com% key secret ;
%host.example.net% key sesame; }||
||parental-agents port 96 { %host.example.edu% key password ; }||
||
||agent-update|
|#!/bin/bash
# Update IP addresses
IP4HOSTS="example.com example.edu"
IP6HOSTS="example.net"
TRUSTED="8.8.8.8"
CONF="myagents.conf"
trap "rm -f ${CONF}.tmp" EXIT
if ! cp -p "${CONF}.template" "${CONF}.tmp" ; then
exit 1
fi
function resolve () {
local HOST="$1" TYPE="$2" IP=""
if ! IP="$(dig +short "$HOST" "$TYPE" "@$TRUSTED")"; then
echo "Failed to resolve \"${HOST}\" \"$TYPE\"" >&2
exit 1
fi
if [ -z "$IP" ]; then
echo "Failed to resolve \"${HOST}\" \"$TYPE\"" >&2
exit 1
fi
sed -i "${CONF}.tmp" -e"s/%${HOST}%/${IP}/g"
}
for HOST in $IP4HOSTS; do
resolve "$HOST" "a"
done
for HOST in $IP6HOSTS; do
resolve "$HOST" ""
done
if ! mv "${CONF}.tmp" "${CONF}" ; then
exit
fi
exit 0
|
Timothe Litt
ACM Distinguished Engineer
--
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
OpenPGP_signature
Description: OpenPGP digital signature
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: parental-agents clause - IP address only ?
'parental-agents' work the same as 'primaries'. It only supports addresses. Listing them as domain names would technically be possible to implement, but it requires an authoritative server to act as an resolver. Adding resolver code to the path of an authoritative server is like crossing the streams. It adds security risks that are unnecessary for an authoritative server, so I'd rather not add such functionality. Best regards, Matthijs On 05-12-2022 03:34, vom513 wrote: Hello all, So I set up parental-agents lists for my zones, and actually got to see it work (awesome !). bind detected the parent DS records and acted accordingly. However, I currently have these lists configured using the IP (v4 only at the moment) addresses of the parent NS’es. I tried inputting hostnames, and I got errors (i.e. syntax) every time. I would prefer to put these in as hostnames. While at a certain level in the tree these don’t change very often, they can and do. I’d rather not have to keep track of these in this manner. So my question - am I just mangling the syntax - or does this clause really only support IPs ? I was thinking if so - perhaps the reason is some chicken vs. egg / security reason ? I.e. not trusting the name (which would have to be itself resolved) ? Thanks in advance for clue++ -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
