Re: [dnsext] Failure to add glue MUST cause TC to be set.

["George Barwood" <[e-mail]>]

----- Original Message ----- 
From: "Mark Andrews" <[e-mail]>
To: "George Barwood" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, February 21, 2011 10:06 PM
Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set.


> 
> In message <4DFFA0E09D824AEC92EA89AFFB9F2120@local>, "George Barwood" writes:
>> 
>> ----- Original Message ----- 
>> From: "Mark Andrews" <[e-mail]>
>> To: "George Barwood" <[e-mail]>
>> Cc: <[e-mail]>
>> Sent: Sunday, February 20, 2011 10:58 PM
>> Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set.
>> 
>> 
>> > 
>> > In message <3D9B2A0D15F84DC6822FCF0FC6F8F214@local>, "George Barwood" writes:
>> >> 
>> >> ----- Original Message ----- 
>> >> From: "Mark Andrews" <[e-mail]>
>> >> To: "George Barwood" <[e-mail]>
>> >> Cc: <[e-mail]>
>> >> Sent: Sunday, February 20, 2011 9:07 PM
>> >> Subject: Re: [dnsext] Failure to add glue MUST cause TC to be set.
>> >> 
>> >> 
>> >> > 
>> >> > In message <3764325DE7FA4B2F9B77387EBD15EAF8@local>, "George Barwood" writes:
>> >> >> >> ----- Original Message ----- 
>> >> >> >> From: "Mark Andrews" <[e-mail]>
>> >> >> >> To: <[e-mail]>
>> >> >> >> Sent: Saturday, February 19, 2011 9:07 PM
>> >> >> >> Subject: [dnsext] Failure to add glue MUST cause TC to be set.
>> >> >> >> 
>> >> >> >> > Below is a example of why TC should be set when glue cannot be added
>> >> >> >> > to the answer.
>> >> >> >> > 
>> >> >> >> > [..]
>> >> >> >> 
>> >> >> >> Agreed, but where exactly should the line be drawn?
>> >> >> > 
>> >> >> > What line?  If the glue doesn't fit then the referral is not complete.
>> >> >> > 
>> >> >> >> If omitting any glue leads to truncation, then many (non-DNSSEC) referrals
>> >> >> >> over UDP will have TC set. e.g. 
>> >> >> >> 
>> >> >> >> dig foo.com @a.root-servers.net
>> >> >> > 
>> >> >> > Yes.
>> >> >> > 
>> >> >> >> Is that sensible?
>> >> >> > 
>> >> >> > Yes.
>> >> >> > 
>> >> >> >> How much glue is enough?
>> >> >> > 
>> >> >> > Depends on the delegation.  The only safe answer is all you have.
>> >> >> 
>> >> >> One suggestion that might work is that glue which matchs QNAME+QTYPE MUST
>> >> >> be included, but other glue can be omitted.
>> >> > 
>> >> > This does not work in all cases where glue needs to be returned.
>> >> > 
>> >> > Zone A.net is served by servers in B.net.  Zone B.net is served by
>> >> > servers in A.net.
>> >> 
>> >> So something like
>> >> 
>> >> 
>> >> But nothing will work in that case - if you make a recursive loop like this,
>> >> then there is no glue ( the name server names are not "below" the cut ) and
>> >> you have had it regardless. 
>> > 
>> > Glue records are records in the parent zone to enable you to reach
>> > the servers for the child zone.  RFC 1034 gave a obvious example
>> > of such records.  There are less obvious examples.
>> > 
>> >> That's a mis-configuration, not a counter-example.
>> > 
>> > No. It is not a mis-configuration.
>> 
>> RFC1034 says
>> 
>>   To fix this problem, a zone contains "glue" RRs which are not
>>   part of the authoritative data, and are address RRs for the servers.
>>   These RRs are only necessary if the name server's name is "below" the
>>   cut, and are only used as part of a referral response.
>> 
>> The second sentence rules out the mutually recursive case ( very sensibly ).
> 
> No.  It just means that they failed to fully analyse the problem.

That's possible. Or they may have fully understood and chosen this form of words
to rule out the mutually recursive case in a subtle way.

I think the other possibility is they were viewing it from an operators point of view.
They were saying "this is all you need". RFC1033 has similar language.

Regardless, the RFC does not deal with this case, so it's best to avoid it.
My resolver rejects all glue that is not in-zone, and in several years of use I have not seen a problem,
so it seems that this technique is not in widespread use.

> 
> If they wanted to prevent the mutually recursive case there would
> have been words to outlaw it or warn of it.  RFC 1034 contains lots
> of errors this is just another one.

I don't think you can call it an error. It is an ambiguity / omission.

Anyway, regardless, to come back to the original suggestion on when glue is essential.
If you want to support this extended form of glue, then such glue records must be included
in a referral, with TC set if there is no room. "Conventional" (in-zone) glue records can
be omitted (to avoid truncation) unless they match QNAME/QTYPE.
This rule avoids TCP fallback in common non-DNSSEC cases.

George
 
> Mark
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]                 INTERNET: [e-mail]