subset of the
other. They simply differ.
Again, the Knot mechanism might be better than RPZ, especially if it
were given a few of what seem to me like easy additions. RPZ has
suffered from feaping creaturism; something simpler could be better.
But please don't call it RPZ, because it is
d me as saying no one else can or should
write real RPZ code. Many people could and I really wish they
would. That's why I spent a lot effort outside my comfort zone on
the I-D. What bugs me are implementations of so called RPZ and RRL
that share only the acronyms with the BIND stuff.
Vernon
as opposed to modified source in a 'contrib' directory that
users must compile specially, I'd be happy to try to propose such
hooks. In other words, I could try to make a patch for Knot Resolver
like the patch that I wrote for Unbound (without cost to NLnet Labs).
If you prefer, you could write the c
ection 5.5 of RFC 6555 seem to differ. They are at
least as much about what humans notice ("humn factors" in RFC 6555)
as network delays; 150-250 ms is about the threshold for what people
consider "sluggish." 150-250 ms also is vastly longer than 10 ms., and
resolver that lacks a (signed) AD=1.
Note that RPZ lies are distinguished by the following and only the 3rd is
dispositive:
- no RRSIG rrsets
- AD=0
- that bogus additional section SOA
Vernon Schryverv...@rhyolite.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
hink RPZ belongs, which
is in a verifying resolver that you trust to do only the RPZ lying
that you want (and so where you don't need that red light except when
debugging). All other uses of RPZ should be considered attacks on
your security and privacy. (I think that's a short form of the agreed
wo
naling?--of course
not!
We're seeing something like this happen with the European demands that
the "rights to be forgotten" apply accross borders.
Vernon Schryverv...@rhyolite.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ional section is perfectly sufficient
to signal the honest presence of an RPZ lie.
Vernon Schryverv...@rhyolite.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
odules for sendmail and postfix. Nevertheless,
it died because it came late, was only a modest improvement, and required
operators to do something more than they were doing.
Vernon Schryverv...@rhyolite.com
___
DNSOP mailing list
DNSOP@ietf.org
should ignore DNSSEC request bits despite the fast
that RPZ invalidates and removes signatures and so verifying stubbs
and verifying downstream resolvers will not accept rewritten answers."
Also, in the two RPZ implementations I've written, t
problem that the BULK RR
would solve?
I agree that a statement of the problems solved by the BULK RR would
be good.
Vernon Schryverv...@rhyolite.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
d anothers running open or large scale DNS resolvers
should be encouraged to provide resolvers without RPZ if they provide
resolvers with RPZ. Because there are plenty of DNS resolver operators
(not to mention policy zone vendors) who charge for their special
policy zone recipes, this does not sound
unspecified RRSIGs to the authority section of RPZ modified DNS
responses is not something that should be without extended discussions,
plenty of real world testing, and more time than has been spent on the
QTYPE=ANY protosal.
Vernon Schryverv...@rhyolite.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ecursive servers will
send ANY requests to authorities?
Vernon Schryverv...@rhyolite.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
he draft
> text, and, in fact, the support for these triggers certainly makes
> the BIND 9's RPZ implementation even more unreadable. So, depending
> on the actual deployment status, we might want to make these
> triggers optional or even excluded from a spec aiming to be a base
&
n. The patches to Unbound are open and have
been offered to NLnet Labs.
Vernon Schryverv...@rhyolite.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
stubs that don't do validation but trust header bits saying that a
resolver operated by a third party did the validation. I think that's
wrong, evil, nasty, unethical, a Major Human Rights Issue, and blah
de blah de blah, but it's also something no one seems willing and able
to change.
Vernon
ction might be good and reasonable
] in another context, but they are irrelevant to a description of RPZ
] as it currently exists.
Vernon Schryverv...@rhyolite.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
y words in section 5 saying
implementations need not check RPZ triggers atomically with respect
to concurrent policy zone transfers?
Vernon Schryverv...@rhyolite.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
l ignore case when comparing with what comes off the wire.
Vernon Schryverv...@rhyolite.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
raft tries to pretend that
all of the rules in all of the policy zones are checked instantaneously,
and never mind real code or the delays forced by recursion. Words
about these issues are not BIND specific would probably be good, so
please suggest some.
Vernon Schryverv...@rhyolite.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
that document would not describe the protocol
and mechanisms at issue. If the mechanisms and protocol now described
in the draft are unacceptable, then no document that describes them
can be acceptable.
Vernon Schryverv...@rhyolite.com
___
DNSOP
ore than you can make DNS server operators forget the
creative use of local zone files or keep all of the millions of code
jockeys like me from writing messaging apps and evil DNS code. All
that you might do is to make encryption and RPZ less available for good.
Vernon Schryverv...@rhyolit
> From: Paul Wouters <p...@nohats.ca>
> So my message to the dnsop list which also was sent to Vernon Schryver
> just got bounced back to me. The Irony.
>
> Luckilly, there was a URL in there instead of just an RPZ policy number
> encoded in a serial number, so I
those domain names. One might hope that the
resolver applying the RPZ rule would receive a suitable RRSIG with
the rest of the policy zone.
But only in a future version of RPZ, and only a "MAY" or a "SHOULD",
and quite possibly not a
d to me.
Browsers and other interested applications would have to do more than
gethostbyname() or a modern equivalent to see those SOAs. But if
browsers ever do any DANE, they'll need to do more than gethostbyname().
(perhaps that "will include" should be "MUST include")
including
"allow-transfer" and "allow-recursion" are also not about keeping secrets.
> Sure, an admin isn't required to keep it secret, but it's absolutely
> built into the design.
If it matters, please point out the words in the draft that prom
om whom I don't want to
see more tend to have delicate and loud feelings, and so I use procmail
to blackhole their missives.
Vernon Schryverv...@rhyolite.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
iptions lacked significant details about
how a single effective policy rule is chosen among multiple hits and
about less common (but I think more effective) types of triggers
including NSIP and NSDNAME.
Comments on the 04 draft (other than marking it Top Secret) are wel
29 matches
Mail list logo
