Re: [dns-operations] Lot's of TXT queries from Google
Hi, just guessing maybe its related to https://developers.google.com/speed/public-dns/docs/security?hl=en#nonce_prefixes cheers, -arsen * Moritz Müller [2021-10-07 13:50 (+0200)]: Hi, For the second time in a few weeks we noticed a significant increase in queries for NS and TXT records at our .nl name servers, originating almost exclusively from the Public DNS resolvers of Google Did someone else noticed something similar or has an explanation? In comparison to beginning of September, the number of NS queries increased 2 fold and the number of TXT queries almost 6 fold. At some point, 25% of all queries to our name servers for .nl where for TXT record. The resolvers query either for a domain name following the pattern _dmarc.foo.nl or default._domainkey.foo.nl. Where foo is a random string, 12 characters long. Examples are: _dmarc.mdvlxtagogij.nl. default._domainkey.vppj4svmbclt.nl. The queried second level domain names are not registered and queries for the same domain name are repeated 3 to 5 times. At some point, 80% of all TXT queries from google had these patterns, 36% of all queries from Google resolvers. The queries started ramping up around 2021-09-05 and reached their peak at 2021-09-18. They never reached a concerning level, but we first noticed them because our machine processing the incoming PCAP files couldn’t cope anymore. We assume that this is likely not an attack but some tests/measurements, which got a bit out of hand. But since we don’t see the origin of the queries behind the Google resolvers, we’re not sure to whom to reach out. — Moritz — SIDN | Meander 501 | 6825 MD | Postbus 5022 | 6802 EA | ARNHEM T +31 (0)26 352 55 00 moritz.mul...@sidn.nl | www.sidn.nl pgp key: https://pgp.mit.edu/pks/lookup?op=get=0x0AF8922B1659B448 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] validating zones before distribution to secondaries
* A. Schulze [2021-05-04 23:32 (+0200)]: Am 04.05.21 um 20:53 schrieb Phil Regnauld: On the validation side, take a look at: https://github.com/tobez/validns validns seem to be unmaintained. Build fail with current openssl :/ https://github.com/DENICeG/validns Is a fork of validns and should work :) cheers, arsen ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] check DNSSEC RRSIG expiry (anybody awake over at comcast.net?)
* Viktor Dukhovni [2021-02-09 13:19 (-0500)]:
My Perl script (below) just checks that none of the RRSIGs are expiring
too soon. If some RRset is not signed at all, that's not detected
presently, but should be easy to add.
named-compilezone -i local -jD -f raw -o - $zone $db 2>/dev/null |
perl -MPOSIX -lane '
BEGIN {
@nsec = () # NSEC signed zones, rest assumed NSEC3
($domain, $maxdays) = splice(@ARGV, 0, 2);
$now = time();
# Expect at least DNSKEY and NS RRsets
for (qw(DNSKEY NS)) { $want->{"IN"}->{$_}->{$domain} = 1; }
if (!grep { $domain eq "$_" } @nsec) {
# Expect NSEC3PARAM in non-NSEC zones
for (qw(MX NSEC3PARAM)) { $want->{"IN"}->{$_}->{$domain} =
1; }
}
}
($owner, $ttl, $class, $rrtype, @rdata) = @F;
next if $rrtype ne "RRSIG";
($sigtype, $alg, $labels, $maxtll, $expiration, $inception) = @rdata;
$expiration =~ m{^(\d\d\d\d)(\d\d)(\d\d)(\d\d)(\d\d)(\d\d)$}
or die "Malformed expiration $owner $sigtype: $expiration\n";
$s = POSIX::mktime($6, $5, $4, $3, $2 - 1, $1 - 1900);
$d = ($s - $now) / 86400;
if ($d < $maxdays) {
warn sprintf("Signature of $owner $class $sigtype expires in %.2f
days\n", $d);
}
$owner =~ s/.\K\.$//;
delete $want->{$class}->{$sigtype}->{lc($owner)};
END {
while (($class, $vc) = each %$want) {
while (($rrtype, $vr) = each %$vc) {
while (($domain, $dummy) = each %$vr) {
warn "No signature found for $domain $class
$rrtype\n"
}
}
}
}
' "$zone" "$maxdays"
That said, if "dnssec-verify" had a parameter to set a minimum remaining
signature time, I wouldn't need the Perl script.
Your script is really nice.
ldns-verify-zone and kzonecheck have both a time option.
cheers,
-arsen
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] dnspooq
Hi Frank, you could use dig! If you ask dnsmasq for the version string: dig @ip-of-your-network version.bind ch txt +short cheers -arsen * Frank Bulk [2021-02-01 10:29 (-0600)]: Is there a tool that would allow me to identify all the DNS servers on our networks that are using dnsmasq? Frank -Original Message- From: dns-operations On Behalf Of Roy Arends Sent: Tuesday, January 19, 2021 9:53 AM To: dns-operati...@dns-oarc.net Subject: [dns-operations] dnspooq fyi https://www.jsof-tech.com/disclosures/dnspooq/ ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNSViz please support DNSSEC algorithm Ed25519 (15)
Hi Matt, * Matthew Pounsett [2021-01-19 14:59 (-0500)]: On Dec 30, 2020, at 06:42, Arsen STASIC wrote: Dear DNS-OARC, Could you please support DNSSEC algorithm Ed25519 (15)? I think Casey Deccio has already added support for Ed25519. [0] Hi Arsen. First, it’s generally better to address mail to OARC to an OARC address — we usually point people toward ad...@dns-oarc.net for general support issues. There’s also a feedback link on the DNSViz site itself (“Questions and Comments”) which gets prompt replies. While we watch the public lists, it’s not really an official support forum. :)I’m still a bit backed up on mailing lists after the holiday break, which is why I’ve been a bit slow to find/reply to this. I wrote to the list because DNSViz was multiple times discussed on the list. I didn't head ad...@dns-oarc.net on my radar for this issue. I try to remember for the future :) The DNSViz code does support ED25519, but (as Casey explained) the problem on the site is the underlying OpenSSL library. That host is already on the list for a major overhaul, which would include an OS update, and I’m expecting to get to that within the next couple of weeks. I am really looking forward to this update. I an highly appreciate OARC's and Casey's effort for this really useful service! cheers -arsen ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNSViz please support DNSSEC algorithm Ed25519 (15)
Hi Jerry, * Jerry Lundström [2021-01-04 09:19 (+0100)]: On 2020-12-30 12:42, Arsen STASIC wrote: Could you please support DNSSEC algorithm Ed25519 (15)? I think Casey Deccio has already added support for Ed25519. [0] ^ [0] https://github.com/dnsviz/dnsviz/commit/375941d1f2c5cb3ad5ae76138cf9887971b611cf I think the code is ready (see [0]). Now it's on DNS-OARC to git pull and run it ;-) Thank you Casey Deccio for the code and DNS-OARC for hosting it! This is really a useful service. While we (DNS-OARC) host and operate the public instance of DNSViz, the code is still owned and managed by Casey Deccio so I'd suggest you create an issue on DNSViz's GitHub: <https://github.com/dnsviz/dnsviz/issues> cheers, -arsen ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] DNSViz please support DNSSEC algorithm Ed25519 (15)
Dear DNS-OARC, Could you please support DNSSEC algorithm Ed25519 (15)? I think Casey Deccio has already added support for Ed25519. [0] RFC 8624 lists Ed25519 as RECOMMENDED [1]. Verisign's dnssec-analyzer already supports DNSSEC algorithm Ed25519 (15) [2]. It would be really handy to have a second tool to check DNSSEC for correctness. cheers, -arsen [0] https://github.com/dnsviz/dnsviz/commit/375941d1f2c5cb3ad5ae76138cf9887971b611cf [1] https://tools.ietf.org/html/rfc8624#section-3.1 [2] https://dnssec-analyzer.verisignlabs.com/ ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] How widely implemented are different DNSSEC algorithms?
* John Levine [2020-09-11 14:29 (-0400)]: Are there any published numbers estimating how well the various DNSSEC algorithms are supported in DNS caches and client software? Or to put it another way, were I to switch from signing with algorithm 8 to 13, how much would I regret it? Geoff Huston from APNIC has some nice graphs on ECDSA support (also in comparison to RSA support) in recursive nameservers: https://stats.labs.apnic.net/ecdsa/AU https://stats.labs.apnic.net/ecdsa/US cheers, arsen ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNSViz Status?
Hi Casey, * Casey Deccio [2020-02-18 15:54 (-0700)]: On Feb 17, 2020, at 1:37 AM, Marco Davids (Private) via dns-operations wrote: Op 14-02-2020 om 16:09 schreef Vladimír Čunát: For me personally, the old historical data isn't much interesting. What I'm missing most is the feature of sending a link to a recent measurement (and keeping the data for, say, a week at least). Exactly! I really hope we can have that functionality back, someday soon. Hi Marco and all, Thanks for the valuable feedback. Matt and I were working just last week on getting a new database up and running, so "permalinks" can be used to save an analysis. We hope to have it done very soon! Thats great news! I really appreciate your effort. cheers -arsen ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] DNSViz Status?
Dear DNS-OARC, What is the status of DNSViz's historical data import job? cheers arsen ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] validation problem on 1.1.1.1
* Vicky Shrestha [2020-02-04 12:57 (-0800)]: Hi, We have identified the bug in a new version that was released to a subset of colos. We have rolled out a fix. how does it look now from your vantage point? It seems to be fixed from my vantage point. -arsen ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Check DNS-anycast-instances for same DNS Cookie
* Mark Andrews [2020-01-25 08:56 (+1100)]: On 24 Jan 2020, at 21:36, Arsen STASIC wrote: This software might be of interest for DNS anycast providers (or customers) which are running BIND. With BIND 9.11 and newer DNS Cookies are enabled **automatically**. You seem surprised? DNS COOKIE is a security feature and to be effective it needs to be enabled on both ends. DNS COOKIE was introduced in a .0 release. This is where feature changes are expected to occur. True. I'm in favour of security features and would appreciate if more vendors implement DNS Cookies in their software! I recently came across ISC's knowledge base article [0] and dived into it and I thought it might not be on all TLD operator's radar. I just wanted to raise awareness and therefore did this small project [1]. While I was searching for software to check DNS Cookies and I didn't find anything. So “dig +cookie=" was not enough? Thanks, I must have missed that! Therefore I wrote this small Perl script to check DNS anycast instances (over their mgmt-ip) for synchronized DNS Cookies: https://github.com/stasic/dns-cookies Which assumes that all the queries are made in the same second as server cookies vary over time. If you really want to test this you need to send the returned cookie option from the first response to all the other servers and check the rcode they return is not BADCOOKIE. Exercise the cookie checking code in the server. I know that cookies varies over time. I've tested it on a small 16-node anycast cluster and in my case I got the same cookie from all 16 nodes. But you are right on large anycast clusters cookies will vary over time due timing which could be addressed by sending asynchronous DNS queries. If DNS Cookies are not the same between different DNS anycast instances it may cause warnings and intermittent query retries. Therefore I suggest either synchronize them or disable them. This is very alarmist. DNS COOKIE secret key mismatches (includes algorithm mismatches) where expected to occur and DNS COOKIE clients are designed to handle them. Unsynchronised secrets/algorithms are safer for the client that disabled cookies. Additionally this really only becomes visible with local anycast clusters which don’t have source IP address affinity. With globally distributed anycast you tend to hit the same node. I just rephrased ISC's knowledge base article [0], which says: "Although the above scenario may cause warnings and intermittent query retries, it should not cause a service outage unless the client is not RFC-compliant or has been implemented particularly strictly." But TLD operators are very keen on performance, DNS security and on "correctness" of their DNS responses. Therefore right configuration is crucial for them. You are right about globally distributed anycast tend to hit the same node, but in cases of maintenance you hit a different node. And TLD operators should take this into account and configure their BINDs properly to circumvent this issue. If all TLD operators are aware of this issue my post would have been useless. Over this weekend my github project [1] was 9 times cloned, which probably means that it was helpful to some of this audience. cheers arsen [0] https://kb.isc.org/docs/dns-cookies-on-servers-in-anycast-clusters [1] https://github.com/stasic/dns-cookies ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Check DNS-anycast-instances for same DNS Cookie
Just a short follow up on this. Out of 4134 unique NS entries in the Root-Zone 1103 NS have DNS Cookies enabled (~26%). (I don't know how many among them are anycasted or load-balanced.) Among these NS with DNS Cookies enabled are big TLDs like: uk, de, fr, br, pl, nl, it Find below the complete list of NS with enabled DNS Cookies. It seems that com, net and org do not support DNS Cookies. All affected TLDs should take a look into (pull requests are welcome): https://github.com/stasic/dns-cookies/ Is there any DNS software which supports DNS Cookies beside BIND? happy cookie gathering Arsen -- 1.ns.ph. a.au. a.cctld.us. a.dns.ar. a.dns.it. a.dns.jp. a.dns.pt. a.gtld.biz. a.gtld.travel. a.nic.bank. a.nic.bg. a.nic.cl. a.nic.de. a.nic.insurance. a.nic.xn--mxtq1m. a.ns.nic.country. a.ns.nic.nowruz. a.ns.nic.pars. a.ns.nic.shia. a.ns.nic.tci. a.ns.nic.xn--mgbt3dhd. a.ns.nu. a.ns.se. a.thains.co.th. a.zdnscloud.com. a2.nic.abarth. a2.nic.abbott. a2.nic.abbvie. a2.nic.ac. a2.nic.aco. a2.nic.agakhan. a2.nic.aigo. a2.nic.akdn. a2.nic.alfaromeo. a2.nic.alibaba. a2.nic.alipay. a2.nic.allstate. a2.nic.ally. a2.nic.apple. a2.nic.archi. a2.nic.audi. a2.nic.autos. a2.nic.avianca. a2.nic.bcg. a2.nic.beats. a2.nic.bestbuy. a2.nic.bet. a2.nic.bio. a2.nic.black. a2.nic.blockbuster. a2.nic.blue. a2.nic.bnpparibas. a2.nic.boats. a2.nic.boehringer. a2.nic.bugatti. a2.nic.case. a2.nic.caseih. a2.nic.cbs. a2.nic.ceb. a2.nic.cern. a2.nic.cipriani. a2.nic.clinique. a2.nic.creditunion. a2.nic.cruise. a2.nic.cyou. a2.nic.dabur. a2.nic.data. a2.nic.delta. a2.nic.dish. a2.nic.dot. a2.nic.dtv. a2.nic.dunlop. a2.nic.dvr. a2.nic.eco. a2.nic.edeka. a2.nic.emerck. a2.nic.esurance. a2.nic.extraspace. a2.nic.fage. a2.nic.fedex. a2.nic.ferrari. a2.nic.fiat. a2.nic.fido. a2.nic.frogans. a2.nic.gallup. a2.nic.gea. a2.nic.global. a2.nic.godaddy. a2.nic.goodyear. a2.nic.green. a2.nic.hdfc. a2.nic.hdfcbank. a2.nic.helsinki. a2.nic.hermes. a2.nic.hkt. a2.nic.homedepot. a2.nic.homes. a2.nic.hughes. a2.nic.icbc. a2.nic.imamat. a2.nic.io. a2.nic.ismaili. a2.nic.ist. a2.nic.istanbul. a2.nic.itv. a2.nic.iveco. a2.nic.jcp. a2.nic.jeep. a2.nic.jio. a2.nic.jll. a2.nic.kim. a2.nic.kosher. a2.nic.lamborghini. a2.nic.lamer. a2.nic.lancia. a2.nic.lasalle. a2.nic.latino. a2.nic.lds. a2.nic.lgbt. a2.nic.llc. a2.nic.locker. a2.nic.lotto. a2.nic.ltda. a2.nic.marriott. a2.nic.maserati. a2.nic.mckinsey. a2.nic.metlife. a2.nic.mit. a2.nic.mobile. a2.nic.mormon. a2.nic.motorcycles. a2.nic.newholland. a2.nic.nokia. a2.nic.nowtv. a2.nic.nra. a2.nic.ollo. a2.nic.onl. a2.nic.organic. a2.nic.origins. a2.nic.ott. a2.nic.pccw. a2.nic.pet. a2.nic.phone. a2.nic.pink. a2.nic.pnc. a2.nic.poker. a2.nic.progressive. a2.nic.promo. a2.nic.pwc. a2.nic.red. a2.nic.redstone. a2.nic.redumbrella. a2.nic.reliance. a2.nic.rich. a2.nic.richardli. a2.nic.ril. a2.nic.rogers. a2.nic.sbi. a2.nic.schaeffler. a2.nic.scholarships. a2.nic.sew. a2.nic.sh. a2.nic.shaw. a2.nic.shiksha. a2.nic.showtime. a2.nic.shriram. a2.nic.sina. a2.nic.ski. a2.nic.sling. a2.nic.srl. a2.nic.stada. a2.nic.star. a2.nic.statebank. a2.nic.stockholm. a2.nic.temasek. a2.nic.thd. a2.nic.travelers. a2.nic.travelersinsurance. a2.nic.trv. a2.nic.tvs. a2.nic.ups. a2.nic.vegas. a2.nic.vig. a2.nic.viking. a2.nic.volkswagen. a2.nic.vote. a2.nic.voto. a2.nic.weibo. a2.nic.wolterskluwer. a2.nic.xin. a2.nic.xn--3oq18vl8pn36a. a2.nic.xn--4gbrim. a2.nic.xn--5tzm5g. a2.nic.xn--6frz82g. a2.nic.xn--9krt00a. a2.nic.xn--b4w605ferd. a2.nic.xn--c1avg. a2.nic.xn--estv75g. a2.nic.xn--fzys8d69uvgm. a2.nic.xn--i1b6b1a6a2e. a2.nic.xn--jlq61u9w7b. a2.nic.xn--kput3i. a2.nic.xn--nqv7f. a2.nic.xn--nqv7fs00ema. a2.nic.yachts. a2.nic.zara. adns1.berkeley.edu. adns2.berkeley.edu. ans1.canar.sd. ans2.canar.sd. any-ns1.nc. any.nic.ci. anycast.eahd.or.ug. anycast.ns.nic.bo. anyns.dns.bs. anyns.nic.bi. anyns.pch.net. anyns.uem.mz. anytld.apnic.net. ao01.dns.pt. ao03.dns.pt. auth02.ns.uu.net. auth100.ns.uu.net. az.hostmaster.ua. b.bh.centralnic-dns.com. b.cctld.us. b.dns.ar. b.dns.br. b.dns.jp. b.dns.kr. b.dns.py. b.fi. b.gtld.biz. b.gtld.travel. b.mynic.centralnic-dns.com. b.nic.adac. b.nic.allfinanz. b.nic.art. b.nic.baby. b.nic.bank. b.nic.bar. b.nic.basketball. b.nic.best. b.nic.bg. b.nic.blog. b.nic.bmw. b.nic.bond. b.nic.cam. b.nic.ceo. b.nic.college. b.nic.coop. b.nic.deloitte. b.nic.desi. b.nic.design. b.nic.dhl. b.nic.dk. b.nic.dvag. b.nic.etisalat. b.nic.fans. b.nic.feedback. b.nic.fo. b.nic.forum. b.nic.fresenius. b.nic.frl. b.nic.fun. b.nic.gay. b.nic.gd. b.nic.gent. b.nic.host. b.nic.icu. b.nic.ink. b.nic.insurance. b.nic.kfh. b.nic.kpn. b.nic.kred. b.nic.lidl. b.nic.love. b.nic.lpl. b.nic.lplfinancial. b.nic.luxury. b.nic.mini. b.nic.monster. b.nic.observer. b.nic.online. b.nic.ooo. b.nic.pid. b.nic.pohl. b.nic.press. b.nic.protection. b.nic.realty. b.nic.reit. b.nic.rent. b.nic.rest. b.nic.rugby. b.nic.saarland. b.nic.schwarz. b.nic.security. b.nic.sfr. b.nic.site. b.nic.smart. b.nic.space. b.nic.stc. b.nic.stcgroup. b.nic.storage.
[dns-operations] Check DNS-anycast-instances for same DNS Cookie
Hi, This software might be of interest for DNS anycast providers (or customers) which are running BIND. With BIND 9.11 and newer DNS Cookies are enabled **automatically**. While I was searching for software to check DNS Cookies and I didn't find anything. Therefore I wrote this small Perl script to check DNS anycast instances (over their mgmt-ip) for synchronized DNS Cookies: https://github.com/stasic/dns-cookies/ If DNS Cookies are not the same between different DNS anycast instances it may cause warnings and intermittent query retries. Therefore I suggest either synchronize them or disable them. ISC addressed this issue in their knowledge base: https://kb.isc.org/docs/dns-cookies-on-servers-in-anycast-clusters happy cookie gathering Arsen signature.asc Description: PGP signature ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] glitch on [ip6|in-addr].arpa?
* Viktor Dukhovni [2019-10-10 20:51 (-0400)]: On Thu, Oct 10, 2019 at 06:25:41PM -0400, Matthew Pounsett wrote: The speculation I've seen is that Cogent refuses to treat HE as a Tier1 network in v6 because they don't try to also be one in v4, but that they should because HE's v6 network is much wider reaching and much longer established than Cogent's. In any case, Cogent's refusal to peer with HE over v6 has been very public and well documented. It makes Cogent unreachable from a significant portion of the v6 network. It has perhaps not been as well known as it deserves to be. Perhaps additional publicity here (and any other relevant fora), might nudge the parties closer to a resolution. The non-reachability of the IPv6 C root from a significant portion of IPv6 space is not a healthy situation. The error is immediately apparent via DNSViz: https://dnsviz.net/d/root/dnssec/ RIPE Atlas DNSMON measurement doesn't indicate this: https://atlas.ripe.net/dnsmon/group/root?dnsmon.session.color_range_pls=0-66-66-99-100=true=server-probes=root=undefined=156816=1570752000=true=both=false=2001:500:2::c cheers, -arsen ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
