> On 5 Nov 2020, at 15:49, fujiw...@jprs.co.jp wrote:
>
>> From: Mark Andrews <ma...@isc.org>
>> 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
I ment
child.example.net NS a.sub.child.example.net
a.sub.child.example.net A 1.2.3.4
(which should have been obvious from the paragraph above)
>
> "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 <fujiw...@jprs.co.jp>
>
>>> On 4 Nov 2020, at 15:31, fujiw...@jprs.co.jp 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 <fujiw...@jprs.co.jp>
>>>
>>> _______________________________________________
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>>
>>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
