Re: Not a representative of gmx.com but their emails are being blocked by those who subscribe to the SORBS RBL.
Sorbs is a pretty good list. And I've been on the listed-side too. I personally would not use it to block, but I would give it 3 of the 5 points. The anti-spam gang is never going to be perfect. But since (self)regulation is not working, we need them. I value them at the moment. The only thing you can do about it, is figuring a way to solve this security issue (called spam). Met vriendelijke groet, David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) - Oorspronkelijk bericht - Van: "Tom Beecher" Aan: "Ken O'Driscoll" , nanog@nanog.org Verzonden: Zondag 18 december 2016 20:08:05 Onderwerp: Re: Not a representative of gmx.com but their emails are being blocked by those who subscribe to the SORBS RBL. I tend to scratch my head at anyone still using SORBS at this point. On Sun, Dec 18, 2016 at 8:27 AM Ken O'Driscoll wrote: > On Sat, 2016-12-17 at 20:15 -0800, Large Hadron Collider wrote: > > > Does anyone have information on why this is, and if you represent SORBS > > > and/or GMX and/or both, would you please trouble yourself with > > > contacting me off-list? > > > > You can find out why an IP was listed via their lookup facility: > > http://www. > > sorbs.net/lookup.shtml > > > > You can request de-listing by opening a support request: > > http://www.sorbs.net/cgi-bin/support > > > > You don't need to be an IP block owner to request de-listing but you do > need to be empowered to stop whatever caused the listing in the first > place. Their support is very responsive. > > > > Ken. > > > > -- > > Ken O'Driscoll / We Monitor Email > > t: +353 1 254 9400 | w: www.wemonitoremail.com > > > >
Re: BGP peering question
I would state that peering gives more control over the traffic you handle (since it is not going over someone else's network). Every hop is a possible problem to your operations, I guess. David On 12 July 2017 at 09:13, Wolfgang Tremmel wrote: > > > On 11. Jul 2017, at 21:43, Nick Hilliard wrote: > > > > Patrick W. Gilmore wrote: > >> 1) Are they present an IX where I am present? > >> > >> 2) Can they configure BGP correctly? > >> > >> 3) … Beer? > > > > > > 1) do they have a pulse? > > 4 ) are they in PeeringDB and keep their entry up to date? (especially the > contact information) > > cheers, > Wolfgang > > > -- > Wolfgang Tremmel > > Phone +49 69 1730902 26 | Fax +49 69 4056 2716 | Mobile +49 171 8600 816 > | wolfgang.trem...@de-cix.net > Geschaeftsfuehrer Harald A. Summa | Registergericht AG Köln HRB 51135 > DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | > Germany | www.de-cix.net > > > -- -- My opinion is mine.
Re: keeping your cabinet clean (was Re: Looking for help @ 60 Hudson)
Care to share some pics? David On 14 November 2017 at 02:04, Ken Chase wrote: > Some tricks I've learned managing multicustomer/shared cabinets over the > last > 20+ years...sorry it's long, but I think there's some good info on keeping > things clean and maintaining sanity. Please send your protips. > > Most of this is lower-end 1-4U sized mixes of gear specific and specific to > cabinets that have 2-6U+ flux per quarter with some rushed installs. Huge > one-time 12U blade installs of $1M appliances usually lend to gorgeous > cable > management schemes (and proper budgets) being included. No such lux here! > > TL;DR: thin premade ethernet of exact lengths and multiple random colours > (never black!), use min gauge required power cable thickness of exact > length, face A/B PDU's backwards on one side of rack cable management on > other side, never get less than 30" wide x 36" deep cabinet (if not, > wider > better than deeper), premeasure vert mount rail positions to be > compatible > with rail length/ front of server clearance, prewire front of rack > power/ether if needed (leave string too), practice tooless rail removal > while you can still get in above/below, rack similar-depth gear together, > switches face backwards (with front-to-back airflow switch config option > of > course) on rail-shelves not ears (that bend over time anyway) so they > can be > extracted out front and easily replaced in emergency. > > Details: > > Installing in 30" wide x 36" long cabinets makes all the diff over 24" x > 30". > A/B 0U PDUs on one side, cable wrangling ladders on other. More room = > more > flexbility. (If have no side panels and no neighbours, 24x30" is ok). 36" > deep > allows facing the PDUs backwards not sideways - cableheads extend > backwards, > not into the rail-tail path/airflow/etc. Worth getting the > 90degree-bent-head > cables too if you need the spare inches. (I ofset my PDUs vertically by > 1/2 a > plug-spacing distance so cable from left one fits between cableheads of > right > one.) > > Avoid racks that don't use cagenuts. Prethreaded holes get abused and > stripped. Try to get the right size of cagenut, there's a few standards out > there. Some will fit - poorly. (Either they fall out under weight or you > end > up trying to force them in with a thin screwdriver - I've seen people stab > themselves in the hand. Ask for a cagenut tool (J-hooked shaped piece of > metal that > looks like a bent desktop-case PCI slot cover.) > > Having many power cables of varying lengths is key (but why doesnt anyone > make > 15" and 21" power cables?). Not having ziptied loops of 12ga wire hanging > around made things much nicer (and better airflow). More $ but worth > sanity. > Esp. with varied coloured heads. Great for tracing (see ethernet below). > Wire > the gauge required - I find 10ga (6' long..) wire delivered with 100VA-max > server > configs often. Too thick to manage properly and usually unnecessary. But > check > your warranties and theoretical max power envelopes. > > Yes, full rack solns w/extendible arms exist but generally require vendor > compatibility. Expensive too. Great for one time well-funded installs. Not > practical for varied species installed over longer periods. > > Prewire any front-of-rack-powered gear when you first get the rack. I have > 5 > pairs (A/B) going to the front permanently ziptied and labelled - 3x2 in > use > for my back-facing switches, 1 for a small piece of gear (low watt > microtik), > others spare. Also prewire some proper length (multiple colours of) ether. > Fishing ether through the side can be impossible in a full cabinet in a > dense > row (we're in APC pods). I leave string in there too (probably will use it > for a twinax pull to the microtik soon, and pull more string with). > > Curse vendors for not picking a standard side (left vs right) for power > ingress! > (ibm and dell vs supermicro, sun and hp, IIRC?) > > Beware Dell's long fins/tails on their rails - won't fit in a 30" cabinet > if > your vert mount rails are too far back - or it blocks the power cord head > on > the pdu if it faces sideways/etc. And beware max/min rail extension - Dell > seems 'longest', with many min. rail lengths of 25.5". I think I saw min. > 26.5" once. > > Also had a cx jam a long Dell rail's tail into his fully assigned cabinet > - in > between a powercable head and the pdu body it was plugged into. BZZT! > Took 20 > min to get a monkey to reset at central panel. Thank proper cabinet > grounding > cables, right?) > > If you have an entirely empty cabinet to start with, grab a few different > rails and ensure your cab's vertical mount rails are all within spacing > spec. > and give door-closing clearance to server noses. (See reference tables.) > Moving them later can be impossible (though with sunfire rails that slid to > varying lengths, it worked out luckily!) > > Must admit Dell's tooless rail installs are awesome now. Better than > supermicro
RE: [mailop] IPv6 DNSBL
I suggest reputation on the reply-to domain also (if authenticated of course). No more running to other IPs / ESPs if you are a bad boy. You can integrate it in browsers and show it there too (watch out; don't enter your email address here because they will spam you or have spam evading practices [if no authentication takes place]). Show the reputation in the email client if possible. And I would like fine-grained complaining possible (so everyone can filter like the big boys can, one might need the 'ham' numbers too). But you want to be sure such numbers are authentic. David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -Oorspronkelijk bericht- Van: mailop [mailto:mailop-boun...@mailop.org] Namens Michael Peddemors Verzonden: Thursday, March 27, 2014 1:06 AM Aan: mai...@mailop.org Onderwerp: Re: [mailop] IPv6 DNSBL On 14-03-26 04:42 PM, John Levine wrote: > As a reliable rule of thumb, any list that's large enough to be > interesting is also large enough to be compromised. > > I know people who have run whitelists at Returnpath, and I was in > charge of the never very successful Spamhaus whitelist. The ones at > Returnpath always said that much of the job was dealing with bullshit > and deception from people trying to sneak into the whitelist. At > Spamhaus, the main problem was that nearly all of the people willing > to go to the effort to be whitelisted didn't qualify, which wasn't > surprising, since people with good mail behavior rarely have trouble > getting their mail delivered. > > R's, > John Here Here.. (For instance, we recommend that people running filtering turn those off right away, eg SA..) But we do see a lot of people discussing this here, and at the risk of making even more noise on this list on this subject, and maybe we should kill the thread there.. It would be interesting to get a poll of sorts.. hands please.. (You can reply off-list) Options: 1) Only allow IPv4 to be used for MTA's 2) Create a Registry of Operators/IPs for MTA's on IPv6 3) Allow all IPv6 to be used for MTA's, and use blacklists 4) Other (Suggestions) And if you believe in item 2, (personally I am happy with 1 or 2 and open to 4) what would you expect such a registry to look like? -- "Catch the Magic of Linux..." Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. ___ mailop mailing list mai...@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
RE: [mailop] IPv6 DNSBL
>> I suggest reputation on the reply-to domain also (if authenticated of >> course). No more running to other IPs / ESPs if you are a bad boy. You can >> integrate it in browsers and show it there too (watch out; don't enter your >> email address here because they will spam you or have spam evading practices >> [if no authentication takes place]). Show the reputation in the email client >> if possible. >Most are not authenticated. The vast majority of SPAM I see is, among other >things, Joe Jobbed. True. But the world must progress too. It would be nice if the spam-issue is better solved on IPv6 (than on IPv4). You would then have a reason to /not/ accept on IPv4 (and give IPv6 a boost). There must be a good reason for people to get of their asses and start implementing things like DMARC. All the banks (!$%^) I talk to do not have any reason to implement it swiftly (they turn on p=none and then all progress stops). Frustrating that they are too lazy to implement a few DNS records. It only needs firm backing by 3+ large companies like Hotmail. Give everyone on IPv6 without DMARC a large spamscore (and publish that beforehand ;-) ). Give me ammunition and all corporates will move. David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -Oorspronkelijk bericht- Van: Owen DeLong [mailto:o...@delong.com] Verzonden: Thursday, March 27, 2014 1:40 PM Aan: David Hofstee CC: Michael Peddemors; nanog@nanog.org Onderwerp: Re: [mailop] IPv6 DNSBL On Mar 27, 2014, at 2:37 AM, David Hofstee wrote: > I suggest reputation on the reply-to domain also (if authenticated of > course). No more running to other IPs / ESPs if you are a bad boy. You can > integrate it in browsers and show it there too (watch out; don't enter your > email address here because they will spam you or have spam evading practices > [if no authentication takes place]). Show the reputation in the email client > if possible. Most are not authenticated. The vast majority of SPAM I see is, among other things, Joe Jobbed. Owen
RE: [mailop] IPv6 DNSBL
Maybe you did not understand my message. I know what you say. However: I see a message from a list as a message-from-a-list , not as a forwarded-message-from-a-list-user. Because: How can a user authorize someone to send a message on behalf of his/her name (by sending an email). This should not ever happen. Example: A bank sends me an email which was authorized (in some way). I now forward this message. The message is genuinely not modified. But it still does not authorize me to send this email pretending to be the bank, even if it is the same message. Conclusion: If an email was sent by me, it should be authorized/authenticated by me. For mailing lists you might want to indicate that the message can be interpreted as being forwarded for a specific user. In that way the user-interface of the email client can reply to a user directly instead of the mailing list. If that is what one wants. David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -Oorspronkelijk bericht- Van: John Levine [mailto:jo...@taugh.com] Verzonden: Monday, March 31, 2014 4:47 PM Aan: mai...@mailop.org CC: David Hofstee Onderwerp: Re: [mailop] IPv6 DNSBL >I don't see how forwarding should break authentication. This is SPF's famous limitation. It's been debated to death, no need to rerun the argument again. DKIM survives normal forwarding, which was one of its design goals, but mailing lists typically modify the message by adding subject tags or message footers, stripping attachments, and the like, which breaks the incoming signature. That's been debated to death, too. It always seemed to me that lists should sign their mail, publish SPF for the lists's bounce addresses, and recipients would use the list's reputation to filter, Some people apparently have a security model I don't understand that evaluates the spamminess of list messages by the presence of signatures from the individual contributors. R's, John
RE: yahoo.fr is no longer interested in your abuse reports.
Yahoo.fr has the p=none policy: $ dig txt _dmarc.yahoo.fr +short "v=DMARC1\; p=none\; pct=100\; rua=mailto:dmarc-yahoo-...@yahoo-inc.com\;"; So there might be some abuse still there ;-). David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -Oorspronkelijk bericht- Van: NANOG [mailto:nanog-boun...@nanog.org] Namens Rich Kulawiec Verzonden: Friday, June 13, 2014 10:31 AM Aan: nanog@nanog.org Onderwerp: Re: yahoo.fr is no longer interested in your abuse reports. On Wed, Jun 11, 2014 at 01:00:58PM -0700, goe...@anime.net wrote: > Looks like they've finally completely blocked off their abuse mailboxes. That's not a problem. Now that Yahoo has deployed DMARC, all the spam, phishing, carding, stalking, kiddie porn, fraud, and other choice bits of unpleasantness that they've either emitted or provided dropboxes for over the past many years have disappeared completely and permanently. You will never need to report any kind of abuse to them ever again. ---rsk
RE: Feedback Requested: Routing Resilience Manifesto
About #3... I had a little discussion on abuse-wg@RIPE a while ago about keeping records up to date and relevant. See below. Nobody at RIPE cares much at the moment (to actually pick up this subject). Maybe they need a push with a TerexRH400. David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -ctrl-v Hi Frederik, Who has an interest in a clean database? The sloppy Org or Ripe? The answer is Ripe, therefore it should also spend energy [via Ripe Ncc] in (making sure that Orgs are) keeping it clean. Kids do not grow up themselves, it requires an active process. Organisations are not much different. David -Oorspronkelijk bericht- Van: Fredrik Widell [mailto:fred...@resilans.se] Verzonden: vrijdag 15 maart 2013 10:37 Aan: MailPlus| David Hofstee CC: anti-abuse...@ripe.net Onderwerp: RE: [anti-abuse-wg] Abuse Reporting Issues On Fri, 15 Mar 2013, MailPlus| David Hofstee wrote: Well, that is probably more a sign of a sloppy organisation, it is up to the LIR to keep the ripedb up to date, this is not the role of RIPE. You probably dont expect RIPE to keep track of your old DNS-entrys and give you a phone-call if it seems that a customer-name is wrong do you? > Hi Frederik, > > I am such a person (DH3195-RIPE). I entered my email a long time ago. Unlike > passwords that expire and accounts that get locked when not used, this vital > contact info is never re-validated. We never get mail that says: "Ripe wants > to confirm that you are still having Role X in your organisation. Click here > to confirm.". A full-inbox bounce could trigger a phone call. Etc. Ripe > should charge money for not keeping records up to date. > > In my (ESP) world, an email address that has not been used by the list-owner > for over a year is a risk for a spam trap ;-). > > Bye, > > David -ctrl-v -Oorspronkelijk bericht- Van: NANOG [mailto:nanog-boun...@nanog.org] Namens Andrei Robachevsky Verzonden: Wednesday, July 2, 2014 4:24 PM Aan: NANOG Onderwerp: Feedback Requested: Routing Resilience Manifesto Colleagues, A small group of network operators has been working on defining a minimal, but feasible package of recommended measures that, if deployed on a wide scale, could result in visible improvements to the security and resilience of the global routing system. Many operators are ahead of the curve and already implement much more than the proposed recommendations. But we believe that gathering support for these relatively small steps could pave the road to more significant actions on a global scale. We called this set of recommendations a Routing Resilience Manifesto - you can find a draft document here: https://www.routingmanifesto.org/. This initial version of the Manifesto was drafted by a small group, but we need a wider community review, your feedback, and, ultimately, your support to make this initiative fly. It was already presented at several venues, like RIPE and NANOG, and now we open it for a more detailed review. Please note that this is very much a work in progress. Please review the document and provide your feedback and text suggestions online or via routingmanife...@isoc.org by 31 August 2014. Regards, Andrei Robachevsky Internet Society
RE: no more "Send through Gmail" option
It is Google's problem. Because they need to check every time, before sending, if they are allowed to send emails. Otherwise they would/could be spamming (depends on your favorite definition of spam). David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -Oorspronkelijk bericht- Van: NANOG [mailto:nanog-boun...@nanog.org] Namens Royce Williams Verzonden: Saturday, September 6, 2014 1:27 AM Aan: Hugo Slabbert CC: NANOG Onderwerp: Re: no more "Send through Gmail" option On Fri, Sep 5, 2014 at 3:01 PM, Hugo Slabbert wrote: >> If it really was more the former, there would be a "if your SPF >> records include:_spf.google.com, you can still do it" option, IMO. > ... > Manager: Works for me. The scenario largely rings true, except that I would think it reasonable to tell people that it if it breaks because they added DKIM, it's not Google's problem to fix. ...
anyone from vodafone(.nl) around?
Hi, Is anyone from Vodafone around? We are having connectivity loss with smtp.vodafone.nl and the helpdesk is not cooperating... David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP)
RE: Industry standard bandwidth guarantee?
-Oorspronkelijk bericht- Van: NANOG [mailto:nanog-boun...@nanog.org] Namens Joe Greco Verzonden: Friday, October 31, 2014 12:02 PM Aan: Rafael Possamai CC: keith tokash; nanog@nanog.org Onderwerp: Re: Industry standard bandwidth guarantee? ... >> A silly example would be this: you fill your gas tank with 12 gallons... >> After driving until it's empty, your engine only used an average of 6 >> gallons to actually move you from point A to point B. The other 6 were >> just wasted in form of heat. Do you ask for your money back at the gas >> station? >> Or maybe you invest in a hybrid car? > >That *is* a silly example. > >A more proper analogy would be that you buy 12 gallons of gas, but the station >only deposits 11 gallons in your tank because the >pumps are operated by gasoline engines and they feel it is fine to count the >number of gallons pulled out of their tank instead of the amount given to the >customer. And bits/s is exactly what you get. With your example: You don't get kilometers at the gas stations, you get quantities of gas (e.g. a liter). And depending on a lot of factors, you get a distance from that quantity. David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP)
RE: Mozilla performing pdf.js DNS queries?
Pdf is quite a standard. One might wonder what it cannot do. One could call it evil. http://superuser.com/questions/368486/link-to-image-within-pdf-and-have-the-image-displayed David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -Oorspronkelijk bericht- Van: NANOG [mailto:nanog-boun...@nanog.org] Namens Seth Mos Verzonden: Thursday, November 13, 2014 2:26 PM Aan: NANOG list Onderwerp: Mozilla performing pdf.js DNS queries? Hi, Whilst rummaging through some DNS (dnsmasq) logs I've noticed quite a decent amount of queries for pdf.js from what appear to be mozilla browsers. Seems rather odd that it is performing DNS queries for a internal PDF viewer. Has anyone else come across these lookups? Kind regards, Seth
RE: DDOS solution recommendation
Hi Mike, About trying to hit the mail ports... It is very easy for a domain to set its MX to a random host name. So before you block you might want to check the To-domain in the header of the mail. Otherwise it is too easy to DoS yourself (by planting email addresses in systems, such as mine, and then changing the MX of that domain to your hosts). David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -Oorspronkelijk bericht- Van: NANOG [mailto:nanog-boun...@nanog.org] Namens Mike Hammett Verzonden: Sunday, January 11, 2015 2:46 PM Aan: Roland Dobbins CC: nanog@nanog.org Onderwerp: Re: DDOS solution recommendation Well there's going to be two sources of the attack... infested clients or machines setup for this purpose (usually in a datacenter somewhere). Enough people blackhole the attacking IPs, those IPs are eventually going to have a very limited view of the Internet. They may not care of it's a server in a datacenter being used to attack, but an infested home PC would care once they can't get to Google, FaceBook, Instagram, whatever. If the attacker's abuse contact doesn't care, then just brute force of more and more of the Internet being offline to them, they'll figure it out. You hit my honeypot IPs, blackholed for 30 days. You do a DNS request to my non-DNS servers, blackholed for 30 days. Same goes for NTP, mail, web, etc. You have more than say 5 bad login attempts to my mail server in 5 minutes, blackholed for 30 days. You're trying to access various web pages known for home router or Wordpress exploitation, blackholed for 30 days. No point in letting troublemakers (manual or scripted) spend more time on the network than necessary. The more people (as a collective or not) that do this, the better. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com - Original Message - From: "Roland Dobbins" To: nanog@nanog.org Sent: Sunday, January 11, 2015 7:24:55 AM Subject: Re: DDOS solution recommendation On 11 Jan 2015, at 20:07, Mike Hammett wrote: > but I'd think that if their network's abuse department was notified, > either they'd contact the customer about it issue or at least have on > file that they were notified. Just because we think something, that doesn't make it true. ;> > The way to stop this stuff is for those millions of end users to clean > up their infected PCs. You may want to do some reading on this topic in order to gain a better understanding of the issues involved: <https://app.box.com/s/4h2l6f4m8is6jnwk28cg> Some of us have been dealing with DDoS attacks for a couple of decades, now. If it were a simple problem, we would've solved it long ago. Here's a hint: scale alone makes any problem literally orders of magnitude more difficult than any given instance thereof. --- Roland Dobbins
RE: Usage Graphing per Subnet
http://graphviz.org/ David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -Oorspronkelijk bericht- Van: NANOG [mailto:nanog-boun...@nanog.org] Namens Methsri Wickramarathna Verzonden: Tuesday, February 17, 2015 12:36 PM Aan: nanog@nanog.org Onderwerp: Usage Graphing per Subnet Hi All, I have a requirement to plot a usage graph per subnet. As an example. I have a 192.168.1.0/24 subnet divided among 32 customers where each one will get a /29 [ 192.168.1.0/29 => Customer A ; 192.168.1.8/29 => Customer B etc... ] ... Is there any tool to graph the usage of entire /24 subnet ??? -- -- ~~( ŊëŌ )~~
RE: AOL Postmaster
Same here. I want to solve things that they seem to have issues with. But when I ask what is wrong they either don't respond (in any meaningful manner) or say that they 'solved it', without me ever knowing what 'it' was. I prefer swimming in seaweed instead of contacting Yahoo (or MS for that matter). And the seaweed here is quite gross. David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -Oorspronkelijk bericht- Van: NANOG [mailto:nanog-boun...@nanog.org] Namens Fred Verzonden: Tuesday, February 24, 2015 3:19 AM Aan: nanog@nanog.org Onderwerp: Re: AOL Postmaster Having exactly the same issue. Also never received any response from AOL. Quite annoying. John Zettlemoyer: > No, started using an IP address that hasn’t been used since we got the > range from Arin, and got this - 554- (RTR:BL) Tried to contact AOL through > normal channels, and no response in over a week. Feedback loop has been in > place for years, and we check it every day (its clean). > > John Zettlemoyer > > > From: Bill Patterson [mailto:billpatterso...@gmail.com] > Sent: Monday, February 23, 2015 3:46 PM > To: John Zettlemoyer > Cc: nanog@nanog.org > Subject: Re: AOL Postmaster > > Did you suddenly start getting "AOL will not accept delivery of this message" > bounce backs? > On Feb 23, 2015 3:30 PM, "John Zettlemoyer" wrote: > Could someone from AOL who deals with the email systems please contact me > off-list. > Thank you. > > John Zettlemoyer > WCiT LLC > 856.310.1375 x221 > j...@wcit.net >
RE: outlook.com outgoing blacklists?
Hi Matthew, I'm pretty sure your 'gkstream.com' is wrong and that he means qkstream.com (see https://www.robtex.com/en/advisory/ip/66/171/128/130/ ). That does not seem broken. I do wonder if this domain qkstream.com used to be squatted? David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -Oorspronkelijk bericht- Van: NANOG [mailto:nanog-boun...@nanog.org] Namens Matthew Petach Verzonden: Thursday, September 10, 2015 3:20 PM Aan: Todd K Grand CC: nanog@nanog.org Onderwerp: Re: outlook.com outgoing blacklists? On Wed, Sep 9, 2015 at 9:49 AM, Todd K Grand wrote: > I have an email server which hosts 3 domains. > I have reason to believe that microsoft maintains an outgoing blacklist and > would like confirmation on this. > > I have had many a report that people on domains hosted on hotmail/outlook are > getting messages bounced back stating that our server was unreachable. > This only happens for one of the three domains hosted on our server. > > I went to outlook.com and setup an account. > When I create a new message and enter the recipient at that affected > domain, the address immediately turns red, and when I hover over it states > that the address may not be valid. > This happens without ever sending a packet to our servers. > The affected domain can send emails to hotmail/outlook accounts just fine. > > Anybody have some recommendations on how I resolve this, as Microsoft support > seems to be under technical. > > Thanks, > > Todd K. Grand > Certainly looks to be broken to me: mpetach@hinotori:~> nslookup -q=any gkstream.com Server: 8.8.8.8 Address:8.8.8.8#53 Non-authoritative answer: Name: gkstream.com Address: 185.53.179.7 gkstream.comnameserver = ns1.parkingcrew.net. gkstream.comtext = "v=spf1 ip6:fd1b:212c:a5f9::/48 -all" gkstream.comnameserver = ns2.parkingcrew.net. gkstream.com origin = ns1.parkingcrew.net mail addr = hostmaster.gkstream.com serial = 144189 refresh = 28800 retry = 7200 expire = 604800 minimum = 86400 Authoritative answers can be found from: mpetach@hinotori:~> mpetach@hinotori:~> traceroute gkstream.com traceroute to gkstream.com (185.53.179.7), 64 hops max, 40 byte packets 1 ws1 (69.36.244.130) 1 ms 1 ms 1 ms 2 s0-0-0-2.core1.sjc.layer42.net (69.36.238.33) 4 ms 4 ms 4 ms 3 ge2-48.core1.sv1.layer42.net (65.50.198.5) 4 ms 4 ms 4 ms 4 te0-0-0-18.ccr21.sjc04.atlas.cogentco.com (38.104.141.145) 6 ms 41 ms 73 ms 5 be2015.ccr21.sfo01.atlas.cogentco.com (154.54.7.173) 47 ms (TOS=40!) 7 ms 7 ms 6 be2132.ccr21.mci01.atlas.cogentco.com (154.54.30.54) 57 ms 57 ms 57 ms 7 be2156.ccr41.ord01.atlas.cogentco.com (154.54.6.86) 57 ms 70 ms 57 ms 8 be2351.ccr21.cle04.atlas.cogentco.com (154.54.44.86) 75 ms 64 ms 67 ms 9 be2596.ccr21.yyz02.atlas.cogentco.com (154.54.31.54) 71 ms 71 ms 71 ms 10 be2090.ccr21.ymq02.atlas.cogentco.com (154.54.30.206) 84 ms 121 ms 161 ms 11 be2384.ccr21.lpl01.atlas.cogentco.com (154.54.44.138) 150 ms 150 ms 151 ms 12 be2182.ccr41.ams03.atlas.cogentco.com (154.54.77.245) 170 ms 170 ms 169 ms 13 be2261.ccr41.fra03.atlas.cogentco.com (154.54.37.30) 164 ms 164 ms 164 ms 14 be2228.ccr21.muc03.atlas.cogentco.com (154.54.38.50) 174 ms 174 ms 174 ms 15 te0-0-0-2.agr12.muc03.atlas.cogentco.com (154.54.56.222) 173 ms te0-0-0-2.agr11.muc03.atlas.cogentco.com (154.54.56.206) 191 ms te0-0-0-2.agr12.muc03.atlas.cogentco.com (154.54.56.222) 174 ms 16 154.25.8.26 (154.25.8.26) 170 ms 154.25.8.22 (154.25.8.22) 175 ms 154.25.8.26 (154.25.8.26) 170 ms 17 149.6.156.195 (149.6.156.195) 175 ms 149.6.156.202 (149.6.156.202) 173 ms 174 ms 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 *^C * 26 ^C mpetach@hinotori:~> mpetach@hinotori:~> telnet gkstream.com 25 Trying 185.53.179.7... telnet: Unable to connect to remote host: Connection timed out mpetach@hinotori:~> Matt
Trusted Networks Initiative: DDoS fallback set of AS'es
Hi, I saw the following and thought it would be interesting to share. In case of a persistent DDoS an ASy can fallback to a small set of (more trustable) AS'es for their routing: http://www.trustednetworksinitiative.nl/ They have a policy with procedural and technical parts, which may be upgraded later, for parties who want to participate: https://www.thehaguesecuritydelta.com/images/20141124_Trusted_Networks_Policy_beta-vs0_7.pdf Without having an opinion if everybody in the world should join this (I don't know the desired scope of this group), but the idea is interesting. I had not seen something like it before. Yours sincerely, David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP)
RE: most accurate geo-IP source to build country-based access lists
4. There are no Russian IPs in Crimea? David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -Oorspronkelijk bericht- Van: NANOG [mailto:nanog-boun...@nanog.org] Namens Måns Nilsson Verzonden: Monday, June 8, 2015 4:23 PM Aan: Martin T CC: nanog@nanog.org Onderwerp: Re: most accurate geo-IP source to build country-based access lists Subject: most accurate geo-IP source to build country-based access lists Date: Mon, Jun 08, 2015 at 05:11:15PM +0300 Quoting Martin T (m4rtn...@gmail.com): > Are there any other possibilities to geolocate IPv4 addresses with > higher accuracy? There are three levels of untruth: (in increasing order of falseness) 1. No, mom, I did not eat the pie. 2. "There are no Russian soldiers in Crimea" 3. IP Geolocation -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 GOOD-NIGHT, everybody ... Now I have to go administer FIRST-AID to my pet LEISURE SUIT!!
RE: free Tools to monitor website performance
We use Zabbix for local monitoring. Quite powerful (Nagios crapped out a lot on larger setups, although 300 is not large). There is a learning curve for Zabbix. We have a few VPS'es outside our network for DNS reasons. They are configured as (pushing) monitoring nodes too. Bye, David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -Oorspronkelijk bericht- Van: NANOG [mailto:nanog-boun...@nanog.org] Namens sathish kumar Ippani Verzonden: Thursday, August 6, 2015 4:24 AM Aan: nanog@nanog.org Onderwerp: free Tools to monitor website performance Hi All, Thanks to all for reviewing my topic, may it is slightly off topic. We have almost 300 URL's (local and web) and we want to monitor few of them which are very critical URL's for web access and local access. I would like to know is there any free tool or software with I can use to monitor url performance in terms of response time. Which gives more information like how much time it taken to connect the server and time to load the page and total response time. Thanks in advance. -- With Regards, Sathish Ippani
RE: Customer Support Ticketing
Hi Paul, I formerly worked at Topdesk http://www.topdesk.co.uk/. I use it at my current employer. It has a nice webbased GUI. It is not a simplistic IT helpdesk type of software (and therefore not ultra cheap). I don't know much about integration options (used to be fairly ok). If you get crazy prices then nag a little longer (and mention competitors). They have all the features you want: Create tickets from email, SLA, change management, escalation, ... I am a real complainer but I am quite happy with it. Another thing I noticed in the past is ManageEngine. I liked it but know not much about it. David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -Oorspronkelijk bericht- Van: Paul Stewart [mailto:p...@paulstewart.org] Verzonden: Wednesday, March 19, 2014 3:01 PM Aan: nanog@nanog.org Onderwerp: Customer Support Ticketing Hey folks…. We need a new customer ticketing system and I’m looking for input. I am still working on a scope document on everything we want to do with the new system. The most common problem I run across is that a system is either built for enterprise internal IT helpdesk or it is built like a CRM sales tracking system. We are an ISP among other things and are looking for a powerful and yet reasonable cost system to answer email inquiries, allow customers to open tickets via portal, mobile support, escalation/SLA support, and several other things. Solarwinds NPM integration would be a huge bonus but not a deal breaker. If anyone has a system that they have integrated with Ivue from NISC (our billing platform) I would be really interested in hearing more as well. So my question is meant high level. For those folks that are ISP’s supporting business customers (including managed customers) along with residential eyeball traffic what system(s) do you use and what do you like/dislike? I’ve looked so far at WHD (Solarwinds product), OTRS, RT, RemedyForce, ZenDesk, HappyFox, Kayako and several others. All of them so far would require a fair amount of configuration or modifications based on our still developing wish list. Also worth noting is that we have no full time development staff so hoping to find something that has a lot of promise and then work with the vendor to evolve it into what we feel we need. **This is not an invitation for sales folks to call on me** Thanks, Paul
RE: why IPv6 isn't ready for prime time, SMTP edition
>Lacking reverse should be one of many things to consider with rejecting >e-mails, but should not be the only condition. And your opinion is just another one. Someone else has a different one. Resulting in the mess email is now. You won't believe the crap I read in bounces (it also gives a funny insight into the email chain/setup of a company). Email security (against spam) should be fixed. Properly. Fine grained complaining should be possible (to the sender and all intermittent parties, as well as external parties). Make some RFCs that work please. David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -Oorspronkelijk bericht- Van: Brielle Bruns [mailto:br...@2mbit.com] Verzonden: Tuesday, March 25, 2014 9:57 PM Aan: nanog@nanog.org Onderwerp: Re: why IPv6 isn't ready for prime time, SMTP edition On 3/25/14, 11:56 AM, John Levine wrote: > I think this would be a good time to fix your mail server setup. > You're never going to get much v6 mail delivered without rDNS, because > receivers won't even look at your mail to see if it's authenticated. > > CenturyLink is reasonably technically clued so it shouldn't be > impossible to get them to fix it. Nothing wrong with my mail server setup, except the lack of RDNS. Lacking reverse should be one of many things to consider with rejecting e-mails, but should not be the only condition. That would be like outright refusing mail unless it had both SPF and DKIM on every single message. Sure, great in theory, does not work in reality and will result in lost mail from legit sources. Already spoken to CenturyLink about RDNS for ipv6 - won't have rdns until native IPv6. Currently, IPv6 seems to be delivered for those who want it, via 6rd. And, frankly, I'm not going to get in a fight with CenturyLink over IPv6 RDNS, considering that I am thankful that they are even offering IPv6 when other large providers aren't even trying to do so to their residential and small business customers. It is very easy for some to forget that not everyone has a gigabit fiber connection to their homes with ARIN assigned IPv4/IPv6 blocks announced over BGP. Some of us actually have to make do with (sometimes very) limited budgets and what the market is offering us and has made available. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org/ http://www.ahbl.org
RE: why IPv6 isn't ready for prime time, SMTP edition
You only need Hotmail, Gmail, Yahoo on board and everyone will follow... They might even be able to dictate new SMTP RFCs. David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) -Oorspronkelijk bericht- Van: Jimmy Hess [mailto:mysi...@gmail.com] Verzonden: Wednesday, March 26, 2014 4:17 AM Aan: John R. Levine CC: NANOG list Onderwerp: Re: why IPv6 isn't ready for prime time, SMTP edition On Tue, Mar 25, 2014 at 9:55 PM, John R. Levine wrote: > I would suggest the formation of an "IPv6 SMTP Server operator's club," >> with a system for enrolling certain IP address source ranges as >> "Active > > Surely you don't think this is a new idea. > Would it make it more unique; if I suggested creation of a new distributed Cryptocurrency something like 'MAILCoin' to track the memberships in the club and handle voting out of abusive mail servers: in a distributed manner, to ensure that no court could ever mandate that a certain IP address be accepted into the club? Not necessarily. But I haven't yet heard of any meaningful attempt to implement something like that. Obviously with IPv4; way too many "legacy" mail servers exist that will never bother to implement new protocols and practice improvements even basic things, such as SMTP rejecting invalid recipients instead of sending unsolicited bounce replies to senders (forged by spammers). > R's, > John -- -JH
Contact person for doh.state.fl.us
Hi, Does anyone know a contact for doh.state.fl.us? I tried to contact them after we received this interesting line of logfile: "554 5.7.1 46.31.52.10 (in 46.0.0.0/8) is blacklisted." received from mx5201.doh.state.fl.us (74.174.235.12) Thanks in advance, David Hofstee MailPlus B.V. Netherlands
RE: Contact person for doh.state.fl.us
Hi, Thanks for the contact info. There is a slight detail that you may have missed (I'm pretty sure it is not our reputation that is an issue). 1/256th part of the internet is being blocked. We are not the owner of 46.0.0.0/8. David P.S. The honeypot stuff was a typo by someone at a fair. He entered a .nl domain when it should have been .com ; the .nl domain was given to honeypot. The same contact was also registered later with the .com extension. Sometimes stupidity overcomes malice. -Oorspronkelijk bericht- Van: asko...@gmail.com [mailto:asko...@gmail.com] Namens Alex Brooks Verzonden: donderdag 20 december 2012 13:54 Aan: MailPlus| David Hofstee Onderwerp: Re: Contact person for doh.state.fl.us Hi, On Thu, Dec 20, 2012 at 9:46 AM, MailPlus| David Hofstee wrote: > Hi, > > > > Does anyone know a contact for doh.state.fl.us? I tried to contact them after > we received this interesting line of logfile: > > > > "554 5.7.1 46.31.52.10 (in 46.0.0.0/8) is blacklisted." received from > mx5201.doh.state.fl.us (74.174.235.12) > > Thanks in advance, > > David Hofstee > MailPlus B.V. Netherlands Well, it's informationtechnol...@doh.state.fl.us but if you're blacklisted that's not going to help you. Fist off, this is probably because they think you are spamming. Have a look at http://www.projecthoneypot.org/ip_46.31.52.11 and http://ip.robtex.com/46.31.52.11.html#blacklists Once you have sorted that out, then you can try getting in touch if they haven't unblocked you. Try ringing +1-850-245-4233 and asking to speak to the 'service desk' about an 'email issue'. If that doesn't work, try +1-850-245-4975 then +1-850-245-5813. These are all numbers for their IT service; the first is the main number, then infrastructure support, then application support. If that doesn't work, nicholas.pl...@dms.myflorida.com is involved in the management of the Florida Government's links to the Internet; he should be able to forward you to the right people. As a last resort, you can try their IT contractor, Hayes Computer Services on +1-850-297-0551. I wish you the best of luck, do post back and let everyone know if you get in touch. Alex
RE: 40 GBit @ 240 GHz across 1 km LoS
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=1139451&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D1139451 -Oorspronkelijk bericht- Van: Phil Fagan [mailto:philfa...@gmail.com] Verzonden: vrijdag 17 mei 2013 13:32 Aan: Eugen Leitl CC: NANOG Onderwerp: Re: 40 GBit @ 240 GHz across 1 km LoS Congrats! How does 240Ghz react to atmospheric conditions other than "clear skys?" On May 17, 2013 4:17 AM, "Eugen Leitl" wrote: > > Fraunhofer: > > http://www.iaf.fraunhofer.de/de/news-medien/pressemitteilungen/presse- > 2013-05-16.html > > Google Translate: > > New world record in data transmission by radio > > Press Release 16/05/2013 > > With a Langstreckendemonstrator between two skyscrapers in Karlsruhe, > a distance of over a kilometer could already be bridged. © KIT > > The RF chip is only 4 x 1.5 mm2 large, since electronic components > with the frequency or wavelength scale. > > © Fraunhofer IAF > > Researchers at the Fraunhofer Institute for Applied Solid State > Physics IAF and the Karlsruhe Institute of Technology KIT, it is able > to transmit 40 Gb / s at 240 GHz and over a distance of one kilometer > by radio. With its recent demonstration they have achieved a new world > record and establish for the first time seamlessly with the capacity > of fiber to. Such future radio links could close gaps in the provision > of broadband Internet by the wireless links complement the network of > hard to reach areas or in rural areas. > > Digital, mobile and networked - the changing media usage behavior and > require progressively increasing faster data transfer rates. The > expansion of the fiber network in Germany is lagging behind European > standards, such as the statistics of the industry organization FTTH > Council Europe show. To lay fiber optic lines is expensive and in the > case of natural or urban obstacles such as rivers and transport hubs > difficult. Broadband radio links can help to overcome such critical > points and so promote the expansion of network infrastructures. In > rural areas, they provide a cost effective and flexible alternative to > "Fibre To The Home 'in the expansion of broadband network dar. > > In the data transmission by radio researchers have set a new world > record for the first time fully integrated electronic transmitter and > receiver are designed for a frequency of 240 GHz, with which the data > transfer rates up to > 40 Gbit s is / possible. This corresponds to the transfer of a full > DVD in less than a second or 2400 DSL16000 Internet connections. With > a Langstreckendemonstrator a distance of over a kilometer could > already be covered, which was built by the Karlsruhe Institute of > Technology between two skyscrapers in the "Milli Link" project. "We > have managed to develop a wireless link based on active electronic > circuits similar to high data rates, such as fiber optic systems, and > thus a seamless integration of the radio link allows" said Professor > Ingmar Kallfass, the project initially at Fraunhofer IAF in looking a > shared professorship - supported by IAF and KIT - coordinated. > Kallfass since 2013 has been working at the University of Stuttgart, > where he continued to lead the project. > > High frequencies allow fast data transfer > > The use of the high frequency range between 200 and 280 GHz not only > enables the fast transfer of large amounts of data, but also a very > compact technical structure. Since the dimensions of electronic > circuits and antennas scalable with frequency or wavelength of the > transmitter and receiver chip is 4 x > 1.5 > mm 2 in size. Developed at Fraunhofer IAF semiconductor technology > based on transistors with high electron mobility transistor (HEMT) > makes it possible to use the frequency range between 200 and 280 GHz > with active transmitters and receivers in the form of compact, > integrated circuits. In this frequency range, the atmosphere has low > attenuation values, so that broadband radio links are possible. "This > is our spark gap compared to optical data transmission systems easier > to align and work in bad weather conditions such as fog or rain," > explains Jochen antes from the KIT. > > So far, radio systems were not yet able to provide the bandwidth of an > optical fiber directly. That could change in the future, as the test > shows construction of the project. Such a powerful system possess the > advantage of the so-called bit transparency, ie, the signal could be > fed directly to a fiber without energy-intensive recoding in a radio > link, transmit and re-routed at the other end with a glass fiber. The > record data from the test set are just the beginning. "With an > improvement in spectral efficiency through the use of complex > modulation formats or combination of channels, ie multiplexing, we can > achieve even higher data rates, 'said Antes is safe. > This could be the expansion of broadba
RE: High throughput bgp links using gentoo + stipped kernel
This is what we do too: Separate firewalling and routing. We use Vyatta for both and it works. Bye, David -Oorspronkelijk bericht- Van: Matt Palmer [mailto:mpal...@hezmatt.org] Verzonden: zondag 19 mei 2013 23:32 Aan: nanog@nanog.org Onderwerp: Re: High throughput bgp links using gentoo + stipped kernel On Sun, May 19, 2013 at 11:48:17AM -0400, Nick Khamis wrote: > We do use a statefull iptables on our router, some forward rules... > This is known to be on of our issues, not sure if having a separate > iptables box would be the best and only solution for this? I don't know about "only", but it'd have to come close to "best". iptables (and stateful firewalling in general) is a pretty significant CPU and memory sink. Definitely get rid of any stateful rules, preferably *all* the rules, and apply them at a separate location. We've always had BGP routing separated from firewalling, but we're currently migrating from one-giant-core-firewall to lots-of-little-firewalls because our firewalls are starting to cry a little. Nice thing is that horizontally scaling firewalls is easy -- just whack 'em on each subnet instead of running everything together. Core routing is a little harder to scale out (although as has been described already, by no means impossible). The important thing is to remove *anything* from your core routing boxes that doesn't *absolutely* have to be there -- and stateful firewall rules are *extremely* high on that list. - Matt -- When the revolution comes, they won't be able to FIND the wall. -- Brian Kantor, in the Monastery
Dns sometimes fails using Google DNS / automatic dnssec
Hi, We've been seeing automatic RRSIG records on Google DNS lately, the 8.8.8.8 en 8.8.4.4. They are not always provided. They cause problems for some of our customers in a weird way I cannot explain. For them these records do not resolve but I cannot reproduce it. So when I run dig command dig @8.8.8.8 m1.mailplus.nl it often provides the RRSIG record (but e.g. the TXT record will not be signed). I've heard that DNS may fall back to TCP and/or may be filtered by firewalls if UDP is over 512 bytes. However, the request is not that long, about 200 bytes if I interpret the answer correctly. Can someone come up with a good explanation why a tiny percentage of our customers cannot resolve (some of) our domains? Btw, our nameservers (transip.nl) only provide DNSSEC records if explicitly asked. What is standard here? Thanks, David Hofstee
RE: Dns sometimes fails using Google DNS / automatic dnssec
root@e3:/home/services# dig @8.8.8.8 m1.mailplus.nl ; <<>> DiG 9.7.3 <<>> @8.8.8.8 m1.mailplus.nl ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38880 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;m1.mailplus.nl.IN A ;; ANSWER SECTION: m1.mailplus.nl. 1867IN A 46.31.50.16 m1.mailplus.nl. 1867IN RRSIG A 7 3 3600 20130517082302 20121115082302 3767 mailplus.nl. WzKY2FnTbF8MOhAuDvnrPkpgskeH4aI1YByh6zBX1z1pQRo8YIcxzlSN tHv2LnKUk+0n6iIXqV77sHynHHP/Y/a0bMKYKIDuK8Gtz47AVDJaU0eX 0FR8F5qqw897ClGf5ISa0njPLFVyF/NJ6hNViDYzOhhHGi58dhZmhKWF ujs= ;; Query time: 5 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Thu Nov 15 16:05:26 2012 ;; MSG SIZE rcvd: 219 --- David Hofstee -Oorspronkelijk bericht- Van: Yunhong Gu [mailto:g...@google.com] Verzonden: donderdag 15 november 2012 15:47 Aan: MailPlus| David Hofstee CC: nanog@nanog.org Onderwerp: Re: Dns sometimes fails using Google DNS / automatic dnssec Hi, David I work at Google Public DNS and will take a look at this issue. No RRSIG should be returned unless the client set the DO bit to ask for it. Thanks Yunhong On Thu, Nov 15, 2012 at 9:12 AM, MailPlus| David Hofstee wrote: > Hi, > > We've been seeing automatic RRSIG records on Google DNS lately, the 8.8.8.8 > en 8.8.4.4. They are not always provided. They cause problems for some of our > customers in a weird way I cannot explain. For them these records do not > resolve but I cannot reproduce it. > > So when I run dig command > > dig @8.8.8.8 m1.mailplus.nl > > it often provides the RRSIG record (but e.g. the TXT record will not be > signed). I've heard that DNS may fall back to TCP and/or may be filtered by > firewalls if UDP is over 512 bytes. However, the request is not that long, > about 200 bytes if I interpret the answer correctly. > > Can someone come up with a good explanation why a tiny percentage of our > customers cannot resolve (some of) our domains? > > Btw, our nameservers (transip.nl) only provide DNSSEC records if explicitly > asked. What is standard here? > > > Thanks, > > David Hofstee
RE: Dns sometimes fails using Google DNS / automatic dnssec
fixed... --- David Hofstee -Oorspronkelijk bericht- Van: Yunhong Gu [mailto:g...@google.com] Verzonden: donderdag 15 november 2012 18:29 Aan: Jay Ford CC: MailPlus| David Hofstee; nanog@nanog.org Onderwerp: Re: Dns sometimes fails using Google DNS / automatic dnssec Hi, we have found the bug that caused this problem. It was introduced in a very recent release. The fix is on its way. Thanks very much for the report, Yunhong On Thu, Nov 15, 2012 at 12:26 PM, Jay Ford wrote: > It looks like if the server has the RRSIG RR, it returns it. For example, a > query with +dnssec will cause it to cache the RRSIG, after which it returns > it even if +dnssec not specified. >
Fw: new message
Hey! New message, please read <http://azstar.1byteshy.com/finding.php?o> MailPlus David Hofstee
Fw: new message
Hey! New message, please read <http://ivcgrp.com/began.php?gpv5> MailPlus David Hofstee
