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
