Hi,
On Aug 8, 2013, at 19:13 , Joe Abley wrote:
> On 2013-08-08, at 12:39, Havard Eidnes <h...@uninett.no> wrote:
>
>>> Why not configure regular nameserver on the same host as
>>> opendnssec instead of replicating full functionality in
>>> opendnssec itself?
>>
>> Well... This may at least partly stem from my local wishes for
>> deployment. I wanted to not touch the current originating name
>> server, and continue to maintain the zones there, and use
>> OpenDNSSEC as a "bump on the wire" between the now hidden master
>> and the new distribution master name server.
>>
>> In other words, I wanted to use "DNS in", and at the same time
>> "DNS out" for transferring respectively unsigned and signed
>> zones. After all, that is supposed to be a supported feature,
>> now, with 1.4?
>
>> If I want to use the "DNS in" adapter, it seems to me that
>> OpenDNSSEC lays claim to port 53, so that presents an additional
>> challenge if you want to run a real name server in parallel with
>> OpenDNSSEC.
>
> Well, there's nothing to say you have to bind a private-use nameserver to
> port 53. You can bind to a different port, and configure your origin masters
> (for the unsigned zones) to notify a different port.
>
>> (Even though you can configure the signer to listen
>> to another port than 53, I don't immediately see a way for me to
>> configure BIND to send notify messages to another port than port
>> 53.)
>
> also-notify {
> target-address port target-port;
> };
>
> I'm not suggesting that what you say doesn't make sense, just that there are
> workarounds that might well be acceptable.
Speaking of tweaking the ports used... what about the source address used?
I'm playing with a setup similar to what Håvard has. In my case I have a hidden
master on address 10.1.0.1, ODS on 10.1.0.2 and a slave for the signed version
of the zone on 10.1.0.3. The problem is that 10.1.0.1 and 10.1.0.2 are two IP
aliases on the same box. So I have tweaked the nameserver on 10.1.0.1 to Notify
10.1.0.2 which began to work when I realised I had to lock the source address
used (otherwise it will Notify 10.1.0.2 with a source of 10.1.0.2, which ODS
correctly ignores).
However, that just caused me to bump my head on the same thing going in the
opposite direction: when ODS requests a zone transfer from 10.1.0.1 it is
refused by the ACL on the hidden master, due to the request coming *from*
10.1.0.1:
OpenDNSSEC logs:
Sep 5 20:37:27 master ods-signerd: [xfrd] bad packet: zone bravo.dnslab
received error code REFUSED from 10.1.0.1
Sep 5 20:42:07 master ods-signerd: [xfrd] bad packet: zone bravo.dnslab
received error code REFUSED from 10.1.0.1
Master nameserver logs (in this case it was Knot, but that's obviously
irrelevant):
2013-09-05T20:37:27 [notice] Outgoing AXFR of 'bravo.dnslab.' to
'10.1.0.1@60434': Operation not permitted.
2013-09-05T20:37:27 [notice] Outgoing AXFR of 'bravo.dnslab.' to
'10.1.0.1@60433': Operation not permitted.
2013-09-05T20:37:28 [notice] Outgoing AXFR of 'bravo.dnslab.' to
'10.1.0.1@60432': Operation not permitted.
2013-09-05T20:42:07 [notice] Outgoing AXFR of 'bravo.dnslab.' to
'10.1.0.1@60431': Operation not permitted.
2013-09-05T20:42:07 [notice] Outgoing AXFR of 'bravo.dnslab.' to
'10.1.0.1@60430': Operation not permitted.
2013-09-05T20:42:08 [notice] Outgoing AXFR of 'bravo.dnslab.' to
'10.1.0.1@60429': Operation not permitted.
Could we please have an option to force the source address that ODS uses? Or,
quite possibly, am I just hopelessly confused here and there is some way to do
that already?
Regards,
Johan
PS. Sure, I realise that this could be done in several other ways, using
separate boxes, different ports, ACLs based on keys rather than addresses, etc.
But still, this ought to work. There's a reason why all nameservers these days
have options for forcing the source address used, and the same needs apply to
ODS now that it is starting to behave like a nameserver.
_______________________________________________
Opendnssec-user mailing list
Opendnssec-user@lists.opendnssec.org
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
