Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Petr Špaček
@pspacek
But certainly we need to think about hints/policy interactions in more depth.
(Even though I would prefer to avoid this use of hints altogether. After all, it is functionality from authoritative server!)
Vladimír Čunát
@vcunat
Yes, I meant that as two orthogonal things. Currently RFC 6761 domains and some others are handled by generic policy.DENY.
That could be generalized similarly to policy.DENY('explanation')
Petr Špaček
@pspacek
Yes, that's what I'm thinking about right now :-)
dvdfabian
@dvdfabian
perfect, with the policy added, everything works as expected
Petr Špaček
@pspacek
@JakubOnderka Finally https://hub.docker.com/r/cznic/knot-resolver/ is up to date, including detailed description how to use it.
I would like to hear your opinion on this, please let me know!
Honza Mikulasek
@mikulasek_twitter
Hello. Do you know how to get source IP of a DNS packet inside a knot resolver module? kn_context context->request->qsource.addr seems invalid.
Vladimír Čunát
@vcunat
Yes, for some requests it's NULL.
That's for those that are originated inside knot-resolver.
For others it should be a pointer to valid sockaddr.
Honza Mikulasek
@mikulasek_twitter
Ah, makes sense. I didn't check for NULL, Now it works, Vlada, thanks for quick help.
Vladimír Čunát
@vcunat
@mikulasek_twitter you're welcome. I now added a comment to the struct field, so that its meaning is clearer.
We have worse descriptions that I would like, in some places.
Jörg Thalheim
@Mic92
@vcunat do you also have some nix snippet for the server side?
https://github.com/NixOS/nixpkgs/issues/33540#issuecomment-363104193
Vladimír Čunát
@vcunat
@Mic92: for server-side TLS on NixOS we'll have to extend the service config, so that the socket is passed from systemd (with FileDescriptorName=tls). I'll do that within a few days.
Vladimír Čunát
@vcunat
@Mic92 NixOS/nixpkgs#34905
Jörg Thalheim
@Mic92
@vcunat is tls-over-dns also vulnerable to dns amplification attacks?
Vladimír Čunát
@vcunat
I don't expect there's a real vulnerability. Even for plain TCP I don't think there's a way to redirect answers to someone else.
If there was, I'd rather attack http(s), as the amplification ratio there is orders of magnitude higher, and usually the cost to generate answers is also higher :-)
Jörg Thalheim
@Mic92
@vcunat OK. When I was young and naive I had a public DNS server running - until the hoster disconnected it from the internet. I thought about running a public DNS-over-tls server again, without marketing though. If dns-over-tls would have suffered from the same problems as plain dns, I would have looked into adding client certificates.
the gnutls interface looks much saner then the openssl one.
Vladimír Čunát
@vcunat
Running public recursive servers, well... People wanting to attack authoritative servers can start sending queries to all public resolvers - that unavoidably results in high load on the authoritatives. One might also do the same without public resolvers, e.g. via botnets or misusing advertisement platforms, but if most resolvers were public, it would be easier.
Jörg Thalheim
@Mic92
@vcunat so everybody should just use 9.9.9.9 instead?
Vladimír Čunát
@vcunat
Speaking of this, there a few other public TLS services but probably none comparably big. https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers
I'm certainly no expert on this, but I think public resolvers that are carefully monitored pose smaller risks. (assuming attacks are actively mitigated in some ways)
Jörg Thalheim
@Mic92
@vcunat I don't mind if my instance is not so public. I was just looking into how this could be achieved.
Vladimír Čunát
@vcunat
Knot-resolver can't filter based on client certificates. It can do so based on IP address (hard to spoof for TCP/TLS, I think).
Jörg Thalheim
@Mic92
@vcunat but should be easy to add, right? https://www.gnutls.org/manual/html_node/Client-Authentication.html
Vladimír Čunát
@vcunat
Yes, I expect so.
Vladimír Čunát
@vcunat
Related to this, Unbound has some *ratelimit* options (experimental?), which could limit at least some kinds of attacks.
Jörg Thalheim
@Mic92
or dnsdist
Vladimír Čunát
@vcunat
That's what Quad9 uses, reportedly.
Jörg Thalheim
@Mic92
@vcunat do you know, why knot decided to pin certificates instead of public keys? Public keys could remain stable, while certificates are updated
Vladimír Čunát
@vcunat
@Mic92: I perhaps don't understand. Knot-resolver supports both pinning and certificates.
(Or is this about knot-dns?)
Jörg Thalheim
@Mic92
@vcunat It does? Then I have not seen this.
Vladimír Čunát
@vcunat
e.g. { '2620:fe::fe', hostname = 'dns.quad9.net', ca_file = '/etc/ssl/certs/ca-bundle.crt' }
Jörg Thalheim
@Mic92
@vcunat right, this is about pinning the ca. There is also pin_sha256 - I assume this is the certificate pin. I tried to compute the sha256 of the public key. echo | openssl s_client -connect '9.9.9.9:853' 2>/dev/null | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
Vladimír Čunát
@vcunat
I'm myself not sure how the pin should be computed, but it's some standard thing.
Note that Quad9 have not announced a SPKI pinset.
Base 64 encoded form of SPKI pin(s) for TLS authentication (RFC7858)
Jörg Thalheim
@Mic92
On the long run I want to have my own server, shared with some other folks. But it would be good to have a working example, people can use, in the nixos example section
I tried pinning 9.9.9.9 to the letsencrypt root ca, but apparently I am missing something.
just using https://letsencrypt.org/certs/isrgrootx1.pem.txt is not enough
Jörg Thalheim
@Mic92
But at least knowing that pin_sha256 follows a standard, is helpful
Vladimír Čunát
@vcunat
Well, I had tested the above config with the bundle.
They use root x3