glue records in child zone

[Valentin Nechayev]

> > Some root servers (e.g. f.root-servers.net, c.root-servers.net) has
> > the same version as mine (9.4.2) and still respond with full list of
> > glue records. So, it is possible for these versions, isn't it?
> 	This is a referral.  Notice the answer section does not
> 	exist.  The additional section is expected to contain glue.

Sorry, Mark, this second letter was result of approval of dup sent
(one day earlier) from unsubscribed address and then resent from
correct address - list maintainer approved it when I had already
resent it from subscribed address.

I thought we already had discussed this issue (i.e. I have understood
your description of the BIND logic). My letter had got the sad *typo*:
of course I should name {c,f}.gtld-servers.net, not
{c,f}.root-servers.net. With correct naming, description of this hack
becomes correct:

; <<>> DiG 9.4.2 <<>> @f.gtld-servers.net c.gtld-servers.net a
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24411
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 8, ADDITIONAL: 8
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;c.gtld-servers.net.            IN      A

;; ANSWER SECTION:
c.gtld-servers.net.     172800  IN      A       192.26.92.30

[skipped rest of answer. -- Netch]

According to logic you described, in absense of knowing of
gtld-servers.net contents (these servers does not answer with the
zone SOA), it shall send only referral which contains NSes for
gtld-servers.net and its glue records which are *.nstld.com.
Instead, this named sends answer section with requested record from
the zone source. This fully corresponds with your earlier sentense
that these servers carry patched logic (I don't say this is the reason
because didn't check the logic by myself in BIND code, but at least
they don't contradict.)

On the other side, I'm still unsure this is finally stable logic to
drop glue record in another zone in special case this another zone is
child of current zone (in my example, ns1.hq.example.org inside child
zone `hq.example.org'). I guess this special case would be configured
specially, but I won't say this is my suggestion or proposal because
I'm definitely ignorant of many aspects and specifics.

> 	This is a answer but f.root-servers.net also serves
> 	root-servers.net so the A records come from the root-servers.net
> 	zone.  All the root servers are supposed to be serving
> 	root-servers.net so that they can return the address records
> 	for the root servers when they receive a "priming" ("."/NS)
> 	query from a interative resolver.  Note the ttl's of the
> 	additional records match those from the ROOT-SERVERS.NET
> 	zone.

As I already said this was typo - correct example should ask
f.gtld-servers.net. It seems not carrying the zone `gtld-servers.net'
(SOA query causes referral, not direct answer) but responds with its
address in direct (not referral) response.

Due to administrative issues we are unable to decide only by
technical committee to add direct glues to the real zone in question.
That's why I started this thread to detect whether is it possible to
fix the glue record answer problem by configuration option. According
to your words in previous letters, there is no problem here because
referrals carry enough information. After diagnosing I generally agree
with this - requests sent according to standard procedure meet
responses with full needed data. (Some problems can appear in case of
divergence of NSes and glues between a zone and its parent zone; in
this case the new behavior prevents recursive caching of incorrect
glues and therefore is very useful.)

But if one want to decide to treat glue record in child zone as
special case which doesn't exclude the record from original zone
contents, and allows it to be fetched using direct request - I'll
definitely meet this decision.:))


-netch-