[dns-operations] unable to use ns1/2-dedi0010.zxcs.nl, ns1/2.superserver07.zxcs.nl
Hi, anyone around here from zxcs.nl or vimexx.nl? My customers complain that they can not sent emails to npsdriven.com or watersnip.nl. My recursor source addresses are 2607:f1c0:5c0:53::/64 2607:f1c0:5c1:53::/64 2001:8d8:5c0:453::/64 2001:8d8:5c1:453::/64 2001:ba0:5c0::/64 2a00:da00:5c0::/64 2a00:da00:5c0:3::/64 2a00:da00:5c0:4::/64 74.208.114.128/26 74.208.114.192/26 77.68.65.64/26 82.165.226.0/26 82.165.226.64/26 88.208.254.128/26 82.223.158.0/26 213.171.202.197/27 please remove firewall drop rules or low hashlimits (<50 qps) for the listed prefixes on your gear to allow your customers to communicate with my customers. I run the DNS for IONOS (incl. arsys, fasthosts, home.pl) 1&1, gmx.net, mail.com, web.de. (>100M email accounts) In case of any problems please contact ab...@ionos.com first. The emails sent there are read and reacted to. Cheers Thomas ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] ns1-proddns.glbdns.o365filtering.com unreachable?
Anyone else with trouble to reach the *.o365filtering.com DNS Servers? ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] azure-dns / edge-global.plcm.vc resolution problems
Dear List Members, I'd like your advice on my dns resolution problems for edge-global.plcm.vc/A When I can successfully resolve it is 1392byte / 84 A or a 1216bytes / 73 A Records answer. But 50% of the requests get SERVFAILs or self referrals (testing from AS8560). Testing from outside AS 8560 with RIPE atlas (see https://atlas.ripe.net/measurements/32509300) looks the same. Using Quad1/8/9 I see these services needing sometimes >2000ms to generate the answer. Thanks Thomas ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] anyone from cisco.com DNS Team around?
Hi, I have trouble to activate my Cisco NCS5xxx Devices. Turns out that tools.cisco.com. resolves to either 173.37.145.8 (this works) or 72.163.4.38 (which was decommissioned earlier this year). By running dig A tools.cisco.com @alln01-ucs-dcz03n-gslb1-snip.cisco.com four times I can reproduce this. Cisco, please fix your DNS. Thanks Thomas ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] .ag outage
Hi, I received customer complaints that quad8 and some german broadband resolvers were unable to resolve .ag secondlevel domains. peak.ag hoevelmann.ag sonnenschein.ag hostedoffice.ag I run the authoritatives serving the first three examples and we've had no outage. I don't understand the DNSEC keys in .ag and the intended change carried out with the current setup. https://dnsviz.net/d/hoevelmann.ag/dnssec/ Do you also see problems with .ag? Cheers Thomas ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Nameserver responses from different IP than destination of request
On 9/1/20 9:15 PM, Andreas Ott wrote: On Mon, Aug 31, 2020 at 8:00 PM P Vixie mailto:p...@redbarn.org>> wrote: [...] the observation that something bad is not happening to somebody doesn't mean it's not happening to anybody. May I please ask an operational question to experts: though I am only running a small number of authoritative and recursive servers, I am coming up short looking up what logging I need to turn on in BIND 9.16 and what logged strings I need to parse out to see responses coming from a different IP? I have various log channels enabled per the BIND logging "FAQ" but either I am missing config bits or the problem does not occur (on my servers). This is in a network lab setup and I am able to share data. I don't think this is implemented in a way need for this kind of analysis in any recursive dns software. I have chosen to do dnscap on the interface with outgoing traffic and may do correlation of request/reponses based on qname/qtype and look for mismatches in dst ip/src ip afterwards. Another option that comes to my mind is to tweak/reuse the collectd dns plugin which also opens the packetflow on a configurable interface with libpcap and may be able to do some online data correlation. Just my 5¢ Thomas ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Nameserver responses from different IP than destination of request
On 8/29/20 5:50 PM, Paul Hoffman wrote: On Aug 28, 2020, at 3:24 PM, Puneet Sood via dns-operations wrote: We would be interested in hearing other operator's experience here. Are recursive servers seeing similar behavior from authoritative servers? If yes, are you discarding these responses? Are there authoritative server operators who still need the flexibility afforded by RFC 1035? Please note that Puneet was asking for other operators' experiences, not the opinions of those of us who believe we should tell Google what to do. (And, yes, I certainly put myself in the latter category.) I, too, would like to hear if other resolver operators see this, and if possible to what extent they are seeing it, and if we're really lucky to hear at least a few names for which this is happening. The latter is not to name-and-shame, but instead to be able to talk to the authoritative operators about what their configuration is so that we can maybe guide others away from this path. At my employer we discard this kind of responses. We could analyze how often we see them but we wait until someone calls customer care for "DNS not working". To me this is similar to the endless discussion around "why can't I use a cname in MX or NS". RFC2181 is pretty clear about NS/MX or "Server Reply Source Address Selection" and I don't see a reason why I should risk the stability of my systems to make it work for a small fraction of the internet. Just my 5¢ Thomas ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] dnsviz.net complaining "UDP_-_NOEDNS_" for gtld-servers.net
I have a customer complaining being unable to send/receive email. https://dnsviz.net/d/sportsproducts.net/dnssec/ shows errors: sportsproducts.net/DS: No response was received from the server over UDP (tried 12 times). (2001:502:1ca1::30, 2001:503:d414::30, 2001:503:eea3::30, UDP_-_NOEDNS_) sportsproducts.net/NS: No response was received from the server over UDP (tried 12 times). (2001:502:1ca1::30, 2001:503:d414::30, 2001:503:eea3::30, UDP_-_NOEDNS_) From Germany (more specific HE-FRA) I can not reproduce this error. From us-mkc (as8560): no problem. Answer size reported by dig: 864 (ds)/ 643 (ns) Anyone an idea what is wrong? Cheers Thomas ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] ttls set in national-lottery.co.uk zone for NS and MX
Hi, if anyone has contacts to national-lottery.co.uk/camelotinteractive.com please ask them to rethink the 30s ttl on NS and MX records. I run a recursive DNS for a Mailsystem with 10 of millions of mailboxes and my pdns_recusor queries fast enough but ns6/7.camelotinteractive.com seem to throttle. Thanks for your help. Best regards Thomas ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] .cm DNS setup
Hi, I have a customer complaining that his mail to camccul.cm do bounce. After checking my recursive and authoritative DNS, I took a look on .cm setup: .cm has the following nameservers configured in root zone: cm. 172800 IN NS sanaga.camnet.cm. cm. 172800 IN NS ns.itu.ch. cm. 172800 IN NS kim.camnet.cm. cm. 172800 IN NS lom.camnet.cm. cm. 172800 IN NS auth02.ns.uu.net. auth02.ns.uu.net. returns SERVFAIL for dig camccul.cm @auth02.ns.uu.net sanaga.camnet.cm. times out .cm has the following nameservers configured in .cm zone cm. 86400 IN NS mbam.camnet.cm. cm. 86400 IN NS ns-cm.afrinic.net. cm. 86400 IN NS auth02.ns.uu.net. cm. 86400 IN NS ns2.nic.cm. cm. 86400 IN NS benoue.camnet.cm. cm. 86400 IN NS phloem.uoregon.edu. cm. 86400 IN NS ns1.nic.cm. cm. 86400 IN NS ns.itu.ch. cm. 86400 IN NS ns-cm.nic.fr. cm. 86400 IN NS lom.camnet.cm. cm. 86400 IN NS kim.camnet.cm. auth02.ns.uu.net. returns SERVFAIL for dig camccul.cm @auth02.ns.uu.net benoue.camnet.cm does not exist .cm, would you please take a look? Thanks Thomas Mieslinger P.S.: please also fix mail setup for do...@antic.cm (SOA mail field) ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] asking the European a-k.cctld.us servers for MX records
Hi Joe, I don't think it's a reasonable characterisation to link the availability of European-based authoritative servers to the ability for Europeans to send mail to Americans. So long as *some* authoritative servers for .us were responding, and so long as the mitigation didn't involve returning false answers, mail would still be delivered; just the recursive MX lookup would take longer. At least in my and Peter van Dijks tests no European v4 connected cctld.us Server did respond to MX queries with a referral. So the 66k dot us domains my employer hosts where effectively offline. Thomas On 03/27/2013 08:10 PM, Joe Abley wrote: On 2013-03-27, at 14:39, Thomas Mieslinger mi...@pc-h.de wrote: --snip-- We have corrected the issue that was blocking email/MX queries to US domain names from Europe. Neustar had noticed a MX spike in it's servers in Europe over the weekend, and to stop any negative effects, we placed those servers in mitigation. We have modified the mitigation to block all inbound MX queries from recursive servers with the recursive bit turned off, and all email from Europe to .US domain names will now be delivered correctly. --snap-- That seems like a curious mitigation tactic. I would worry, though, that timing out on MX queries specifically would cause use of those European nameservers to be suppressed for other RRTypes, too. That would amount to a wholesale shifting of query traffic from European .us nameservers to those elsewhere without the mitigation. The apparent availability and non-availability of those particular servers from the point of view of caches would make capacity planning difficult. The difficulty in diagnosing problems at end-sites is already evident. There are a lot of moving parts there, and a lot of unpredictable behaviours. I wouldn't have taken that approach to defend against MX spikes. Joe ___ 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] asking the European a-k.cctld.us servers for MX records
On 03/27/2013 04:48 PM, Chris Thompson wrote: On Mar 26 2013, Thomas Mieslinger wrote: [...] When doing a dig MX soderman.us @a.cctld.us in Europe I get no answer at all. [...etc...] This seems to be fixed now, at least as seen from here. Does anyone know any details of how it happened in the first place? Blocking MX queries (only) seems quite a strange thing for even the usual run of idiot firewall software to be doing. Hi Chris, thanks for your interest in this strange case. I got this email from neustar technical support: --snip-- We have corrected the issue that was blocking email/MX queries to US domain names from Europe. Neustar had noticed a MX spike in it's servers in Europe over the weekend, and to stop any negative effects, we placed those servers in mitigation. We have modified the mitigation to block all inbound MX queries from recursive servers with the recursive bit turned off, and all email from Europe to .US domain names will now be delivered correctly. --snap-- Are we already in a time where everybody uses facebook, google+, linked in or whatever to communicate? I think that it was very bad decision to prohibit europe from sending emails to .us domains. Will they block SRV the next time? Disabling VoIP and various instant messengers? Thomas ___ 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] asking the European a-k.cctld.us servers for MX records
Hi, am I the only one having trouble to resolve MX records for .us Domains? When doing a dig MX soderman.us @a.cctld.us in Europe I get no answer at all. In the US I get a referral to the nameservers which are authoritative for this domain. To make this even more strange dig soderman.us @a.cctld.us or any other record type except for MX just gives the referral also in Europe. Can you just try it yourself? Regards Thomas ___ 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
