Thought-provoking article by Paul Vixie:

http://queue.acm.org/detail.cfm?id=1647302

--
Alex Balashov - Principal
Evariste Systems
Web     :  http://www.evaristesys.com/
Tel     : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671

I doubt Henry Ford would appreciate the Mustang.

-Dave

I don't think that is a very accurate analogy, and in any case, the
argument is not that we should immediately cease at once all the
things we do with DNS today.

DNS is one of the more centralised systems of the Internet at large;
it works because of its reliance on intermediate caching and
end-to-end accuracy.

It seems to me the claim is more that DNS was not designed to handle
them and that if this is what we want to do, perhaps something should
supplant DNS, or, alternate methods should be used.

For example, perhaps in the case of CDNs geographic optimisation
should be in the province of routing (e.g. anycast) and not DNS?

-- Alex

--
Alex Balashov - Principal
Evariste Systems
Web     :  http://www.evaristesys.com/
Tel     : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671

In most cases it already is.  He completely fails to address the concept
of Anycast DNS and assumes people are using statically mapped resolvers.

He also assumes that DNS is some great expense and that by not allowing
tons of caching we're taking money out of peoples' wallets.  This is
just not true with the exception of very few companies whose job it is
to answer DNS requests.

-Dave

This myth (that Paul mentions, not to suggest Dave T's comment is a  
myth) was debunked years ago:

"DNS Performance and the Effectiveness of Caching"
Jaeyeon Jung, Emil Sit, Hari Balakrishnan, and Robert Morris http://pdos.csail.mit.edu/papers/dns:ton.pdf

Basically:  Caching of NS records is important, particularly higher up  
in the hierarchy.  Caching of A records is drastically less important  
- and, not mentioned in the article, the cost imposed by low-TTL A  
records is shared mostly by the client and the DNS provider, not some  
third party infrastructure.

From the paper:

"Our trace-driven simulations yield two findings. First, reducing the  
TTLs of A records to as low as a few hundred seconds has little  
adverse effect on hit rates. Second, little benefit is obtained from  
sharing a forwarding DNS cache among more than 10 or 20 clients. This  
is consistent with the heavy-tailed nature of access to names. This  
suggests that the performance of DNS is not as dependent on aggressive  
caching as is commonly believed, and that the widespread use of  
dynamic low-TTL A-record bindings should not degrade DNS performance.  
The reasons for the scalability of DNS are due less to the  
hierarchical design of its name space or good A-record caching than  
seems to be widely believed; rather, the cacheability of NS records  
efficiently partition the name space and avoid overloading any single  
name server in the Internet."

   -Dave

DNS is NOT always defined by Paul... :)

--bill

And of course in many cases these are the same people who are benefiting
significantly by the geo-aware (and sometimes, network-aware) CDN's that
this type of DNS service provides.

  Scott.

-----------

    a simulation is driven from a mathmatical model, not real world
    constructions.  

--bill

Hi, Bill -

The paper is worth reading.

"The paper also presents the results of trace-driven simulations that  
explore the effect of varying TTLs and varying degrees of cache  
sharing on DNS cache hit rates. "

emphasis on *trace-driven*.  Now, you can argue whether or not their  
traces are representative (whatever that means) -- they used client  
DNS and TCP connection traces from MIT and KAIST, so it definitely has  
a .edu bias, iff there is a bias in DNS traffic for universities vs.  
"the real world", but to the extent that their traces represent what  
other groups of users might see, their evaluation seems accurate.

   -Dave

I don't know why Paul is so concerned, just think how many F root mirrors
it helps him sell to unsuspecting saps. The Henry Ford analogy was amazingy
apt, imagine 'ol Henry coming back and claiming that automatic transmissios
were a misuse of the automobile.

Drive Slow ('cause someone left the door open at the old folks home)

I'm not debating the traces - I wonder about the simulation
    model.  (and yes, I've read the paper)

--bill

I'm happy to chat about this offline if it bores people, but I'm  
curious what you're wondering about.

The method was pretty simple:

  - Record the TCP SYN/FIN packets and the DNS packets
  - For every SYN, figure out what name the computer had resolved to  
open a connection to this IP address
  - From the TTL of the DNS, figure out whether finding that binding  
would have required a DNS lookup

There are some obvious potential sources of error - most particularly,  
name-based HTTP virtual hosting may break some of the assumptions in  
this - but I'd guess that with a somewhat smaller trace, not too much  
error is introduced by clients going to different name-based vhosts on  
the same IP address within a small amount of time.  There are  
certainly some, but I'd be surprised if it was more than a %age of the  
accesses.  Are there other methodological concerns?

I'd also point out for this discussion two studies that looked at how  
accurately one can geo-map clients based on the IP address of their  
chosen DNS resolver.  There are obviously potential pitfalls here  
(e.g., someone who travels and still uses their "home" resolver).  In  
2002:

Z. M. Mao, C. D. Cranor, F. Douglis, and M. Rabinovich. A Precise and  
Efficient Evaluation of the Proximity between Web Clients and their  
Local DNS Servers. In Proc. USENIX Annual Technical Conference,  
Berkeley, CA, June 2002.

Bottom line:  It's ok but not great.

"We con- clude that DNS is good for very coarse-grained server  
selection, since 64% of the associations belong to the same Autonomous  
System. DNS is less useful for finer- grained server selection, since  
only 16% of the client and local DNS associations are in the same  
network-aware cluster [13] (based on BGP routing information from a  
wide set of routers)"

We did a wardriving study in Pittsburgh recently where we found that,  
of the access points we could connect to, 99% of them used their ISP's  
provided DNS server.  Pretty good if your target is residential users:

http://www.cs.cmu.edu/~dga/papers/han-imc2008-abstract.html

(it's a small part of the paper in section 4.3).

   -Dave

I'm not sure that's a correct assumption.

It's kind of the same sort of thing that led to what is commonly called
the "Kaminsky" vulnerability; the fact that it was predicted years before
continues to be ignored.

The reason that's relevant is because the resource consumption argument
in question is the same one; in the last ten years, bandwidth, CPU, and
memory resources have all moved by greater than an order of magnitude
in a favorable direction for DNS operators.  

Paul's argument is best considered on an idealistic basis.  For example,
with the CDN stuff, people who muck with DNS should absolutely be aware
of what Paul is saying; that does not mean that there aren't equally
valid reasons to treat DNS in a different manner.  The technical
problems related to CDN-style use of DNS lookups are pretty well known
and understood.  The resource consumption issues are trivialized with
the advent of high speed Internet, cheaper resources, etc.  It doesn't
make it idealistically *right*, but it means it is really much less
damaging than ten or fifteen years ago.

To classify NXDOMAIN mapping and CDN "stupid DNS tricks" in the same
class of "DNS lies" is probably damaging to any debate.  The former is
evil for breaking a lot of things, the latter ia only handing out varied
answers for questions one should have the answer to.  It's the difference
between being authorized to answer and just handing out answers that Paul
objects to, and being unauthorized to answer and handing out answers that
many people object to.

My opinion is that it'd be better for Paul to avoid technical arguments
that were weak even in the '90's to support his position.  As it stands,
people read outdated technical bits and say "well, we know better,"
which trivializes the remaining technical and idealistic bits.

That's damaging, because Paul's dead on about a lot of things.  DNS is
essentially the wrong level at which to be doing "my web browser could
not find X" mapping; it'd be better to build this into web browsers
instead.  But that's a discussion and a half.  :-)

... 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.

Well my first answer to that would be that GSLB scales down a lot further
than anycast.

And my first question would be what would the load on the global routing
system if a couple of thousand (say) extra sites started using anycast for
their content?

Each would have their own AS (perhaps reused from elsewher in the
company) and a small network or two. Routes would be added and withdrawn
regularly and various "stupid BGP tricks" attempted with communitees and
prefixes.

I heard some anti-spam people use DNS to distribute big databases of
information. I bet Vixie would have nasty things to say to the guy who
first thought that up.

--
Simon Lyall  |  Very Busy  |  Web:  http://www.darkmere.gen.nz/
"To stay awake all night adds a day to your life" - Stilgar | eMT.

Are you asking what the impact would be of a couple of thousand extra  
routes in the current full table of ~250,000? That sounds like noise  
to me (the number, not your question :-)

Joe

I agree Bill, but Paul is right on the money about how the DNS is being
misused and abused to create more smoke and mirrors in the domain
name biz.

I really find annoying that some ISPs (several large ones among them) are
still tampering with the DNS responses just to put few more coins on
their coffers from click through advertising.

What I'm really afraid is that all the buzz and $$ from the domain biz
will create strong resistance to any efforts to develop a real directory
service or better  better scheme for resource naming and location.

BTW simulations != real world.

Cheers
Jorge

Given that paper is 7 years old and the Internet has changed a bit since2002 (and the DNS looks to change somewhat drastically in the relativelynear future) it might be dangerous to rely too much on their results. This might be an interesting area of additional research...

Regards,
-drc

Well, the marketing folks have sure taken advantage of it. It would be nice
to see the technology folks... not just lie there and take it.

- - ferg

Bah, many of the CDN's I've dealt with don't seed geographical responses
based on DNS, but rather use many out of band methods for determining
what response they will hand out. The primary reason for short cutting
cache is to limit failures in case the system a requestor is going to
goes down.

And different CDN's behave differently, depending on how they deliver
content, support provider interconnects, etc. I'd hardly call many of
them DNS lies, as they do resolve you to the appropriate IP, and if that
IP disappears, try and quickly get you to another appropriate IP.

The rest of the article was informative,though.

Jack

the automatic transmission was a huge step forward since he wanted everybody
to have a car.  i can't think of anything that's happened in the automobile
market that henry ford wouldn't've wished he'd thought of.

i knew that the "incoherent DNS" market would rise up on its hind legs and
say all kinds of things in its defense against the ACM Queue article, and i'm
not going to engage with every such speaker.

there three more-specific replies below.

"anycast DNS" appears to mean different things to different people.  i didn't
mention it because to me anycast dns is a bgp level construct whereby the
same (coherent) answer is available from many servers having the same IP
address but not actually being the same server.  see for example how several
root name servers are distributed.  < http://www.root-servers.org/>.   if you
are using "anycast DNS" to mean carefully crafted (noncoherent) responses
from a similarly distributed/advertised set of servers, then i did address
your topic in the ACM Queue article.

my reason for completely dismissing that paper at the time it came out was
that it tried to predict the system level impact of DNS caching while only
looking at the resolver side and only from one client population having a
small and uniform user base.  show me a "trace driven simulation" of the
whole system, that takes into account significant authority servers (which
would include root, tld, and amazon and google) as well as significant
caching servers (which would not include MIT's or any university's but
which would definitely include comcast's and cox's and att's), and i'll
read it with high hopes.  note that ISC SIE (see  http://sie.isc.org/  may
yet grow into a possible data source for this kind of study, which is one
of the reasons we created it.)

someone made this same comment in the slashdot thread.  my response there
and here is: the MAPS RBL has always delivered coherent responses where the
answer is an expressed fact, not kerned in any way based on the identity of
the querier.  perhaps my language in the ACM Queue article was imprecise
("delivering facts rather than policy") and i should have stuck with the
longer formulation ("incoherent responses crafted based on the identity of
the querier rather than on the authoritative data").
--
Paul Vixie
KI6YSY

Hi, Paul - I share your dislike of DNS services that break the DNS
model for profit in ways that break applications.
For instance, returning the IP address of your company's port-80 web
server instead of NXDOMAIN
not only breaks non-port-80-http applications, it also breaks the
behaviour that browsers such as
IE and Firefox expect, which is that if a domain isn't found, they'll
do something that the user chooses,
such as sending another query to the user's favorite search engine.

There is one special case for which I don't mind having DNS servers
lie about query results,
which is the phishing/malware protection service.  In that case, the
DNS response is redirecting you to
the IP address of a server that'll tell you
       "You really didn't want to visit PayPa11.com - it's a fake" or
       "You really didn't want to visit
dgfdsgsdfgdfgsdfgsfd.example.ru - it's malware".
It's technically broken, but you really _didn't_ want to go there anyway.
It's a bit friendlier to administrators and security people if the
response page gives you the
IP address that the query would have otherwise returned, though
obviously you don't want it to be
a clickable hyperlink.

However, I disagree with your objections to CDN, and load balancers in
general - returning the
address of the server that example.com thinks will give you the best
performance is reasonable.
(I'll leave the question of whether DNS queries are any good at
determining that to the vendors.)
Maintaining a cachable ns.example.com record in the process is
friendly to everybody;
maintaining cachable A records is less important.
If reality is changing rapidly, then the directory that points to the
reality can reasonably change also.

Well, there's the built-in GPS navigation system that tells you to go
drive off the dock into the water,
because it wasn't smart enough to know that the route the map database
showed in dotted lines was a ferryboat...

--
----
             Thanks;     Bill

Note that this isn't my regular email account - It's still experimental sofar.
And Google probably logs and indexes everything you send it.

When I write applications that make DNS queries, I expect the request
to turn NXDOMAIN if the host does not exist - HTTP as well as
non-HTTP, but especially non-HTTP.

Anything else is COMPLETELY UNACCEPTABLE.  I don't understand how or
why this could possibly be controversial.

--
Alex Balashov - Principal
Evariste Systems
Web     :  http://www.evaristesys.com/
Tel     : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671

Because some people want the ability and choice to block DNS responses
they don't like; just as they have the ability and choice to reject
email they don't want to accept.

When the conficker worms phones home to one of the 50,000 potential
domains names it computes each day, there are a lot of IT folks out
there that wish their local resolver would simply reject those DNS
requests so that infected machines in their network fail to phone home.

To use your language, I don't understand how or why this could possibly
be controversial.  --  Apparently it is.

-David

Paul: I completely agree with you that putting wildcards into the  
roots, GTLDs, CCTLDs, etc. is a Bad Idea and should be squashed.  
Users have little (no?) choice on their TLDs.  Stopping those is a  
Good Thing, IMHO.

However, I own a domain (or couple hundred :).  I have a wildcard on  
my domain.  I point it where I want.  I feel not the slightest twinge  
of guilt at this.  Do you think this is a Bad Thing, or should this be  
allowed?

Also, why are you upset at OpenDNS.  People _intentionally_ select to  
use OpenDNS, which is clear in its terms of service, and even allows  
users to turn off the bits that annoy you.  Exactly what is the issue?

And lastly, DNS is not "truth".  DNS is the Domain Name System, it is  
what people configure it to be.  You yourself have argued things like  
responding with "192.0.2.1"  for DNSBLs that are being shut down.  
That is clearly NOT "truth".

--
TTFN,
patrick

P.S. Yes, I am intentionally ignoring the CDN side of things.  Find me  
in private, preferably with a shot of single-malt, if you want my  
opinion.

Actually, the one I hate is when they return NXDOMAIN for any RR type
other than A, breaking DNS. Most common is AAAA to return NXDOMAIN,
which immediately has the effect of breaking the ability to fallback to
A (why query for another RR, when the domain doesn't exist?). Several
high end load balancers have the ability to do this according to the
content providers I have addressed the matter with.

As a side note, any IPv6 capable stack which has determined there is
IPv6 connectivity (through 6to4, native, teredo, etc) cannot access
these sites. For an example (an ongoing issue) see www.txu.com. Responds
to A, gives NXDOMAIN to AAAA.

I will not shame the high profile websites that have fixed their
loadbalancers/DNS servers, but everyone on this list knows and has
probably used them.

Jack

I find it mildly amusing that my first contact with Paul was about 25
years ago when he was at DEC and I objected to his use of a wildcard for
dec.com. The situations are not parallel and the Internet was a
very different animal in those days (and DEC was mostly DECnet), but
still I managed to maintain a full set of MX records for all of our
DECnet systems.

--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman*******            Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751

Dealing with 10k~ uni students who like to spread new viruses faster
than STD's I often make light of the fact that we can use OpenDNS to a)
keep tabs on who's infected at what sites and b) prevent them from
possibly doing more damage by phoning home with info or to collect
instructions.

It's as David says, there are a lot of us who would rather have the
choice than not have it.
If that's not acceptable to some then that's their decision however as a
part of our network this DNS 'tomfoolery' is something that both we and
the end user see benefits from so I don't see it going away anytime soon.

Regards,
Andrew Cox
AccessPlus HNA

notbeing Paul, its rude of me to respond - yet you posted this
    to a public list ... so here goes.

    Why do you find your behaviour in your domains acceptable and yet the
    same behaviour in others zones to be "a Bad Thing" and should be stopped?

    
--bill

Ok, devils advocate argument.  

Is there is a difference between being a domain "owner"
(Patrick wanting to wildcard the domain he has paid for),
and a domain "custodian" (Verisign for the .com example)
in whether wildcards are ever acceptable in the DNS
responses you provide?

Not being anyone who has posted on this thread on a public list...

I agree that the rules for what is acceptable in the operations of
DNS zones vary from zone to zone.  This is because of the different
relationships between the zone administrator and the entities
represented in the zone and the different relationships between the
zone administrator and the relying parties.

(I"m just going to pick on one "reason.")

For the root zone or aTLD (which themselves have differences) the
relationships tend to be global, multilingual, etc.  Stability and
coherence here are vital for operations, because as you know being in
"operations" really means "handling outages." Once a problem pops up,
it might take a while (hours, days) to go from report to root cause
analysis to long-term fix.  If the root and TLDs have lots of "bells
and whistles" then, well, this is hard, so the root and TLDs are kept
simple.

For a zone "lower in the stack" assumptions are different.  Generally
speaking, the zone represents a single entity (a government agency,
store, school) who will have a varying degree of active management of
what is in the zone.  They may even be able to "roll back" to some
point in time and see what is in the zone.  On-the-fly response
generation is even acceptable because they can see what mislead
someone, etc. (if they zone is properly run).  And by on-the-fly I am
including wildcards generated answers, calculated answers or answers
based on source of the request, etc., and other demographics or
current load measures.

As far as relying parties, think about "who do I call?" when I can't
get through.  They have two obvious choices - their ISP or the
organization they want to reach.  Calls will end up with the ISP if
the issue is high up in the zone, calls might get to the organization
if the problems are lower in the tree.   (Because perhaps they got to
the main web page but not to the department page.)

This is just one reason why it's reasonable to manage different DNS
zones differently, why the "rules" don't apply the same everywhere.
There are many other reasons.  But this is a public list.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

I think this is spot on.

In particular:  Patrick, for some domains at least, can implement a  
wildcard with the full cooperation and agreement of all of the  
customers of sub-zones within his domain.  Particularly if he doesn't  
resell any subdomains within it.  Verisign cannot. [1]

[1]  As a customer of .com, my own disagreement on this is sufficient  
to prove that they don't have unanimous agreement. :-)

   -Dave

good question - does patrick own the domain or has he paid for
    the registration of mapping a string into a database? either? both?
    neither?

    I'll lay out what I just did in private email a moment ago.

    regardless of payment, ownership, or other considerations, we
    all (who manage a delegation  point) are stewards of that delegation.
    Patrick, as steward of a domain, feels certain behaviours are
    acceptable when he performs them within his stewardship, yet is
    nonplused when another steward does the exact same thing in a different
    delegation.

    not being able to resist the analogy....

    Its ok for me to practice indentured servitude in my home, yet when I
    see my neighbor practicing it in their home - I call the cops on her
    for practicing slavery.  and hope that no one notices me.

--bill

Sent from my iPhone, please excuse any errors.

Thought I was clear: Choice.

I believe there is a qualitative difference between a *TLD and a  
second level domain.  /Especially/ for the GTLDs.

I guess one could argue CCTLDs are different, but I disagree.  If you  
are in Germany, a .de is nearly as important as .com in the US.  
(Don't believe me?  Go to www.dtag.com.)

But no one has to use ianai.net.  Or aa.com.  Or ....

A second issue is ownership.  I own my domain.  The .com domain is not  
owed by Verisign (despite what they may think :-).

Again, one could make an argument that the CCTLDs are different -  
"owned" by their host countries.  I personally disagree, but I admit  
that argument is less objective than the GTLDs.

Do you disagree wih my logic?   Do you believe Verisign should be  
allowed to do with .net the same things I should be allowed to do with ianai.net
?

If so, please explain why.

If not, uh ... Why did you ask? =)

--
TTFN,
patrick

Interesting statement, did you get a property title with your domain name ?

Just curious

so you are making the arguement that as one navigates
    the dns heirarchy, operational choices nearer the root
    affect more people.

    as may be. - yet we see ICANN under serious pressure to
    flatten out the root zone - to create the same amount of choice
    at the root as one might find in .COM

    I will echo your original question to Paul, If its a "Bad Thing"
    at the root or TLD, is it a "Bad Thing" in ianai.com?

    I would say yes it is  -  looking for consistency in the stewardship
    guidelines for any delegation.  personally, I take the path less
    traveled and woudl suggest that a wildcard - at any delegation point -
    can be a useful tool.

    the unspoken compoent here is the diversity of expectation on what
    one might do with a wildcard.  Is the wildcard in and of itself a
    "Bad Thing" or has the wildcard been used in conjunction with other
    heinous practice to unfairly exploit the gullible masses?

    I don't think it fair to blame wildcards here - they are a symptom
    but not the actual cause of "Bad Thing" - for that you need other
    bits in play.

--bill

Remember this...

Returning bogus non-NXODMAIN gives non-port-80-http apps heartburn as well.

Shouldn't such apps be checking the content they receive back from a
server anyway?
Regardless of if they think they're getting to the right server (due to
a bogus non-NXDOMAIN response) there should be some sort of validation
in place.. otherwise you're open in any sort of man-in-the-middle attack.

I think the issue is more that older apps would expect that if they can
get a response then everything is ok.. perhaps this simply an outdated
method and needs to be rethought.

The app is expecting a response of some kind. When it gets back bogus
information that has it connecting to an IP that may not respond at all,
the app will have to sit around waiting on a timeout.

Jack

nerds pull sometimes."  (The "****" is mine, not the original quote,  
so the Communications Committee doesn't send me a warning.)

The argument is silly at best.  I "own" the domain for the year I paid  
for it.  You call it "stewardship".  I won't argue if you want to play  
that game.

(BTW, I seriously considered putting the word "own" in quotes, but it  
would have required five extra keystrokes on the iPhone and I didn't  
think it was worth the effort.  Everyone - including Bill - knows  
exactly what I meant.  I mean, we're not newbies or idiots or ....  
Oh, right.  Teach me to be lazy.)

Let's use "stewardship", or any other string of characters that makes  
you happy.  The basic premise does not change.  My "stewardship" of ianai.net
  (and it's not ".com" - one would think someone like you would  
realize the difference) is qualitatively different than the  
"stewardship" of the *TLDs.

For one thing, I have every right to point any hostname in my domain  
at any IP address I want.[*]  I could create a zone file with 36^N  
entries pointing them all at the same IP address.  No one would blink  
an eye.  It is not unexpected, inappropriate, or in any way "wrong".  
Putting "* IN A 1.2.3.4" has the exact same results for any hostname  
up to N letters.  Consider it shorthand.  Think of all the RAM I'll  
save!

Verisign putting a domain into .com that does not exist is not only  
unexpected, it is inappropriate, and Just Plain Wrong.  They do not  
"own" the zone, they have _no_right_ to put any entries in that zone  
that are not requested through the appropriate method.

If you do not (want to) see that, we will have to agree to disagree.

Also, you were so busy picking on my choice of words that you  
completely ignored the "choice" point.  Guess you couldn't come up  
with any feeble semantic arguments on that one?

s/the/a really bad/

Honestly, Bill, don't you think that was a little pathetic?

Why don't you just compare me to Hitler and get it over with.

--
TTFN,
patrick

[*] I'm not going to explain things like "I shouldn't point hostnames  
at IP addresses I do not own" (er, "steward") because anyone who  
brings up that point is not worth talking to.  If your best counter  
argument is so stupid that anyone with more than three brain cells to  
rub together already knows, understands, and has gone right past, then  
please un-sub from NANOG, throw your laptop in a lake, and go get a  
job a HS drop out can do.  Because that's all you deserve.

I'd take that question up with your IP attorney.

[ Summary: lots of lawyers and courts seem to think that domain names are
property ]

http://news.cnet.com/2100-1023-223597.html

http://www.domainnamenews.com/legal-issues/are-domain-names-[..]

http://newmedialaw.proskauer.com/2008/12/articles/domain-nam[..]

http://www.law.duke.edu/journals/dltr/articles/2001dltr0032.[..]

http://pblog.bna.com/techlaw/2009/09/domain-name-deemed-tang[..]

-M<

--
Martin Hannigan                               martin*******
p: +16178216079
Power, Network, and Costs Consulting for Iceland Datacenters and Occupants

In which case, make your own nameserver authoritative for those
domains; do not foist your own wishes on other people.

--
John

Since people need to *explicitly* choose using the OpenDNS servers, I
can hardly see how anybody's wishes are foisted on these people.

If you don't like the answers you get from this (free) service, you
can of course choose to use a different service - for instance your
ISP's name servers.

(I may or may not agree with what OpenDNS does - that is completely
irrelevant in this case.)

Steinar Haug, Nethelp consulting, sthaug*******

That's an extremely bad idea: many of the domains generated by the
Conficker algorithm are already registered by a legitimate registrant
(in .FR: the national railways, a national TV, etc).

Also, the example is not a good choice since Conficker now mostly uses
P2P: < http://mtc.sri.com/Conficker/P2P/> > for those who like assembly
code and awful technical details.

It's an idea that needs to be used *with caution*. We did something
similar as part of testing a new DNS product, and found that any such
list of domain names needed to be *manually* vetted before being used
as input to a DNS-based blackhole system. We also found that we had
to explicitly whitelist a number of domains (generated by Conficker
but registered many years ago and pretty clearly legit).

Steinar Haug, Nethelp consulting, sthaug*******

This is correct.  And we take this into consideration in determining
what to block using our existing datasets, which are sufficient
considering the volume of DNS traffic that crosses our network.

-David

Umm... That's precisely what I've done.  Please read the thread.

-David

What if your ISP's name servers are those from OpenDNS?

Run your own nameservers or get a different ISP that doesn't force you to e filtered :-)

1) You can personally opt-out of OpenDNS' NXDOMAIN stuff & such.

2) I don't really see how that makes a difference.  The point is,OpenDNS is not forcing anyone.  Your ISP has a policy you don't like,use a different ISP.  If there is no other ISP, well, I don't know whatto tell you?  Start one?  Move?

End of day, it is an OPT-IN service.  If you happen to "opt-in" bybuying service from your ISP, that does not change the basic premise.

--
TTFN,
patrick

Then I guess you need to vote with your wallet and find a different ISP.

Steinar Haug, Nethelp consulting, sthaug*******

# vi /etc/resolv.conf

We don't sell service to ISPs.  That's a deliberate decision.  But you
already knew that.

-David

* David Ulevitch:

No, I'm genuinely surprised, really.  After all, there is
< http://www.opendns.com/customers/industry/3/>.   Generally, I've got
less knowledge about OpenDNS than you might think.

I was only an egg.

Based partly on my conversation with you, I ended up pulling over the
list of DECnet nodes and generating MX's for each one, just to remove
that wildcard.  You were right, and I listened.  Probably I forgot to
thank you until now.  Thanks.
--
Paul Vixie
KI6YSY

Well,

If it counts Paul, thanks for vixie cron. ;)

It depends what you mean by "appropriate".  It may not be "least cost"
or "closest", and that can be a rude shock when the CDN traffic suddenly
costs you A$5/GB (delivered from the US by undersea cable) rather than
$0 (delivered from an in-country peer).

DNS is the wrong answer, simply because there's no way for the user to
express *their* policy.  But since there no CDN support in HTTP.....

--
  Glen Turner   < http://www.gdt.id.au/~gdt/> >

Maybe Google needs to incorporate some level of CDN support into their
SPDY layer...

Better than DNS I would think.

-brandon

--
Brandon Galbraith
Mobile: 630.400.6992
FNAL: 630.840.2141

In some cases this may be true. However, many of the CDN's I've talked
to will happily update which POP my network talks to. Is automatic
detection perfect? Probably not. That is why they support manual
correction. Their goal is to get you the best connectivity, and they
usually don't have a problem, in my experience, working with a provider
to ensure the right IP ranges go to the best POP.

See above. It appears I have no problem expressing my policy to CDN's.
Corporate world often uses views to express external and internal
policy. Unfortunately, it's not that easy for the CDN, so they do the
best that they can, and they correct when it's important enough for a
provider to say "hey, this pop isn't the best for my network!"

Jack

As a follow up to this, one of the large Australian ISP's has just
introduced a DNS redirection "service" for all home customers.

"/The BigPond-branded landing page provides BigPond customers with
organic search results, sponsored links, display advertisements and
intelligent recommendations, all derived from the invalid domain input -
much more helpful and friendly than a nasty 404 page error./"

http://www.crn.com.au/News/160923,bigpond-redirects-typos-to[..]

with high ecoli

--- andrew*******wrote:
From: Andrew Cox <andrew*******>

As a follow up to this, one of the large Australian ISP's has just
introduced a DNS redirection "service" for all home customers.

"/The BigPond-branded landing page provides BigPond customers with
organic search results, sponsored links, display advertisements and
intelligent recommendations, all derived from the invalid domain input -
much more helpful and friendly than a nasty 404 page error./"

http://www.crn.com.au/News/160923,bigpond-redirects-typos-to[..]
------------------------------------------------------------------------------

>From AUSNOG:

On Thu, Nov 19, 2009 at 2:08 PM, Paul Foote <pfoote*******> wrote:

    All that's left for them to complete the "404" strategy is to put transparent proxies in place that redirect on real 404's :P

    Did nobody learn the lessons from when Verisign did this with .com ? baah.

In fairness (and I use that term loosly) to BigPond, this is probably a little different to what Verisign did.

I haven't seen the BigPond details, but I have seen what Comcast are doing on my US cable connection, and I presume BigPond is doing something similar.

The major differences between the two are :
* Only responds for "www" addresses.  a lookup for "non-existantdomain.com" will still return an NXDOMAIN, but "www.non-existantdomain.com" returns their search page.  This means that (the majority of) things like RBL/anti-spam/etc things which broke under Verisign's redirection no longer break.
* It's only home users. Business plans/etc are not redirected.  Obviously this is different to Verisign where everyone was hit.
* You can turn it off, and the page you end up on even gives you the details on how to turn it off.

Also despite claims to the contrary, Comcast are not actually "intercepting" DNS traffic - or at least they aren't for me.  They are only doing this for traffic sent directly to their DNS servers, and pointing to another DNS server works as expected, as does running your own resolver.

I'm still not saying that it's a good thing for them to be doing, but it's not quite as bad or destructive as Verisign's move was...

Hi,

Telefonica is doing that here, and not onlw for www. hostnames...

# nmap nonexist.merit.edu.

Starting Nmap 4.68 (  http://nmap.org  ) at 2009-11-19 23:44 ARST
Interesting ports on smartbrowsebr-mx.terra.com (208.70.188.15):
Not shown: 1712 filtered ports
PORT     STATE SERVICE
80/tcp   open  http
554/tcp  open  rtsp
1755/tcp open  wms

Nmap done: 1 IP address (1 host up) scanned in 28.324 seconds

Cheers,
        Eduardo.-

--
Eduardo A. Suarez
Facultad de Ciencias Astronomicas y Geofisicas
Universidad Nacional de La Plata

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

It would be intersting to see what would happen if MERIT issued a
cease and decist request for using their domain name without
permission.


Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka*******

--- marka*******wrote:
From: Mark Andrews <marka*******>

> Telefonica is doing that here, and not onlw for www. hostnames...
>
> # nmap nonexist.merit.edu.

It would be intersting to see what would happen if MERIT issued a
cease and decist request for using their domain name without
permission.
---------------------------------------------

I sure would like to have a front row seat for that! :-)

scott

Scott,

If you're going to blatantly copy what others have written on another
mailing list, please at least have the common decency to attribute it to the
original author, and/or get the original authors permission first.

  Scott.

That's really bad, because by doing that they could redirect things
like hardcoreporn.merit.edu creating huge liability for the rightful
admin of any domain name without them knowing.

This will not stop until a big pocket corp sends the legal dogs
for hunting.

Regards
Jorge

well they can sue them in the US...

# traceroute 208.70.188.15
traceroute to 208.70.188.15 (208.70.188.15), 30 hops max, 60 byte packets
  1  * * *
  2  * * *
  3  * * *
  4  * * *
  5  * * *
  6  * * *
  7  * * *
  8  * * *
  9  * * *
10  * * *
11  * * *
12  * * *
13  so-1-1-0-0-grtbueba2.red.telefonica-wholesale.net (213.140.51.73)  
3.913 ms  3.911 ms  3.905 ms
14  Xe7-3-0-0-grtlurem4.red.telefonica-wholesale.net (213.140.49.18)  
58.677 ms Xe8-0-0-0-grtlurem4.red.telefonica-wholesale.net  
(213.140.49.6)  59.780 ms  
Xe11-0-0-0-grtlurem4.red.telefonica-wholesale.net (213.140.36.150)  
59.784 ms
15  
Xe8-3-0-0-grtmiabr5.red.telefonica-wholesale.net.126.142.94.in-addr.arpa  
(94.142.126.113)  129.878 ms  129.878 ms  
Xe5-1-3-0-grtmiabr4.red.telefonica-wholesale.net (84.16.15.62)  
130.615 ms
16  P9-0-0-0-gramiatc2.red.telefonica-wholesale.net (213.140.37.201)  
131.945 ms  131.942 ms  131.936 ms
17  84.16.6.150 (84.16.6.150)  129.855 ms  129.850 ms  129.838 ms
18  tdcsdr11-vl-3.mia1.ustdata.net (66.119.65.19)  130.774 ms  130.761  
ms  130.754 ms
19  terra-g-3-1-dsw01-mia.tc.terra.com (66.119.71.2)  130.724 ms  
130.724 ms  130.719 ms
20  bsw01a-mia.tc.terra.com (208.70.191.245)  134.385 ms  135.200 ms  
135.189 ms
21  bsw01a-mia.tc.terra.com (208.70.191.245)  127.450 ms  127.455 ms  
127.451 ms

Eduardo.-

--
Eduardo A. Suarez
Facultad de Ciencias Astronomicas y Geofisicas
Universidad Nacional de La Plata

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

*Facepalm*  Maybe my browser's just doing something wrong, but when was the
last time you got a "nasty 404 page error" for an NXDOMAIN response?

- Matt
*mumblemumble*journalists*mumblemumble*

Paul's article "What DNS Is Not" published in December's Issue of Communications
of the ACM.

Also ICANN publishes memorandum about Harms and Concerns Posed by
NXDOMAIN Substitution:

http://www.icann.org/en/topics/new-gtlds/nxdomain-substituti[..]

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

Cheers
Jorge

In message <202705b0911251258s3256434vf7864d212a1f1cf1*******>, Jorge A

Sign your response (DNSSEC).  That makes it abundently clear that
you don't want your answers to be tampered with.

Send cease-and-desist letter for all namespaces you own, to all ISP
that you are aware of that are doing this.   Followup if they fail
to take corrective action.

Mark

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka*******

Some options:

Contact your local, state and federal legislators and convince them it's in
the public interest for them to draft legislation to outlaw this practice -
and hope among all hope that the end result resembles something technically
benevolent.

Contact ICANN/IANA and plead with them to stop assigning any more resources

significantly deplorable enough practice for them to find another ISP.

--
Dan White

And what is needed to have a consistant 'whois' reporting format :)

Keeping adding to the list?

--
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors - President/CEO - LinuxMagic
Products, Services, Support and Development
Visit us at  http://www.linuxmagic.com
------------------------------------------------------------------------
A Wizard IT Company - For More Info  http://www.wizard.ca
"LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-589-0037 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.

Hi,

ICANN/IANA doesn't assign resources to ISPs.

Regards,
-drc

Do we really want big brother sniffing around ? What about net neutrality ?

ICANN has no contractual relationship with the service providers abusing the
DNS, but a far reaching idea could claim ICANN responsibility and commitment
to preserve and enhance the operational stability, reliability,
security, and global
interoperability of the Internet, stated in one of its core values on
its bylaws.

Well Time Warner/Road Runner does it at least here in San Antonio, at least
the don't filter DNS traffic if you choose to use other name servers and don't
have a nasty proxy like the guys from Telefonica in Argentina.

DNSSEC is fully deployed (someday).

Regards
Jorge

It's fraud, theft or both.  The ISP's doing this don't own these
names and they are pretending to be someone they are not.  Just
because lots of them are doing it doesn't make it right.  You should
be able to go to your local police and report this and have action
taken.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka*******

Indirectly they're responsible for assignment of IP address, enterprise
numbers, domain names etc. Of course you're not going to get very far with
that approach.

My point was there isn't really an authority to enforce rules on ISPs when
it comes to how they manage their DNS servers. Government and IANA
won't be interested in fielding such complaints. Shining a flash light
on the problem publicly is going to be the best best.

--
Dan White

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.)

< http://queue.acm.org/detail.cfm?id=1647302> > lays out this case.
--
Paul Vixie
KI6YSY

any more.... :)

--bill

Hi,

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 happyif ICANN/IANA were to refuse to allocate a /8 (or a /12) to an RIRbecause one of the RIRs' customers was hijacking NXDOMAINs.

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

ICANN/IANA is directly responsible for (and has contractualrelationships with folks who operate) gTLDs and has, to the distress ofsome folks on this list, imposed restrictions onwildcards/synthesis/etc.  ICANN/IANA discourages wildcards/synthesis/etcfor ccTLDs, but the operation of a ccTLD is considered a nationalsovereignty issue and thus, ICANN/IANA has no way to do anything otherthan point out the problems wildcards/synthesis/etc. can lead to.  As Iwrite this, there are 11 ccTLDs that do wildcards/synthesis/etc. andthere will undoubtedly be more in the future. ICANN/IANA has nointeraction with, much less control, over ISPs.

Yep.

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

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

There are folks on this list who work for ISPs which are doingwildcards/synthesis/etc.  They (or, more likely their management) cantell you there are obvious business reasons why they dowildcards/synthesis/etc.  Perhaps I'm overly cynical, but I suspect thatuntil those business reasons go away, shining a flash light willprobably just result in more ISPs implementing wildcards/synthesis/etc.

Regards,
-drc

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

Regards,
-drc

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 ("noooooooooooo!!").

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 ).

* Jorge Amodio:

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.)

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

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?

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

I'm wondering if the money is sufficient for the SPs in question to resistDNSSEC 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 <rdobbins*******> >

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

                        -- H.L. Mencken

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

Why not simply run a validating resolver locally?

To quote you, "noooooooooooo!!"

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

Regards,
-drc

Dan,

CG (Congo) -- Web redirects to the registry website to register a .CGdomain.
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. Usesan 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 ASCIIlabels.

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

Regards,
-drc

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."

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  detect    the  IPs  that are wildcarding,
and substitute  responses detected as the wildcard  host IP addresses,
with  NXDOMAIN.

For example,   randomly generate  2  test lookups    for 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

Those who didn't read RFC2826 are condemned to repeat it.

Of course, it's *your* help desk that gets to answer the phone and explain
to your users why www.giraffes-r-us.com went to a nice page of cute pictures
of giraffes when they were at Starbucks, but when they got home to show
their kids, it was giraffe pr0n.

Preemptive action or smart move ?

http://googlecode.blogspot.com/2009/12/introducing-google-pu[..]

Cool IP address to remember though (8.8.8.8)

Cheers
Jorge