Re: [DNSOP] search for reference

[Ólafur Guðmundsson]

Those numbers are not allocated they are just an artifact of bad design
from the 199x's

Olafur


On Fri, Dec 30, 2016 at 6:00 AM, A. Schulze  wrote:

> Hello,
>
> I'm searching for a reference (IANA?) that define the DNSSEC hash
> algorithm hmac-sha256
> has assigned the number 159
> ( see http://git.nlnetlabs.nl/ldns/tree/ldns/keys.h#86 )
>
> I only found https://www.iana.org/assignments/tsig-algorithm-names/tsig-
> algorithm-names.xhtml
> defining the /name/ but no /number/
>
> Thanks,
> Andreas
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

[Warren Kumari]

On Sat, Dec 31, 2016 at 7:06 PM Mukund Sivaraman  wrote:

> On Sat, Dec 31, 2016 at 11:32:02PM +, Warren Kumari wrote:
> > P.S / full-disclosure: I happen to use RPZ, and have for a number of
> years
> > -- I run a number of (personal) mailing lists on my own mailserver, and
> use
> > a number of RPZ feeds (e.g Spamhaus' DBL) for spam mitigation.
>
> Are you thinking of DNSBL instead of RPZ?
>

Nope.
This is an older page, but has more readable information:
https://www.spamhaus.org/news/article/669/spamhaus-dbl-as-a-response-policy-zone-rpz
More info:
https://www.spamhaustech.com/protecting-networks/security-solutions/dns-rpz/rpz-zone-transfer/


root@vimes:/etc/namedb/rpz# wc -l ~/tmp/rpz.spamhaus.org.text
3316563 /home/wkumari/tmp/rpz.spamhaus.org.text

This contains things like:
smalbany.academy.rpz.spamhaus.org.300 IN CNAME  .
*.smalbany.academy.rpz.spamhaus.org.  300 IN CNAME  .

My named.conf contains:
   response-policy {
   # Rewrite all responses to blackhole.ne-where.com, which is 127.0.0.2
   zone "rpz.spamhaus.org" policy CNAME blackhole.ne-where.com;
  };

and then I have a postfix access file:
root@vimes:/etc/postfix# more access
# REMEMBER: Run  postmap hash:/etc/postfix/access to rebuild this.
#
# THIS FILE MANAGED BY PUPPET!

192.0.2.1   REJECT This domain is listed in an RPZ zone.
127.0.0.200   REJECT This domain is listed in an RPZ zone.


(yup, the comments are wrong...)
This has been working nicely for me with (so far) no false positives.
Because I have the RPZ zone locally I'm not leaking private info by doing
DBL lookups, it is nice and fast, etc...
It cut down on my sysadmin work drastically, and I ended up disabling
spamassassin because it wasn't needed any more...

W


>
> Mukund
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

[Mukund Sivaraman]

On Sat, Dec 31, 2016 at 11:32:02PM +, Warren Kumari wrote:
> P.S / full-disclosure: I happen to use RPZ, and have for a number of years
> -- I run a number of (personal) mailing lists on my own mailserver, and use
> a number of RPZ feeds (e.g Spamhaus' DBL) for spam mitigation.

Are you thinking of DNSBL instead of RPZ?

Mukund


signature.asc
Description: PGP signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

[Warren Kumari]

On Sat, Dec 31, 2016 at 5:00 PM Ted Lemon  wrote:

> On Dec 31, 2016, at 3:27 PM, Viktor Dukhovni 
> wrote:
>
> why is there a need to make it easier for outside forces
> to pressure providers to use such mechanisms to exert control over
> their users rather than protect them from harm?
>
>
> There is no _way_ to make it easier for said outside forces to pressure
> providers.   They have the force of law on their side.   What we do makes
> no difference in that arena.   The arena in which it _does_ make a
> difference is protecting people from losing their homes because they got
> suckered by some malware that got into their personal records on their
> computer.
>

Another arena in which we have some control is how well implemented and
interoperable the feature is -- if we document RPZ properly then,
regardless of why it is being deployed, at least it will behave
deterministically across implementations.

RPZ is already implemented in nameserver software -- if the feature exists,
I'd like it to work the same wherever it gets uses, and not cause
collateral damage...

W
P.S / full-disclosure: I happen to use RPZ, and have for a number of years
-- I run a number of (personal) mailing lists on my own mailserver, and use
a number of RPZ feeds (e.g Spamhaus' DBL) for spam mitigation.


>
> IOW, the argument you are presenting has nothing to do with the choice
> that faces us.   If you want to make the case for rpz being a bad thing,
> the argument you should be making would have to show why protecting people
> in this way is the wrong solution to the problem, and why some other
> solution to the problem (e.g., a blacklist in the browser) is less bad.
>
> Can’t we have that conversation, instead of these repeated assertions
> about things over which we have no control?
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

[Ted Lemon]

On Dec 31, 2016, at 3:27 PM, Viktor Dukhovni  wrote:
> why is there a need to make it easier for outside forces
> to pressure providers to use such mechanisms to exert control over
> their users rather than protect them from harm?

There is no _way_ to make it easier for said outside forces to pressure 
providers.   They have the force of law on their side.   What we do makes no 
difference in that arena.   The arena in which it _does_ make a difference is 
protecting people from losing their homes because they got suckered by some 
malware that got into their personal records on their computer.

IOW, the argument you are presenting has nothing to do with the choice that 
faces us.   If you want to make the case for rpz being a bad thing, the 
argument you should be making would have to show why protecting people in this 
way is the wrong solution to the problem, and why some other solution to the 
problem (e.g., a blacklist in the browser) is less bad.

Can’t we have that conversation, instead of these repeated assertions about 
things over which we have no control?

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

[Viktor Dukhovni]

On Thu, Dec 29, 2016 at 05:45:59AM -, John Levine wrote:

> >I'm seeing how it really helps governments cheaply create and enforce
> >the creation of national internets -- especially with the walled garden
> >features.  Are those the good guys to you, or are there other benefits?
> 
> Please see the previous gazillion messages from people who are using
> RPZ in production to keep malware away from their users.
> 
> Also see the previous gazillion messages noting that governments do
> all sorts of DNS censorship now and don't need RPZ.
> 
> Could you explain in more detail why you don't believe operators will
> continue to use RPZ to protect their users, and why you think hostile
> actors will do things with RPZ that they couldn't do now?

If providers have been, are now, and are going to keep using
mechanisms like RPZ, for their own internal reasons, sans any
"standard", why is there a need to make it easier for outside forces
to pressure providers to use such mechanisms to exert control over
their users rather than protect them from harm?

This technology is not ethically neutral, and some care is I think
appropriate to avoid harms.  It is I think prudent to broaden the
analysis beyond "Once the rockets are up, who cares where they come
down? ..."[1]

Though the irony does not escape me; let a hundred flowers bloom...

-- 
Viktor.

[1] http://www.songtexte.com/songtext/tom-lehrer/wernher-von-braun-3c72d1f.html

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] search for reference

[Dick Franks]

If you generate keys using the dnssec-keygen that comes with BIND, then
ISC's arbitrary numbers are exposed as follows:

HMAC-MD5157a.k.a.  HMAC-MD5.SIG-ALG.REG.INT
HMAC-SHA1   161
HMAC-SHA224   162
HMAC-SHA256   163
HMAC-SHA384   164
HMAC-SHA512   165


Dick Franks



On 30 December 2016 at 11:20, A. Schulze  wrote:

>
> Mukund Sivaraman:
>
> TSIG uses DNS names for encoding the algorithm type.
>>
> I didn't expected that...
>
>
> Thanks!
>
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop