Subject: ANY queries, recursing nameserver?

From: bert hubert <[email-masked]>
Date: Tue, 28 Mar 2006 20:46:39 +0200

People,

I've trawled RFC 1034, 1035 and 2181, yet I can't find it written down on
what a recursing nameserver should do on receiving an ANY query (aka
QTYPE=*).

http://www.faqts.com/knowledge_base/view.phtml/aid/30221 lists nonsense I
think - step 4 of the algorithm is never reached if RD is turned on.

'Mr DNS' (why I think was Cricket), said in 1997:

   Actually, a T_ANY lookup isn't guaranteed to return the TXT records,
   unless you're querying the authoritative name server directly. On another
   name server, T_ANY will only return whatever the server already knows
   about the domain name.

I'd love to believe this but it doesn't sound all too useful to me, but it
sure makes coding simple.

Anybody have an authoritative (haha) reference?

Thanks.

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "Everhart, Craig" <[email-masked]>
Date: Tue, 28 Mar 2006 14:07:57 -0500

My mental model is that T_ANY semantics agrees with 'Mr DNS'.  If the
server knows anything about the name, that's what the response will be.
If it has to forward the query, you might get back what some *other*
server knows about the name, which might be authoritative.

Back in the day I was sending mail, so I needed T_MX if it existed, but
T_A if it didn't.  I decided to query with T_ANY and see what I got,
then for the specific types, just because of this T_ANY behavior.  That
is, if my server had to ask around for the answer, it might as well get
everything (with T_ANY) rather than have to make one trip for T_MX and
then another for T_A.

I think the point is that T_ANY is not what the hypothetical
T_ABSOLUTELY_EVERYTHING might be.

		Craig 

> -----Original Message-----
> From: bert hubert [mailto:[email-masked]] 
> Sent: Tuesday, March 28, 2006 1:47 PM
> To: [email-masked]
> Subject: ANY queries, recursing nameserver?
> 
> People,
> 
> I've trawled RFC 1034, 1035 and 2181, yet I can't find it 
> written down on what a recursing nameserver should do on 
> receiving an ANY query (aka QTYPE=*).
> 
> http://www.faqts.com/knowledge_base/view.phtml/aid/30221 
> lists nonsense I think - step 4 of the algorithm is never 
> reached if RD is turned on.
> 
> I'd love to believe this but it doesn't sound all too useful 
> to me, but it sure makes coding simple.
> 
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' 
> in a single line as the message text body.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 30 Mar 2006 09:14:15 +1100

> On Wed, Mar 29, 2006 at 02:10:37PM -0500, Edward Lewis wrote:
> > Going back to the start of the thread...
> > 
> > Does anyone want a T_ALL?
> 
> I wouldn't say no to it, but what most clients actually want is probably
> more along the lines of T_ADDR. I can't think of a use case where you'd just
> want to have *everything*.
> 
> It would need to be an EDNS thing though.
> 
> Generally, I think there are bigger fish to fry in the DNS world.
> 
> My own favorite, and one that I think DNS operators are actually waiting
> for, is the zone provisioning protocol as described in:
> http://www.ops.ietf.org/lists/namedroppers/namedroppers.2003/msg00565.html
> 
> And in this message to dnsop, which appears not to have arrived or hasn't
> been archived:
> 
> I've been pondering writing a 'zone provisioning protocol', from
> http://wiki.powerdns.com/projects/trac/wiki/TodoList :
> 
>  The big idea waiting to happen is the Zone Provisioning Protocol which
>  allows 'dns peers' to exchange zones, or force resyncs (regardless of SOA
>  serial numbers). This might live outside of PowerDNS
> 
> Would anybody be interested in this?
> 
> My idea would be to keep this as simple as possible, but still provide for
> zones to be provisioned and deprovisioned by different parties, ie, you get
> to deprovision only the zones you've previously provisioned etc.
> 
> It is highly probable that this protocol will not be on port 53, nor use DNS
> messages. It would only talk about DNS.
> 
> Let me know.

	It would be interesting.  Whatever it is would need to be
	extensible and handle vendor specific extensions.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]