[dns-operations] IANA testbed problem

[George Barwood]

Florian,

Thanks, I realised this fairly shortly after posting ( maybe I should have followed-up ),
the last paragraph of http://tools.ietf.org/html/rfc4035#section-4.2 explains all.

I haven't yet understood *why* the standard is this way, as it seems quite counter-intuitive,
but certainly the onus is on resolvers to issue explicit NS queries to make sure the immediate
parent is queried. I think SOA records can be used to jump up the chain, but the standard
doesn't mention this.

It's certainly rather surprising and in-elegant ( why choose to answer a query from a zone
which is not authoritative for the query!), I presume there is some kind of backwards compatibility
justification, although I cannot see see it.

George

----- Original Message ----- 
From: "Florian Weimer" <fweimer at bfk.de>
To: "George Barwood" <george.barwood at blueyonder.co.uk>
Cc: <dns-operations at dns-oarc.net>
Sent: Friday, April 09, 2010 3:43 PM
Subject: Re: [dns-operations] IANA testbed problem


* George Barwood:

> should ( I think) be a referral to the org servers, since the DS RRset is served by the parent zone. 
> However, the actual response is an authoritative NoData response, 
>
> iana.org.               3600    IN      SOA     dns1.icann.org. hostmaster.icann
>
> i.e. it is coming from the iana.org zone rather than the root zone.
>
> Am I being stupid, or is this a bug?

Resolvers are supposed to have special processing logic (chopping of
labels from the front of the QNAME) to deal with this.  The production
root shows a similar behvaior for A.ROOT-SERVERS.NET/IN/DS queries.

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99