Re: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer
> On 5 Nov 2020, at 15:49, fujiw...@jprs.co.jp wrote: > >> From: Mark Andrews >> 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/ from root (or child.exapmle.net). > > Then I think the idea works. > > -- > Kazunori Fujiwara, JPRS > >>> 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 >>> >>> ___ >>> 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
Re: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer
> From: Mark Andrews > 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/ from root (or child.exapmle.net). Then I think the idea works. -- Kazunori Fujiwara, JPRS >> 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 >> >> ___ >> 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 > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer
> From: Bob Harold > If an attacker is spoofing responses, it seems that they could send a > different NS and A record, and a new calculated DS hash. So this provides > no protection against spoofing? > > We would need instead (or in addition) an RRSIG record to actually protect > this. Thanks for reading the draft. I'm assuming that DiS RR is treated as the DS RR, so if the parent side is signed, DS (+DiS) RRSet will be signed. > An example would help. Yes. I will add examples in next version. example.com.IN NS ns.example.com. ns.example.com. IN A 2001:dc8::53 example.com.IN DS 12345 8 2 (hash of DNSKEY RR) example.com.IN DS 0 0 100 (hash of (example.com IN NS | ns.example.com IN )) example.com.IN RRSIG DS (signature of DS RRSet (2 DSes)) DNSSEC signer may generate DiS RR and signature of DS RRSet (including DiS RR). -- Kazunori Fujiwara, JPRS > -- > Bob Harold > DNS and DHCP Hostmaster - UMNet > Information and Technology Services (ITS) > rharo...@umich.edu 734-512-7038 > > > On Tue, Nov 3, 2020 at 11:31 PM 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 >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer
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 > 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 > > ___ > 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-rfc7816bis: hopefully ready for WG Last Call
Thanks for the work on this, Stephane, Ralph, and Paul. Could you please clarify explicitly what should happen in the case of encountering CNAMEs? Or DNAMEs? The way I read it, at least for CNAMEs, is that you just keep prepending labels to the ANCESTOR name so encountering the CNAME is in practice no different from encountering any rrtype other than NS. This would also be consistent with the existing DNS not having any prohibition of data beneath a CNAME, such that we can fetch data for foo.bar.example.com even in the presence of a bar.example.com CNAME. Ralph's original presentation for OARC 24 though had a different implication on slide 11 that, in the absence of speaker explaining it to me, implies that encountering a CNAME ... well, I'm not sure. https://www.nlnetlabs.nl/downloads/presentations/unbound_qnamemin_oarc24.pdf#page=11 With the word "change" there and the arrows it says to me that it's doing a query restart on the CNAME and continuing onward with the minimisation algorithm from there. And it's mentioned right there with referrals as something parenthetically noteworthy. How do BIND andc Unbo,und currently handle this? I'm guessing both like the way described by the algorithm. It'd help future implementers to have explicit guidance. Perhaps something like: (6b) All other NOERROR answers (either positive or negative). Cache this answer. Regardless of the answered RRset type, including CNAMEs, continue with the algorithm from step 3 by building on the original QNAME. I changed it to "All other" because 6a is also a NOERROR answer. I orthogonally think you should make that change, even if my other text is rejected. I'm not feeling great about my wordsmithing, but I made an effort under the "please send text" maxim. Or maybe this should just be an unnumbered note at the end of the section, saying something like: Note that in this algorithm, encountering a CNAME is no different from encountering other non-referral positive answers. They are not followed when discovered for intermediate labels. Always use the labels of the original QNAME. Then have an example cover this case in section 4, maybe just by using NOTE to observe it could be "any positive answer, even CNAME". Doesn't fit on the line well though. Oh and for DNAME ... maybe in 6a describe that it's also a referral, one that should set CHILD to the target and resume the algorithm at step 5? That seems maybe insufficient, but it's a starting point for thinking about. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-bretelle-dnsop-recursive-iprange-location
Hi all, There is currently no streamlined way for recursive resolver operators to distribute the IP ranges/locations that their server farm may use. It is currently a mixture of csv files shared over email, or web pages with formats that may be unique to each provider and rarely directly parseable by automation. This document is an attempt to provide a consistent mechanism that recursive providers can use to distribute their ranges/locations, and auth providers can use to apply the policies they may wish to. Thanks Manu --- A new version of I-D, draft-bretelle-dnsop-recursive-iprange-location-01.txt has been successfully submitted by Emmanuel Bretelle and posted to the IETF repository. Name: draft-bretelle-dnsop-recursive-iprange-location Revision: 01 Title: Recursive Resolvers IP Ranges location distribution and discovery Document date: 2020-10-29 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/archive/id/draft-bretelle-dnsop-recursive-iprange-location-01.txt Status: https://datatracker.ietf.org/doc/draft-bretelle-dnsop-recursive-iprange-location/ Html: https://www.ietf.org/archive/id/draft-bretelle-dnsop-recursive-iprange-location-01.html Htmlized: https://tools.ietf.org/html/draft-bretelle-dnsop-recursive-iprange-location-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-bretelle-dnsop-recursive-iprange-location-01 Abstract: This document specifies a way for recursive resolvers operators to signal the IP ranges and locations used by their server pools. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/chantra/draft-dns-recursive-iprange-location. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-hardaker-dnsop-private-namespace-options
On 4 Nov 2020, at 17:47, Wes Hardaker wrote: "Andrew McConachie" writes: 1. Is a special-use domain per [RFC6761], and does not (and will never) exist in the GID. In this document, we refer to this as ".internal" for discussion purposes only following conventions in [draft-wkumari-dnsop-internal]. I read the above text as telling me that .internal will never exist in the GID. Ahh... thanks for the precise reference. Yes, those two bullets are backwards in their examples. Ugh. .internal and .zz should be switched there. (fixed in the source) Thanks Wes. That makes sense. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-hardaker-dnsop-private-namespace-options
"Andrew McConachie" writes: > 1. Is a special-use domain per [RFC6761], and does not (and will never) > exist in the GID. > In this document, we refer to this as ".internal" for discussion purposes > only following > conventions in [draft-wkumari-dnsop-internal]. > > I read the above text as telling me that .internal will never exist in > the GID. Ahh... thanks for the precise reference. Yes, those two bullets are backwards in their examples. Ugh. .internal and .zz should be switched there. (fixed in the source) -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer
If an attacker is spoofing responses, it seems that they could send a different NS and A record, and a new calculated DS hash. So this provides no protection against spoofing? We would need instead (or in addition) an RRSIG record to actually protect this. An example would help. -- Bob Harold DNS and DHCP Hostmaster - UMNet Information and Technology Services (ITS) rharo...@umich.edu 734-512-7038 On Tue, Nov 3, 2020 at 11:31 PM 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 > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-hardaker-dnsop-private-namespace-options
On 4 Nov 2020, at 2:11, Wes Hardaker wrote:
"Andrew McConachie" writes:
I’m having a hard time understanding the two proposed deployments
in
this document.
It's not as clean as I'd like, certainly. I was pushing up against
the
draft submission deadlines and didn't get all the wording into place.
In 2.2.1 it states that .internal does not exist in the GID. Yet in
the Summary section immediately after it states that .internal is an
unsigned TLD. Which is it?
.internal is an unsigned TLD and is the GID.
1. Is a special-use domain per [RFC6761], and does not (and will
never) exist in the GID. In this document, we refer to this as
".internal" for discussion purposes only following conventions
in
[draft-wkumari-dnsop-internal].
I read the above text as telling me that .internal will never exist in
the GID.
I don't see where in 2.2.1 it says that though.
In 2.2.2 it states that .zz is an unsigned delegation in the GID’s
DNS
root. Yet in the summary section it states that “.zz is a
special-use-like TLD that MUST never be assigned”. Which is it?
The later. .zz is not delegated. Again I'm not sure which sentence
you're referring to though.
2. Is an unsigned delegation within the (GID's) DNS root, with NS
records likely pointing eventually to something like
127.0.53.53.
In this document, we refer to this as ".zz" following convention
in [draft-ietf-dnsop-private-use-tld]. We note that
[draft-ietf-
dnsop-alt-tld] also proposed a private namespace (".alt") that
also fits into this category.
This seems to be saying that .zz is an unsigned delegation. Am I missing
something obvious here?
[someone did note that one of my section names is incorrect as well
and
referred to the wrong one]
My understanding of an unsigned TLD is that it is delegated in the
root zone unsigned. And I take it that GID is simply a synonym for
what many call The Public DNS.
Yep. It's "Global Internet's DNS (GID)", per the document.
There are, unfortunately, more than one naming environments. We've
known this for years with even /etc/hosts being different from the
DNS,
and NIS coming along later, etc. Nowdays, there are so many
split-systems with both internal and externally differing naming sets
I
was trying to use something that included the world "global" to be
super-clear this is the "big one".
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
