Re: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer

[[e-mail]]

> From: Mark Andrews <[e-mail]>
> One problem with DiS is that assumes that address records in the additional
> section *always* come from the delegating zone (see how the hash is created).
> This is not how DNS works.  Address records can, correctly, come from other
> sources, even when the name is *below* the zone cut.
> 
> Take a server that serves example.net and sub.child.example.net.  That A record
> comes from sub.child.example.net not example.net when the name of the server is
> a.sub.example.net.
> 
> 	child.example.net NS a.sub.example.net
> 	a.sub.example.net A 1.2.3.4
> 
> Mark

"a.sub.example.net" is not a "in-domain" glue. (it is "sibling" glue).
Then, DiS RR for child.example.net will be generated
from "child.example.net NS a.sub.example.net".

Authoritative server of "child.example.net" responds
  child.example.net NS a.sub.example.net in authority section
  with/without a.sub.example.net A 1.2.3.4 as a glue in additional section.

Sibling glue "a.sub.example.net A 1.2.3.4" is not a target of DiS RR
for "child.example.net NS".
Validator can validate "child.example.net NS a.sub.example.net".

Validating resolver can accept the sibling glue "a.sub.example.net A 1.2.3.4".
Or,
validating resolver may reject the sibling glue "a.sub.example.net A 1.2.3.4",
and treat it similar to out-of-bailing domain name,
then, resolve "a.sub.example.net" A/AAAA from root (or child.exapmle.net).

Then I think the idea works.

--
Kazunori Fujiwara, JPRS <[e-mail]>

>> On 4 Nov 2020, at 15:31, [e-mail] wrote:
>> 
>> I submitted draft-fujiwara-dnsop-delegation-information-signer-00.
>> 
>> Name:		draft-fujiwara-dnsop-delegation-information-signer
>> Revision:	00
>> Title:		Delegation Information (Referrals) Signer for DNSSEC
>> Document date:	2020-11-03
>> Group:		Individual Submission
>> Pages:		6
>> URL:            https://www.ietf.org/archive/id/draft-fujiwara-dnsop-delegation-information-signer-00.txt
>> 
>> DNSSEC does not have a function to validate delegation information.
>> I think it is a large missing peace of DNSSEC.
>> 
>> I have a question why we did not include signature validation function
>> to delegation information ?
>> 
>> Probably, because it is non-authoritative information.
>> Or, because it was difficult to define the necessary and sufficient
>> delegation information.
>> 
>> It is now widely agreed (although not explicitly documented) that the
>> delegation information is the information used for name resolution and
>> does not result in name resolution.
>> 
>> We have a word "in-domain" glue which is the necessary and sufficient glue.
>> 
>> And the idea may offer the signature for root priming data.
>> 
>> If someone interested the document, I would like time slot at dnsop WG
>> meeting.
>> 
>> Regards,
>> 
>> --
>> Kazunori Fujiwara, JPRS <[e-mail]>
>> 
>> _______________________________________________
>> DNSOP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: [phone]              INTERNET: [e-mail]
> 
>