Hi Evan.
Thank you for your response and comments. I know you are all pretty busy,
I just didn't want the request for comment to get lost in the pile of emails.
Please see my inline comments.
On 04/02/2015 12:47 AM, Evan Hunt via RT wrote:
> Hi, my apologies for the slow reply, I missed this one when it came in
> for some reason.
>
> The allow-transfer statement is an ACL -- it allows access, or not, based
> on matching the client's IP address or TSIG key. That's why it accepts IP
> subnets.
Right, I understand that. However when someone allows the whole subnet
to transfer some zone, they have to list explicitly IP addresses in also-notify
from the subnet to which to send NOTIFY.
> By default, NOTIFY messages are sent to all the servers listed in the
> zone's NS RRset. The "also-notify" option lets you add extra servers
> that will also receive NOTIFY messages. Caveat: If you've set the
> "notify explicit" option, then the NOTIFY messages are *only* sent to
> the "also-notify" list. Either way, if you specified a subnet,
> such as "also-notify { 10/8; };", the implied behavior would be for
> BIND to send NOTIFY messages to every address in 10/8... which obviously
> doesn't make very much sense.
>
> I guess maybe the idea is to have a global list of server addresses from
> which BIND selects only those that match 10/8 -- but where is this list
> of addresses specified?
>
> Without understanding the exact use case better, I'm not sure what to suggest,
> but I don't think "also-notify" is the right place to make this change.
The point is not to have to specify the list of servers to which send NOTIFY
explicitly.
Sorry for not describing any specific use case. We have a customer which apart
from slave servers on their site uses another company's service. It is RU-CENTER
which provides secondary DNS services. According to the requirements [1] of this
service,
the zone transfer has to be allowed for specific ranges of IPs. The customer wants
to send NOTIFY to those ranges,
However reading the service site I realized that in fact they don't require
NOTIFY to be sent to all servers in the IP subnet, just to the specific ones.
I agree that sending NOTIFY e.g to all IPs in 10/8 range is not a really good idea.
Please let me check with our support engineers if there is any real use case,
since the initial one does not seem to be valid (given what is written on the
service
site).
[1]
http://www.nic.ru/dns/service/dns_hosting/secondary/settings.html?level=2nd%29,specifically
Thank you!
Tomas
> On Tue Mar 03 11:50:22 2015, thozza@redhat.com wrote:
> > Hello.
> >
> > I would like to ask if it would be acceptable to merge feature
> > into BIND, that would allow using subnet instead of just specific
> > IP address in the also-notify configuration statement.
> >
> > Based on documentation and our testing, it is not possible.
> >
> > The idea is to modify
> >
> > [ also-notify { ip_addr [port ip_port] [dscp ip_dscp] ;
> > [ ip_addr [port ip_port] [dscp ip_dscp] ; ... ] }; ]
> >
> > to something like
> >
> > [ also-notify { ip_addr [/length] [port ip_port] [dscp ip_dscp] ;
> > [ ip_addr [/length] [port ip_port] [dscp ip_dscp] ; ... ] }; ]
> >
> > where [/length] would specify the prefix length and if not used
> > it would default to "32" in case of IPv4 or "128" in case of IPv6.
> >
> > Another possibility would be to modify the also-notify to accept
> > "address_match_list". Although I don't think all of its elements
> > make sense in the context of also-notify (e.g. "key" and the possibility
> > to negate it using "!").
> >
> > The use case for this is that one is able to specify the subnet
> > in allow-transfer statement. However if the administrator needs
> > to notify all slaves in the subnet, then their IPs need to be
> > explicitly listed. This may not be feasible if the list is extensive.
> >
> > I'll start working on the patch once you agree on some of proposed
> > approaches (and on the feature itself).
> >
> > Thank you!
> >
> > Regards,
--
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience
PGP: 1D9F3C2D
Red Hat Inc.
http://cz.redhat.com