Re: I got a live one! - Spam source

[Steve Linford]

On 25 Nov 2009, at 04:22, Russell Myba wrote:

Looks like of our customers has decided to turn their /24 into a  
nice little

space spewing machine.  Doesn't seem like just one compromised host.

Reverse DNS for most of the /24 are suspicious domains.  Each  
domain used in
the message-id forwards to a single .net which lists their mailing  
address

as a PO box an single link to an unsubscribe field.


Classic snowshoe spam setup, probably a professional snowshoe spam  
outfit known to Spamhaus as 'Tactara' and 'Webzero'.


Snowshoe spam operations operate by contacting ISP pretending to be  
'IP space brokers', they buy lots of IP space and have it all SWIPed  
in small chunks, mostly /24s, to an endless array of anonymous  
Wyoming and Delaware shell companies at UPS mailboxes. They then fill  
the /24s with freshly-registered 'nonsense' domains, tunnel into the  
server to hide their real location, and start the spamming. Usually  
almost every IP in the /24 has a spam cannon on it and a web page  
with just an 'unsubscribe' field.


They're the reason we created the CSS announced here:
http://www.spamhaus.org/news.lasso?article=646

(please don't follow up to this post here on NANOG, as NANOG is not  
an appropriate forum for spam discussions)


  Steve Linford
  The Spamhaus Project
  http://www.spamhaus.org

Re: I got a live one! - Spam source

[Rich Kulawiec]

On Wed, Nov 25, 2009 at 09:25:27AM -0800, Michael Peddemors wrote:
> I here people saying that they don't publish whois information because they 
> don't want the email's made public.  Okay, at least  the registered company 
> name, or individual who presented the ID should be there.  

Without delving too far into this: there is no point whatsoever in attempting
to conceal or obfuscate email addresses --not any more.  It is an obsolete,
"cargo cult" practice that many are still engaged in without grasping that
it was quite thoroughly defeated by spammers and their associates years ago.

That said, I concur in full with your opinions in re whois data and
the need to assign it properly.  I've long since stopped trying to
deal with missing information and have adopted the rule that if the
neighborhood looks sufficiently bad, I just block a /24 worth.  That
may sound arbitrary, but in practice it works extremely well.

---Rsk

Re: Who has AS 1712?

[Michael Dillon]

> How do you announce an ASN?

Using RSS.

Doesn't ARIN already announce all allocations via RSS?

--Michael Dillon

Re: What DNS Is Not

[David Conrad]

Hi,

On Nov 25, 2009, at 4:41 PM, Dan White wrote:
> On 25/11/09 14:17 -0800, David Conrad wrote:
>> On Nov 25, 2009, at 1:22 PM, Dan White wrote:
>>> Contact ICANN/IANA and plead with them to stop assigning any more resources
>>> to said ISP.
>> 
>> ICANN/IANA doesn't assign resources to ISPs.
> 
> Indirectly they're responsible for assignment of IP address,

In the sense that they allocate /8s (and, in IPv6, /12s) to the RIRs, sure.  
I'm just guessing but I don't think the RIRs would be very happy if ICANN/IANA 
were to refuse to allocate a /8 (or a /12) to an RIR because one of the RIRs' 
customers was hijacking NXDOMAINs.

> enterprise numbers,

Actually, ICANN/IANA assigns these directly (see http://pen.iana.org), but I 
suspect the folks in the IETF would get a bit distressed if ICANN/IANA started 
imposing restrictions on who could get PENs.

> domain names

ICANN/IANA is directly responsible for (and has contractual relationships with 
folks who operate) gTLDs and has, to the distress of some folks on this list, 
imposed restrictions on wildcards/synthesis/etc.  ICANN/IANA discourages 
wildcards/synthesis/etc for ccTLDs, but the operation of a ccTLD is considered 
a national sovereignty issue and thus, ICANN/IANA has no way to do anything 
other than point out the problems wildcards/synthesis/etc. can lead to.  As I 
write this, there are 11 ccTLDs that do wildcards/synthesis/etc. and there will 
undoubtedly be more in the future. ICANN/IANA has no interaction with, much 
less control, over ISPs.

> My point was there isn't really an authority to enforce rules on ISPs when
> it comes to how they manage their DNS servers.

Yep.

> Government and IANA won't be interested in fielding such complaints.

Government might -- politicians like to be seen solving problems, even if they 
haven't the slightest idea what the problem is, whether it actually is a 
problem, or how to go about fixing it.

With the exception of the gTLDs, ICANN/IANA simply can't -- it has no mechanism 
to do anything other than wag its finger.

> Shining a flash light on the problem publicly is going to be the best best.

There are folks on this list who work for ISPs which are doing 
wildcards/synthesis/etc.  They (or, more likely their management) can tell you 
there are obvious business reasons why they do wildcards/synthesis/etc.  
Perhaps I'm overly cynical, but I suspect that until those business reasons go 
away, shining a flash light will probably just result in more ISPs implementing 
wildcards/synthesis/etc. 

Regards,
-drc

Re: What DNS Is Not

[David Conrad]

On Nov 25, 2009, at 8:16 PM, Paul Vixie wrote:
> we have to fix DNS so that provider-in-the-middle attacks no longer work.
> (this is why in spite of its technical excellence i am not a DNSCURVE fan,
> and also why in spite of its technical suckitude i'm working on DNSSEC.)

As you know, as long as people rely on their ISPs for resolution services, 
DNSSEC isn't going to help.  Where things get really offensive if when the ISPs 
_require_ customers (through port 53 blocking, T-Mobile Hotspot, I'm looking at 
you) to use the ISP's resolution services.

Regards,
-drc

ARIN/RIPE NCC Joint Statement on ASN Assignment Discrepancies

[John Curran]

ARIN and the RIPE NCC have worked together to research the issues with
the Autonomous System Number (ASN) range AS1707-AS1726. Below is our
analysis of what happened and a plan to resolve these issues.

It appears that prior to 1993, Renater was issued AS1707 with an AS
name of "ASNBLOCKA".  This is the name format used to assign a block
of ASNs, but the DDN NIC (the Defense Data Network Network Information
Center, which was responsible for ASN assignments until 1993) recorded
only a single assignment of AS1707, rather than the entire block of 20
ASNs (AS1707-AS1726), as would have been expected. AS1712 was never
registered in the DDN NIC database.

Since the proper registration was never recorded, this mistake carried
over from the InterNIC database into ARIN's database at ARIN’s inception
in 1997. The ASN range was not transferred to the RIPE NCC along with
AS1707 because AS1708-AS1726 appeared to be unassigned, and thus
remained with ARIN.

Because this is simply an error in registry data and Renater is the
actual registrant of this entire range of ASNs (AS1707-AS1726), ARIN
will work with its customers who received ASNs from this range in July
and August of 2009 to provide them with replacement ASNs.  While we
understand that this may cause some difficulty for these customers, we
feel that this is the best path forward given the circumstances.

RIPE NCC and ARIN will update their respective databases and work with
the IANA to ensure that the ASN registry data is properly updated for
this range.

To prevent future issues, ARIN and RIPE NCC will implement two new
processes for issuing new ASNs: checking all other RIR databases to
ensure that the ASN is not previously registered, and checking BGP
routing tables to ensure the ASN is not already found in an announced
AS-path.  ASNs that fail either of these conditions will not be issued
until the discrepancy has been addressed.

Regards,
John Curran, President and CEO, ARIN
Axek Pawlik, Managing Director, RIPE NCC

Re: What DNS Is Not

[Paul Vixie]

> From: David Conrad 
> Date: Thu, 26 Nov 2009 07:42:15 -0800
> 
> As you know, as long as people rely on their ISPs for resolution
> services, DNSSEC isn't going to help.  Where things get really offensive
> if when the ISPs _require_ customers (through port 53 blocking, T-Mobile
> Hotspot, I'm looking at you) to use the ISP's resolution services.

the endgame for provider-in-the-middle attacks is enduser validators, which
is unfortunate since this use case is not well supported by current DNSSEC
and so there's some more protocol work in our future ("n!!").

i also expect to see DNS carried via HTTPS, which providers tend to leave
alone since they don't want to hear from the lawyers at 1-800-flowers.com.
(so, get ready for https://ns.vix.com/dns/query/www.vix.com/in/a&rd=1&ad=1).

Re: What DNS Is Not

[Florian Weimer]

* Jorge Amodio:

> What needs to be done to have ISPs and other service providers stop tampering
> with DNS ?

First, stop calling it "NXDOMAIN rewriting".  These guys are rewriting
everything they want, so that they can respond to your search queries,
or serve different ads to you.

Then try to opt out of rewriting for your own domains, asking the
offenders to stop doing it in your namespace, and if that doesn't
help, use the court system.  Fight your own fights, and don't expect
others to do it for you.  (Oh, in case you wonder---I can't, because
in Germany, registering a domain name does not grant you rights to
that name, even if you've been using it for quite a while.)

Re: What DNS Is Not

[Dan White]

On 26/11/09 07:37 -0800, David Conrad wrote:
There are folks on this list who work for ISPs which are doing wildcards/synthesis/etc.  They (or, more likely their management) can tell you there are obvious business reasons why they do wildcards/synthesis/etc.  Perhaps I'm overly cynical, but I suspect that until those business reasons go away, shining a flash light will probably just result in more ISPs implementing wildcards/synthesis/etc. 


That's a disagreement we'll have to have. Anytime this issue has been brought
up in a public setting (here, slashdot, etc.) has resulted in terrible press
and even corrective action. In particular, Network Solutions' attempt to
at this at the .com level was corrected. Of course I don't know what, if
any, ICANN pressure has to do with that, but the flash light practice was
apparently successful.

--
Dan White

Re: What DNS Is Not

[Valdis . Kletnieks]

On Thu, 26 Nov 2009 12:25:49 CST, Dan White said:
> That's a disagreement we'll have to have. Anytime this issue has been brought
> up in a public setting (here, slashdot, etc.) has resulted in terrible press
> and even corrective action. In particular, Network Solutions' attempt to
> at this at the .com level was corrected.

There's two types of in-flight editing of data by a provider:

1) The kind I've requested that they do.

2) The kind they're doing without my knowledge or consent.

The first should be monetized, the second needs a really bright flashlight.

Why is this distinction so hard for people to comprehend?


pgpYqInYwjai4.pgp
Description: PGP signature

Re: What DNS Is Not

[Dobbins, Roland]

On Nov 27, 2009, at 2:25 AM, Dan White wrote:

> Anytime this issue has been brought up in a public setting (here, slashdot, 
> etc.) has resulted in terrible press
> and even corrective action. 

Does anyone have any idea of the financial 'rewards' SPs who do this kind of 
thing reap from it?

I'm wondering if the money is sufficient for the SPs in question to resist 
DNSSEC on the grounds that it will 'cost them revenue'.

If it isn't, then what's the economic case for doing it in the first place?

---
Roland Dobbins  // 

Injustice is relatively easy to bear; what stings is justice.

-- H.L. Mencken

Re: What DNS Is Not

[Eric Brunner-Williams]

Dan White wrote:

On 26/11/09 07:37 -0800, David Conrad wrote:
There are folks on this list who work for ISPs which are doing 
wildcards/synthesis/etc.  They (or, more likely their management) can 
tell you there are obvious business reasons why they do 
wildcards/synthesis/etc.  Perhaps I'm overly cynical, but I suspect 
that until those business reasons go away, shining a flash light will 
probably just result in more ISPs implementing wildcards/synthesis/etc. 


That's a disagreement we'll have to have. Anytime this issue has been 
brought
up in a public setting (here, slashdot, etc.) has resulted in terrible 
press

and even corrective action. In particular, Network Solutions' attempt to
at this at the .com level was corrected. Of course I don't know what, if
any, ICANN pressure has to do with that, but the flash light practice was
apparently successful.


I do know what, if any, ICANN pressure had to do with that. The pressure 
on ICANN was real, and the pressure ICANN put on VGRS was sufficient.


Eric

Re: What DNS Is Not

[David Conrad]

On Nov 26, 2009, at 8:37 AM, Paul Vixie wrote:
>> From: David Conrad 
>> Date: Thu, 26 Nov 2009 07:42:15 -0800
>> 
>> As you know, as long as people rely on their ISPs for resolution
>> services, DNSSEC isn't going to help.  Where things get really offensive
>> if when the ISPs _require_ customers (through port 53 blocking, T-Mobile
>> Hotspot, I'm looking at you) to use the ISP's resolution services.
> 
> the endgame for provider-in-the-middle attacks is enduser validators, which
> is unfortunate since this use case is not well supported by current DNSSEC
> and so there's some more protocol work in our future ("n!!").

Why not simply run a validating resolver locally?

> i also expect to see DNS carried via HTTPS, which providers tend to leave
> alone since they don't want to hear from the lawyers at 1-800-flowers.com.
> (so, get ready for https://ns.vix.com/dns/query/www.vix.com/in/a&rd=1&ad=1).

To quote you, "n!!"

At some point, we may as well bite the bullet and redefine http{,s} as IPv7.

Regards,
-drc

Re: What DNS Is Not

[David Conrad]

Dan,

On Nov 26, 2009, at 10:25 AM, Dan White wrote:
> On 26/11/09 07:37 -0800, David Conrad wrote:
>> There are folks on this list who work for ISPs which are doing 
>> wildcards/synthesis/etc.  They (or, more likely their management) can tell 
>> you there are obvious business reasons why they do wildcards/synthesis/etc.  
>> Perhaps I'm overly cynical, but I suspect that until those business reasons 
>> go away, shining a flash light will probably just result in more ISPs 
>> implementing wildcards/synthesis/etc. 
> 
> That's a disagreement we'll have to have. Anytime this issue has been brought
> up in a public setting (here, slashdot, etc.) has resulted in terrible press
> and even corrective action. In particular, Network Solutions' attempt to
> at this at the .com level was corrected.

Right.  And since then, ICANN has contractually disallowed gTLD registries from 
doing SiteFinder like services (unless they can demonstrate such a service 
won't have a negative security/stability impact).  However, as I said, ICANN 
has no control over what ccTLDs do and there are 12 doing 
wildcards/synthesis/NXDOMAIN redirection/etc. as I type this, namely:

CG (Congo) -- Web redirects to the registry website to register a .CG domain.
KR (South Korea) -- If it is a non IDNA-encoded IDN, converts to IDNA. For 
ASCII, generates a “fake” page-not-found error for web requests.
NU (Niue) -- Web requests solicit you to register the domain.
PH (Philippines) -- Web requests solicit you to register the domain.
PW (Palau) -- File not found error. Uses an invalid SSL certificate.
RW (Rwanda) -- Connection time out (wildcard site is down)
ST (Sao Tome) -- Web requests solicit you to register the domain. Uses an 
invalid SSL certificate.
TK (Tokelau) -- Connection refused (wildcard site is down)
VG (Virgin Is., UK) -- Web requests solicit you to register the domain.
VN (Viet Nam) -- Web requests solicit you to register the domain.
WS (Samoa) -- Web requests solicit you to register the domain.
CN (China) -- Uses synthesis for IDN labels. Returns NXDOMAIN for ASCII labels.

However, that's different than what I thought we were talking about.  I thought 
we were talking about ISPs doing wildcards/synthesis/NXDOMAIN redirection/etc.  
There are a number of ISPs that do this, some of which are quite well known 
(there is even an Internet Draft on the techniques, see 
http://tools.ietf.org/html/draft-livingood-dns-redirect-00).  Pretty large 
flash light...

Regards,
-drc

Re: What DNS Is Not

[Paul Vixie]

> From: David Conrad 
> Date: Thu, 26 Nov 2009 13:25:39 -0800
> 
> At some point, we may as well bite the bullet and redefine http{,s} as IPv7.

since products and services designed to look inside encrypted streams and
inspect, modify, or redirect them are illegal in most parts of the world:

"yes, inevitably."

Happy Thanksgiving

[Shane Ronan]

Happy Thanksgiving 

Re: Happy Thanksgiving

[Warren Bailey]

I was wondering when someone was gonna tell Paul to go have a stiff drink and 
relax lol 
Sent from my Blackberry. Please execute spelling errors.

- Original Message -
From: Shane Ronan 
To: nanog 
Sent: Thu Nov 26 13:38:43 2009
Subject: Happy Thanksgiving

Happy Thanksgiving 

Re: Happy Thanksgiving

[chaim . rieger]

Paul, have a stiff one .
Sent via BlackBerry from T-Mobile

Re: Happy Thanksgiving

[Shane Ronan]

The reality is, lets see you create something that ends up being used in a 
manner wildly different from your intentions, and not be emotional about it.

On Nov 26, 2009, at 5:41 PM, Warren Bailey wrote:

> I was wondering when someone was gonna tell Paul to go have a stiff drink and 
> relax lol
> Sent from my Blackberry. Please execute spelling errors.
> 
> - Original Message -
> From: Shane Ronan 
> To: nanog 
> Sent: Thu Nov 26 13:38:43 2009
> Subject: Happy Thanksgiving
> 
> Happy Thanksgiving
> 
> 
> 
> 
> 

Re: I got a live one! - Spam source

[Michael Peddemors]

Not to keep endlessly on this thread, but again with reference to good whois 
record keeping and bad..

64.21.87.136: mx2.yvzus.com
64.21.87.141: mx3.xmabs.com
64.21.87.168: mx5.zgows.com
64.21.87.170: mx5.zntas.com

 We know the activity is probably limited to:

Found a referral to whois.nac.net:43.

NAC-Rwhoisd32 Server Ready - [hydrogen/43] Rwhoisd32 - 1.0.76

Private (NET-40155780-26)
   1000 Elliott Ave W
   Seattle, WA  98119
   US

OrgID   : NAC-40612
Netname : NET-40155780-26
Netblock: 64.21.87.128/26
NetUse  : additional loopback ips for 66.246.252.57

Coordinator:
   Whitaker, Claude  washwhita...@aol.com
   Phone: 206-407-3201


67.229.101.206: hikmvo.leadingsolutionlinks.com
67.229.101.207: noqo.leadingsolutionlinks.com
67.229.101.208: rqecf.leadingsolutionlinks.com

 We know that the activity is probably limited to:

VPLS Inc. d/b/a Krypt Technologies VPLSNET (NET-67-229-0-0-1)
  67.229.0.0 - 67.229.255.255
Roy Diaz ROY (NET-67-229-96-0-1)
  67.229.96.0 - 67.229.111.255

(Other than VPLS/Krypt seems to really like these type of customers)

70.97.119.58: mail1.ugallshwomange.com
70.97.119.59: mail1.ugouricarali.com
70.97.119.60: mail1.utanonesiana.com
70.97.119.61: mail1.vatetricarkose.com
70.97.119.62: mail1.venesiandsgu.com
70.97.119.63: mail1.viandslahass.com
70.97.119.64: mail1.vientianarica.com
70.97.119.65: mail1.vientuckyan.com



Integra Telecom, Inc. ELI-NETWORK-ELIX (NET-70-96-0-0-1)
  70.96.0.0 - 70.99.255.255
Syptec ITCM-70-97-118-0-23 (NET-70-97-118-0-1)
  70.97.118.0 - 70.97.119.255

This is a /23 but with Syptec's record... They sure like opening ranges to 
email marketers first :)  Unless Syptec is operating those machines 
themselves.. but in that class C all the IP's don't appear to start on a 
normal boundary, .35-.65 with all the rest of the IP's having no reverse DNS.  
Does this client of theirs have control over the whole /23 or just a part?


205.251.11.130: loneas41.instantcasheasynow.com
205.251.11.163: lon69.instantcasheasynow.com
205.251.11.70: lon83.instantcasheasynow.com
205.251.7.144: click37.fallcreditcash.com
205.251.7.204: track42.fallcreditcash.com
205.251.7.253: click14.fallcreditcash.com
205.251.7.99: track4.fallcreditcash.com



InfoRelay Online Systems, Inc. INFORELAY-EST-02 (NET-205-251-0-0-1)
  205.251.0.0 - 205.251.127.255
Reaction54 REACT54-03 (NET-205-251-8-0-1)
  205.251.8.0 - 205.251.15.255

Is this two different clients on Reaction54, or is this Reaction54 themselves?
I think you have to assume the later based on this whois information..  
Especially when you see that the whole class C has the same naming patterns.

216.52.246.253: host6.chemistryearth.com
216.52.246.254: host6.consecutiveworld.com

 

Internap Network Services Corporation PNAP-8-98 (NET-216-52-0-0-1)
  216.52.0.0 - 216.52.255.255
Aurora Networking INAP-LAX-AURORA-34937 (NET-216-52-246-0-1)
  216.52.246.0 - 216.52.246.255

More companies on Internap, but at least we know exactly what range is owned 
by this company.. We can just look at the one class 'C'.

And of course we can see that this is quite typical right across the range..

218.213.228.76: ad-a11.pointdnshere.com
218.213.228.92: ns193.pointdnshere.com



Ummm.. we can't say the same operator is using all of these can we?

inetnum:  218.213.0.0 - 218.213.255.255
netname:  HKNET-HK
descr:HKNet Company Limited
descr:15/F, Tower 2, Ever Gain Plaza,
descr:88 Container Port Road, Kwai Chung, N.T.
country:  HK

And if we guessed, and said the same behavior was across the board, we would 
be hurting the poor guy on that class C in the top of the range..  

(Oh, yeah.. I know.. I threw that last example to show that this isn't just a 
North American problem)




On November 26, 2009, Rich Kulawiec wrote:
> On Wed, Nov 25, 2009 at 09:25:27AM -0800, Michael Peddemors wrote:
> > I here people saying that they don't publish whois information because
> > they don't want the email's made public.  Okay, at least  the registered
> > company name, or individual who presented the ID should be there.
> 
> Without delving too far into this: there is no point whatsoever in
>  attempting to conceal or obfuscate email addresses --not any more.  It is
>  an obsolete, "cargo cult" practice that many are still engaged in without
>  grasping that it was quite thoroughly defeated by spammers and their
>  associates years ago.
> 
> That said, I concur in full with your opinions in re whois data and
> the need to assign it properly.  I've long since stopped trying to
> deal with missing information and have adopted the rule that if the
> neighborhood looks sufficiently bad, I just block a /24 worth.  That
> may sound arbitrary, but in practice it works extremely 

Re: Multicast LDP or P2MP RSVP & LDP

[devang patel]

Brendan,

Thanks for your reply and link. Do you have any good white paper or scenario
based example to share?

Thanks,
Devang

On Thu, Nov 26, 2009 at 7:45 PM, Brendan Kelly  wrote:

> Devang here is our guide.
>
>
> http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-vpns/vpns-configuring-point-to-multipoint-lsps-for-multicast-vpns.html#jd0e38149
>
> Thanks
> Brendan
> On Nov 26, 2009, at 12:53 AM, devang patel wrote:
>
> > Rob,
> >
> > Can you share some documentation with me on how to configure as well as
> any
> > kind of configuration example will be great help.
> >
> > Thanks,
> > Devang
> >
> > On Thu, Nov 26, 2009 at 12:46 AM, Rob Shakir  wrote:
> >
> >>
> >> On 26 Nov 2009, at 06:27, devang patel wrote:
> >>
> >> Hi All,
> >>>
> >>> I just want to know about the deployment of Multicast LDP or P2MP RSVP
> and
> >>> LDP is available from any vendor or they are still in draft status?
> >>>
> >>
> >> Hi Devang,
> >>
> >> To the best of my knowledge, the only current P2MP LSP implementation
> >> available is in JunOS [0]. The guys at Juniper wrote a draft relating to
> >> their experience with scaling and implementing P2MP MVPN [1], which is
> worth
> >> a look -- this draft mentions that IOS XR has an implementation,
> although I
> >> struggled to find any documentation that confirms this.
> >>
> >> Both the LDP-based [2] P2MP standard are still in draft status, but the
> >> extensions required in RSVP-TE for signalling P2MP paths are in RFC4875
> [3].
> >>
> >> From a couple of discussions I've had, there are not very many people
> using
> >> this functionality -- with most common application being IPTV. For
> >> traditional transport of multicast over an SP core, it's often easier to
> >> provide some AToM/L2VPN service.
> >>
> >> Hope this helps somewhat.
> >>
> >> Kind regards,
> >> Rob
> >>
> >> [0]:
> >>
> http://www.juniper.net/techpubs/software/junos/junos91/feature-guide/configuring-traffic-engineering-p2mp-lsps-in-provider-tunnels.html
> >> [1]: http://tools.ietf.org/html/draft-joseph-p2mp-mvpn-experience-00
> >> [2]: http://tools.ietf.org/html/draft-ietf-mpls-ldp-p2mp-08
> >> [3]: http://tools.ietf.org/html/rfc4875
> >>
> >> --
> >> Rob Shakir  
> >> Network Development EngineerGX Networks/Vialtus Solutions
> >> ddi: +44208 587 6077mob: +44797 155 4098
> >> pgp: 0xc07e6deb nic-hdl: RJS-RIPE
> >>
> >> This email is subject to: http://www.vialtus.com/disclaimer.html
> >>
> >>
> >>
> >>
>
>

Re: What DNS Is Not

[James Hess]

On Wed, Nov 25, 2009 at 2:58 PM, Jorge Amodio  wrote:
[snip]
> What needs to be done to have ISPs and other service providers stop tampering
> with DNS ?

Well, NXDOMAIN substitution,  on ISP provided DNS servers, is not
"tampering with DNS",  anymore than  spam/virus filtering/attachment
limits, disk quotas, or message expiration  on ISP mail servers  is
"tampering with E-mail",

It's ISPs providing their customers with a modified service. Their DNS
resolvers,  their terms.  They  _could_   accomplish  similar  by
requiring all their customers  utilize a   custom  web browser,   but
that would be less convenient.


"Tampering with DNS"  would  be hijacking port 53 UDP packets a
customer sent directly to an outside authoritative DNS server,  and
substituting their own answer.
That would be very harmful,  especially  if  the ISP customer is
attempting to troubleshoot a DNS issue...

Just because someone registered  EXAMPLE.COM   with one particular
internet registry, doesn't mean they own the lookup result for every
DNS server in the world. All they have paid for is the creation
and maintenance of entries in one particular shared database,   and
they only have control for the (large) subset of DNS servers that
utilize that particular database.

People can start new DNS roots,  old DNS roots can be superceded,
there can even be multiple conflicting private roots.


In the long run, the only method to discourage might be a form of blacklisting.
If  major DNS hosting providers discriminate in the authoritative
replies they give, based on asker:

*If the IP asking for a DNS record is in the IP range of an ISP that
you know substitutes NXDOMAINs with their own  reply,then you
discriminate  against that DNS query source, and don't give them
NXDOMAINs.

*Why hand them a NXDOMAIN response that they will just substitute?

If major DNS providers barred the ISP's overall range  from getting
any NXDOMAIN replies from the  authoritative nameservers,   then the
ISP would derive no benefit from substituting them,since  their
acts caused them  to be deemed unfit to receive NXDOMAIN responses  at
all.


In addition, their now lack of ability to get NXDOMAIN  responses,
could be an inconvenience to them,  esp.  in the operation of mail
servers,   since  latency of  certain  mail server DNS requests will
increase,  due to the delay to time out the query  (that would be
NXDOMAIN if they were allowed to receive NXDOMAIN).


*That is: always reply SERVFAIL  or send no reply to such blacklisted
IP ranges, when the database entry doesn't exist, instead of NXDOMAIN.

However, it  doesn't really penalize the  NXDOMAIN substitution
practice too much,  unless the root and TLD servers also  implement
the blacklisting,  it only deprives them of benefit.
--

As for  ccTLDs  performing wildcarding,  One could consider patches to
recursive resolvers   to  detectthe  IPs  that are wildcarding,
and substitute  responses detected as the wildcard  host IP addresses,
 with  NXDOMAIN.

For example,   randomly generate  2  test lookupsfor domains that
are unlikely to exist, eg afut429.ahfeai4728.xyz.xx  .
If  both  randomized lookups  return  A record responses   for the
same IP addresses,then  you detected  the  wildcard  method  used
by that ccTLD.

Substitute  NXDOMAIN  in  for any responses for the ccTLD  that
respond with the same list of A records.

In other words:   retaliating against NXDOMAIN substitution,  by
substituting response with those IPs  back to NXDOMAIN.

--
-J

Re: Happy Thanksgiving

[Matthew Moyle-Croft]

I think most fathers who have daughters have that happen when they start going 
out with boys ...

Happy Thanksgiving USA people.

MMC

On 27/11/2009, at 10:04 AM, Shane Ronan wrote:

> The reality is, lets see you create something that ends up being used in a 
> manner wildly different from your intentions, and not be emotional about it.
> 
> On Nov 26, 2009, at 5:41 PM, Warren Bailey wrote:
> 
>> I was wondering when someone was gonna tell Paul to go have a stiff drink 
>> and relax lol
>> Sent from my Blackberry. Please execute spelling errors.
>> 
>> - Original Message -
>> From: Shane Ronan 
>> To: nanog 
>> Sent: Thu Nov 26 13:38:43 2009
>> Subject: Happy Thanksgiving
>> 
>> Happy Thanksgiving
>> 
>> 
>> 
>> 
>> 
> 
> 

-- 
Matthew Moyle-Croft
Peering Manager and Team Lead - Commercial and DSLAMs
Internode /Agile