t 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 misunderstand 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 w
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 prefe
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
long compared to network delays even in 2
from the
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
only place I think 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 th
or in response to any signaling?--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
work with future RPZ installations
with real "give me both" signaling, old RPZ installations, and covert
DNS liars. Even if a future version of RPZ has real "give me both"
signaling, you will always need and will reach first for dual digs.
The SOA added by RPZ to the additional
. 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
https://www.ietf.org/mailman/listinfo
gnore 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, the default
BREAK-DNSSEC value is "no" so that
d 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
Ps and 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
ection 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
ers will
send ANY requests to authorities?
Vernon Schryverv...@rhyolite.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
se would be quite complicated and error
> prone in addition to the performance overhead described in the 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 deploy
eparate daemon that acts like a slave master for
policy zones using AXFR/IXFR/NOTIFY. However, I stopped maintaining
and deleted the patches for version 1.5.4 through 1.5.8 long ago.
Another caveat is that the work was for hire and so the daemon and its
interface .so are not open. The patches to
rs are
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 see
on 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
be covered by 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
ase 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
tend 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
installed base.
Words that convey that intended meaning would be appreciated.
Vernon Schryverv...@rhyolite.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ld 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 mailing list
DNSOP@ietf.
NS 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...@rhyolite.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
> From: Paul Wouters
> 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 could look up the reaso
chain for 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 poss
s 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 includ
ransfer" 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 prompt
that mistaken notion.
Vernon Schryve
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
ficant 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 welc
30 matches
Mail list logo
