Re: Filtering A records in combination with DNS64
Hey Mark, we have deployed the dns64 settings some years ago and I did not notice the settings at the time - but it seems their combination looks excatly like what we were looking for. Thanks a lot for the pointer! Best regards, Nico Mark Andrews writes: > Have you actually played with dns64 settings? > > dns64 { > break-dnssec ; > clients { ; ... }; > exclude { ; ... }; > mapped { ; ... }; > recursive-only ; > suffix ; > }; // may occur multiple times > > >> On 19 Feb 2021, at 06:39, Nico Schottelius >> wrote: >> >> >> Good morning everyone, >> >> we have peculiar request to solve and were wondering whether it is at >> all possible with bind: >> >> a) >> For a certain source range, let's say 2001:db8::/96, we want to *only* >> reply with generated DNS64 entries - i.e. we want bind to only reply >> with mapped IPv4 addresses, NOT with proper entries, if they exist. > > dns64 { clients { acl; }; exclude { ::/0; }; }; > >> b) >> For a different source range, let's say 2001:db:1::/64, we want to reply >> only with *proper* IPv6 entries, i.e. disable DNS64 for them. > > dns64 { clients { !prefix; any; }; > >> >> c) (optional) >> >> In the best case, we would even like to remove A replies from the >> results, in case a misconfigured client requests A records. > > Then you break the ability of those clients to do their own DNS64 mappings > which is required when they are doing DNSSEC themselves. > >> Background for this is that we have clients in specific networks, which >> are mapped via SIIT to IPv4 addresses. These clients should never >> connect to an IPv6 address (besides they actually do...) after >> translation. And the clients in the other network should behave the >> opposite, they should *only* connect to IPv6 hosts. >> >> However, both client networks are IPv6 only, as there is no IPv4 link >> into these networks, so we are dealing with NAT64/SIIT. And >> unfortunately we don't have a lot of control over the client behaviour, >> whether they will ask for A/ entries, so we will need to steer them >> on the DNS side. >> >> Looking forward to your replies. >> >> Best regards, >> >> Nico >> >> -- >> Sustainable, Modern Infrastructures by ungleich.ch >> ___ >> 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 -- Sustainable and modern Infrastructures by ungleich.ch ___ 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: AXFR rejected
Hi Erich, please fill an proper issue at our GitLab instance - https://gitlab.isc.org/isc-projects/bind9/issues and we’ll take it from here. We will need more information and mailing list is very clumsy way of tracking that. Thanks, Ondrej -- Ondřej Surý (He/Him) ond...@isc.org > On 19. 2. 2021, at 14:07, Erich Eckner wrote: > > Signed PGP part > 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 > > signature.asc Description: Message signed with OpenPGP ___ 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