> Set 3:
>
> > One bigger issue, which may not be worth a Discuss, but
> > something that
> > IMHO should be discussed in some forum:
> >
> > All nodes that need to resolve names SHOULD implement stub-
> > resolver [RFC-1034] functionality, in RFC 1034 section 5.3.1 with
> > support for:
> >
> > - AAAA type Resource Records [RFC-3596];
> > - reverse addressing in ip6.arpa using PTR records [RFC-3152];
> > - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512
> > octets.
> >
> > .. I'm operationally concerned about the last SHOULD. As far as I
> > know, EDNS0 is not really implemented. It does not seem to include a
> > SHOULD to something that hasn't seen practical, wide-spread deployment
> > already. I'd recommend removing this or rewording it to a MAY.
Define "not really implemented".
RFC 2671 was published August 1999.
Production servers w/ EDNS0 were release Jan 2000.
The root servers have been EDNS aware for over a year if memory
serves me. There is still one holdout (B).
Even the load balancer cowboys are implementing EDNS0.
Their server's may not understand MX/NS/SOA/AAAA but they
do understand EDNS queries.
Over half the servers on the net currently talk EDNS based on
the figures I have seen.
The majority of the problems come from servers that fail to
implement RFC 1034 by dropping EDNS queries and firewalls that
either reject additional records in queries or reject UDP answers
bigger than 512 octets. Retrying the query w/o EDNS on timeout
addresses these.
The firewall vendors now have code that is EDNS aware.
Most of the servers that dropped EDNS queries were load balancers.
While we still have to win the battle to get them to understand
AAAA. They appear to have seen the light on EDNS.
I have no problem with a SHOULD for stub resolvers. While most
don't do it there is real unknowns in saying that they should
do it. The caching server they are using most probably is already
making EDNS queries on their behalf.
Mark
> John
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [EMAIL PROTECTED]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
