In message <cakr6gn3ohsbmm9wcize8cg03ze2-nxcbvl4gnvj+k0gmtpl...@mail.gmail.com>
, George Michaelson writes:
>
> Mark.. can you amplify a bit on:
>
> >FORMERR will just cause the nameserver to think that EDNS is not
> >supported. This is not a issue unless there are signed zones and
> >the resolver is validating.
>
> Because somewhere north of 10% of the world now validates..
It is only a problem if the zone is signed and the server is broken
and you are validating. That combination is miniscule.
EDNS -> FORMERR -> Plain DNS
EDNS + OPTION -> FORMERR -> Plain DNS
Now nameservers could do
EDNS + OPTION -> FORMERR -> EDNS -> FORMERR -> Plain DNS
but that adds yet another round trip if EDNS is not supported.
BADVERS isn't as bad as you at least know that EDNS is supported
EDNS + OPTION -> BADVERS -> EDNS
That said we need to have a active program to notify operators of
broken servers so they can get them fixed before people run into
these issues.
It is easy enough to identify servers that misbehave with unknown
EDNS options. It only takes a couple of queries to differentiate
between EDNS not supported and broken EDNS support.
These were generated by looking at subsets of the Alexa top 1M and
processing the root zone.
http://users.isc.org/~marka/gov-report.html
http://users.isc.org/~marka/tld-report.html
http://users.isc.org/~marka/au-report.html
http://users.isc.org/~marka/alexa-report.html
http://users.isc.org/~marka/bottom-report.html
What would be useful would be for all TLD operators to generate
lists of broken servers and inform their operators.
Mark
> On Wed, Jan 14, 2015 at 10:09 AM, Mark Andrews <[email protected]> wrote:
>
> >
> > In message <[email protected]>, Paul
> > Wouters wr
> > ites:
> > > On Tue, 13 Jan 2015, Davey Song () wrote:
> > >
> > > > As to the draft itself, there are two questions:
> > > >
> > > > First, for a same transaction, the cost from using TCP may be more than
> > > > the gain from the queries you save, which may ultimately let the
> > > > performance become even worse. Do you have any consideration on this?
> > >
> > > And also, if already doing tcp the the auth server, why not just ask the
> > > 4 questions asynchronously over the TCP channel, instead of waiting to
> > > see if the server will give you a freebie, where you might have to send
> > > another query (After the RTT) for the data?
> > >
> > > > Second, the purpose of using TCP is to mitigate amplify attack as you
> > > > describe in the draft. I notice that there is a draft using DNS cookie
> > > > to counter that problem. But it lacks incentive to deploy. For my
> > concern,
> > > > you can consider to combine the two ideas to achieve better result.
> >
> > Nameserver vendors will just turn this on by default, that is ISC's
> > intention with named once the option is finalized. Theoretically
> > it should be ignored if not understood and if not it can be disabled
> > of a per server basis.
> >
> > >From BIND 9.10 (configure --enable-sit).
> >
> > server 2001:428::7 { request-sit no; };
> >
> > http://users.isc.org/~marka/ts/gov.optfail.html
> > http://users.isc.org/~marka/ts/au.optfail.html
> > http://users.isc.org/~marka/ts/tld.optfail.html
> > http://users.isc.org/~marka/ts/bottom.optfail.html
> > http://users.isc.org/~marka/ts/alexa.optfail.html
> >
> > FORMERR will just cause the nameserver to think that EDNS is not
> > supported. This is not a issue unless there are signed zones and
> > the resolver is validating.
> >
> > BADVERS is identifiable in the response and you use it as a heuristic
> > to disable sending the option.
> >
> > Echoing of the option is not a issue for cookies.
> >
> > Timeout will be treated like EDNS is not supported.
> >
> > NXDOMAIN can sometimes be returned by badly configured load balancers.
> > Adobe's load balance is a example of this. They just need CNAME's
> > added to the backend nameserver but Adobe doesn't seem to understand
> > this. They also don't respond correctly to CNAME queries despite
> > returning CNAME to A/AAAA queries.
> >
> > > The cookies wouldn't help much because it per definition introduced
> > > another round trip.
> >
> > Cookies don't "require" another round trip. Authoritative servers
> > can still adjust the responses they send depending upon whether
> > there is as valid server cookie or not.
> >
> > Additionally I don't see nameservers leaving idle TCP connections
> > around for hours / days.
> >
> > > Also, why hardcode the records on the auth server. I think it is much
> > > better to leave the auth servers as is, and have resolvers figure out
> > > dynamically what is often asked in bundles and see if it can stuff
> > > in an additional record there.
> > >
> > > While I see a great use of a long term TCP connection between stubs and
> > > resolvers, I am not sure I'm much in favour or doing lots of TCP between
> > > resolver and auth server.
> > >
> > > Paul
> > >
> > > _______________________________________________
> > > DNSOP mailing list
> > > [email protected]
> > > https://www.ietf.org/mailman/listinfo/dnsop
> >
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: [email protected]
> >
> > _______________________________________________
> > DNSOP mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/dnsop
> >
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
