[dns-operations] Signaling client protocol to authority

[Mark Andrews]

In message <FDD5F81B-3512-4598-8FC3-5A63612451CA at ianai.net>, "Patrick W. Gilmore" 
writes:
> On Jan 16, 2011, at 9:05 PM, Paul Vixie wrote:
> 
> >> From: Dan Collins <en.wp.st47 at gmail.com>
> >> Date: Sun, 16 Jan 2011 20:10:32 -0500
> >> 
> >> Forgive me, but...exactly. Isn't that the problem? Not that a DNS
> >> server sends them an AAAA record that they can't use, but that they
> >> asked for an AAAA record that they can't use. The problem lies in the
> >> client that's making requests for an address using a protocol that it
> >> ought to know it can't use, and the problem is absolutely not that the
> >> server is doing exactly what the client asked it to do.
> >> 
> >> It isn't the job of a DNS server to decide what the DNS client
> >> actually wants.
> > 
> > +1.
> 
> -1
> 
> It is not the job of a DNS server to do anything except what the person
> configuring it tells it to do.
> 
> BTW, I do agree the problem isn't the name server, it is definitely the client. 
> However, Grandma ain't gonna figure out her OSX is too old to do v6 right (hell,
> the latest one STILL does broken shit), so perhaps we can help her out in other
> ways?

Well ask Apple/MS/RedHat/Google/Mozilla etc. to send out updates
for the broken applications even if they are deprecated.  Grandma
won't have turned off the update service.  It also much easier than
getting every ISP to update their nameservers to support a DNS
extension of questionable value.

This isn't about the OS doing things right.  The OS isn't broken.
It's the applications running on the OS and only a handful of them
in most cases.

> > however, and forgive me also, this isn't about dns, this is about money.
> > there is money being lost (or in some cases money not being made or made
> > fast enough or often enough) on the server and cdn side because clients are
> > asking for AAAA RR's they can't use.  the money is not being lost by the
> > clients, nor by the ISP's of the clients, nor by the vendors of the 
> > software used by the clients.  the money is being lost on the server side.
> > and so, irrespective of what the clients should have done or should do,
> > or what is or is not in-purview for the dns server, we're going to see a
> > never-ending set of proposals from server-side vendors and operators to
> > get this problem solved.
> 
> First, yes, this will probably end up being about money.  Which, to a first
> approximation, encompases _everything_ on the 'Net.  Anyone who says otherwise
> is deluding themselves.  (Or worse, trying to delude you.)

And for many sites it is not a problem, otherwise there wouldn't
be any IPv6 web services at all.

> Second, it is not just server-side people who need this fixed.  You really
> think Comcast isn't worried about calls from broken v6 end users?

Yes they are worried which is why they have added 6to4 relays on
their own network.  This improves the IPv6 connectivity for their
customers that use 6to4.  It also improves IPv6 connectivity for
any other 6to4 clients out there that talk to them.

Every ISP that offers IPv6 should be deploying 6to4 relays.  This
then brings 6to4 connectivity issues back under control of the point
ISP's rather than trying to diagnose problems with 3rd party relays.

> You really think if we can collectively do something to lower their call
> center queue that they wouldn't jump on it?  Again, anyone who thinks
> otherwise is deluding themselves.

They will get just as many calls about AAAA records not being
returned when they should be.

> Third, assume only server-side people want something.  Is that so terrible?
> Suppose only client-side people want something?  Does that automatically
> make it bad?

No.  It's not terrible, just misdirected.

> Finally, I think your last four words are the most important.  "[G]et this
> problem solved."  It is a problem.  It does need solving.  So what exactly
> is wrong with proffering solutions?

There's nothing wrong with offering solutions.  However the "solution"
being offered introduces its own set of problems and does not get
to the heart of the problem.  The "solution" is seen, by many, as
being worse than the problem.

> As a side note, you _really_ need to stop seeing everything through the
> "CDN is bad" lens.  Akamai had nothing to do with my question, and I
> honestly don't know if anyone inside Akamai would code such a thing if
> there were an RFC available today.  That's not why I was asking.  (To be
> honest, it had nothing to do with money either, I was just musing about
> ways to stop the whitelisting & such.  But, since white-listing is about
> money, even though money wasn't my original motivation, I am
> guilty-as-charged - it ended up being about money in the end.)
> 
> -- 
> TTFN,
> patrick
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org