>
> > 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
s/is real/is no real/
> 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]
--
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
--------------------------------------------------------------------
