Re: [dns-operations] Old version of dig on macOS
On 18/12/2023 19:48, Weinberg, Matt via dns-operations wrote: Hi Matt, The latest patched versions of macOS Ventura (13.6.3) and Sonoma (14.1.2) both include an old version of the dig client: % dig -v DiG 9.10.6 I only noticed the issue when I attempted to retrieve the ZONEMD record of the root zone from my MacBook (it didn’t work). I can’t speak to whether this older version of dig is missing any other features (or addresses any security concerns). Anyone know how best to nudge Apple into updating the default dig client on macOS? Thoughts either way? ISC switched to the MPL 2.0 license for BIND version 9.11 onwards. I don't know the details, but I believe that Apple cannot or does not wish to distribute code with this license. That's why dig is stuck at version 9.10, and this situation is unlikely to change. You're better off installing Homebrew, and using that to install the latest versions of BIND or Knot DNS. These will provide you with up to date versions of "dig" and "kdig". Both of these tools are suitable for all kinds of modern DNS usage. I personally prefer kdig, because it is more consistent than dig in some ways, and is also the only tool capable of doing queries over QUIC. Regards, Anand ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] in-addr.arpa. "A" server "loopback network" misconfiguration
On 22/06/2023 16:48, Matthew Pounsett wrote: Hi Matt, Which of the below would you suggest? SOA rname:ns...@iana.org WHOIS Administrative: i...@iab.org WHOIS Technical: tld-cont...@iana.org I would have started with the IANA addresses, since they publish the zone and operate the name servers where this misconfiguration exists. Minor correction here: IANA publishes the zone, but the 6 servers are operated independently by ICANN and the 5 RIRs. The "A" server is operated by ARIN. Viktor has already received several pointers about whom to contact. Regards, Anand ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] New addresses for b.root-servers.net
On 03/06/2023 23:09, Doug Barton wrote: Hi Doug, [snip] Since the host records are the interesting bit, we do absolutely need to make sure that we can sanity check them somehow. I'm not sure Chris' suggestion to essentially "vote" on which host records are the right ones based on the results returned from polling all the known addresses is the right solution. Personally I would love to see the political drama around signing root-servers.net go away and have that zone signed already. RSSAC 028 has a detailed analysis of various naming schemes for root name servers, along with their benefits and problems. One of those problems is that the dependency on .net can lead to failure of priming response validation, or even a node re-delegation attack against a resolver. Regards, Anand ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Stale .GN and .LR zone data in some instances of "ns-{gn, lr}.afrinic.net"
On 30/08/2022 18:42, Randy Bush wrote: Hi Randy, Viktor, another day of no response from afrinic, and i guess i should ask the iana to remove them from the NS RRset for GN and LR. anyone have a way to get afrinic dns folk's attention? Try the address dns-mast...@afrinic.net. This is the address I use when I need to ask for configuration changes or alert them about problems. Regards, Anand ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] Changes to Time-to-Live (TTL) values in reverse DNS zones
Dear colleagues, In 2021, we announced a plan to change the time-to-live (TTL) values in the reverse DNS zones that we maintain. You may view the announcement here: https://www.ripe.net/ripe/mail/archives/dns-wg/2021-November/003928.html Many members of the community expressed support for our proposal. Therefore, we are going to make these changes next week on Wednesday 20 April. We will lower the TTL of NS records to 86400 (1 day) and that of DS records to 3600 (1 hour). Note that the TTL of records imported from other Regional Internet Registries (RIRs) will not be affected. Those records will be imported with the TTLs as published by the origin RIR. Regards, Anand Buddhdev RIPE NCC ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] K-root in CN leaking outside of CN
Hi Davey, Manu, The server we operate in Guangzhou was indeed reachable from outside China. This is not the intention, of course. On Saturday, when we got notification about this, we withdrew the prefix from the server, and we are communicating with the host to solve this. Many people have already said this, but I'd like to make it clear that the K-root server was NOT emitting false responses for Facebook and WhatsApp. The responses were being modified by something between the server and its clients. Regards, Anand Buddhdev RIPE NCC On 08/11/2021 08:45, Davey Song wrote: If it is urgent, I suggest the K root operator withdraw the route of the instance in Guangzhou immediately. ___ 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
On 04/05/2021 15:59, Klaus Darilion wrote: Hi Klaus, > In my setup I receive zones from various hidden primaries to my > "incoming" nameserver. Before my "distribution" nameserver fetches the > zone from the "incoming" nameserver (and hence sends NOTIFYs to the > public secondaries) I I want to perform various checks on the zone > loaded on the incoming nameserver. > > Currently I use a freaky Bind9 setup with several perl scripts. Do you > know if there exists any software tool that were written for such > setups? For example a Secondary which fetches a zone not automatically > but only on request? Or a nameserver which fetches a zone but only > "loads" it if an external tool validates the zone? I don't think any of the existing name servers have that facility. I know that the latest Knot DNS can do DNSSEC validation of incoming XFRs, and I guess this implies general DNS correctness checks. However, if you want to do custom checks, you'll have to do this yourself. You might want to look at Tony Finch's nsnotifyd, which is a custom program that can monitor zones for changes, and run custom commands when changes are detected. It can also listen for NOTIFY messages and act immediately on zone changes. You could use it to run your custom checks before distributing your zones. https://github.com/fanf2/nsnotifyd Regards, Anand Buddhdev ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Possibly-incorrect NSEC responses from many RSOs
On 01/03/2021 18:55, Viktor Dukhovni wrote:
Hi Viktor,
> Cool, but at first blush the feature appears to have a bug in BIND 9.16.12:
>
> # dig +noall +ans +nocl +nottl +nosplit +norecur -t rrsig .org
> @ | awk '{print $2}' | uniq -c
>1 RRSIG
>
> # dig +noall +ans +nocl +nottl +nosplit +norecur -t any .org
> @ | awk '{print $2}' | uniq -c
>1 RRSIG
>1 NSEC3PARAM
>1 TXT
>2 CAA
>1 MX
>6 NS
>2 TYPE65534
>2 DNSKEY
>7 RRSIG
>1 SOA
This probably has nothing to do with the server. It's a change in
behaviour in dig. Newer versions of dig use TCP for ANY queries, and so
you'll get a full response. You have to explicitly use +notcp with an
ANY query to see the behaviour over UDP. I also ran into this issue and
was very confused. I even opened a bug report with ISC, only to be told
that it was a "feature". I don't like this change at all, for many
reasons. But we're stuck with it.
Regards,
Anand
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] NXDOMAIN for a-dns.pl and e-dns.pl
Hi, Anyone from the Polish ccTLD around? The .PL delegation contains a-dns.pl and e-dns.pl, but when the name server addresses of .PL are queried for A and records for these names, I get NXDOMAIN responses. ; <<>> DiG 9.16.3 <<>> +trace +nodnssec a-dns.pl a ;; global options: +cmd . 515108 IN NS k.root-servers.net. . 515108 IN NS h.root-servers.net. . 515108 IN NS g.root-servers.net. . 515108 IN NS a.root-servers.net. . 515108 IN NS m.root-servers.net. . 515108 IN NS f.root-servers.net. . 515108 IN NS l.root-servers.net. . 515108 IN NS e.root-servers.net. . 515108 IN NS b.root-servers.net. . 515108 IN NS i.root-servers.net. . 515108 IN NS j.root-servers.net. . 515108 IN NS d.root-servers.net. . 515108 IN NS c.root-servers.net. ;; Received 239 bytes from 193.0.19.101#53(193.0.19.101) in 14 ms pl. 172800 IN NS g-dns.pl. pl. 172800 IN NS h-dns.pl. pl. 172800 IN NS f-dns.pl. pl. 172800 IN NS i-dns.pl. pl. 172800 IN NS c-dns.pl. pl. 172800 IN NS b-dns.pl. pl. 172800 IN NS e-dns.pl. pl. 172800 IN NS a-dns.pl. pl. 172800 IN NS d-dns.pl. couldn't get address for 'e-dns.pl': not found couldn't get address for 'a-dns.pl': not found ;; Received 579 bytes from 192.33.4.12#53(c.root-servers.net) in 24 ms pl. 3600IN SOA a-dns.pl. dnsmaster.nask.pl. 1591009275 900 300 2592000 3600 ;; Received 88 bytes from 2a02:38:14::146#53(c-dns.pl) in 29 ms ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] DNSSEC Validation Failures for RIPE NCC Zones
Dear colleagues, Yesterday afternoon (21 May 2020), our DNSSEC signer rolled the Zone Signing Keys (ZSKs) of all the zones we operate. Unfortunately, a bug in the signer caused it to withdraw the old ZSKs soon after the new keys began signing the zones. Validating resolvers may have experienced some failures if they had cached signatures made by the old ZSKs. We apologise for any operational problems this may have caused. We are looking at the issue with the developers of our Knot DNS signer to prevent such an occurrence in the future. Regards, Anand Buddhdev RIPE NCC ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Outages last night?
On 03/04/2020 11:43, Greg Choules via dns-operations wrote: > Good morning all. > Did anyone else experience service outages around 22:20 to 22:30 (UTC) > yesterday? Yes. No. Maybe. If you ask a more specific question about which service you're talking about, it might be easier to answer. > Just curious. I am too. -- Anand ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Surprising behaviour by certain authoritative name servers
On 07/01/2020 15:20, Niall O'Reilly wrote: Hi Niall, > What's surprising is that an authoritative name server > shows both a decremented TTL value (as if it were answering > from cache) and the AA flag. It could be tinydns, using this feature: "You may include a timestamp on each line. If ttl is nonzero (or omitted), the timestamp is a starting time for the information in the line; the line will be ignored before that time. If ttl is zero, the timestamp is an ending time (``time to die'') for the information in the line; tinydns dynamically adjusts ttl so that the line's DNS records are not cached for more than a few seconds past the ending time. A timestamp is an external TAI64 timestamp, printed as 16 lowercase hexadecimal characters. For example, the lines +www.heaven.af.mil:1.2.3.4:0:400038af1379 +www.heaven.af.mil:1.2.3.7::400038af1379 specify that www.heaven.af.mil will have address 1.2.3.4 until time 400038af1379 (2000-02-19 22:04:31 UTC) and will then switch to IP address 1.2.3.7." Regards, Anand Buddhdev ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] IPv6 only for nameservers
On 30/12/2019 10:38, Yonah Peng wrote: Hi Yonah Peng, > As IPv4 addresses were exhausted today, if we have deployed the > nameservers with IPv6 addresses only, can they be resolvable by world wide? If your domain's authoritative name servers have only IPv6 addresses, then your domain will not be resolvable by many resolvers on the Internet, because many of them only have IPv4 connectivity. Regards, Anand ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Verifying that a recursor is performing DNSSec validation
On 17/07/15 07:51, Frank Bulk wrote: I've completed writing the first iteration of a NAGIOS-oriented Perl script that does the checks I've described. It was actually more painful to get the Net:DNS:DNSsec Perl module installed than anything else. I haven't seen your script, of course, so I can't know the specifics, but may I suggest the following logic? 1. First send a query to the resolver with CD=1. This tells the resolver you don't want it to do validation. This will catch the case where a zone doesn't resolve for other reasons (unreachable name servers, expired, etc). 2. If you get back a good result, then repeat the query with CD=0. If you still get back an answer, and AD is set, then you know you have a good dnssec-signed zone. If you get an answer, but AD is not set, then the zone doesn't have a chain of trust (but could still be signed). If it SERVFAILs this time, you can conclude that the zone is signed, but validation has failed. Of course this logic is simple, and doesn't get anywhere close to the likes of Casey Deccio's DSNViz or Verisign's DNSSEC debugger, but it's good enough for a Nagios check. Regards, Anand ___ 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] .MW inconsistent zone updates?
On 25/06/15 10:30, Randy Bush wrote: rip.psg.com:/root# dig +short @196.45.188.5 mw. soa ;; connection timed out; no servers could be reached rip.psg.com:/root# dig +short @41.221.99.135 mw. soa ;; connection timed out; no servers could be reached having fun over there? We also operate a name server for .MW, mw.cctld.authdns.ripe.net. We picked up serial 2010251866 (containing the new NS records for cheki.mw) on 23 June: 23-Jun-2015 08:40:23.754 general: zone mw/IN/main: transferred serial 2010251866 But after that, we've also been unable to reach .MW's masters: 23-Jun-2015 19:05:26.224 general: zone mw/IN/main: refresh: retry limit for master 196.45.188.5#53 exceeded (source 0.0.0.0#0) 23-Jun-2015 19:05:56.225 general: zone mw/IN/main: refresh: retry limit for master 41.221.99.135#53 exceeded (source 0.0.0.0#0) Regards, Anand Buddhdev RIPE NCC ___ 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] com. Glue
On 19/05/15 23:12, Jim Popovitch wrote: Hi Jim, Hello, I'm stuck in the middle with $registrar saying glue exists, and intodns, et.al., saying no glue exists. I would appreciate any insight into why there is no glue appearing for speedyiguana.com (a mailman dev/test system that i use) I don't see the problem. speedyiguana.com's name servers are in the .org zone, so the .com/.net servers cannot and should not provide any glue records in their referral response. Regards, Anand ___ 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] [Security] Glue or not glue?
On 04/05/15 09:11, Stephane Bortzmeyer wrote: Bonjour Stéphane, A new edition of the DNS security guide by ANSSI (French cybersecurity agency) recommends to prefer delegations with glue because glueless delegations may carry additional risks since they create a dependency. Is there any other best practices text which makes such a recommendation? DJB also talks about the risks of glueless delegations on his page: http://cr.yp.to/djbdns/notes.html#gluelessness and recommends the use of in-bailiwick names. Regards, Anand ___ 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] DNSSEC validation failures for .KE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wouter Wijngaards just alerted me to validation failures for .KE (Kenya). I tried to call KENIC, but their phone numbers are all unreachable. If anyone has local contacts in Kenya or nearby, please alert them! http://dnsviz.net/d/ke/VRp4ag/dnssec/ Their current DS record points to a key that has the revoke bit set, but it is no longer signing the DNSKEY rrset. Regards, Anand Buddhdev RIPE NCC -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlUahw8ACgkQi+U8Q0SwlCtKAQCfX3kq7G+YN4oKbQuQBbI6bybV /NcAn33VsMdFZnW1/rSddTEBqx2TKTgf =O224 -END PGP 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] DNSSEC validation failures for .KE
On 31/03/15 13:53, Stephane Bortzmeyer wrote: There are other problems: * 10 (!) DNSKEY which seems too many I saw 9 when I looked. This seems to be getting worse. * lame delegations to mzizi.kenic.or.ke mzizi.kenic.or.ke was answering earlier, but is now giving SERVFAIL as well. Anand ___ 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 load-balancing/failover using an ASR 9xxx (few questions)
On 15/08/2014 00:00, Nat Morris wrote: BGP sessions between the ASR 9 and each DNS server in the cluster, ExaBGP running on them announcing their loopback/service /32 + /128 address(es). Health check scripts on each service to probe for service ability, retract the announcement upon failure. We are doing this exact same thing on many RIPE NCC DNS servers, and it works very well. The other advantage of BGP is that as soon as you withdraw the announcement, the router stops sending traffic to the server. With OSPF, you have timeouts of several seconds before traffic stops arriving at a dead server. Regards, Anand ___ 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] DNSSEC problem with 174.in-addr.arpa
On 17/11/2013 18:57, Chris Thompson wrote: Hi Chris, As a matter of interest to many of us, what are ARIN's operational procedures for interlocking KSK rollovers in NNN.in-addr.arpa zones with the change of DS records in in-addr.arpa? (Of course we could ask the same question of the other RIRs as well...) I haven't understood your question fully, but let me try answering. The RIPE NCC's procedure involves removing the old DS records, and inserting the new ones, in a single transaction, when we do KSK roll-overs. This saves us from having to do double the work. Last week, we began KSK roll-overs for all the RIPE NCC's zones. We began a slow start by updating the DS records for just 2.in-addr.arpa. However, our update did not appear in the in-addr.arpa zone. Our DNSSEC signer will not withdraw the old KSK until it has seen the new DS record, so it patiently kept waiting and logging this fact. We informed ICANN, and they fixed the operational issue in their provisioning system that was blocking the update. We expect to update the DS records of all zones this week. Regards, Anand Buddhdev RIPE NCC ___ 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] Discarding bad records from an AXFR
Hello DNS experts, I am seeking opinion about an aspect of AXFR. Let's start with what BIND does. When configured as a slave, and receiving an AXFR, if there are out-of-zone records in the zone, BIND excludes them from its in-memory copy of the zone. However it *does* save the entire zone to disk, including the bad records. When a downstream slave asks this instance of BIND for an AXFR, it provides the complete zone, including the bad records. Now I'm looking at Knot DNS 1.3.0-rc5. When it receives an AXFR with out-of-zone records, it discards them, completely. So when it saves the zone to the disk, the out-of-zone records are not saved, and if a client asks this instance of Knot for an AXFR for this zone, the client will receive Knot's sanitised copy of the zone. I can see the positive and negative sides to both approaches, and since RFC 5936 (AXFR) does not say anything specific about how to treat bad records in a zone, both BIND and Knot are doing what they think is right. BIND is trying to pass on the zone unchanged, but will of course not serve any out-of-zone records. Knot will not serve out-of-zone records, but will not pass them on either. What do you all think is the correct behaviour? Or are both correct? PS. I realise that Knot's behaviour could break a DNSSEC-signed zone, but then, no sane signer will sign a zone with out-of-zone records, so that the process of signing a zone would force the operator to clean up their zone. Regards, Anand Buddhdev RIPE NCC ___ 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] Comparing TCP and UDP response times of root name servers
[Apologies for duplicates] Dear colleagues, The RIPE NCC has just published an article on RIPE Labs, comparing the TCP and UDP response times of DNS queries to the root name servers: https://labs.ripe.net/Members/bwijnen/tcp-udp-dns-soa-rt-ratio Your comments, questions and suggestions are welcome. Regards, Anand Buddhdev RIPE NCC ___ 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] Minimalistic DNS server for SOA and AXFR
On 17/07/2012 15:33, Mark Andrews wrote: Actually named does do SOA queries over TCP before AXFR. Hi Mark, On my MacOS X laptop (which comes with BIND 9.7.3-P3), I didn't see SOA queries over TCP. I saw a SOA query over UDP, followed by an AXFR request over TCP. Besides TC in a UDP response, what would cause BIND to do an SOA query over TCP? Anand ___ 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] Minimalistic DNS server for SOA and AXFR
On 17/07/2012 21:38, Jaap Akkerhuis wrote: Hi Bert, Anand, Sorry to be obtuse, and of course, nothing on the internet needs a reason. But inquiring minds want to know. WHY are you inventing yet another nameserver when we have so many fine ones available already? As far as I understood he wanted something which would only provide AXFR, not a full blown server. Jaap is correct. I only need to provide AXFR, and nothing else. Since enquiring minds want to know: I'm doing some work on the RIPE NCC reverse DNS provisioning system. At the moment, it works by reading in DNS information from different sources, doing the necessary checks, and then injecting the DNS information into a BIND view. This BIND view then provides AXFR to a pair of DNSSEC signers, where the zones are signed and AXFR'ed out to publication servers. In this chain, the BIND view is used merely for accepting dynamic updates, maintaining zones, and providing AXFR. If I can provide AXFR out of the provisioning system directly to the signers, I don't need the intermediate BIND view. I know PowerDNS can do funky things, but since my needs are very simple, I prefer to just code in the AXFR support into the provisioning code. In fact, I did so earlier today, and tested it, and it appears to work as I expect. It's not even very complicated, especially since I'm not writing for any generic AXFR client, but for clients under my control. As Duane said in another message, it's a great learning experience too. Regards, Anand ___ 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
