Re: Splitting off a sub-zone "atomically"
On 10.05.10 16:20, Phil Mayers wrote: > We're doing some DNSSEC testing with sub-zones of our main zone, and I > had a little accident largely due to my own incompetence today where I > basically did this: > > 1. Existing zone "example.com"; create new zone "sub.example.com" > > 2. Run a SQL->DNS update; *.sub.example.com RRs are removed from > "example.com", and added to "sub.example.com" > > 3. Slaves immediately get the NOTIFY for "example.com" and remove the > records via IXFR, but aren't yet configured for "sub.example.com" (cron > job hasn't yet run) > > 4. Some time later, the cron job runs > > > Obviously between 3 & 4 we weren't resolving "sub.example.com" on the > slaves. Tedious. that's why you should push glue NS records for sub.example.com to example.com pointing to servers that will have those zones (at least some of them must already have them). The same set of NS records should be in sub.example.com of course. > Obviously I can change my procedures to do: > > 1. Create zone on master > 2. For each slave: > a. axfr file from master > b. add zone into /etc/named.conf > c. rndc reload > 3. On master, remove *.sub.example.com RRs from example.com > > ...but I was just curious. creating proper delegation is much safer way to achieve that. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Microsoft dick is soft to do no harm ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Allowing recursion for just specific zones
On Mon, May 10, 2010 at 11:54:57AM -0700, Chris Buxton wrote:
> One strategy would be to set up a view that matches recursive queries
> only. Set allow-query to none at the view, then set it any (or
> whatever) in each zone of type forward or stub.
Thank you Chris.
Unfortunately, allow-query is rejected in forward zones. The error is
explicit:
option 'allow-query' is not allowed in 'forward' zone 'example.com'
The 9.2.4 ARM doesn't make this clear, but the 9.4.2 ARM does show a
restricted grammar for forward zones:
zone zone_name [class] {
type forward;
[ forward (only|first) ; ]
[ forwarders { [ ip_addr [port ip_port] ; ... ] }; ]
[ delegation-only yes_or_no ; ]
};
> Or if you want to use your root zone idea, make sure to populate it
> with delegations to the domains that should resolve.
Interesting. It seems to work even if I just delegate to 'localhost',
without having to hardcode the real NS RRs for the zone. That seems like a
bit of a frig though, which may confuse people maintaining it. And ideally
I'd prefer a REFUSED response to NXDOMAIN.
> I'm not sure if the match-recursive statement existed in 9.2. You may
> need to upgrade to something current.
There is "match-recursive-only" (boolean). Does that match queries with the
RD flag set? If so it won't make a difference here, because all the clients
are dumb endpoints which will set RD always.
The application, by the way, is supporting a network of kiosk-like
terminals. They run some third-party applications which need to make
external access to certain services across the Internet. Of course, the
firewall only lets them make connections to specific hosts/ports they need.
However I want to give a similar level of control for DNS lookups too;
otherwise, in the event of a virus infection, the virus could use the DNS as
a covert channel.
Regards,
Brian.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Splitting off a sub-zone "atomically"
On 05/11/2010 09:12 AM, Matus UHLAR - fantomas wrote: On 10.05.10 16:20, Phil Mayers wrote: We're doing some DNSSEC testing with sub-zones of our main zone, and I had a little accident largely due to my own incompetence today where I basically did this: 1. Existing zone "example.com"; create new zone "sub.example.com" 2. Run a SQL->DNS update; *.sub.example.com RRs are removed from "example.com", and added to "sub.example.com" 3. Slaves immediately get the NOTIFY for "example.com" and remove the records via IXFR, but aren't yet configured for "sub.example.com" (cron job hasn't yet run) 4. Some time later, the cron job runs Obviously between 3& 4 we weren't resolving "sub.example.com" on the slaves. Tedious. that's why you should push glue NS records for sub.example.com to example.com pointing to servers that will have those zones (at least some of them must already have them). The same set of NS records should be in sub.example.com of course. We run hidden master, so the (single) server which has the zone at creation time is not queriable. As per my original email, I realise that what I did was sub-optimal - I am asking about bind's behaviour in two slightly different alternatives. Essentially, I guess I'm talking about the requirements for priming the new zone onto the slaves before creating the zone cut, and was wondering what bind did between the "rndc reconfig" and the AXFR completing. Mark has answered that - it returns SERVFAIL - which is all I wanted to know. Obviously I can change my procedures to do: 1. Create zone on master 2. For each slave: a. axfr file from master b. add zone into /etc/named.conf c. rndc reload 3. On master, remove *.sub.example.com RRs from example.com ...but I was just curious. creating proper delegation is much safer way to achieve that. It's difficult to see how that alone solves the problem along with a hidden master; you have to at the very least create the zone definition on the slaves first, else they'll NXDOMAIN queries rather than SERVFAIL them. Thanks for all the info. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Out-of-zone data mistaken for glue?
Following on from yesterdays query; if I have this zone: test.com. 86400 IN SOA ... test.com. 86400 IN NS ... foo.test.com. 86400 IN NS ns.foo.test.com. ns.foo.test.com.86400 IN A 192.168.254.254 www.foo.test.com. 86400 IN A 192.168.1.1 ...this zone loads fine, and www.foo.test.com does *not* resolve, which is as expected I guess. However, neither bind nor named-checkzone report the non-glue A record as an error. Is this expected? (This is just curiosity - obviously it's a bad idea to populate zones like this!) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Out-of-zone data mistaken for glue?
In article , Phil Mayers wrote: > Following on from yesterdays query; if I have this zone: > > test.com. 86400 IN SOA ... > test.com. 86400 IN NS ... > foo.test.com. 86400 IN NS ns.foo.test.com. > ns.foo.test.com. 86400 IN A 192.168.254.254 > www.foo.test.com. 86400 IN A 192.168.1.1 > > ...this zone loads fine, and www.foo.test.com does *not* resolve, which > is as expected I guess. However, neither bind nor named-checkzone report > the non-glue A record as an error. Is this expected? > > (This is just curiosity - obviously it's a bad idea to populate zones > like this!) Are you sure you have the trailing dot on that record? -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Out-of-zone data mistaken for glue?
On 11/05/10 12:20, Barry Margolin wrote: In article, Phil Mayers wrote: Following on from yesterdays query; if I have this zone: test.com. 86400 IN SOA ... test.com. 86400 IN NS ... foo.test.com. 86400 IN NS ns.foo.test.com. ns.foo.test.com.86400 IN A 192.168.254.254 www.foo.test.com. 86400 IN A 192.168.1.1 ...this zone loads fine, and www.foo.test.com does *not* resolve, which is as expected I guess. However, neither bind nor named-checkzone report the non-glue A record as an error. Is this expected? (This is just curiosity - obviously it's a bad idea to populate zones like this!) Are you sure you have the trailing dot on that record? Pretty sure. I can start out with no zone cut, insert one via "nsupdate", freeze the zone, and the resultant zone still reports no errors: == Initial zone, no zone cut == # dig @localhost test.com axfr test.com. 86400 IN SOA ... test.com. 86400 IN NS ... www.foo.test.com. 86400 IN A 192.168.1.1 == www host resolves as expected == # dig +norec +noide +noqu +noqr +norec @localhost www.foo.test.com ;; ANSWER SECTION: www.foo.test.com. 86400 IN A 192.168.1.1 ;; AUTHORITY SECTION: test.com. 86400 IN NS ... == Insert the zone cut == # nsupdate > server localhost > zone test.com > update add foo.test.com. 86400 NS ns1.example.com. > # dig @localhost test.com axfr test.com. 86400 IN SOA ... test.com. 86400 IN NS ... foo.test.com. 86400 IN NS ns1.example.com. www.foo.test.com. 86400 IN A 192.168.1.1 == www host no longer resolves, as expected == # dig +norec +noide +noqu +noqr +norec @localhost www.foo.test.com ;; AUTHORITY SECTION: foo.test.com. 86400 IN NS ns1.example.com. == Flush the zone to disk == # rndc freeze test.com # cat test.com $ORIGIN . $TTL 86400 ; 1 day test.comIN SOA ... NS ... $ORIGIN test.com. foo NS ns1.example.com. $ORIGIN foo.test.com. www A 192.168.1.1 == Run compilezone - no errors == # named-compilezone -o /dev/null test.com test.com zone test.com/IN: loaded serial 2006405210 dump zone to /dev/null...done OK ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Out-of-zone data mistaken for glue?
In message <4be937b1.7070...@imperial.ac.uk>, Phil Mayers writes: > Following on from yesterdays query; if I have this zone: > > test.com. 86400 IN SOA ... > test.com. 86400 IN NS ... > foo.test.com. 86400 IN NS ns.foo.test.com. > ns.foo.test.com. 86400 IN A 192.168.254.254 > www.foo.test.com. 86400 IN A 192.168.1.1 > > ...this zone loads fine, and www.foo.test.com does *not* resolve, which > is as expected I guess. However, neither bind nor named-checkzone report > the non-glue A record as an error. Is this expected? > (This is just curiosity - obviously it's a bad idea to populate zones > like this!) > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users Named checks that NS's have A's or 's it doesn't do the reverse checks of A's and 's having NS's. The latter is more complicated and is not required for correct operation. Note also that UPDATE requires that you be able to add then remove a delegating NS and get back the same zone so it is not a error to have all sorts of stuff hidden beneath a zone cut. You can also build up the contents beneath a zone cut then remove the delegation. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Allowing recursion for just specific zones
Yes, of course. I've made that mistake before, in fact.
Use a custom root zone, as I believe you originally mentioned, with
delegations to just the zones that should be reachable.
Or else set up secure proxies and disallow all DNS resolution (an
empty root zone).
Chris Buxton
BlueCat Networks
On 5/11/10, Brian Candler wrote:
> On Mon, May 10, 2010 at 11:54:57AM -0700, Chris Buxton wrote:
>> One strategy would be to set up a view that matches recursive queries
>> only. Set allow-query to none at the view, then set it any (or
>> whatever) in each zone of type forward or stub.
>
> Thank you Chris.
>
> Unfortunately, allow-query is rejected in forward zones. The error is
> explicit:
>
> option 'allow-query' is not allowed in 'forward' zone 'example.com'
>
> The 9.2.4 ARM doesn't make this clear, but the 9.4.2 ARM does show a
> restricted grammar for forward zones:
>
> zone zone_name [class] {
> type forward;
> [ forward (only|first) ; ]
> [ forwarders { [ ip_addr [port ip_port] ; ... ] }; ]
> [ delegation-only yes_or_no ; ]
> };
>
>> Or if you want to use your root zone idea, make sure to populate it
>> with delegations to the domains that should resolve.
>
> Interesting. It seems to work even if I just delegate to 'localhost',
> without having to hardcode the real NS RRs for the zone. That seems like a
> bit of a frig though, which may confuse people maintaining it. And ideally
> I'd prefer a REFUSED response to NXDOMAIN.
>
>> I'm not sure if the match-recursive statement existed in 9.2. You may
>> need to upgrade to something current.
>
> There is "match-recursive-only" (boolean). Does that match queries with the
> RD flag set? If so it won't make a difference here, because all the clients
> are dumb endpoints which will set RD always.
>
> The application, by the way, is supporting a network of kiosk-like
> terminals. They run some third-party applications which need to make
> external access to certain services across the Internet. Of course, the
> firewall only lets them make connections to specific hosts/ports they need.
> However I want to give a similar level of control for DNS lookups too;
> otherwise, in the event of a virus infection, the virus could use the DNS as
> a covert channel.
>
> Regards,
>
> Brian.
>
--
Sent from my mobile device
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
