On Sep 21, 2014, at 11:14 AM, bert hubert <bert.hub...@netherlabs.nl> wrote:
> On Sun, Sep 21, 2014 at 08:13:46AM -0700, Paul Hoffman wrote: >>> PS: the above is currently not yet supported for DNSSEC domains! >> >> Can you say (much) more about that aside? Does it mean that the server >> will fail to load the zone if there is DNSSEC records and ALIAS >> pseudo-records? Or that the DNSSEC gets broken? Or that the ALIAS gets >> broken? Or... ? > > In the current branch, it will load the zone, but neglect to add signatures > for the proxied records. In other words, if you do DNSSEC, it will load the > zone but make you BOGUS. Far be it from me to tell you want to do with your UI, but that seems like a worse choice than refusing to load the zone and giving an error that indicates that the zone file is misconfigured. In specific, when the operator will discover that the zone is bogus because someone else tell them, they will stare at the zone file and see nothing wrong. > This is not a fundamental problem as long as we have keys. If you don't have > the keys, we can't sign any how. We'll add the signing code shortly, we just > haven't typed it in yet. I'm not sure what that paragraph means at all. > An interesting opening is that we'd be signing potentially unsigned data > this way. Potentially, we should check for the AD bit. But first let's see > how this idea fits. It is seeming to fit, so discussing the DNSSEC implications of it seems appropriate to do now. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
