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: host your subdomain on your own ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, 13 Nov 2021, Reindl Harald wrote: Am 12.11.21 um 18:55 schrieb lejeczek via bind-users: On 12/11/2021 17:14, Reindl Harald wrote: wouldn't it be easier to setup two different subdomains in which case you don't need delegation at all - your local named would hist the internal subdomain and doing recursion for everything else i mean when it's private and not www why does the world need to know about the subdomain? Because I might not be able to control nor have input into local-private bind(s) and thus... clients/nodes on private networks would query www/public bind and only then would learn of 'priv.zone.top' and then, via that delegation to my own binds, 'priv.zone.top' would be served to local-private networks. - here is where 'views' come to mind, on my binds... don't get me wrong but when you a) control a local bind where b) a public resolver delegates a subzone you should also be able to control that clients in this network use your named via dhcp The problem arises, as soon as you have some clients *outside* of this local net (inside some other local net), which should also resolve the internal ips - this is, what I have, and why I use a public zone for my private addresses: Most hosts are within my lan behind my own dns server, but some are "outside", but reachable via vpn - but I do not want to route all dns traffic for those through vpn, neither do I want to deploy dns servers for each of those machines. regards, Erich -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmGPZj8ACgkQCu7JB1Xa e1rJdg/+P+7n1FXtDvqSS1upOYL4mAuHATSbaXnYM8bg8mrcpFOPkZ8bIIj4Srsy 89YzSR/xp9ySKp+OfzHe0LpwqAgVMhagcrQtUcc3WUIK5xHG9nYOgmZFuR5PSzWX kh+mDRLkCu81/MmVoKsCDrYrxHAv5gMHK82M0S6pt+bMLwOQl5xddYF9whCC9tvu HFx3Dd1ZGZdnr2cBH4oQ+od8fVeN0HW7Ve+XfupQbbj2vx9yZ8fT/BhidwycGOSw 9GvtQhnSr4vj1+UpWMGI+IkcIXjipWTAQ/e5Cy7ix4ai2w6NsDAdXdXpWy3Aym39 OVipulxjsMtAKY+/RfAF7MTAUtPRSWmbyiXIjc+PQ066M8pNpEgDbbJQDD9WcNMi wHAFmSSLOECqaHw7UFxGMZArW2pu+vdBmIEGxEzPGgFIkfQSaRfnEgNSDEd3pFoc HN+ieTTYwJLwvluUc9X7Wj3XzOihnQarZKQf/QDpGh9BQO+jdR2HD1xPtobbWSWw c8tmMcqWr3Xsxu51j+YmnuLtXoEd8UCINXMAZl7/t3JE+xz6huBBe8niATrO7f2f mgEZWILyMVfNN6pATYRDqDndkRUT3v9AlpGtHGrGAtCdD7gghMQlzaDN95Q7ZBk1 ybIZFyN6/IPCU5IOXFtPCeRpkjTj2zfavJk+wFlqFwpf/54O56I= =MkWj -END PGP SIGNATURE- ___ Please 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: BIND 9.16.17-snapshot - testers needed - recursive performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I switched to the 9.16.17 release candidate yesterday and so far, it runs well on my 6 very-low traffic dns servers (one of which is also authoritative). Only thing, I noticed, is, that it uses more memory than 9.16.16 on the weakest of my servers (a 32-bit machine running archlinux32): ~14.8% -> ~20.4% (of 256MB total memory) But this could also be due to different load - there is no real long-time monitor set up for this, and I simply took some values right before the change and have been monitoring the memory consumption since then. I cannot really tell, whether the memory consumption is higher on the other machines, as those circle around or below 1% and there's too much noise down there :-D (but "10MB more ram needed" could well be possible, as these other machines all have >=2GB ram). regards, Erich On Tue, 25 May 2021, Ondřej Surý wrote: Hi, we merged a change that substantially reduces a contention between threads and improves the recursive performance in 9.16 branch quite significantly. After the change, the 9.16 branch performance will surpass 9.11 performance in both scenarios - authoritative (already the case, from the very beginning) and recursive (since a version to be released in June). Although, we are quite confident that the new code is correct, we would appreciate if people running different work loads than ours to test the snapshot tarball available from here: https://users.isc.org/~ondrej/bind-9.16.17-pre.tar.xz We would like to hear both success (it’s ok here in the mailing list) and failure stories (please create GitLab issues). Thanks, Ondrej -- Ondřej Surý (He/Him) ond...@isc.org ___ Please 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 -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmCvkfcACgkQCu7JB1Xa e1oQ7A/9HLKlZYHrnnNUyirda9rN2dn1sAooGm3EPESNSK264afB09lUHtUPrxZZ RXVKET5pKmyVyxuidm4pyytxG7UbBcw+pR7eW6aBQ84a6P7sEbTm4qQYEbBXkCHx 4VZn5d3rzaFnOdUHiFpSFR2rkD8Xty2X0fR/usYSrA3Qhe+Iu9HEeFzezQnevTYK AiXxFYghiHcTnSVM/tjL16f8iOs7u+QNM/jHncouM2x0AFJ5N3bBvz8SsTVlM8lr A1jxxh37N5/HT/d2vTz6PW4J18A7IaXbc323HUwvYJ/+vxY1s0u3CKhLO2+sctnX PkIIXD3G7jStCP2+HZgLnw3KPGDEU+Nxi79jirZxRI2NFB8wlon69LUd17W+Om3g 0OsHMIsRLblcmyBTdWoa35peeRchS9ktaWPh3TdoDwEBuU3QiYgjJTWFbxJ0lfhI KlFx0TLU6ZgI3vaF4av/7FMvoFn+ouOtha2gu62B13qGgHXVAS1XnVSM2XONmsLJ PaOTAPGpV9+SoC5ENNnyeRtP6wVlclogOO/RSwlNY357feqPSCOlPfuCJp1i9JCJ +G+Xe2dRVeRhJRv7qnUvM8nubV9rpIHYrNJX871Qv7MbFU+U21Zbs/ejptrlXvVO V2S32/TTq2n07Jt05qmmp624gYytGyl+hRj6Jya1iaITfmsbwVs= =HK4f -END PGP SIGNATURE-___ Please 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: BIND 9.16.17-snapshot - testers needed - recursive performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 25 May 2021, Ondřej Surý wrote: Hi, Hi Ondrej, we merged a change that substantially reduces a contention between threads and improves the recursive performance in 9.16 branch quite significantly. After the change, the 9.16 branch performance will surpass 9.11 performance in both scenarios - authoritative (already the case, from the very beginning) and recursive (since a version to be released in June). Although, we are quite confident that the new code is correct, we would appreciate if people running different work loads than ours to test the snapshot tarball available from here: https://users.isc.org/~ondrej/bind-9.16.17-pre.tar.xz I tried to pull the tarball from this url, but only got some gitlab page (which firefox refused to show, but insisted to download). Is this my error or did you accidentally push the wrong content? We would like to hear both success (it’s ok here in the mailing list) and failure stories (please create GitLab issues). Thanks, Ondrej regards, Erich -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmCtDVkACgkQCu7JB1Xa e1orPA/+NjQN6Z7zhz2aI/XQkf7eK0s810hpuXN5zJiQG7OJwogr+SLOrW6VKLa/ UrfqXIoDU36kNKHQTWTjlOxi2Eh2l/c5W5qWv2I0ZQdLe4pU//5+i+Bxdv8o925r d3nATQeYdi4sz8LZtzI0GTbyIRVCF7rQki1F5PGnk3XteT5zuZYNxTbkqv8/m+Lg VX/bc5KmY5SVZBge4aNk+rI03v1+KMT5zVwVhlgTS3dpgCI7qhtWKyMN686nMfcN 0v/7mRa9qFHklBh7FTLpY5N/vW89NM40IYjehyoXc3QA/IzU7SqKbSPuJjB5tMkK ct4UMX+P7ISAPu82w2vf/86UYdO/GiHWGeisG4322rdydDVh5vaa5jn/a6YVTl5h SdfbqDTevG2n+/T3FOT1/hf4Ryb8WaG2gH4iqHiNeuiM1VNeR40cQZIe0euBVv4H MomQHFQBHzHjP8HIFTkKs3XVX+LtsAIq5AvhXcYkGozPNLz0/+W/8LniV+jFgKzX oR8sRlzNTFwmNHDhRd0AAZyw84ZvAam424DcNYuR1bP5nPXBGY0S1tktfQ7wJD4D 1oWyuu9bKz5wEHIx9GpenAoRfc0feL6LjwnRYc4q0t/hkfbEgOz/jpOEI1UVWfLq O1yJPhSvoR8gW2PMMrNSxGqUtlJ7pbQPvRFPyC7sejBboAfjRQ0= =GN6u -END PGP SIGNATURE-___ Please 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
AXFR rejected
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
I upgraded from bind 9.16.11 to 9.16.12 (on arch linux) and suddenly, AXFR
transfers were denied:
19-Feb-2021 13:56:01.276 client @0x7f37c8015028 127.0.0.1#57139: TCP request
19-Feb-2021 13:56:01.276 client @0x7f37c8015028 127.0.0.1#57139: using view
'_default'
19-Feb-2021 13:56:01.276 client @0x7f37c8015028 127.0.0.1#57139: request is not
signed
19-Feb-2021 13:56:01.276 client @0x7f37c8015028 127.0.0.1#57139: recursion
available
19-Feb-2021 13:56:01.276 client @0x7f37c8015028 127.0.0.1#57139
(ddns.eckner.net): AXFR request
19-Feb-2021 13:56:01.276 client @0x7f37c8015028 127.0.0.1#57139
(ddns.eckner.net): zone transfer setup failed
19-Feb-2021 13:56:01.276 client @0x7f37c8015028 127.0.0.1#57139
(ddns.eckner.net): reset client
19-Feb-2021 13:56:01.276 client @0x7f37c8015028 127.0.0.1#57139: freeing client
Relevant part of the config (I can post more/full config, if desired):
/etc/named.conf:
options {
...
allow-recursion { any; };
allow-transfer { none; };
...
}
...
zone "ddns.eckner.net" IN {
type master;
allow-transfer { 127.0.0.1; ...; };
}
I cannot find any relevant change in the changelog at
https://ftp.isc.org/isc/bind9/cur/9.16/CHANGES - did I miss something or
is this a bug?
(Adding 127.0.0.1 to allow-transfer in options clause did not help.)
regards,
Erich
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmAvuBYACgkQCu7JB1Xa
e1q+QQ//Z3UDNyeppdz1+FeWa/+0OSDze96dG6ZAFSO34/+oxb1xCqt+3wGGgazt
BXsfJJkF+z41BWUI3AwEysgz9y1G1enqd0wy37xi+RwdwSRbzwuyaGusHZ4hVeUK
uccJVQE9krwNLsmPu1Cb6AK8qOCC5sYa4cfR4zzlj0wFq7H9ju9AsuUI2nb+bs2H
dsueA2RclvLR3hHMmEhjCIIrGcbzCdWoBFCs7dBEmtHW9RbsmfyouMOuF259Oe1E
u5dp3B4xCx5KexCJK4Wk30Nn4slsX4/GLeUDMcRqEI141WkR8DydG2v+nM4qR+7J
m0R9Rjht5eaqWwW1SUGVbvB13azl0d0rMbSMc9zdRwfwBxvg4Cx1LIH9CgpxKpF9
tE4F26gsMe6esgiLcj6Lq7lkDevB+auvwt0Q5plthJFrRqNUiqixcqZltz9uQrla
yN96E5w+1mqxPNdUMZIHecvRpVWftO73MWaz8SNgGOcv1ExgrSbkfRCRor8GWrq0
hDAV8iDCZax9gVRgXt9AokxpbKLH4pRcbpiN5JnBDIVmhM1V431LOVRzqT4wDbrM
ncYIaatf4Adc1jNKKbJ+RQgsKFEJa7GdqT4yD9UYC72mZqWh18cK2UXZYlkmDndq
WPIt2t5IIeiCMH16rYm3XA+fdtAsqp9fiitAJXeMBnUz/chBRvI=
=wgll
-END PGP SIGNATURE-
___
Please 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
rpz depending on query type
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I'm running bind as a recursive dns server. I wonder, if it's possible to modify responses via rpz for some query type only - e.g.: I want to return NODATA for "example.com ", but the real answer for "example.com A" (and all other record types). Currently, I do this, by adding a rpz rule "example.com A 1.2.3.4". But obviously, I'm relying on a) example.com's address not changing and b) me knowing every possible record type, that might be queried for example.com btw: I do *not* want to disable responses. The only way, I can currently think of, is to redirect all queries for example.com via CNAME to a custom server (or just a view), that has disabled. regards, Erich -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl/0lMIACgkQCu7JB1Xa e1qGkQ/9E0j0MTq4Z8KDO//IIz7dd0iOnYTpSh91iAsU2DI1U3ZDkOkTeCNaxdkP 4DUoYj6xcNxQJWnMPRxKKmglaptP2Kkr0V5bzvyMqct12pyngv3o7xqabeqad640 ffVdhWYaX1y5eq2QiFQRY9jY9cQALeF5nGz9X1XZwfANhj0gsyBr9BEMPjNQRkIP 5Vhw/rbQWnfuA52/fVhLYfP3RPjdgcsUp/yeW2jodI7/o/1TLgR0IfGhM0ay7bxN 5vKsDd5R2XuPTXTpTmSX3UmtBav0dl1x++XxApb+TMyN5z84a6b0oqBxY7/hBsgX iIRhKJjF8WJn5jpHg6PEjxO8GsL4uEZAmeVN074xMpkB9KRSOgwdjySUYu7D6uDI LWrhz924gsWmfybktMY8LQNErcnxx07DevEsUKTxrdAjR2eFqsnACvDPSoYj9OHH wvzTxPGldmxRNTwPCqz5RrZAYK4p7NBIORzFo/fHDArnZL13DRp5XZjNz6pE34fl OAIuX0vgwuDb5r6108rzEPB+qvLd+0WG3GXLy/WHX5Lh+SaLnw0NUiCxzarT4/jJ L+x/x48pfgU7aAAs0OcjdH9ox6dEH/uX14vuH+6ZjDzKwSMB2rzjD2H/dUQZ7qY8 pFUhdclDxFNn0HXzjTRCIz6tnQi4Ke+N3Lo6R5Q1azNbmgtWm04= =Xyu+ -END PGP SIGNATURE- ___ Please 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: Steps to reload zone files automatically?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 1 Jul 2020, Harshith Mulky wrote: Hello Hi, Is there an automatic way we could use reloading the zone files rather than using rndc reload or named restart? Shouldn't the design be, that: Whoever changes the zone file, runs "rndc reload" afterwards? Any methods or links which can be shared to help us reload the zone files automatically once we make changes to the zone files ( cron methods or shell scripts) If you really want to go that path (see suggestion above), have a look at inotifywait from inotifytools (I'm not sure, how the package is called in suse): https://linux.die.net/man/1/inotifywait We are running bind with version as below # rpm -qi bind Name : bind Version : 9.9.5P1 Release : 2.2.2 Architecture: x86_64 Install Date: Tue Oct 17 16:46:22 2017 Group : Productivity/Networking/DNS/Servers Size : 747523 License : ISC Signature : RSA/SHA256, Tue Oct 7 04:18:01 2014, Key ID b88b2fd43dbdc284 Source RPM : bind-9.9.5P1-2.2.2.src.rpm Build Date : Tue Oct 7 04:17:04 2014 Build Host : cloud124 Relocations : (not relocatable) Packager : http://bugs.opensuse.org Vendor : openSUSE URL : http://isc.org/sw/bind/ Summary : Domain Name System (DNS) Server (named) Description : Berkeley Internet Name Domain (BIND) is an implementation of the Domain Name System (DNS) protocols and provides an openly redistributable reference implementation of the major components of the Domain Name System. This package includes the components to operate a DNS server. Distribution: openSUSE 13.2 sataradnsVM1:~ # regards, Erich -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl78OW8ACgkQCu7JB1Xa e1poQRAAuGVb4Nr+qv82wtzIGkgXElOY8fW+kWf0p8UbZAiQZvVK25RlSytbmO2e A5Ie7ttJbMDM3qwSJfN69eDj3h8ctL6pVtsazIMUJpT8jGKvncHbm5xLyJUgCWt0 /GaO9gvwthbkmkfA5TyWPAk8SdeHDFS03RsbHcONs2MWwmUYWBeooX3N48DwX6r+ DlNJVIyAi3H2ApT2V/BZ+XTqE5wW9IPZbUqB9wwzzIib+pRq3EOoBpLnXMMZsI96 IJu/7mpTaV8XtY6K8Q+LeAdg86PrXlwg3sgd4ss0b9VkwvH3dELqMPn4I6DwfFkM 4H1AZU413udKx0R4a9CEZfBPHOo0IHAEZsAV3A0gi8/HUU4pUZVhHXza0I5imgHc rXyl/g6dXhPx/pYIWZmLACYkyNQoJNZEvek9dLn9+ywy2C/jr4H7ivIC1q3I2og5 IaKNHSv6l9VqHK03fCjpm+xxSY5U758N1oReS7khJnBWPGNUh5jLYnC/NXUgEz5a 4hx7K/Syg+WXfAH3TZPx+RCbARNcP7dz3sbpRWu7J6eL4Zhxmht2RcsMtSB2Ckpv dgZ4/5zD3e0Fi0xDyvnfEoNMp8ihBYUrsvL7vUJXv7ek/VMG6QHJSKxk0U94/io6 xQZXizzvgeHWnYsaWhnR/NkVyyk23R3v+czHf+In5/iOeNU/S/c= =uZm6 -END PGP SIGNATURE-___ Please 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: DoH plugin for BIND
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I assume, the (on-topic) discussion so far was about the serving part of bind. (Correct me, if I'm wrong) Will there be client-side DoT/DoH support in bind, too? E.g. will my recursive (or forwarding) resolver be able to resolve upstream dns via those? I don't see, how I could use a reverse proxy or stunnel to achieve this, currently (assuming, the authoritative dns server supports DoT and/or DoH, of course), because I would need one stunnel per upstream dns server which I do not know in advance - right? regards, Erich On Sat, 2 May 2020, John Levine wrote: In article you write: On Sat, 2 May 2020, Michael De Roover wrote: Even if your ISP allows it, chances are that other mail servers will reject it ... My residential-class static IP mail server has never had problems delivering mail. I've checked it many times over the years on many blacklist checkers and never had anything but green lights. Your ISP is quite unusual. Count your blessings. The large cable providers in the US and Canada block outgoing port 25 on residential networks. To whoever said that MUAs still default to port 25 submission, you must use different MUAs from the rest of us. All the ones I use default to 587 and 465. R's, John PS: What deoes this have to do with BIND? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl6tusEACgkQCu7JB1Xa e1pbzw//UuwXI4N3++MssIej6JUnC5BkoQnAfQv3ZyLJRDsQywKsP3Q1nZ/aTDlZ TfbZ7HHSceQXRtlpGJyLflXNt1tnTOWwXV/KmT1Cgk7z2s8lRAP8OZm7qEO7rN1f c4KIVJwbbIpThcCm8HgWrfKgk56wjqRpu9iv9gS713dtcbL/zcSOMRLLdWBsFnFz uJaRBA8fOpZmrjp5Mmei25XOzrJ+zwJsJUxmYcefzsa5A1f709wls20T5TN2It+W bM+fJJ1DboWB8xiIyY26+xkwD3zqI8l8v284n6Da9c3PyZkyTdivxI3nsZbpqal/ dzw4f0vKPGfd9wKl8VJx00i+awtDaay+cgEvd3g/qTPC894Ygs+MfiONQ/gGiaQu E+ztbUulEv/ZidOBhJVakfNY5GVOjaNvreZmRWqudaTNAmNwSVuYgxnf+5eTXiy3 VJoW+edhNw5b6YQvyQEKZCNx8eTimd5SQZ9poEqum9Enldb9+QopwmbWsneK+pMH ydMgCrdcnYPliXwf86PzLZ+YYaWplq1xcwOA9JrdzltENRFiQCSqlK4uwt1zo0X8 MNvtAlkjxxx0NOV/54OdKnjk7Wm3TxTAHFKA9bNtsgn25iZ+BL/+ENKSbZIPVXXk u7n5yAVBtQciCxcmGSpOua+EmbLjFbZY5Xp5AEWWoWYIvDNLWOw= =EENM -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: AW: Debian/Ubuntu: Why was the service renamed from bind9 to named?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 15 Apr 2020, Klaus Darilion wrote: -Ursprüngliche Nachricht- Von: bind-users Im Auftrag von Reindl Harald Gesendet: Mittwoch, 15. April 2020 09:05 An: bind-users@lists.isc.org Betreff: Re: Debian/Ubuntu: Why was the service renamed from bind9 to named? Am 15.04.20 um 08:56 schrieb Reindl Harald: Am 15.04.20 um 08:51 schrieb Klaus Darilion: Hello! What is the rationale of: bind9 (1:9.13.6-1) experimental; urgency=medium ... * Rename the init scripts to named to match the name of the daemon Since years, Debian and Ubuntu User, and plenty of scripts and automation software (Puppet ...), know that the service is called "bind9". I think it is very confusing and will cause lots of headaches once Ubuntu 18.04 or Debian 11 is released. So I really do not understand this renaming. The software is "Bind 9". The package is "bind9". The service for long time was "bind9". The config is in /etc/bind. Only the binary is named. So it would have made more sense to rename the binary. (actually the binary is not so important for end users: they install the package and manage the service and usually do not have to worry about the name of the binary). It would be great if you undo this change before release of 18.04 you confuse the upstream project with your distribution bind9 was completly wrong in the debian world as well as apache2 for httpd, on sane distributions it's "httpt" and "named" all the years beause it's nonsense to throw vesions in service names BTW in case Debian/Ubuntu when they do RTFM it wouldn't be an issue at all [root@srv-rhsoft:~]$ systemctl status sddm ● sddm.service - Simple Desktop Display Manager Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/display-manager.service.d [root@srv-rhsoft:~]$ systemctl status display-manager.service ● sddm.service - Simple Desktop Display Manager Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/display-manager.service.d └─security.conf, start-before.conf [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/sddm.service [Unit] Description=Simple Desktop Display Manager Conflicts=getty@tty1.service After=getty@tty1.service systemd-logind.service [Service] ExecStart=/usr/bin/sddm Restart=always EnvironmentFile=-/etc/sysconfig/sddm [Install] Alias=display-manager.service Can you please describe what you want to point out? I can not follow you. You can set aliases in the service file and call the service whatever you like (multiple names possible, too). I admit, this has nothing to do with the package name. Though: you should complain to debian/ubuntu/..., not upstream (=here) about package name changes. Regarding version numbers: In the world, where I come from (arch linux), version numbers are only appended for *legacy* packages - e.g. "bind9" would be valid, if there is a "bind" package, that has a higher version than 9. Btw.: bind is packaged as "bind" for years on arch linux. regards, Erich Klaus ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl6WtScACgkQCu7JB1Xa e1oenBAAloNKuOGmXxJsf8qLa3MxagpaCQNwSvf5IrfbMXfRELMEJ/phXujI+Aim KAbmTyklYLF/esuUzl9ttj02OBlyx7+blDOQtHmkC8kgtyBzWXI99Nk6pWGAS4hs cxIMsNHqgIcH22Tv254eWaJjV/rxeB5xVrK4TbZn2JD7Mz/6GOrPgNDsEa4SoCER q+q/8bUauH8JryvHBidOQ3at06XGkl/CEOZz2VcWohE+/K32giJmNK2XTJAoIMQ6 s49sgp9pWjv+fP9pbbniS2HTHlYn4rhyGJk3LlRfbyN9iYRSfOB52/xog/egl8Ur lfi8BDotghbmm19it9f0chtNPyob/FytrcMt1iQxfvkFDHPfaRmh/cCkT7elsPHa s8ypNodJULyocKIrkwsabV4+rFau05SZVRNoIMAOdwSTvRUJfbmDY5dgjJl0QDOy 5WvAfEVXJ3Q/rZEqtsXowlOGLLyA+tRyb1wTsH7b4vBdzZhXt3mLdo3yTz+UDQnv mcWPC5LoW94M9KAF2t9C1yS90/8IPY2B8lKsJ+XoWAdMKm8oWstvAh+tGvccGiuT ITkPv14ht+Ev8X+f5gD2WyXQI1H3Udm8NFXMYj32XPh4GpqRXvcobpNY7ezWXm/j yQWzI3FxGdelPE3fH/k49KELhj7mdiBeacmmyZSEzW/C1FynQec= =5NW9 -END PGP SIGNATURE-___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind as "reverse-proxy"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 26 Feb 2020, Matus UHLAR - fantomas wrote: On 26.02.20 15:28, Erich Eckner wrote: is it possible to set up a zone in bind similar to a http(s) reverse proxy: No. DNS is very far from proxying. 1. The server appears authoritative to clients (the consulted server is indeed authoritative). 2. Each request is passed on to the other server (or served from cache), but the information is *not* obtained by zone transfers (because the other server does not have/allow this). For records that are managed locally, BIND is authoritative. For records that are stored elsewhere, BIND is NOT authoritative. So, either you have authoritative server, or you have not. What is the point of your request? The point is, that I have two authoritative dns servers running on the same machine which I would like to "merge". The problem there is, that one of them runs some special software, which does not "speak too much dns" (it is not broken as far as I can tell, but it is also not that versatily configurable as bind is). A is a normal bind installation and B is the "custom made" dns server. Unfortunately, B does not allow zone transfers and (though it allows forwarding queries for "foreign" domains to a separate name server (A) in principle) it does not forward AXFR/IXFR which breaks slave duplication of A's master zone. So I cannot place B in front (which I would like to avoid anyways, as bind is waaayyy more mature than B). So my question was, whether I could place A in front of B - which currently works, besides that my server now looks non-authoritative to clients. But maybe my whole train of thought is backwards: The problem, I'm currently experiencing, is, that the nameserver setup for B's subdomain (i.eckner.net) looks all-right when querying A (or the nameserver of the parent domain) directly, but not, if I traverse from the root zone. Maybe I missed to set up some cross-reference and A not appearing authoritative is not a problem for the name resolution? @Tony: dnsdist looks interesting. At first glance, it looks, like it can do what I need: send queries to different servers depending on the queried domain. I'll take a closer look at it. regards, Erich -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "Where do you want to go to die?" [Microsoft] ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl5WpTEACgkQCu7JB1Xa e1qOSxAAqoAQeCkPrqXGVlgvcQA7WfFVfmQTaVLk8p7qVz5JwoK+UCZzUINIDlhP Og/Ca13lPG9+G2RamLDk9OKSZW+UBIb/AipHTndGz8EHjHOWbmHYP90aeJZ4nJzZ c4gweD9/kCOXTrWkzTkpGChxPSb+CiiiVW2TW4DKwGTniEMJ0yhX+35vobaP17eI 1A4Sg/asZsNS287K3WUxGR/R69u6SQTtcL07zgtYx0n45bCd80OCedwhdKTvSTBr PmpRxPdY4ePy6/6dtq1aGI9eb7OrAAhHw5ign3SWj12xDLJUZQDxewpdK3gqdGFc 5Cv78xHTJ1SiZSYAugGWbRSuEdTFVCCKAIqk/310Y3HeBBKd8JCc2l9jcC0VhHDe GsRv8XMC4oEVt3aFIe3HFACnkBAc8sp7+CLXHzsbPa+fZIQPse9hiEjXpTz3iaVu GmJb0dMQ3zO3oI+ziC2qc3zEpmhTD10EiF7FTbWkt3yxt9Q7/rlOff3banokKRpo /qmO34agDTf9Ao3q9LdtDkPff5jiqdKNcYDXneQnXuyHH9MEKbIm+F418R/MUFK3 z+OSuXPOhNeKfxOKwFIpzic3KM13Odaxsep4c7KNQBeKp2566iAVbPszVkpumZd5 HX89VK//kKYWrImc1smvBZkohKtu0v96QFJ+YACk1oozjzN0OSM= =20jI -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
bind as "reverse-proxy"
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
is it possible to set up a zone in bind similar to a http(s) reverse
proxy:
1. The server appears authoritative to clients (the consulted server is
indeed authoritative).
2. Each request is passed on to the other server (or served from cache),
but the information is *not* obtained by zone transfers (because the other
server does not have/allow this).
So far, I had used a forward zone (to assure condition 2), but it violates
condition 1:
directly queried:
# dig @127.0.0.1 -p 5353 ns.i.eckner.net
; <<>> DiG 9.16.0 <<>> @127.0.0.1 -p 5353 ns.i.eckner.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61359
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;ns.i.eckner.net. IN A
;; ANSWER SECTION:
ns.i.eckner.net.3600IN A 193.30.121.109
;; Query time: 0 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Wed Feb 26 15:09:45 CET 2020
;; MSG SIZE rcvd: 49
querying the "reverse-proxy":
# dig @127.0.0.1 -p 53 ns.i.eckner.net
; <<>> DiG 9.16.0 <<>> @127.0.0.1 -p 53 ns.i.eckner.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30724
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: de8d1f39eca0150901005e567c38203e4e1025c43f9d (good)
;; QUESTION SECTION:
;ns.i.eckner.net. IN A
;; ANSWER SECTION:
ns.i.eckner.net.3600IN A 193.30.121.109
;; Query time: 6 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Feb 26 15:10:00 CET 2020
;; MSG SIZE rcvd: 88
This is the relevant part of my config (so far):
zone "i.eckner.net" IN {
type forward;
forwarders {
127.0.0.1 port 5353;
};
forward only;
};
Is it possible to fake/force the authoritative-bit in the answer for
queries below "i.eckner.net"?
regards,
Erich
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl5WgIEACgkQCu7JB1Xa
e1oOlg/+Or2ffpo0YM3po5zv3VZK0q+AAOBqG5MKVvsnJPhoyfZmwmAd0B3ri3j3
105cJP0Y2sKLEWmHgUms28yws7VyTljFik8hJfncOlb3PUS4LTJeI00YjqWTgvKN
i7WgaD/l+DnJD1Hp8PRa1ddHoDqDDqVs2mZcTzr5pVmx1xb9kgsvzu6N+qph+Joj
4zhVZc3hhyTA9RpMcQbX2+uHY67j+p3q4rwHCZkCCs6JF5Y1S/BZSyne+OEOjUUz
giZNHl5Bjld6mAwUNneVFBF6VmbrTAt1W0IKpNwlDcSTX58wDEWZLY4vR1DNDFh3
BTWLqM0rM4yc9VRHdf2gkKCMFKcOtKne0/T+Pi9j2QSBRKrnvg2wwHfCfT4+0zb0
YTiiJV2gsaChXiIf7CIpNa7Uvx0bngOt8xgsY3CrRVyEY6KqnFCSXtcAIQtuoTv4
JMJoBeZLOkWM21AE5W4v4u5xJ4e88ji5T6t+s2G7lHgpjpxdl8fLMdqEGv7JThTR
vd0mlWHztl/0XfjAtEG0uCWCzYkX2F5n/PVAj+a+IiKNB70h7gFyQ9Cz/Z2tUjwG
B+2Gx4W4tev6oTej9ELyMY/6UOlxgw2yh7kKW5/BR9nYTwDgySmXzDb9uOf3N5/i
6EgceIWHDzPd6Z2PnIeCEcmR3IYIXIJSbbT6wKzv0+BGuN1dUF8=
=A0Mn
-END PGP SIGNATURE-
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: .onion and dnssec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 12 Nov 2019, Tony Finch wrote: Erich Eckner wrote: I have also a hard time, generating some useful debug output - setting `-d 9` does not give additional information in the system log. You might find it is being written to the file named.run in named's working directory (this is the default_debug logging channel configuration). I generally use `rndc trace 11` to tell named to log details of resolution and validation, including sent and received DNS mesaages. It's very verbose but it can tell you what is happening to your .onion queries. Thanks! I now get the desired log. I noticed, that there were *no* queries sent by the dns server at all (even when asking for subdomains of onion.eckner.net - which were successfully resolved by tor). I suspected, that the slave "." zone superseeds every other zone I have, and confirmed that by commenting out the other (slaved opennic) tlds which did *not* break the resolving. I replaced "." by a hint zone and now it works as intended: - - opennic tlds are resolved via their slave zones (before, they were not: I could comment them out and still resolve) - - normal tlds are resolved via hint root zone (I think) - - onion. is forwarded to tor thanks a lot! I have another (minor) question, though: To my understanding, the difference between "forward first;" and "forward only;" is, that the former caches and the latter forwards all queries. However, I see the same behaviour in the log for both. Where is my mistake? cheers, Erich -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl3KsgIACgkQCu7JB1Xa e1o+rg/8Cdvrih+r9bYtwGSu12GTQtzVrSJY8Xtmjcoh4O4QJPZ/CRCEP/q3ok2Z mgDVoVp+whJRnVZJIPHJKx+Iq8PJ5Gp9RTH26gWpZ4jMxpilTnSLC9SVY5CSsMeY CFZ6A5QEGg5I2fzZKVUa6CbKW/3AjqrcbOASoORarWEdZRIv9U/CwfS8D0o2zywW rH4CEqVswx0SWwFtBLkY5+C/90AkEOB40W1RJymHMJK3+r+AQdnj/p3BXHwA2VbD 8R4tK3VoTWd4exuXet8JCvGHM7uJZVBfkChGy+uCBiY9oY0CHLGnc1dEp0E4QcVX 6V58YHehPgYJ4S1OQVJzk4F2I3PD4Bp47pKCxOhTwhRt9VnlYCK3XGD0sOSbccJa KxloL3D8RLSE7l/kQk7mcnH2cdSZVCuJUPYraK38zBumwh6uFGKHiRyhYWhsBZEU ODdDn1hPsPfe/X/cEdBMpt/zv2J7HMrm15MBYDCxw3obnmPlsibc4ztlf71yyflN lJJvvkJgDmT+jpjazVWs/1NJd7vvTp6QrsQwPnGjQNTxmh+FDvTP6BT9qWjQxcd8 bFgqdziI7gFH26FwfzKpC9TkZFxga4Bg5PI5F2M1k0sAEe7ykwsOvukQVNZL9VYO CD/s5qpvrmAEuI5oO49oYiY4+7tfxOrxyY0CumRoWObpmq+zRJc= =9vdi -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: .onion and dnssec
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Tony,
On Mon, 11 Nov 2019, Tony Finch wrote:
Erich Eckner wrote:
However, I encounter the issue here:
https://lists.isc.org/mailman/htdig/bind-users/2011-November/085536.html
If you are running 9.14 (or newer) you can use the validate-except
configuration option. In older versions you can use `rndc nta` but
that is very inconvenient if you need a long-term exception.
I'm running 9.14.7 and tried both, but while it does not give any errors,
the lookup still fails (`rndc nta onion` is logged successfully, so it
seems to do the right thing). I have also a hard time, generating some
useful debug output - setting `-d 9` does not give additional information
in the system log. And running named manually with -d 9 prints nothing to
stdout (though, it seems, it generates a log file, then)
Digging a little through my configuration, I noticed, that "." is actually
a slave zone:
zone "." in {
type slave;
file "/etc/opennic/slave/tld-root";
notify no;
masters {
45.56.115.189; # ns0.opennic.glue
45.56.116.224; # ns0.opennic.glue
2001:470:1f0e:8a0::2; # ns0.opennic.glue
2600:3c02::f03c:91ff:fe33:e1ba; # ns0.opennic.glue
};
};
Might this be an issue? (I notice, that the lookup succeeds when I comment
out the root zone.)
Cheers,
Erich
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl3Jr+EACgkQCu7JB1Xa
e1oB3w//XDc4qamyWEgKc/kEDwcmE0EKCYZnA7uP5D/yQjm0wHLUbz+mOccB7x22
S+G4FE320B5E7r3mHBNAS441G/9tRdAhH69DlTQUsUyyE5g0ETP/8lyoPcZdJLwJ
Uip/ibaff71AE+HURre8xOIG0yTvPyA1rOJ7viGS99TSPLLC35QhAU5niPw6KhPt
398ApmJab3cTLtO+Vg+aRZLhMmPxNdbeJCIF7pKsHqFMOde2P+Ru5bvnGIxf6Fmi
WPpHY+EG26A7cD0XfQKvskjgAlcgLW2SinLV6NwScjH60fxIhzWgKe2QH9+Z5GDi
NKH8MeGPCDs9KHI5cn4lBJ6eCFSbXVmWa9J+MBcbOB7OdHBuBLm1Vbvu6py65djz
hlfSZ4HXgCHTUjipSGkLIvcG2tcVwyiRA8k6vBTrNjY6orFW1E52MaRvtml0aM16
xmOwfhlSuFPZ2X/l8m8hR5/Sz6aEyBGBl6tK56ESmvgYoOhiAVke7PGGBnArP8N2
BpeZQn5DTXg0tAtr4mjEetTeb2LJUa29cnWYdkheN3+2kK4eloSfAEynDfgpzfVu
zbZpayZIXzQf8F2XmtEOgEyTWJiKa+lvwJHrqelGpqFsMinPSJfqYeKMguEG32p5
w8N+QBDI1jlmjqhiYn0A9ww4AgtDBspDD6CYIgX1YA2Bu3kv2Q8=
=64oN
-END PGP SIGNATURE-
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
.onion and dnssec
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
I'm running a recursive bind (root hint, several master zones for opennic
tlds) and would like to extend it by resolving .onion addresses through my
tor node.
Naively, I tried to add this to my config file:
zone "onion" IN {
type forward;
forward only;
forwarders {
192.168.0.3 port 9053;
192.168.1.3 port 9053;
};
};
However, I encounter the issue here:
https://lists.isc.org/mailman/htdig/bind-users/2011-November/085536.html
I confirmed that by putting the domain (like suggested in the answers)
below a self-controlled domain without DNSSEC (e.g. "onion.eckner.net"),
which made things work.
However, this feels really clumsy for .onion addresses: you have to edit
the url in the address bar and - even worse - you leak the used domain to
the hidden service (in case of http(s), at least) ...
Configuring .onion as master/slave is also not an option, because tor does
not offer zone transfers (for privacy reasons, probably) and because the
ip addresses are auto-generated on request.
Is there any possibility to get this running without stripping DNSSEC from
the clients (e.g. without setting up another nameserver infront which does
not do DNSSEC)? Can I somehow (locally) resign the root zone with my own
keys but still check the signature on all but .onion tlds?
Any other ideas?
regards,
Erich
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl3JekoACgkQCu7JB1Xa
e1pSsA//dJKqnjvzCZRzL3kFtkYabd8g8OYTB7aZdjzuGRxIR9Wn40RxbkavaN1I
Xtm9MI3D352ZW9ibxW/djJrhXZht0qxCKQqewpi9ucSzbjHcDMCljccLOD5EOA1C
o3t5Lk4KGQeHWAhulD9WrDzEa3ZjvCcStZc3h5An/PaXUHxLEd227bK6qm0ooS9L
IgnGhvbGeo7kiaMoI6r/wPCVDhiBwcn434+s1oE7NG5PedQwNAR4QESOD/PFe388
v5YhGVW8PtySObQrcq0fGIDXGGyXbzAZ2+F0nBzB+HJ7azPi69mA5XA0PX7gBrj+
+79N/A1KaJ05p8gdsM5N/ySes4ClY8fTxNSRwqJocCO32dNXAkXxqGVZrowvHCqu
xZHqXWmRIG4WOTvYiTfPtNkdJfqAN/i/w8r9kV6OG7KqOXMvRsZa2XAn7vReyUVB
BylpUfp0FxRlcKt514rziI5q5MrL23jOIdRNX3pUwsscbRPx8Ak4HmbyDcmz5X/r
/L/s5dodD6qa4tPnXGI+TPOvXU2D9uKaaN+0XncvZtebqwZt00WZKXtwGq0LkjRB
luXI4LX3YuqJD58BWpOZlIiBmAETkOljAStJiV5HuIxuLAlJ6yGGr1PsEffl+wLY
GHsol1K0NbO5m88PruGqvPDXq9AYrpaGrDyQnvsqUeEJYpyasJU=
=pTLQ
-END PGP SIGNATURE-
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: per-zone query-source on recursive resolver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On Mon, 28 Oct 2019, Tony Finch wrote: Erich Eckner wrote: RPZ rewrites responses as they are going out of your nameserver, so you can't use RPZ to change the way the nameserver's resolver works (because the resolver depends on incoming responses not outgoing responses). Ah, right, the name should have turned me away from it (it's "*response* policy zone", not "*question* policy zone" :-D) There are two ways to do what you want, depending on the DNS servers on the other end of the VPN: * If they are recursive, use a forward zone. This applies to all the subdomains as well, since the recursive server is expected to follow referrals/delegations itself as necessary. I'm undecided whether they're authoritative or not. On one hand, they are distributed via DHCP as default DNS servers, speaking for "recursive", on the other hand, they have matching SOA records (and I think, that means, they're authoritative) - maybe they're both? * If they are authoritative, use a static-stub zone. In this case your server will follow referrals/delegations from the remote zone, which will need to make sense wrt your split horizon network topology. Due to the SOA, I took this path and it works like a charm :-) Googling the difference between forward and static-stub zones I found this: https://jpmens.net/2011/01/25/binds-new-static-stub-zone-type/ which made me understand it - I'll use static-stub, because I want to do the recursion myself (because I can and because it's slower :-D) If you need special source addresses as well as special target addresses, add server clauses for each of the target servers on the other end of the VPN to specify which query-source address to use for them. I tried without forcing the source address and it works out-of-the box. Most probably, some iptables-MASQUERADE action gets triggered (in the end, this box also *routes* network traffic through the vpn). Thanks! Cheers, Erich Tony. -- f.anthony.n.finchhttp://dotat.at/ Humber, Thames, Dover: North 3 or 4, veering northeast 4 or 5. Slight or moderate in Humber, otherwise slight, occasionally smooth. Showers. Good. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl23FjcACgkQCu7JB1Xa e1qceg//ZMavRLfEby1qXiBFCJxU8+dDFs3AyZd+k7XQec5K2BZgn+MaEOOBRiZ0 /WfSqe3pwTJ++SPNCPPGKEB2TH4JJV9R/tepMhI8t7x5ka91dGCW9uLWcfbaF2fo 2hewwMREFk6oUL59uqfEEvT5VZx8DCissjs4RpKuhX7NXCilnDM8upDnu41XK2gR JLlOoH6PwGXAgKajDS+JdGvSwr2vJVli+1PqKeJTg2BKzIhBoP7TzucAGy9Eb612 z17WV58KmnuFobURnghe2pgU9i/nfrXy0JcS72VcYZvsVDSTVBVyeE4Lh29ifxBR b/ivDu3P8VOCLW8tLB4ealTaCWqfYbdccRlr+XHG04a1KkEWRhAvLo+isosa/ION bRqrusn9I6dOsxQxAFPxdthIRB0yUoOi36PnjTrMnpjyXhyp0UKK011ZX93D3vuT hSk5luBD0ZFsF6D6NmSkVSilsrUV5AopmKc2wt6sj6pFFDfqYxuod2CAABJVQ0eC Kj7xA77XPqTXDCviVJs+0cRReQu7CILGOVFZkiXSep1cmtsICEWtLHaKjA3gMsMA idiVNcS6jEW9QEr0QrDMmdILyxC760GtwBg5L+1t+GnyWvN13TD5AbIqUAbb+1nL +xLNhCCWydJbILCDjsHyAdasfbYQFmQBCaE6n/50zOxZoTlU3tg= =ow+h -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
per-zone query-source on recursive resolver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I'm running bind as a recursive resolver. This box also has a vpn tunnel to another network (not mine) with split-horizon dns (internal clients see different NS entries than external clients; those in turn resolve different addresses). I would like to resolve the majority of requests directly (e.g. not through the vpn), but some requests (all below a certain second-level domain) through the vpn.[1] I had two ideas to accomplish that: 1. Set a custom query-source (the one of the vpn interface) for that second-level domain. (This would also be applied to all subdomains thereof, right?) 2. Overwrite (by rpz?) the name-servers for that domain to the (somehow obtained) internal nameservers (they differ from the external ones and have adresses which are automatically routed through the vpn anyways). Any idea which approach is the best and how I best accomplish that? (an even better third idea would be welcome, also) 1] sry for not handing out details about *which* second-level domain that is, but because you're not inside its network, most probably, you couldn't take a peek at the internal dns servers anyway. cheers, Erich -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl22k8MACgkQCu7JB1Xa e1pn4xAAoKHhd6shEJy2E5/nrZPQhQRQl+u9w8nyz5xPgmnJcs2JxgBf2jVMT4fl D6/xlTD2tlEgtpPRy+/I0VluSsRGut2HgizH9G12vbrqGS0FI4tBd+qiTB/UH1Xh 2mUbEykdjH8u9dUEARZPaM6ZvVauyQCpQybTRc1Y6HMbzv6jd6CalNDeeuVmIxTc KvfoVD2Ixk0jWL8Bel+ScW660sHK0NaG/RNg494/hXnITp+uR/NesHEGeUeEa9rJ 3egtzsdFuIANl9Y1UCnF51u1eZNPlCbYVfekyFopsHBAeQ1bnJn6STKnGpie9oSK wUL9D9W1LNOOz2ahpYgU3Vueh+T50OFjPmA6BF95qq/OfTk2Qi7syWz1ReYvvBH+ grpjbxAhrM/hK7aroepdvz2E5pCyZQ0IhzpPAxTccbzZAxzFgy0e5uR68R1OjoKn yQEw6pgj6NonIlPPqKeOXYzrQwfojwvU4MS3P29lwODH+NBbhEXegbGXn2XJrlZN n7kvZDFzqfwyTclEJjtJENk+hbUb2GoCty2xiNB7cFV0T0lTzUYTbMg/86hRtmVX pMfLk3RchEYuMSqTodfL6sQjXBEItPkCdwI/bleMRTo/NlQIEPa90cuameokHoII /2xFx8hGcs5KbyTnUhJj2ZCcZruDTtE68O+/S9dAOucS2Biy5tE= =Rdho -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
make bind prefer DoT for recursion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I am running a recursive resolver for my local network and was wondering whether it is possible (and if so: how) to make it resolve via DNS-over-TLS if that's available on the authoritative name servers. Setting up stunnel like for stub resolvers seems non-practical, as bind will have to contact many different remote dns servers. cheers, Erich -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAlyUnWYACgkQCu7JB1Xa e1pIFBAAuKb2yuK5KvYtrnQ/PI4DRcOHz33Y71vYzBjGUf6RhcZF7N6SmIcyul13 gFWxmyHbha+O+a1D7CEUCnUVJ5Spx1KeNJbCI8XKPvPd6Fg0n35WDQV8iHtWuMhT Z09E7bn0FaDbcUxNYY9fXVNA9JXTjZAYayOaVwX3Sd7wwHhLuyR2PZrUfZ+sIoW9 XqaeAbSvSYvjqnuhjvXA7a5UfO8aEVQAQI5mfASODHQQN3Sb/Zvvrx7MCLEzXpSa P5+0HCWWyVE1IIyKy2yU4Cov8uZ95r6+BcfKBYOfIrpz4WlROnPubKfee7o40YB/ KhrRQZJ0pWrPdJGgPZUfqp3DLadGgCCYd7UFm5efptRtWiUvNcx5Z3pl1VQlHU/F /d3qJtD0KCzV2qlo/5YVilYtHeHBZNRhyfmVPlj2Ousp6euBoDT6s4J3uIFUU6nK v51IE8h2GwwGNtmzqcqPRHdRGngEMH5PBD2uhKZ/EUi4+DYhCeqGY+SkM0/37RMv cWEsXU1nnjuAzpWUob/BxCsR1p7DVWNXMUp+2XuUlee08spksR7QfjQCEk/eCaeK xsv2JtIQGWpR72uysjRAq9M4E6ZohOsqMS1ELYS/yPyT5Ox/cCER8iMR1bw/tS4p 4siaxnp3tvHlX0w8r2kdiPm8pC6Vd/qFslS6XtFiC9NmiqBrnZw= =9oou -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
forward all but ANY requests
Hi, I'm running a bind9 name server (9.13.4 on debian) which forwards some zone (onion.) to tor's name server. Unfortunately, tor's name server only answers A and requests, but not e.g. ANY requests. 192.168.1.3 is running the tor dns, 192.168.1.13 is running bind9 forwarding to 192.168.1.3:9053 $ dig +short @192.168.1.3 -p9053 3g2upl4pq6kufc4m.onion ANY ;; Connection to 192.168.1.3#9053(192.168.1.3) for 3g2upl4pq6kufc4m.onion failed: connection refused. $ dig +short @192.168.1.3 -p9053 3g2upl4pq6kufc4m.onion A 10.255.55.223 $ dig +short @192.168.1.3 -p9053 3g2upl4pq6kufc4m.onion febe:5163:d2b9:98aa:345b:ee04:2c32:d10e $ dig +short @192.168.1.13 3g2upl4pq6kufc4m.onion ANY $ dig +short @192.168.1.13 3g2upl4pq6kufc4m.onion A 10.255.55.223 $ dig +short @192.168.1.13 3g2upl4pq6kufc4m.onion febe:5163:d2b9:98aa:345b:ee04:2c32:d10e Is there any option: - to make bind fall back to A or when the ANY request fails (even the connection fails!) or - to only forward requests of certain type(s) or - to answer ANY requests _always_ with A or records (not trying if the ANY request can be forwarded successfully), possibly for certain zones only? Sry, if that has been asked before, but I seem unable to find anything useful on the internet, since "ANY" is not a good search term ;-) and without "ANY" I only turn up how to set bind to ipv4/ipv6-only. regards, Erich signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
