Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706

[Paul Vixie <[e-mail]>]

On Friday, April 7, 2017 12:51:40 AM GMT David Conrad wrote:
> Paul,
> 
> On Apr 6, 2017, 2:24 PM -1000, Paul Vixie <[e-mail]>, wrote:
> > the proviso is, RFC 7706 is also completely unsuitable for non-hardcore or
> > non-experienced or non-protocol-geeks;
> ... This strikes me as a bit more complicated than 7706. YMMV.

yes, it does.

> > and both approaches are appropriate only for closed internal networks
> > where the configuration is controlled by a single administration.
> If I set up an open resolver using 7706, what negative repercussions do you
> see?

you'll need some name server features that aren't otherwise standardized, and maybe a 
patch or two. in my preferred approach, you just load a zone, because all of the special 
logic is outside of the name server and its configuration.

> > the misstatement is, dnssec's purpose is not defeated, because iana's
> > signatures are checked before the zone is accepted, and new signatures
> > are added using local keys before publication.
> Meaningless given you are explicitly editing the zone as published from and
> signed by the authority.

i hear you say meaningless, but i know that you know the difference between a name 
space and a zone that implements that namespace, and i know you've read my 
explainations about the importance of that distinction. it's not meaningless.

> You claim you aren't modifying the namespace
> content (well, except for the root NSes), ...

what is namespace content? i know namespaces, and i know zone content.

> but the point of DNSSEC and the
> rather Byzantine structures we've built around establishing trust is that
> we don't have to believe you: you can see _everything_ having to do with
> creating the trust anchor and everything down to the leaf.

that point is not lost. dig +trace +dnssec works as expected. transitive trust is a real thing: 
if i trust where i got the data, because i verified the signatures, and i trust my own keys 
and signatures, then trading one set of trust anchors and signatures for another lost me 
no root-to-leaf trust, in the eyes of my target audience, who is in the case of my laptop, 
me.

> The only advantage(?) I see in your approach is that is allows (forces) you
> to play around with the namespace and re-sign.

it plays around with the zone content. not the namespace.

> Might be useful for neo maxi
> zoom DNSSEC nerd experimentation, however as mentioned previously, that
> doesn't strike me as something one might recommend lightheartedly.

note that since many enterprise networks do augment the iana namespace for internal 
use (creating problems like .home and .corp collisions), there is often a loss of dnssec 
integrity. my approach is one way to retain dnssec integrity in that situation, and has not 
been recommended lightheartedly.

> > for my many-vm's laptop environment, running on a loopback isn't a
> > solution.
> I strongly suspect you could come up with a solution that didn't use
> loopback but which also didn't require modifying the root zone, resigning
> it, and getting all relying devices to use both your NS hints and trust
> anchor. Like, perhaps running on a non-loopback address within your flock
> of laptop VMs?

i do run on a non-loopback address within my vm-local network. but unless i pirate the 
addresses of all the real root name servers (which i won't do), or re-sign the iana content 
with a local NS RRset and trust anchoe (which i am doing), then cache priming is going to 
cause my hints to be ignored by the other rdns servers local to me.

note that very few people will ever run multiple rdns servers inside a laptop. i am not 
suggesting that my use case is or will ever be common. but it works.

at a slightly broader scale, for instance my home network, it would also work. however, i'm 
using the yeti system here, so i can't experiment separately.

at enterprise scale, or metro or region or national scale, it would also work.

as you know i've suggested for some time now that iana build and sign a second root 
zone, having the same name space (which is regulated by icann and ietf) but having a 
different apex NS RRset (which i think can be regulated differently.) iana is in a perfect 
position to sign its zone using NS RR's and associated AAAA RR's that lead to addresses i 
*would* be willing to pirate. this is also called "the AS112 unowned anycast approach".

if i could slave an iana-signed zone on my laptop that already had pirateable IP addresses 
reached by hints and the apex NS RRset, i would not need Perl to do what i'm doing. and i 
would be using the iana trust anchor. and it would be a configuration that i would 
recommend for all internet users.

sadly, a lot of people saying that "the namespace and the zone are the same thing" has 
kept that door pretty well closed. so, here i am with Perl instead.

> > http://www.circleid.com/posts/20160330_let_me_make_yeti_dns_perfectly_clear/
> Saw that a year ago and still think it post-hoc rationalization and
> specious, but I'm sure that's just me.

i am also sure that it's just you, because those principles were documented by the yeti 
project before it served its first request.

vixie