[IPv6] Managing dynamic /64 reverse zones inside a static /48 (no delegation)
Hello, Since 2005, we are manually managing a /48 IPv6 prefix with a homemade software, our reverse zone is x.x.x.x.0.6.6.0.1.0.0.2.ip6.arpa. We are now deploying dynamic/private networks for our workstations and to keep the IPv6 reverse zone up-to-date without rewriting our software, we came with the following solution : we create a /64 zone within the /48 and we allow dynamic updates on it (e.g. 0.0.1.0.x.x.x.x.0.6.6.0.1.0.0.2.ip6.arpa.). The PTR records on the dynamic /64 are for workstations, we don't do delegation with the /48 and so the /64 is not visible on our external view, this keeps our "private" prefix private. As far as our software won't create PTR on a dynamic /64 and that the DHCP server isn't allowed to update the /48, is this setup can be considered safe? It's working exactly as expected and I'm about to create dozens of /64 IPv6 reverse zones, so I'm checking here in case I forgot something. Regards, Nicolas ___ 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
Shared dynamic zone on external view?
Hello,
I have a dynamic zone on an external view, this zone is updated with a
TSIG key from outside of our network. There is a secondary DNS server,
also outside our network on which zones transfers are working fine with
no key.
We would like to make one of our internal DNS secondary for this zone
and we have the "dynamic zone shared between views" problem. I tried to
follow the FAQ but no luck so far.
I'm not sure that what I'm trying to do is possible, can someone confirm
this?
Should I follow the FAQ and make my dynamic zone "master" on the
"internal" view? That makes less sense to us because this are public
zones, updated from the outsite.
This is my configuration :
view "internal" {
match-clients {
!key external;
key shared;
};
zone "" {
type slave;
file "db.shared-int";
masters { IPv4-of-my-DNS; };
transfer-source IPv4-of-my-DNS;
};
};
view "external" {
match-clients { !key shared; any };
allow-transfer { IPv4-of-my-DNS; };
server IPv4-of-my-DNS; { keys { shared; }; };
zone "" {
type master;
file "db.shared-ext";
notify yes;
also-notify { IPv4-of-my-DNS; };
update-policy {
grant another-key subdomain ANY;
grant princi...@rea.lm subdomain ANY;
};
};
When I reload the configuration or try to initiate a zone transfer with
dig and the "shared" key, I have this message in the logs.
zone /IN/internal: refresh: unexpected rcode (SERVFAIL) from
master IPv4-of-my-DNS#53 (source IPv4-of-my-DNS#0)
Regards,
Nicolas
___
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: Shared dynamic zone on external view?
Le 08/11/2012 13:20, /dev/rob0 a écrit :
On Thu, Nov 08, 2012 at 09:23:05AM +1100, Mark Andrews wrote:
In message <509a8796.7060...@nryc.fr>, "Nicolas C." writes:
I have a dynamic zone on an external view, this zone is updated
with a TSIG key from outside of our network. There is a secondary
DNS server, also outside our network on which zones transfers are
working fine with no key.
We would like to make one of our internal DNS secondary for this
zone and we have the "dynamic zone shared between views" problem.
I tried to follow the FAQ but no luck so far.
I'm not sure that what I'm trying to do is possible, can someone
confirm this?
Should I follow the FAQ and make my dynamic zone "master" on the
"internal" view? That makes less sense to us because this are
public zones, updated from the outsite.
This is my configuration :
view "internal" {
match-clients {
!key external;
key shared;
};
zone "" {
type slave;
file "db.shared-int";
masters { IPv4-of-my-DNS; };
You need to force the internal zone to talk to the external zone.
masters { IPv4-of-my-DNS key external; };
Should not the master also have an "also-notify" to notify the
internal zone as well? Or the zone might contain a bogus internal-
only NS host, but that would seem less appropriate. If the notify
received is only for the external view, the internal view will only
update on elapsed SOA expire time.
Yes, it is specified on the FAQ and you can see it in my configuration
below (also-notify { IPv4-of-my-DNS; };).
It's working now, I had some issues because the DNS server was 100%
secondary so notifications were disabled globally in "options". When it
became master for this dynamic zone, it wasn't notifying the internal
view on the secondary.
Enabling notifications or explicitly notifying the secondary solved the
problem.
Regards,
Nicolas
transfer-source IPv4-of-my-DNS;
};
};
view "external" {
match-clients { !key shared; any };
allow-transfer { IPv4-of-my-DNS; };
server IPv4-of-my-DNS; { keys { shared; }; };
zone "" {
type master;
file "db.shared-ext";
notify yes;
also-notify { IPv4-of-my-DNS; };
___
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
Slowing down bind answers ?
Hello, Is it possible to make bind answering slowly to requests ? Here is the context : we installed new DNS servers but some clients with static IP configuration are still using the old ones. We enabled queries logging to track the badly-configured workstations and warned the persons but as far as is it still working, they don't seem to be willing to change their static IP configuration to DHCP. Before stopping completely the old servers I'd like to slowly degrade the service and make the old DNS slow in order to force them to react. I'm sure it's possible to do it at a network-level (with iptables) but I'm curious to know if it's possible to do it directly with bind. Regards, Nicolas ___ 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: Slowing down bind answers ?
On 03/01/2014 18:00, wbr...@e1b.org wrote:
From: Mark Andrews
After that specify a final date for them to fix their machines by
after which you will send NXDOMAIN responses. Sometimes sending a
poisoned reponse is the only way to get peoples attention.
zone "." {
type master;
file "empty";
};
empty:
@ 0 IN SOA . stop.using.this.nameserver 0 0 0 0 0
@ 0 IN NS .
@ 0 IN A 127.0.0.1
Or really mess with them and answer all A queries with 199.181.132.249
It's not a bad idea. I could wildcard all requests to an internal HTTP
server saying that the DNS configuration of the client is deprecated.
___
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: Slowing down bind answers ?
On 05/01/2014 18:17, Sten Carlsen wrote: You might also make a list of those who use the old server, send a message (assuming the management system allows identification) that the service goes down at a specific date in e.g. a month from that date. And then remove it. Threats are not much worth if the are not followed through. And : On 05/01/2014 14:25, Timothe Litt wrote: You can also turn on query logging (which helps slow down the old server) - and use the logs to backtrack to the machines that need to be reconfigured. Scripts can send an e-mail daily with a warning and instructions on how to reconfigure. If you have the ownership data, scripts can escalate to a manager/sponsor if ignored. Hopefully this will get you down to a manageable list of miscreants that require manual follow-up. As I said in my original request : I did the query logging / warning but it had no effect. I could hold them at gunpoint until they change their configuration but we have strict gun laws in France :) ___ 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: DDNS from DHCPv4 and DHCPv6
On 04/04/2014 14:49, Philipp Schulz wrote: Hello, I hope this wasn't allready discussed in the past. I am currently trying to setup a "dual Stack Network". Both of the two dhcpd instances are doing their job, updating the nameserver, but when i try using both of them at the same time some problems accure. Running named in foregroung tells me . client ::1# 52164: updating zone 'example.org/IN': update unsuccessful: tux.example.org/A: 'rrset does not exist' prerequisite not satisfied (YXRRSET) So i took a look at RFC 2136 which tells me , I can't add an additional RR because there is allready a RR for 'tux'. Quote: For this prerequisite, a requestor adds to the section a single RR whose NAME and TYPE are equal to that of the RRset whose nonexistence is required. My question is: can I somehow disable that behaviour? Sorry for the poor english ;) Hello Philipp, This is a known behavior caused by different identifiers : "client-identifier" in DHCPv4 and DUID in DHCPv6. DDNS doesn't work because this identifiers are conflicting, even if they're coming from the same host. The answer is to use DHCPv4 clients that comply with RFC 4361, it is the case of ISC-DHCP 4.3.x. In this case, v4 and v6 clients use the same DUID as identifier and they can update the same FQDN independently. Unfortunately, ISC-DHCP 4.3.x has been release recently and I don't think Linux distros have updated their "isc-dhcp-client" package yet. As far as I know, DHCPv4 clients in Windows OS aren't RFC 4361-compliants. The other solution is to stop doing statefull DHCPv6 and going back to EUI64 addresses. As such, you can script DDNS of EUI64 addresses, this is what I have in production in my campus. If you can read french, I wrote an article about it : https://conf-ng.jres.org/2013/document_revision_1437.html?download Feel free to ask me (or the isc-dhcp-users list) if you need help. Cheers, Nicolas ___ 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
