Re: sink.arpa question
Joe Greco wrote: >> On Fri, 18 Dec 2009, Jason Bertoch wrote: >> >>> Do metrics exist on how many current installs still rely on the implicit >>> MX? >>> >> It's very common for email from web servers to be poorly configured such >> that it uses the webserver's hostname as the return path's mail domain. >> > > It is very difficult to measure how many current installs rely on the > implicit MX, as someone else noted. > > On a somewhat different angle of attack: > > Even five years ago, it was considered mildly problematic to deploy a > hostname where the A pointed someplace incapable of receiving mail, > since some "products" (you know who you are) were so poorly written > and still in use that they would connect to the A (or "implicit MX" > if you prefer) even in the presence of MX records. > > Now that another five years have passed, it would be interesting to > see how many antiques are still sending e-mail AND are worth talking > to. I'm guessing not many. > > That suggests that it might well be fine to point A at something that > is not capable of receiving SMTP, as long as you have MX records. An > arrangement that should always have been practical, of course. > > Is anyone actually doing this? > > ... JG > I'd think this more than common - the A record for the domain quite often is set to point to the same IP as the www. A record where that server isn't running an smtp service. We've certainly got clients who do this, and haven't ever reported it causing problems = one example :- banquo>host -t A www.thehut.com www.thehut.com has address 89.234.46.152 banquo>host -t A thehut.com thehut.com has address 89.234.46.152 banquo>host -t MX thehut.com thehut.com mail is handled by 3 mail.thehutgroup.com. banquo>host -t A mail.thehutgroup.com. mail.thehutgroup.com has address 217.158.230.4 Regards Pete
Re: Chinese bgp metering story
> However, if they are after some consultancy time to write some useless > documents then I will happily take their money. i suspect their intelligence is far greater then your arrogance randy
Tools BOF at NANOG-48
Dear all, I am planning on organizing the Network Tools BOF at NANOG-48 with the objective of presenting interesting and useful non-commercial tools that have a fairly widespread appeal. Tool owners would make short presentations and show usefulness of the tool with case studies. If you have developed or know of a tool/package that you would like to include, please send me an email directly. As part of the tools BOF, I also plan to run a short 15-20 min "Tools roundup" outlining the most common non-commercial tools used for day to day networking tasks. The objective of this is not to present details of tools, but rather a rough taxonomy. Feel free to suggest tools you find useful. Thanks -Mohit
Re: sink.arpa question
> On Fri, 18 Dec 2009, Jason Bertoch wrote: > > Do metrics exist on how many current installs still rely on the implicit > > MX? > > It's very common for email from web servers to be poorly configured such > that it uses the webserver's hostname as the return path's mail domain. It is very difficult to measure how many current installs rely on the implicit MX, as someone else noted. On a somewhat different angle of attack: Even five years ago, it was considered mildly problematic to deploy a hostname where the A pointed someplace incapable of receiving mail, since some "products" (you know who you are) were so poorly written and still in use that they would connect to the A (or "implicit MX" if you prefer) even in the presence of MX records. Now that another five years have passed, it would be interesting to see how many antiques are still sending e-mail AND are worth talking to. I'm guessing not many. That suggests that it might well be fine to point A at something that is not capable of receiving SMTP, as long as you have MX records. An arrangement that should always have been practical, of course. Is anyone actually doing this? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: sink.arpa question
On Fri, 18 Dec 2009, Jason Bertoch wrote: > > Do metrics exist on how many current installs still rely on the implicit > MX? It's very common for email from web servers to be poorly configured such that it uses the webserver's hostname as the return path's mail domain. Tony. -- f.anthony.n.finchhttp://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.
RE: Chinese bgp metering story
However, if they are after some consultancy time to write some useless documents then I will happily take their money. -- Leigh Porter -Original Message- From: Randy Bush [mailto:ra...@psg.com] Sent: Sat 12/19/2009 11:42 AM To: North American Network Operators Group Subject: Re: Chinese bgp metering story i am truely in awe how deeply the implications and alternatives have been analysed. this is particularly impressive given the complete absense of any facts about the alleged proposal. randy
RE: Routing to multiple uplinks
Am I right in assuming that you're establishing application-layer sessions to two hosts with two different IP addresses (outside of your control) which provide (close to) identical services? If so, there's not much you can do outside of the application itself (at least if you want a semi-robust solution). You could try (reverse) load balancer, but even then the application session would have to be disconnected before being switched over to the other host. > As stated before Path A and Path B are two distinct paths they do however > provide identical services but application state is not preserved. A new > session and state must be established if a user decides to switch between > paths. Ivan Pepelnjak blog.ioshints.info / www.ioshints.info
RE: Routing to multiple uplinks
> The overall design is being driven by our rigorous application needs > more > than anything. > > The implementation is straight forward we receive a duplicate set of > feeds > from site A and site B and can also access various services coming from > site > A or site B however, at any given time a user will be sending/recieving > data > from one of those destinations. Never both simultaneously. So my > question > what is the best way to provide this type of redundancy at the host > level? > > The application will only use one target address. > You've stated two seemingly contradictory things. 1) The User decides which paths to take yet the 2) application cannot see more than one path. First, this sounds like a User issue. The application with such rigorous requirements should have the features you need to manage this. Barring that... :) The mechanism the User uses to (manually) decide which path to take should make the election and handle the switchover in visibility. Presumably, since your application cannot tell when its switched destinations/paths it needs to be notified if the network makes a VRRP/HSRP decision. This all points to the mechanism you presumably already have in place for manual path decisions. If you are using your Linux box or whatever to make your path choices, simply have a script that sees if the path preferences have changed and use your method to notify the Application. If you are using a Cisco (or other) dedicated router, run something on the Application box or servers that will notice this change (if even by querying the router) so it can proactively detect this. You've asked for a technical suggestion but have not provided any detail about the actual constraints you have -- though you've implied them without context. Deepak Jain AiNET
