In message <[email protected]>, 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 <[email protected]> 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: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
