is there anything special about zz.com?
Hello, [ insert decent apology here if this is unrelated. ] I am trying to find out whether there is anything special regarding zz.com that anyone who has seen attacks against their hosted dns servers. If there is anything you can think of please feel free to reply me offlist. thanks Mehmet
Re: DNS question, null MX records
On Wed, 16 Dec 2009, Douglas Otis wrote: > > To avoid server access and hitting roots: > > host-1.example.com. IN A 192.0.2.0 > host-10.example.com. IN A 192.0.2.9 > > example.com. IN MX 0 host-1.example.com. > example.com. IN MX 90 host-10.example.com. This is not very good from the point of view of a legitimate but mistaken sender, because their messages will be queued and retried. The advantage of pointing MX records at nonexistent hosts is most MTAs (and all common ones) will stop trying to deliver the message immediately. It is perhaps more polite to use a nonexistent name that you control, but that doesn't allow the source MTA to skip further DNS lookups, unlike the nullmx or sink.arpa ideas. Tony. -- f.anthony.n.finchhttp://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.
Re: Arrogant RBL list maintainers
on Wed, Dec 16, 2009 at 09:27:06PM -0500, Mike Lieman wrote: > > > > ...and if people used "static" and "dynamic" keywords in DNS as I suggested > > in my previously mentioned draft, > > What are the words for "static" and "dynamic" in Lower Sorbian? I was bored so I looked them up. :-) dynamic: dynamika static: statik Dynamic was easy, translate to German dynamik, then to Lower Sorbian. Static doesn't seem to translate directly (a translation for statische wasn't in the online dictionary I found, but statik was). Either way, it's actually pretty close to English. But the point stands; some synonyms for static tokens from around the world: biz bus client /cliente commercial / commercio corp corporate corporativo cust ded dedicated emp / empresa fija (South America) fix fixee (FR) fixo (PT-BR) fx (JP, often used with bflets) sta / stat / static and some for dynamics: da dhcp dia dial dinamic (South America) dip du / dup dyn dynamic / dynamicip pool res And again, that doesn't even begin to address the mixins like resnets and NATs and other weirdnesses that lie outside this simplistic dichotomy. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/
Re: Arrogant RBL list maintainers
> dynamic: dynamika > static: statik > One wonders how this will be handled when the flood of non-Latin domains starts. Are these RBL maintainers really going to figure out how many different ways there are to say the (English/Latin) equivalent of "static" in Chinese, Cyrillic, Swahili, etc. Cheers, Michael Holstein Cleveland State University
Re: DNS question, null MX records
On 12/17/09 4:54 AM, Tony Finch wrote: On Wed, 16 Dec 2009, Douglas Otis wrote: To avoid server access and hitting roots: host-1.example.com. IN A 192.0.2.0 host-10.example.com. IN A 192.0.2.9 example.com.IN MX 0 host-1.example.com. example.com.IN MX 90 host-10.example.com. This is not very good from the point of view of a legitimate but mistaken sender, because their messages will be queued and retried. The advantage of pointing MX records at nonexistent hosts is most MTAs (and all common ones) will stop trying to deliver the message immediately. It is perhaps more polite to use a nonexistent name that you control, but that doesn't allow the source MTA to skip further DNS lookups, unlike the nullmx or sink.arpa ideas. "." or "*.ARPA." are domains that won't resolve A records. Omit the A record in the above example accomplishes the same thing. DNS traffic can be reduced with long TTLs by using the TEST-NET technique. Pointing MX records toward root or ARPA domains exposes shared infrastructure to nuisance traffic from perhaps millions of sources expecting NSEC responses at negative caching rates. Traffic that should be handled by the name server declaring the service hostname. Better operators handling large email volumes reduce bounces and use retry back-off. Those who don't will find themselves disproportionally affected by a TEST-NET scheme. This seems to be a good thing, since there are far too many operators who carelessly accept email and expect others to deal with spoofed DSNs. Often the problem is due to serves being behind a border server lacking a valid recipient list that filters spam. The subsequent server with the valid recipient lists then aggressively attempts to deliver a growing number of DSNs having spoofed addresses holding spam that gets past filters. Why be friendly toward this type of behavior, especially at the expense of shared infrastructure? -Doug
sink.arpa question
Silly question: how well would using 1.0.0.257.in-addr.arpa match the need identified in draft-jabley-sink-arpa ? It seems like it would be equally well guaranteed to be non-existant (short of change in the def of IPv4 and in-addr.arpa). Like sink.arpa, it would get you a valid SOA and nothing else. Am I missing something, or is this operationally equivalent? regards, Ted
Re: sink.arpa question
On 2009-12-17, at 23:16, Ted Hardie wrote: > Silly question: how well would using 1.0.0.257.in-addr.arpa match the > need identified in draft-jabley-sink-arpa ? > > It seems like it would be equally well guaranteed to be non-existant > (short of change in the def of IPv4 and in-addr.arpa). Like > sink.arpa, it would get you a valid SOA and nothing else. > > Am I missing something, or is this operationally equivalent? That seems operationally equivalent, in the same way that sink.hopcount.ca doesn't exist. The philosophical difference is that (it is proposed that) SINK.ARPA be guaranteed never to exist, whilst it's conceivable I suppose that someone could one day propose a use for 257.in-addr.arpa and descendants. Joe
Re: sink.arpa question
Joe Abley wrote: > On 2009-12-17, at 23:16, Ted Hardie wrote: > >> Silly question: how well would using 1.0.0.257.in-addr.arpa match the >> need identified in draft-jabley-sink-arpa ? >> >> It seems like it would be equally well guaranteed to be non-existant >> (short of change in the def of IPv4 and in-addr.arpa). Like >> sink.arpa, it would get you a valid SOA and nothing else. >> >> Am I missing something, or is this operationally equivalent? > > That seems operationally equivalent, in the same way that sink.hopcount.ca > doesn't exist. > > The philosophical difference is that (it is proposed that) SINK.ARPA be > guaranteed never to exist, whilst it's conceivable I suppose that someone > could one day propose a use for 257.in-addr.arpa and descendants. I was actually thinking that what could be useful would be a generic way to signal that a service is not available. Something like "noservice" (actual label is not important) as the first label of any hostname. Then if you are a person of good will and see that MNAME or the RHS of an MX record is assigned to "noservice.example.com" you would know not to bother to try doing whatever you were trying to do (dynamic dns updates, deliver mail, etc.). I would think that further specifying that any hostname with "noservice" as the first/only label MUST resolve to 127.0.0.1, etc. I'm sure there are also some other rough edges I'm not thinking of from off the top of my head. If this is interesting I would volunteer to write a draft for it, hopefully with Joe's help? (Both since I'm poaching his idea and because he's really good at writing drafts.) Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/
Re: sink.arpa question
On Thu, Dec 17, 2009 at 03:16:12PM -0800, Ted Hardie wrote: > Silly question: how well would using 1.0.0.257.in-addr.arpa match the > need identified in draft-jabley-sink-arpa ? > > It seems like it would be equally well guaranteed to be non-existant > (short of change in the def of IPv4 and in-addr.arpa). Like > sink.arpa, it would get you a valid SOA and nothing else. > > Am I missing something, or is this operationally equivalent? > > regards, > > Ted which is likely to be a more persistent as a non-existant delegation? the forward space is almost entirely controlled by simple policy - while the reverse tree has some more structure around its non-existant state... imho of course. --bill
Re: sink.arpa question
On Thu, Dec 17, 2009 at 06:43:36PM -0800, Doug Barton wrote: > Joe Abley wrote: > > On 2009-12-17, at 23:16, Ted Hardie wrote: > > > >> Silly question: how well would using 1.0.0.257.in-addr.arpa match the > >> need identified in draft-jabley-sink-arpa ? > >> > >> It seems like it would be equally well guaranteed to be non-existant > >> (short of change in the def of IPv4 and in-addr.arpa). Like > >> sink.arpa, it would get you a valid SOA and nothing else. > >> > >> Am I missing something, or is this operationally equivalent? > > > > That seems operationally equivalent, in the same way that sink.hopcount.ca > > doesn't exist. > > > > The philosophical difference is that (it is proposed that) SINK.ARPA be > > guaranteed never to exist, whilst it's conceivable I suppose that someone > > could one day propose a use for 257.in-addr.arpa and descendants. > > I was actually thinking that what could be useful would be a generic > way to signal that a service is not available. Something like > "noservice" (actual label is not important) as the first label of any > hostname. Then if you are a person of good will and see that MNAME or > the RHS of an MX record is assigned to "noservice.example.com" you > would know not to bother to try doing whatever you were trying to do > (dynamic dns updates, deliver mail, etc.). > > I would think that further specifying that any hostname with > "noservice" as the first/only label MUST resolve to 127.0.0.1, etc. > I'm sure there are also some other rough edges I'm not thinking of > from off the top of my head. > > If this is interesting I would volunteer to write a draft for it, > hopefully with Joe's help? (Both since I'm poaching his idea and > because he's really good at writing drafts.) > > > Doug > > -- > > Improve the effectiveness of your Internet presence with > a domain name makeover!http://SupersetSolutions.com/ > I don't think we really want to see the return of the HINFO record do we? --bill
OT: Voice Equipment
Hi Nanogers, I am preparing for my CCIE Voice lab, which needs voice equipment hands on practice, and i don't have enough money to pursue that. Would it be possible if someone has spare phones like Cisco 7960g, PVDM modules, fxo/fxs VICs, mc3810 voice gateway, Digium T1/E1 card, 2621/3640 router or any other related equipment. I am in Pasadena, CA and can pick if available locally, or i would be happy to pay the shipping cost via paypal. Please send me any email off list. Thanks and appreciated. -aam
Re: DNS question, null MX records
On Thu, Dec 17, 2009 at 6:54 AM, Tony Finch wrote: > On Wed, 16 Dec 2009, Douglas Otis wrote: > more polite to use a nonexistent > name that you control, but that doesn't allow the source MTA to skip > further DNS lookups If you want to be kind, point the MX to an A record that resolves to 127.0.0.1. Common MX'es should immediately reject, and report a "configuration error"/MX loop with the domain. Your intent will also be clear, to just about everyone, it will be obvious the MX is intentionally broken. Other tricks may be more obscure, will be less obvious that you don't want mail, and may look like a mistake -- you might even get visitors to your domain contacting you to report the broken MX record. An alternative to resolving MX to an invalid IP might be to cut to the chase and just make further DNS lookups impossible altogether... @604800 IN MX MX.BOGUSMX BOGUSNS 604800 IN A 0.0.0.0 BOGUSMX 604800 IN NS BOGUSNS Or for that matter delegate the subdomain to 255.255.255.255. The recursive resolvers already have to immediately reject DNS delegation to broadcast addresses and the like. Though i'd be afraid of finding that some obscure resolver didn't.. [EG] "Gee thanks... some spammer exploited my open relay, and your broadcast NS delegation, caused my LAN to get swamped by my mail servers' DNS lookups while it was trying to send the 10 million spams to you" -- -J
Re: DNS question, null MX records
In message <6eb799ab0912172126g1eac7e49ve8f803552f6db...@mail.gmail.com>, James Hess writes: > On Thu, Dec 17, 2009 at 6:54 AM, Tony Finch wrote: > > On Wed, 16 Dec 2009, Douglas Otis wrote: > more polite to use a nonexisten > t name that you control, but that doesn't allow the source MTA to skip furt > her DNS lookups > If you want to be kind, point the MX to an A record that resolves to > 127.0.0.1. > Common MX'es should immediately reject, and report a "configuration > error"/MX loop with the domain. > > Your intent will also be clear, to just about everyone, it will be > obvious the MX is intentionally broken. Other tricks may be more > obscure, will be less obvious that you don't want mail, and may look > like a mistake -- you might even get visitors to your domain > contacting you to report the broken MX record. > > An alternative to resolving MX to an invalid IP might be to cut to the > chase and just make further DNS lookups impossible altogether... > > @604800 IN MX MX.BOGUSMX > BOGUSNS 604800 IN A 0.0.0.0 > BOGUSMX 604800 IN NS BOGUSNS > > Or for that matter delegate the subdomain to 255.255.255.255. > The recursive resolvers already have to immediately reject DNS > delegation to broadcast addresses and the like. > > Though i'd be afraid of finding that some obscure resolver didn't.. > > [EG] "Gee thanks... some spammer exploited my open relay, and your > broadcast NS delegation, caused my LAN to get swamped by my mail > servers' DNS lookups while it was trying to send the 10 million > spams to you" > > -- > -J Just document "MX 0 ." and be done with it. MTA and MUA vendors will update their products. Most caching nameserver negatively cache the non-existance of address records so the traffic is mostly between the non-updated MTA and the recursive server. 2 queries (A and ) every 3 hours won't kill the roots. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: OT: Voice Equipment
I would suggest renting the gear with rack time On Thu, Dec 17, 2009 at 11:37 PM, itservices88 wrote: > Hi Nanogers, > > I am preparing for my CCIE Voice lab, which needs voice equipment hands on > practice, and i don't have enough money to pursue that. Would it be > possible > if someone has spare phones like Cisco 7960g, PVDM modules, fxo/fxs VICs, > mc3810 voice gateway, Digium T1/E1 card, 2621/3640 router or any other > related equipment. > > I am in Pasadena, CA and can pick if available locally, or i would be happy > to pay the shipping cost via paypal. > > Please send me any email off list. > > Thanks and appreciated. > -aam >
