[dnsop] draft-ietf-dnsop-bad-dns-res-04.txt is now out

["Larson, Matt" <[e-mail]>]

Folks,

I just submitted a new version of draft-ietf-dnsop-bad-dns-res.  If
you just can't wait to read it, it's available here right now:

http://www.verisignlabs.com/~matt/draft-ietf-dnsop-bad-dns-res-04.txt

It appears we last called this document twice, both in June-July and
November-December of last year.  I believe this new version addresses
all the comments received during both last call periods.  An omnibus
reply follows to address specific comments.

I'd like to give my sincere thanks to everyone who read the document
and made comments.  I'm sorry it's taken so long to get a new version:
full blame for the delay goes to me and not Piet Barber, my
long-suffering co-author.

Matt


On Fri, 11 Jun 2004, ?lafur Gu?mundsson wrote:
> I found one error,
> Section 2.5.1 first paragraph
> s/behind a firewall that prohibits queries to pass through/
>   behind a firewall that allows queries to pass through/

Fixed.

On Thu, 24 Jun 2004, Pekka Savola wrote:
> First, this document gives three sets of recommendations with 
> uppercase keywords.  This raises two issues:
> 
>  1) the category should be at least BCP, or the wording changed. 
> (You're making changes/enhancements to the standards track documents!)

I don't have strong feelings about how it ends up being published.  I
disagree that the document recommends changes to standards track
documents.  Upon a careful re-reading, I believe this document offers
implementation advice to iterative resolver developers and does not
change the DNS protocol itself.

>  2) have these changes been reviewed and/or adopted by DNSEXT WG?  

Not necessary in light of above, though comments from everyone are
welcome.

>    o  Do not make assumptions based on NS RRset order: all NS RRs should
>       be treated equally.  (In the case of the "com" zone, for example,
>       most of the root servers return the NS record for
>       "a.gtld-servers.net" first in the authority section of referrals.
>       As a result, this server receives disproportionately more traffic
>       than the other 12 authoritative servers for "com".)
> 
> ==> why don't they randomize it then?  seems like it's the root 
> servers that should be fixed here!

It's not a question of fixed or broken: you can't depend on RRset
order.  That being said, the current software on most of the roots
does not randomize, which lends support to this advice: don't depend
on RRset order.

> ==> should be updated to have RFC3668 boilerplate
>
> ==> should move the keywords from the abstract to the Introduction.

I'm using the latest xml2rfc which should address this.

> ==> all the references are listed as Normative, while some  (e.g., 
> [8]) certainly don't qualify as normative.  Perhaps move [7] and [8] 
> to informative references?

I made all the references Informative for now.

> ==> in abstract, s/This Internet-Draft/This memo/ (and similar -- this 
> text should also apply when published as RFC!!) [the same in IANA 
> considerations]

Done.

> 2.9.1 Recommendation
> 
>    It would be desirable for the root name servers not to have to answer
>    these queries: they unnecessarily consume CPU resources and network
>    bandwidth.  One possibility is for recursive name server
>    implementations to produce the Name Error response directly.  We
>    suggest that implementors consider the option of synthesizing Name
>    Error responses at the recursive name server.  The server could claim
>    authority for synthesized TLD zones corresponding to the first octet
>    of every possible IP address, e.g. 1., 2., through 255.  This
>    behavior could be configurable in the (probably unlikely) event that
>    numeric TLDs are ever put into use.
> 
> ==> does this work for v6 addresses?  maybe need a bit rewording.

Not applicable to IPv6 addresses for now, since the traffic in
question results from IPv4 addresses.  (Not everything in the IPv4
universe has an IPv6 analog...)

On Fri, 10 Dec 2004, JINMEI Tatuya / ?$B?@L@C#:H wrote:
> Below is my proposed text to address my concern.  I'd first like to
> proposed an additional paragraph at the end of section 2.2.  And then
> I'd propose some changes in the paragraph of Section 2.2.1.  In the
> proposed text I assume we can refer to
> draft-ietf-dnsop-misbehavior-against-aaaa-02.txt to provide background
> information, but I believe we can also convey the same point without
> the reference if we do not want to have an additional reference.
> 
> Thanks,
> 
> 					JINMEI, Tatuya
> 					Communication Platform Lab.
> 					Corporate R&D Center, Toshiba Corp.
> 					[e-mail]
> 
> 2.2  Repeated queries to lame servers
> 
> [...]
> 
>    It should also be noted, however, that some authoritative name
>    server behave as lame servers only for queries of some specific
>    types [x].  In this case, it makes sense to retry the "lame"
>    servers for other types of queries, particularly when all known
>    authoritative name servers seem to be "lame".
> 
> [x] draft-ietf-dnsop-misbehavior-against-aaaa-02.txt

Thanks.  I adopted this text almost as-is.

> 2.2.1  Recommendation
> 
>    Iterative resolvers SHOULD cache name servers that they discover are
>    not authoritative for zones delegated to them (i.e.  lame servers).
>    Lame servers MUST be cached against the specific query tuple <zone
>    name, class, server IP address>.  Zone name can be derived from the
>    owner name of the NS record that was referenced to query the name
>    server that was discovered to be lame.  Implementations that perform
>    lame server caching MUST refrain from sending queries to known lame
>    servers based on a time interval from when the server is discovered
>    to be lame as long as the implementations know non-lame servers.
>    A minimum interval of thirty minutes is RECOMMENDED.  However, it
>    still makes sense to keep trying the lame server when all servers
>    are seem to be lame as a last resort, in order to workaround the
>    type-specific lame servers described in the previous section.

Thanks.  I reworked this text and put it in.

On Sat, 20 Nov 2004, Andras Salamon wrote:
> I've attached a diff containing suggested fixes for a few nits.
> 
> The first is a missing 'by'.

Got it.

> The second is an insertion of a conditional into a MUST clause.

Got it.

> The third is replacement of 'zone name' with 'domain name associated
> with the root of the zone'.  As far as I can tell, zone name is not a
> term defined in any of the DNS standards documents and should be more
> clearly specified.

I disagree with this one: I think the text as it stands is
sufficiently clear.

> The last item is a fix for a double 'the'; this may have been obscured
> by the line unwrap.

Got it.

On Sun, 21 Nov 2004, Suzanne Woolf wrote:
> My only reservation is with the use of standards-track language in a
> BCP. The recommendations are good and useful in substance, but I'm not
> entirely comfortable that we're doing as much as we reasonably could
> to discourage errant vendors in future. 

I like the emphasis provided by the capitalized RFC 2119 words, but
I'm open to all alternatives.

On Sun, 21 Nov 2004, Mark Andrews wrote:
> 	2.6.1  Recommendation
> 
> 	The following sentence is not true.
> 
> 					       But in any case, the
>    address record must still be present in this zone, either as
>    authoritative data or glue.

Yes, you're right.

> 	The classic example is the root zone where the address
> 	records for the root servers are not part of the root zone.
> 	The root zone contains glue for the NET servers and the NET
> 	zone contain glue for ROOT-SERVERS.NET servers.
> 
> 	I would make 'missing "in zone" address records' a fatal load
> 	error.  Error messages don't get read unless the server stops
> 	serving the zone.  A address record is not "in zone" if there
> 	is a delegation between the top of zone and the owner name of
> 	the address record.
> 
> 	Note:  this also catches the cases were people only put in
> 	glue records.  In a IPv4 only world one could often get
> 	away with this.  In a IPv4/IPv6 world this fails miserably.

There were several opinions on this.  I changed the recommendation in
2.6.1 and I'm open to suggestions.

> 	2.3  Inability to follow multiple levels of out-of-zone glue
> 
> 	Should also say how to avoid this pactice.  The simple rule
> 	is that "a server SHOULD be an official server for the zone
> 	it lives in".  Historically this was the case.  Something like:
> 
>    You can avoid triggering this problem by always having a server
>    offically serve (be listed in the NS RRset) the zone it lives in.

Good idea.  I added this.

On Mon, 29 Nov 2004, Jaap Akkerhuis wrote:
> Executive Summary
> 
>  Although I think that most of it is fine, I have an issue with
>  section 2.9, "Queries for domain names resembling IP addresses".
>  I fear the recommendation(s) in 2.9.1 will create more problems
>  then they will solve. Therefore I propose to drop this section.

I didn't drop this section, but...

> Details:
> 
> Section 2.9 makes the observation that the root servers receive a
> lot of queries, which are actually IP numbers and notes that it
> would be desirable that these queries won't end up at the root
> servers at all. Therefore it is suggested that
> 
> 	(1) ...  implementors consider the option of synthesizing
> 	Name Error responses at the iterative resolver.  The server
> 	could claim authority for synthesized TLD's corresponding
> 	to the first octet of every possible IP address, e.g. 1.,
> 	2., through 255.  This behavior could be configurable in
> 	the (probably unlikely) event that numeric TLDs are ever
> 	put into use.
> 
> or that
> 
> 	(2) ... root servers delegate these domains to separate
> 	servers which are currently already delegated the in-addr.arpa
> 	zones corresponding to RFC 1918 for the AS 112 "black hole"
> 	project.
> 
> Suggestion (1):
> 
>  I consider it a bad idea that resolvers synthesize answers for
>  some class of specific names as suggested in (1), it is simply not
>  in the dns specifications. Making configurable in case numerical
>  become existing is not a good idea, because when they do, it will
>  be difficult, if not impossible, to have the configurations of all
>  caching forwarders changed timely and consistently whenever this
>  needs to be done.

...I agree with this.  Synthesizing Name Error is bad in light of
DNSSEC, which we creep every closer toward.  I've deleted this
suggestion and beg forgiveness.

> Suggestion (2):
> 
>  This means the root server operators change the root zone data on
>  their own, bypassing the usual channels.

I disagree here: the root operators don't ever change the root zone
contents.  Ever.  They just publish what comes from IANA.

I think if IANA wanted to add numeric TLDs and delegate them to the AS
112 servers (or wherever), it would be a good thing.  I don't ever
expect this to happen, but I don't think there's harm in mentioning
the problem of these IPv4-address-like domain names and a possible
solution.

> Also:
> 
> - The observation in 2.9 concentrates on ipv4 like addresses used
>   as names, but that is just a subset of the problem that too many
>   queries end up where they don't belong.  There are other ones,
>   such as queries for ".localdomain" and I won't be surprised that
>   ipv6 like addresses are showing up as well.

You're right, there are other problem strings that show up at the
roots.  I suppose the section could be expanded cover them, but you
have to start somewhere (if you're going to start in the first place).

> - Using technical tricks as suggested tolerates misbehaving resolvers
>   or bad configuration issues and thereby removes the motivations
>   of getting these things fixed. Where will this stop?

The problem is that there is no motivation for the offenders to fix
anything: with little or no cost they spew their junk at the roots,
where it is aggregated and becomes a nuisance.

> - If these solutions are going to adapted be anyway, there might
>   be impact on DNSSEC, which will require further study.

Agreed.

On Wed, 01 Dec 2004, Peter Koch wrote:
> >    domain (TLD) name servers.  In some cases we recommend minor
> >    additions to the DNS protocol specification and corresponding changes
> >    in iterative resolver implementations to alleviate these unnecessary
> 
> This promise would probably not warrant the BCP but instead the standards
> track. However, as far as I understood the recommendations they are all
> guidelines for resolver implementors and (recursive) server operators, so
> BCP
> is OK.
> However, I'd suggest the wording be changed to reflect that the standard
> itself, i.e. the on-the-wire protocol, remains unchanged. These are
> guidelines.

I believe the new abstract and introduction is now clear about the
scope and intent of the document.

> >    rate.  Some of the changes recommended affect the core DNS protocol
> >    specification, described principally in RFC 1034 [2], RFC 1035 [3]
> >    and RFC 2181 [4].
> 
> Since I may have missed those changes, could they please be clearly
> identified?

That text is now gone.

> > 2.1  Aggressive requerying for delegation information
> > 
> >    There can be times when every name server in a zone's NS RRset is
> >    unreachable (e.g., during a network outage), unavailable (e.g., the
> >    name server process is not running on the server host) or
> 
> ... or the host does not exist (name doesn't resolve) ...
> 
> >    For this query of the parent zone to be useful, the target zone's
> >    entire set of name servers would have to change AND the former set of
> >    name servers would have to be deconfigured or decommissioned AND the
> >    delegation information in the parent zone would have to be updated
> >    with the new set of name servers, all within the TTL of the target
> >    zone's NS RRset.  We believe this scenario is uncommon:
> >    administrative best practices dictate that changes to a zone's set of
> >    name servers happen gradually when at all possible, with servers
> >    removed from the NS RRset left authoritative for the zone as long as
> >    possible.  The scenarios that we can envision that would benefit from
> >    the parent requery behavior do not outweigh its damaging effects.
> 
> Explicit "NS" queries should never happen (there were some implicit
> assumptions
> in this direction during the discussion of wildcard NS RRs), but there are
> situations where some requery can be justified:

I've mentioned that QTYPE=NS is not part of the RFC 1034 algorithm.
That being said, I don't think we need to fear it.

> 1) When the NS-RRset in the parent zone is larger than that sent
>    authoritatively from within the zone, additional information may be
>    discovered. This is a configuration problem, of course, but is not too
>    uncommon.
> 
> 2) More importantly, consider a cache content like this:
> 
> 	example.com.		NS	dns.example.com.
> 				NS	dns.example.net.
> 	dns.example.net.	A	192.0.2.42
> 
>    The dns.example.com A RR has expired. Now, if dns.example.net is not
>    available, the zone is 'non-responsive'. To learn the address of
>    dns.example.com. there's no other way than to make use of the necessary
>    glue RR present in the COM zone, so there is justification for going
>    one step up. Another recommendation following from this could be that the
>    address records of nameservers in or below the zone served should not
> have
>    TTLs lower than the NS RRs.

I've noted this example.

> > 2.1.1  Recommendation
> > 
> >    An iterative resolver MUST NOT send a query for the NS RRset of a
> >    non-responsive zone to any of the name servers for that zone's parent
> >    zone.  For the purposes of this injunction, a non-responsive zone is
> >    defined as a zone for which every name server listed in the zone's NS
> >    RRset:
> >    1.  is not authoritative for the zone (i.e., lame), or,
> >    2.  returns a server failure response (RCODE=2), or,
> >    3.  is dead or unreachable according to section 7.2 of RFC 2308 [5].
> 
> This recommendation now can be adjusted accordingly. Explicit NS type
> queries
> can be recommended against reagrdless of the responsiveness of the zone.
> They
> have no place in the resolution process, do they?

I've chosen to leave the recommendation as-is because it addresses a
very specific bad behavior that I don't want to get lost if it were
generalized.  I believe I've still addressed your concern about
QTYPE=NS.

> > 2.2.1  Recommendation
> > 
> >    Iterative resolvers SHOULD cache name servers that they discover are
> 
> s/cache name servers/cache the status of name servers/;

Got it.

> >    not authoritative for zones delegated to them (i.e.  lame servers).
> >    Lame servers MUST be cached against the specific query tuple <zone
> >    name, class, server IP address>.  Zone name can be derived from the
> >    owner name of the NS record that was referenced to query the name
> >    server that was discovered to be lame.  Implementations that perform
> >    lame server caching MUST refrain from sending queries to known lame
> >    servers based on a time interval from when the server is discovered
> >    to be lame.  A minimum interval of thirty minutes is RECOMMENDED.
> 
> In general I support this recommendation. Here's a corner case:
> 
> 	dns.example.com is delegated (and detected) lame example.com but
> 	is authoritative for sub.example.net 
> 
> During resolving www.sub.example.net dns.example.com must be skipped but
> upon
> receipt of the referral containing the reference to dns.example.com it
> should
> be eligible again. The problem is that one cannot tell in advance whether
> www.sub.example.net is part of the example.net zone. The recommendation
> could be given more precisely:
> 
>   old:	MUST refrain from sending queries to known lame servers
> 
>   new:	MUST refrain from sending queries whose QNAME is likely to be in the
> 	lame zone (i.e. equals the zone name or is below the zone name and
> not
> 	positively identified to belong to a distinct zone) to known lame
> 	servers

This is a good point (i.e., don't consider subzones lame) and I put
text in to that effect.

> > 2.3  Inability to follow multiple levels of out-of-zone glue
> 
> In this paragraph the term glue is used where 'additional data' would be
> more
> precise.

This is a tough one terminology-wise.  I decided I didn't like
additional data, so I changed the text to "inability to follow
multiple levels of indirection".

> >    new gTLDs will use name servers in other gTLDs, increasing the amount
> >    of inter-zone glue.
> 
> Again, that's not glue then. s/glue/additional data/

Changed to "indirection" and side-stepped the terminology issue.

> > 2.4  Aggressive retransmission when fetching glue
> 
> >    implementations take this address inclusion a step further with a
> >    feature called "glue fetching".  A name server that implements glue
> 
> While at least one popular implementation called this 'fetch-glue', it's
> actually just additional section processing. Glue is just there (or it
> isn't),
> it can't be fetched. That should have been clarified by the AXFR draft, but
> that's unfortunately in some indetermined state.
> Sorry for the nitpicking here, but fuzzy or changing use of wording is
> extremely counterproductive in educating DNS operators. And yes, that does
> matter since they are part of our target audience here. So please let's
> use 'additional data processing' in favor of 'glue'.
> 
> The overall recommendation is fine, though.

Because there's a precedent for the term "glue fetching" and because
by even the most conservative defitnion, "glue" is an out-of-zone
address record, I left most occurrences of "glue" in this section.  We
might have to agree to disagree.  :-)

> > 2.6.1  Recommendation
> > 
> >    An authoritative server can detect this situation.  A trailing dot
> >    missing from an NS record's RDATA always results by definition in a
> >    name server name that exists somewhere under the SOA of the zone the
> 
> I'd prefer the term 'zone apex' over SOA, since the latter is just an RR
> type.

Yes, good call: I don't know what I was thinking using SOA here.

> >    NS record appears in.  Note that further levels of delegation are
> >    possible, so a missing trailing dot could inadvertently create a name
> >    server name that actually exists in a subzone.  But in any case, the
> >    address record must still be present in this zone, either as
> >    authoritative data or glue.
> 
> I disagree with this analysis. Given the zone
> 
> 	example.net.	NS	dns.example.net
> 			->	dns.example.net.example.net.
> 
> Now, if a delegation at example.net.example.net. or net.example.net. exists,
> there's no need that dns.example.net.example.net. be one of the
> authoritative
> servers, so the absence of a glue A RR does not indicate that the name
> dns.example.net.example.net. does not exist. So, not only doesn't it have to
> exist in the zone, it also need not be part of the zone file (using the AXFR
> draft logic).

Yes, you're as right as Mark Andrews was.  I changed the
recommendation a bit.

> >    An authoritative name server SHOULD report an error when one of a
> >    zone's NS records references a name server below the zone's SOA when
> 
> s/zone's SOA/zone apex/

Changed.

> >    a corresponding address record does not exist in the zone.
> 
> First, I'd suggest that any slave server only issue a warning but still load
> the zone. A master should report an error if the target of the NS RR
> is below the zone apex and an address record does not exist (because the
> name is within the zone and neither A nor AAAA RRsets exist or because the
> name doesn't exist) and a warning if the domain name belongs to a child
> zone (regardless of any glue RR).

I couldn't reconcile everyone's suggestions for this recommendation,
so we'll have to see how everyone likes what I wrote in 2.6.1.

> > 2.7.1  Recommendation
> > 
> >    Because of the additional load placed on a zone's parent's
> >    authoritative servers resulting from a zero TTL on a zone's NS RRset,
> >    under such circumstances authoritative name servers SHOULD issue a
> >    warning when loading a zone or refuse to load the zone altogether.
> 
> A warning is OK at both a master and a slave, otherwise a slave should not
> refuse a zone on these grounds. Causing harm sometimes heals, but the
> slave administrator can't do much about this problem. Also, the
> recommendation
> should be clear in what to do (warning vs error), and a warning seems less
> invasive here. Also, refusing to load a 0 TTL zone while silently accepting
> TTLs of 1 second is probably hard to sell.
> This is registry policy, though, and could already be implemented there ...

I relaxed 2.7.1 a bit.

> > 2.8.1  Recommendation
> > 
> >    Dynamic update agents SHOULD send SOA or NS queries to progressively
> >    higher-level zones to find the closest enclosing zone for a given
> 
> s/zones/names/, since there's no need to send the query to higher zones.
> The actual problem is that you don't know what zone the name belongs to.

Changed.

> >    name to update.  Only after the appropriate zone is found should the
> >    client send an UPDATE message to one of the zone's authoritative
> 
> I'd restrict this recommendation to SOA queries only. NS queries are
> currently
> not necessary and shouldn't be introduced. Also, the SOA MNAME might be
> helpful anyway.

I didn't (and don't) see the harm in using NS queries here.  Unless we
can make a case for their being harmful, I'd like to leave the text
as-is.

> > 2.9  Queries for domain names resembling IP addresses
> > 
> >    The root name servers receive a significant number of A record
> >    queries where the qname is an IP address.  The source of these
> 
> s/is an IP address/looks like an IP address/

Changed.

> > 2.9.1  Recommendation
> 
> >    to produce the Name Error response directly.  We suggest that
> >    implementors consider the option of synthesizing Name Error responses
> >    at the iterative resolver.  The server could claim authority for
> >    synthesized TLD zones corresponding to the first octet of every
> >    possible IP address, e.g.  1., 2., through 255.  This behavior could
> >    be configurable in the (probably unlikely) event that numeric TLDs
> >    are ever put into use.
> 
> That would be in conflict with DNSSEC, which isn't discussed in the security
> considerations section. Instead of fiddling with these issues at the
> iterative
> resolver, why not recommend stub resolvers either produce a name error or
> silently translate the query to the appropriate answer as gethostbyname()
> has been doing for quite some time?

Ack to the DNSSEC concern.  Regarding the stub resolver change, in my
opinion, we don't want to condone the bad behavior, which help from
gethostbyname() would do.

> >    Another option is to delegate these numeric TLDs from the root zone
> >    to a separate set of servers to absorb the traffic.  The "black hole
> >    servers" used by the the AS 112
> > Project [8], which are currently
> >    delegated the in-addr.arpa zones corresponding to RFC 1918 [7]
> >    private use address space, would be a possible choice to receive
> >    these delegations.
> 
> While that's an interesting project, now we have two alternatives. Which
> one is endorsed by the WG?
> 
> > 2.10  Misdirected recursive queries
> 
> > 2.10.1  Recommendation
> > 
> >    When the IP address of a name server that supposedly offers recursion
> >    is configured in a stub resolver using an interactive user interface,
> >    the resolver could send a test query to verify that the server indeed
> 
> That invites Murphy. The particular test query should be specified here,
> i.e. '<randomstring>.invalid'. To decrease root server load further, the
> test query might be sent non-recursively although I'm not confident that
> all implementations will offer RA if the query did not have RD set.

I didn't specify a specific query because any query should work,
right?

> >    The stub resolver could also report an error, either through a user
> >    interface or in a log file, if the queried server does not support
> >    recursion.  Error reporting SHOULD be throttled to avoid a
> >    notification or log message for every response from a non-recursive
> >    server.
> 
> Now, if there's state to keep anyway (for throttling), the answers should
> be delayed, too. This might work for stateless stub resolvers, too.

I don't understand what you mean about answers being delayed.

> > 2.11  Suboptimal name server selection algorithm
> 
> > 2.11.1  Recommendation
> 
> >    This list is not conclusive, but reflects the changes that would
> >    produce the most impact in terms of reducing disproportionate query
> >    load among a zone's authoritative servers.  I.e., these changes would
> >    help spread the query load evenly.
> >    o  Do not make assumptions based on NS RRset order: all NS RRs SHOULD
> >       be treated equally.  (In the case of the "com" zone, for example,
> >       most of the root servers return the NS record for
> >       "a.gtld-servers.net" first in the authority section of referrals.
> >       Apparently as a result, this server receives disproportionately
> >       more traffic than the other 12 authoritative servers for "com".)
> 
> Shouldn't the root servers also shuffle the NS RRset, as most of them (K and
> the NSD instance of H don't) do for the '.'?

Please see my comments above about depending on RRset order.

> > 4.  Security considerations
> 
> A discussion of the 'synthesis hack' in 2.9 is missing here.

No longer necessary since synthesis hack was dropped.

> > 6  Normative References
>  
> >    [8]  <http://www.as112.net>
> 
> Whether or not a reference is normative in a BCP may be irrelevant, but
> since
> this is a moving target, it might better be under informational references.

Ack.

> Finally, there's one assumption made in 1.1 which is current practice but
> not explicitly stated anywhere as far as I remember: the fact that
> 'recursive
> servers' or so called 'iterative resolvers' actually send only non-recursive
> queries. RFC 1034 in its section '2.3. Assumptions about usage' only
> addresses
> the server side, allowing servers to not offer recursion. The client side
> is covered later:
> 
>      Clients may request recursive service
>      from any name server, though they should depend upon receiving
>      it only from servers which have previously sent an RA, or
>      servers which have agreed to provide service through private
>      agreement or some other means outside of the DNS protocol
> 
> So, since root, TLD and many large ISP or enterprise servers have disabled
> recursion over time, we'd have arrived where we are. However, looking at
> our servers' logs, there are still a number of recursive queries which do
> not result from misdirected (stub) resolvers (covered in 2.10). So, an
> additional recommendation would be helpful stating that 'recursive servers'
> only issue queries with RD bit cleared.

I couldn't figure out a good place to fit this in.  It is a little
esoteric.  :-)

On Fri, 03 Dec 2004, Kevin Darcy wrote:
> Strongly agreed. SOA and zone apex are *not* interchangeable terms. This 
> is one of my pet peeves and I'm surprised I didn't notice it in my 
> previous readings of this ID.

Got it.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html