Re: [dns-operations] DNSSEC and multiple signatures
--- Begin Message --- Eric Germann wrote on 2021-05-17 20:34: > I have a question regarding multiple signings. I’ve seen some domains > sign with multiple algorithms (8 and 13 specifically). > > How does a validating resolver choose which signature to use. First > available? Stronger crypto? Both have to be valid through the chain? > Random? The resolver attempts validation of all signatures (for which it has algorithm support) until it finds one that validates correctly. One valid signature suffices. Regards, Matt --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Authoritative name server replies NODATA for a non-existing domain
* Stephane Bortzmeyer [2015-04-22 16:16]: On Wed, Apr 22, 2015 at 03:12:24PM +0200, Stephane Bortzmeyer bortzme...@nic.fr wrote a message of 30 lines which said: IMHO, all the name servers should reply NXDOMAIN, no? Or could it be a minimum response, intended to prevent zone enumeration? It's not minimal, the hash range is very large (wraparound record from D9D... to VVV... and 000... to 4DL...), covering the hashes of the query name, wildcard name and closest encloser. d9dhvu2eiln97dgi23tkh43hq2uvh7uq.adult. 829 IN NSEC3 1 1 1 D399EAAB 4DLOEEUR1VQ4LQ6N7QUS62O2MAIUPGRM NS SOA RRSIG DNSKEY NSEC3PARAM I'd expect NXDOMAIN, too. Apart from an unusual rcode, the response looks valid. Does this qualify as a protocol violation? Regards, Matt smime.p7s Description: S/MIME Cryptographic Signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Atlas Probe - Result question hostname.bind = clboh-dns-cac-307
* Chris Baker [2014-02-07 17:27]: Hello Everyone, I have been running a collection of US Atlas probe CHAOS queries for the hostname.bind of our anycast announced nameserver IPs to get a sense for what is reaching what name server. One of the probes has an interesting response. *Probe ID :* 14064 *Firmware Version :* 4580 Hosted by Komodo Labs : Springsboro, Ohio The results I am getting from the CHAOS query for hostname.bind @ 208.78.70.34 is below hostname.bind. 0 CH TXT clboh-dns-cac-307 I was wondering if anyone else had experienced similar oddities and if they were traced back to a specific provider, device, … etc A few probes are behind a transparent DNS proxy. Whatever destination address you set, the query will go to a resolver in the local network. Regards, Matt -- Universität Duisburg-Essen Verteilte Systeme Bismarckstr. 90 / BC 316 47057 Duisburg smime.p7s Description: S/MIME Cryptographic Signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] It's begun...
* Peter Andreev [2013-11-05 18:55]: 2013/11/5 Matthäus Wander matthaeus.wan...@uni-due.de mailto:matthaeus.wan...@uni-due.de The operator of xn--80asehdb. and xn--80aswg. is using a custom-made name server according to their version.bind. Their version.bind looks REFUSED for me. AFAIK this is the default behaviour of all major nameserver implementations. So I'm not sure if they use modified BIND or completely selfmade server. Don't forget CH TXT: $ dig @anycast10.irondns.net. -c ch -t txt version.bind. +short ironDNS Name Server (1.3.6, nameserver-1.3, r2992) pr-206 Regards, Matt -- Universität Duisburg-Essen Verteilte Systeme Bismarckstr. 90 / BC 316 47057 Duisburg smime.p7s Description: S/MIME Cryptographic Signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
[dns-operations] Resolvers choosing low latency nameservers
Hi, are there any studies or anecdotal evidence about how recursive resolvers select a query destination from a set of authoritative servers with known RTTs, and how often they re-probe the slower ones? Specifically, how many queries in what period of time would it take until a BIND or Unbound has re-probed all auth ns of e.g. com? Regards, Matt -- Universität Duisburg-Essen Verteilte Systeme Bismarckstr. 90 / BC 316 47057 Duisburg smime.p7s Description: S/MIME Kryptografische Unterschrift ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Missing nameservers reported by parent
* fenghe [2013-05-21 04:16]: Hello, from: http://www.intodns.com/dns-oarc.net FAIL: The following nameservers are listed at your nameservers as nameservers for your domain, but are not listed at the parent nameservers (see RFC2181 5.4.1). You need to make sure that these nameservers are working.If they are not working ok, you may have problems! ns2.dns-oarc.net How about this warning? Compare: $ dig ns dns-oarc.net @g.gtld-servers.net [...] ;; AUTHORITY SECTION: dns-oarc.net. 172800 IN NS sns-pb.isc.org. dns-oarc.net. 172800 IN NS ns.dns-oarc.net. [...] With: $ dig ns dns-oarc.net @ns.dns-oarc.net [...] ;; ANSWER SECTION: dns-oarc.net. 3600IN NS ns2.dns-oarc.net. dns-oarc.net. 3600IN NS sns-pb.isc.org. dns-oarc.net. 3600IN NS ns.dns-oarc.net. [...] Regards, Matt -- Universität Duisburg-Essen Verteilte Systeme Bismarckstr. 90 / BC 316 47057 Duisburg smime.p7s Description: S/MIME Kryptografische Unterschrift ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] bind-9.9.3rc2 ANY+TCP patch
* Vernon Schryver [2013-05-15 21:40]:
From: Jared Mauch ja...@puck.nether.net
This is a crude but effective hack. It doesn't stop the system from
recursing to find the response.
I can understand simplistic DNS reflection mitigation in firewalls,
especially when response rate limiting is not available in the DNS
server implementation or when local policies forbid the use of patches.
I don't understand why would one use a patch like that with its
limitations and drawbacks (e.g. usable only on recent versions of
BIND9, affects only ANY, affects all ANY, doesn't limit the flood of
reflected truncated responses during attacks, no whitelisting for local
clients, not view-specific) instead of the full blown RRL patch for
9.9.3rc2, 9.9.2, 9.9.2-P1, 9.9.2-P2, 9.8.4-P2, 9.8.4-P1, or 9.8.5rc2.
By the way, why use qtype == 255 instead of qtype == dns_rdatatype_any ?
Why #define TCP_CLIENT() and use the macro exactly once instead
something like
if (qtype == dns_rdatatype_any
(client-attributes NS_CLIENTATTR_TCP) != 0) {
If TCP_CLIENT() is used in query.c, then its definition should be moved
from client.c to bin/named/include/named/client.h and the several uses
of client-attributes NS_CLIENTATTR_TCP in query.c replaced with
TCP_CLIENT(). It's bad form to define macros (or much of anything)
more than once, because you can be sure that eventually the definitions
will differ.
I think the keyword here is hack. I wouldn't invest too much time in
an analysis.
Regards,
Matt
--
Universität Duisburg-Essen
Verteilte Systeme
Bismarckstr. 90 / BC 316
47057 Duisburg
smime.p7s
Description: S/MIME Kryptografische Unterschrift
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS 9.9.2 open socket error
* Ayca Taskin (Garanti Teknoloji) [2013-05-06 13:25]: We have a DNS server bind 9.9.2 on Solaris Generic_147441-24 running on VM. We got errors from DNS server that cannot resolve some domain names. When we checked the logs, the error like this 06-May-2013 13:45:25.566 dispatch: warning: dispatch dd91e50: open_socket(0.0.0.0#2049) - permission denied: continuing 06-May-2013 13:51:41.421 dispatch: warning: dispatch 1efc7e90: open_socket(0.0.0.0#4045) - permission denied: continuing Is this error cause our resolving problem? Probably not the cause of your problem, BIND will continue with another port. Note that there is a BIND users mailing list which might be helpful: https://lists.isc.org/mailman/listinfo/bind-users And here's how to fix the above warning: https://lists.isc.org/pipermail/bind-users/2011-October/085498.html Regards, Matt -- Universität Duisburg-Essen Verteilte Systeme Bismarckstr. 90 / BC 316 47057 Duisburg smime.p7s Description: S/MIME Kryptografische Unterschrift ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Another whitepaper on DDOS
* David Conrad [2013-02-22 16:18]: Has there been any documented attack that would have been prevented by DNSSEC that one can point to? This paper describes a censorship attack which could be mitigated by DNSSEC: http://conferences.sigcomm.org/sigcomm/2012/paper/ccr-paper266.pdf Regards, Matt -- Universität Duisburg-Essen Verteilte Systeme Bismarckstr. 90 / BC 316 47057 Duisburg smime.p7s Description: S/MIME Kryptografische Unterschrift ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] 10% was Re: .mm ....
* Joe Abley [2013-01-19 03:31]: I'll assume (since I didn't see the original mail) that the proposal is to make validators tolerant by 10%, rather than to change anything on the authority server or on the signers. (If you want to extend the validity of a signature by 10% when you sign the zone you can already do that just by changing the parameters used by your signer.) If the idea is I'll tolerate an expired signature for 10% of the original validity period (I didn't see the original mail) then you're just trading a failure today for a failure today + T. I don't think there's much practical difference between those outcomes. I don't see the point of the change. If the idea is I'll tolerate an expired signature for 10% of the original validity period and use that extra time to shout loudly about the fact that there is a failure then I'd suggest just setting your monitoring systems to start the loud klaxons when you only have 10% validity remaining, and avoid the change too. I think it's more like I'll tolerate an expired signature for 10% of the original validity period and use that extra time to let other people notice and fix it. Assuming that 1) the majority of validators do *not* tolerate expired signatures and 2) most DNSSEC failures are fixed within that 10%, it is a way to trade off reliability vs. security. In this specific case it didn't really work out: $ dig dnskey mm @unbound.odvr.dns-oarc.net [...] ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 11736 [...] I don't see much good, here. I think the main things that are missing from the world are: - a pragmatic approach to setting signature validity periods in signers, mindful of operational considerations - people monitoring their own zones and getting early warnings when signer policy appears not to be reflected in the DNS Sure. But keep in mind that's not under control of the resolver operators. It's not cool to be one of the few resolvers suffering from DNSSEC configuration errors that other people caused, while all the non-validating resolvers seem to work fine. The security benefit is hardly noticed by users outside of the DNS community as long as applications are not showing green DNSSEC icons or other gizmos. Regards, Matt -- Universität Duisburg-Essen Verteilte Systeme Bismarckstr. 90 / BC 316 47057 Duisburg smime.p7s Description: S/MIME Cryptographic Signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
* bert hubert [2012-09-28 09:44]: Hmmm for authoritative servers, we might also emit a CNAME challenge. This would be a needless and semantically null transition, but only a bona fide resolver will come back to follow the CNAME trail. This allows us to test for two-way communications without using truncated packets or TCP. We could encode the encrypt the correct destination in the CNAME, for A and this is trivial. If you come back to resolve encoded-12.32.43.43.attackeddomain.com, you get 12.32.43.43 etc. For extra resilience encrypt it. There has been recently a patent granted with this method: http://www.freepatentsonline.com/8261351.html Though they don't use it do decide about blocking, but use the CNAME challenge on every query, still providing a small amplification. This comes at the risk of running into resolver issues with NS or MX records... Regards, Matt -- Universität Duisburg-Essen Verteilte Systeme Bismarckstr. 90 / BC 316 47057 Duisburg smime.p7s Description: S/MIME Kryptografische Unterschrift ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Research Project: Identifying DNSSEC Validators
Hi, Am 06.09.2012 21:54, schrieb Vernon Schryver: From: Ralf Weber ralf.we...@nominum.com The protocol doesn't mandate a resolver to retry, ... Which protocol is that? I'm not disagreeing since the claim matches my intuition, but only asking for an RFC number (or numbers) so that I can understand the exegesis. RFC 4035 Section 5 explains how to validate signatures and what to do it that fails (5.5). It says nothing about doing or not doing retries. BIND and Unbound retry a couple of times and scatter the queries among all authoritative NS. How is javascript involved? That sounds like a pair of ordinary IMG beacons. If javascript is involved, do you figure that browsers with javascript controlled manually or automatically (e.g. with NoScript) are insignificant or that the resolvers of users that do such things should not be counted? JavaScript is only needed if you want to show the result to the user. For statistics the img tags suffice, no JS involved. I assume I'm odd, because I'm not eagar to put the invisible HREF anchor on my web pages because of the extra DNS transactions imposed on users. I also have vague worries I can't articulate about privacy concerns. My answer to putting a simple IMG beacon on my web pages would be a flat never. There are too many technical and legal issues. For example, what about privacy issues with the referer string? I'd have trouble responding politely to a request that I add javascript to my web pages. I don't think I'm religiously opposed to javascript, since I'm taking a break from fighting some javascript bugs to write this. It's just simple security and operational prudence to never code that is not strictly necessary. Can't argue with that. If privacy is an issue, you won't become friends with foreign HTTP resources. Kind regards, Matt -- Universität Duisburg-Essen Fachgebiet Verteilte Systeme Bismarckstr. 90 / BC 316 47057 Duisburg Tel: +49 203 379 2767 smime.p7s Description: S/MIME Kryptografische Unterschrift ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Research Project: Identifying DNSSEC Validators
Hi, Am 04.09.2012 22:57, schrieb Wessels, Duane: Within Verisign Labs we have a project underway to quantify the number of DNSSEC-validating resolvers in use on the Internet. In particular, we want to identify recursive name servers which have configured the root zone trust anchor. We find this data a useful metric for DNSSEC adoption and especially helpful for informing discussions about key rollovers for the root zone. My research group has a similar project that you may be interested in. We run a DNSSEC validation test with user feedback at http://dnssec.vs.uni-due.de (for fun) and a hidden test in some websites (for research). We gathered 69k results from 54k distinct IP addresses since May this year. The validation ratio was 4.4% which is close to the 3.25% of the current VeriSign 'prefetch' results. Our results vary significantly by country, US is ~13% (Comcast...), some European countries up to 4% and the others are basically zero (this might be inaccurate, the majority of our results are from DE and US). In order for our our measurements to be meaningful, we need to receive queries from a wide variety of recursive name servers. To achieve this goal we ask members of the DNS and networking communities to assist by adding the following single line of HTML code to your web pages: a href=http://prefetch.validatorsearch.verisignlabs.com;/a This HTML snippet should have no visible impact on a rendered page. Since nearly all web browsers now implement DNS prefetching, the code above results in a DNS query for the name shown and allows us to characterize the recursive name server that the query goes through. Our test methodology is to load 1px images from two domain names, one correctly signed and the other one with a broken signature. Please note that we are not interested in identifying individual users who have loaded the web page. The name above points to the localhost IP address (127.0.0.1) so even if someone does manage to click on it, that request does not reach us. Definitely an advantage over our test as we generate more traffic and log HTTP requests. For some preliminary results, please visit the project web page at http://validatorsearch.verisignlabs.com/ Here's some more information about our measurements: http://www.vs.uni-due.de/personal/wander/20120821_DNSSEC_Validation/ I'm right now putting all results together in a paper for PAM2013 (submission is next week). Kind regards, Matt -- Universität Duisburg-Essen Fachgebiet Verteilte Systeme Bismarckstr. 90 / BC 316 47057 Duisburg Tel: +49 203 379 2767 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] A lot of CNAME queries for domain ?
Hi, Am 05.07.2012 20:22, schrieb Mohamed Lrhazi: Looking at it further, it does seem like the source IPs of these queries are actually fake... as most seem to be consecutive IPs, like such: 74.125.126.86 74.125.126.85 74.125.126.84 74.125.126.83 ... That's Google public DNS. Here's a full list of their source IP ranges: https://developers.google.com/speed/public-dns/faq#locations They claim however to rate-limit their queries to nameservers: https://developers.google.com/speed/public-dns/docs/security#rate_limit Kind regards, Matt smime.p7s Description: S/MIME Kryptografische Unterschrift ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
