> On 21 May 2019, at 12:06, Tobi <jahli...@gmx.ch> <jahli...@gmx.ch> wrote: > > Hi Frank > > fully agree that this is very very very ugly. We never considered this a > "longterm" solution but just as a temporary fix until the problem is > solved upstream. > >> I managed an MSP for more than 15 years, we moved a lot of email as >> well, so I feel your pain. > > then you know its very hard to explain a customer why a certain sender > could not send him mail although the same mail arrives on his private > account with a big ESP. Or explain him why we cannot deliver his mail to > the recpient although when he sends from his ESP all works well :-)
Yes, and there are a lot of factors involved. If the reachability of that ISP really is the problem, then you’d need to fix your network. Fixing it on a DNS layer isn’t going to help much… Frank > > Thanks a lot for your detailed answer. We thought about iptables too, > but hoped that there is a pdns/dnsdist-only solution. Using iptables > makes that very ugly idea even worse ;-) > > > Have a good one > > -- > > tobi > > > Am 21.05.19 um 10:24 schrieb frank+pdns--- via Pdns-users: >> Hi Tobi, >> >> I managed an MSP for more than 15 years, we moved a lot of email as well, so >> I feel your pain. >> >> However, in all cases (about a hand-full that I can recall over that time) >> where we had real reachability issues, we routed the other AS using a >> different network path. In BGP speak: we preferred a different next-hop for >> that particular AS or prefix. This is still my advise to fix your problem >> and to be honest: it’s the only real fix. Because once you’ve solved the >> resolving problem, next up is the mail delivery problem: if you have issues >> reaching the nameservers of that particular network, you’re going to have >> issues reaching the mailservers as well. >> >> If you do want to solve at what I still feel is the incorrect place, and you >> don’t have the list of domain names only the ip-addresses of the >> nameservers, then things get complicated, as you need 2 dns requests, and >> that’s not something dnsdist would easily fix. >> >> What you might do, but again, this is very ugly and will bite you some day: >> >> I am just freewheeling here, no idea if this will actually work, there could >> be design flaws in here, disclaimer, yadayadayada. Imagine your primary >> resolver has ip 10.10.10.10, your backup resolver has ip 10.200.200.200, and >> 192.168.123.123 is the “problem ip” of the remote auth server. >> >> Setup: >> - ip 10.10.10.10 on eth0, pdns_recursor binds on port 53 of this ip and of >> localhost >> - add 10.10.10.11 as alias, dnsdist binds on port 53 of this ip. Make sure >> dnsdist uses ip 10.10.10.11 for all outbound ip connections >> - add an iptables dNAT rule to rewrite all packets with source ip >> 10.10.10.10, destination ip 192.168.123.123, destination port 53 to >> destination ip 10.10.10.11 >> >> >> Flow: >> - have the query arrive at the resolver ip >> - resolver will do it’s job, and notice that the auth NS has ip >> 192.168.123.123 >> - resolver dispatches the Q to the dnsdist on 192.168.123.123, which get >> rewritten to 10.10.10.11, our local dnsdist >> - dnsdist then dispatches the Q to 10.200.200.200 (you’d probably need to >> fiddle with the flags at this point). >> >> But again: this is ugly, very ugly, and I feel it’s the worst solution to >> your problem, in my 20+ years experience as a network engineer and >> MSP-manager. >> >> You might also get away with longer TTLs on the problematic NS records? >> >> Frank Louwers >> Certified PowerDNS Consultant @ Kiwazo.be >> >>> On 21 May 2019, at 07:51, Tobi <jahli...@gmx.ch> <jahli...@gmx.ch> wrote: >>> >>> Brian >>> >>>> In any case, it's the responsibility of the authoritative domain owner >>>> to host their domain on at least two different ASes (RFC 2182), if >>>> they care about people being able to resolve it. >>> >>> Full agree with that, but our customer is not interested why he cannot >>> send a mail to the other end of the world. It just needs to work :-) We >>> had such problems where after a 5 day investigation by our provider they >>> found out that such a BGP issue occured somewhere in the world with >>> their peering partner. >>> >>>> An authoritative server with that sort of limit, such as could affect >>>> a single end-user site, would be completely broken IMO. >>> >>> who said it's concerning my homebrew dns server? That issue occured on >>> our resolvers at the company where I work. We're working in email >>> filtering buissiness and we have quite a lot of dns queries per day. >>> >>> Frank >>> >>>> Note that the second reason you mention (src address rate limiting) >>>> won’t be fixed by implementing this solution… >>> >>> true, not fixed as in "not occur anymore" but fixed as in "more than one >>> src address --> more queries in total before per SRC address limits kick in" >>> >>> >>>> If you *do* want to solve it at the configuration layer: do you have a >>>> list of domains that should use the other resolver? >>> >>> thats our "problem": we only have the IP address(es) of the authorative >>> nameservers we want to reach via the 2nd resolver. >>> >>> >>> Cheers >>> >>> -- >>> >>> tobi >>> >>> Am 20.05.19 um 20:43 schrieb Brian Candler: >>>> On 20/05/2019 17:57, Tobi <jahli...@gmx.ch> wrote: >>>>> - BGP routing issues (ex from Provider 1 you can reach target and from >>>>> provider 2 not) >>>> >>>> That happens, but very rarely in my experience. In any case, it's the >>>> responsibility of the authoritative domain owner to host their domain on >>>> at least two different ASes (RFC 2182), if they care about people being >>>> able to resolve it. >>>> >>>>> - per SRC limits on the recipient side >>>> >>>> An authoritative server with that sort of limit, such as could affect a >>>> single end-user site, would be completely broken IMO. >>>> >>>> If you can replicate this issue, then I think it would be worth drilling >>>> down further with tests to prove or disprove these theories. It sounds >>>> more likely that the problem is local to you, either in your network, or >>>> with your upstream provider - especially if this affects a wide range of >>>> domains and not just a specific few. However, routing issues in your >>>> part of the world may be different to what I see here (in the UK). >>>> >>> _______________________________________________ >>> Pdns-users mailing list >>> Pdns-users@mailman.powerdns.com >>> https://mailman.powerdns.com/mailman/listinfo/pdns-users >> >> _______________________________________________ >> Pdns-users mailing list >> Pdns-users@mailman.powerdns.com >> https://mailman.powerdns.com/mailman/listinfo/pdns-users >> > _______________________________________________ > Pdns-users mailing list > Pdns-users@mailman.powerdns.com > https://mailman.powerdns.com/mailman/listinfo/pdns-users _______________________________________________ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
