Re: [DNSOP] draft-ietf-dnsop-rfc6598-rfc6303-01

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Joe Abley writes
:
> Hi Chris,
>
> I went quiet on this thread because I was going to try this out in a lab
> before commenting further, but since I haven't done that and you had
> something to say...
>
> On 20 Aug 2014, at 12:50, Chris Thompson <[e-mail]> wrote:
>
> > On Aug 14 2014, Joe Abley wrote:
> >
> > [...]
> >> It seems to me that no delegation is a perfectly reasonable steady
> state,
> >
> > It fails to break the chain of trust. Because a validator can "prove"
> that
> > the names in the putative subzone do not exist, it will consider locally
> > defined content "bogus".
>
> Doesn't this depend on how you do it?
>
> (a) If your resolvers are all configured as authoritative for the zones
> that you want special treatment for (e.g. 239.in-addr.arpa,
> 64.100.in-addr.arpa) I think the expected behaviour is that they will
> return that authoritative data in response to queries.
>
> So, for example, if your BIND9 recursive server has a bunch of "type
> master" or "type slave" zones, stub resolvers will get answers regardless
> of the presence or absence of RRSIGs, secure delegations elsewhere, etc.

You will give answers that validate as bogus in the stub resolver.
A validating stub resolver talking to a ISP's recursive server will
reject the answers from the ISP's server.

> (b) If your resolvers are configured with those special zones as
> "forward" type zones (again, using BIND9 language) and the local
> authoritative servers for those zones are separate, is the behaviour
> different? I had thought it was the same as (a).

The answers received from the forwarder will be rejected as bogus.

> (c) If you are providing service for particular zones locally by
> hijacking the traffic intended for the real servers out on the Internet,
> then it does seem likely that your answers are going to be ignored as
> bogus by a validator.
>
> Since (c) is about the hardest and most unsupportable way of doing this,
> I hadn't thought it much of a problem (the mitigation is "well, don't do
> it like that"). Am I wrong about (a) and (b)?

All down stream validating clients will reject the answers as the reverse
namespace for 100.64/10 is currently configured.  All the above senarios
lead to the answers being rejected.

> Joe
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]