Re: [DNSOP] [homenet] My assessment of .homenet as described during the WG session yesterday.
In message , Brian Dickson writes: > On Wed, Mar 29, 2017 at 5:07 PM, Mark Townsley wrote: > > > > > > On Mar 29, 2017, at 10:07 AM, Michael Richardson > > > wrote: > > > > > > > > > Terry Manderson wrote: > > >> B) seek a .homenet special use domain WITHOUT the delegation request > > >> AND ask the IETF/IESG/IAB to commence the discussion with the ICANN > > >> community to achieve an insecure delegation > > > > > >> c) seek a .arpa insecure special use delegation > > > > > >> d) go for "B" and if that doesn't work shift to "C" > > > > > > Is there some reason we can not proceed with "C", concurrently with (B). > > > > I think that would require a new consensus call. There was a lot of work > > done to get to the point of agreeing on a path forward at the last IETF, > > and this path would be rather different than that. > > > > > This might cause stub resolvers to have to have two cases > > > (SOMETHING.arpa, and .homenet) eventually, but at least we could deploy > > > and attempt interop with SOMETHING.arpa NOW, and it would more clearly > > > permit "home." to be removed from code. > > > > > > > /chair-hat-off > > > > I donât think we want to have two defaults in our specs. Itâs bad enough > > that we are already going to end up with .home and .homenet depending on > > the version of code used or forked from, I really donât want to do > > anything > > that could lead to a third if we can avoid it. > > > > - Mark > > > > Taking a STRICTLY devil's advocate position here: > > Isn't it the case that the thing that knows what the label is, > should be able to masquerade on behalf of anything that isn't aware of the > divergence of the three possible values for ? If you end up with > some boxes thinking it is ".home", some ".homenet", and some > ".homenet.arpa", as long as one of them knows about all three, it should > be possible to resolve the differences. > > The scope of the namespace is "the home network", and never reaches the > real DNS (roots), so at worst it would be folding the three fake > namespaces into a unified (three-headed) fake namespace. Can we please stop with this "and never reaches the real DNS (roots)" garbage. Queries for homenet/DS *will* reach the roots. That is how DNSSEC validation is designed to work. They *need* to be answered with a signed NOERROR NODATA response. Lots of Linux distributions ship with DNSSEC validation enabled for on machine clients and they are also configured to forward to the nameservers that are returned by DHCP. These machines behave *exactly* like a validating stub resolver from the DNSSEC perspective. This isn't something that will be in the future. It is the PRESENT. > I.e. avoid it if you can, but if you can't, I think the issues are > solvable, even if they get a little funky/ugly under the hood. > > None of that should be visible to users, I don't think. > > Brian > > P.S. Guide to implementers - never expose multiple handles for the same > object; over-exuberant users may be tempted to try to "clean up" the > duplicates. -- 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] [homenet] My assessment of .homenet as described during the WG session yesterday.
On Wed, Mar 29, 2017 at 5:07 PM, Mark Townsley wrote: > > > On Mar 29, 2017, at 10:07 AM, Michael Richardson > wrote: > > > > > > Terry Manderson wrote: > >> B) seek a .homenet special use domain WITHOUT the delegation request > >> AND ask the IETF/IESG/IAB to commence the discussion with the ICANN > >> community to achieve an insecure delegation > > > >> c) seek a .arpa insecure special use delegation > > > >> d) go for "B" and if that doesn't work shift to "C" > > > > Is there some reason we can not proceed with "C", concurrently with (B). > > I think that would require a new consensus call. There was a lot of work > done to get to the point of agreeing on a path forward at the last IETF, > and this path would be rather different than that. > > > This might cause stub resolvers to have to have two cases > > (SOMETHING.arpa, and .homenet) eventually, but at least we could deploy > > and attempt interop with SOMETHING.arpa NOW, and it would more clearly > > permit "home." to be removed from code. > > > > /chair-hat-off > > I don’t think we want to have two defaults in our specs. It’s bad enough > that we are already going to end up with .home and .homenet depending on > the version of code used or forked from, I really don’t want to do anything > that could lead to a third if we can avoid it. > > - Mark > Taking a STRICTLY devil's advocate position here: Isn't it the case that the thing that knows what the label is, should be able to masquerade on behalf of anything that isn't aware of the divergence of the three possible values for ? If you end up with some boxes thinking it is ".home", some ".homenet", and some ".homenet.arpa", as long as one of them knows about all three, it should be possible to resolve the differences. The scope of the namespace is "the home network", and never reaches the real DNS (roots), so at worst it would be folding the three fake namespaces into a unified (three-headed) fake namespace. I.e. avoid it if you can, but if you can't, I think the issues are solvable, even if they get a little funky/ugly under the hood. None of that should be visible to users, I don't think. Brian P.S. Guide to implementers - never expose multiple handles for the same object; over-exuberant users may be tempted to try to "clean up" the duplicates. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [homenet] My assessment of .homenet as described during the WG session yesterday.
> On Mar 29, 2017, at 10:07 AM, Michael Richardson > wrote: > > > Terry Manderson wrote: >> B) seek a .homenet special use domain WITHOUT the delegation request >> AND ask the IETF/IESG/IAB to commence the discussion with the ICANN >> community to achieve an insecure delegation > >> c) seek a .arpa insecure special use delegation > >> d) go for "B" and if that doesn't work shift to "C" > > Is there some reason we can not proceed with "C", concurrently with (B). I think that would require a new consensus call. There was a lot of work done to get to the point of agreeing on a path forward at the last IETF, and this path would be rather different than that. > This might cause stub resolvers to have to have two cases > (SOMETHING.arpa, and .homenet) eventually, but at least we could deploy > and attempt interop with SOMETHING.arpa NOW, and it would more clearly > permit "home." to be removed from code. > /chair-hat-off I don’t think we want to have two defaults in our specs. It’s bad enough that we are already going to end up with .home and .homenet depending on the version of code used or forked from, I really don’t want to do anything that could lead to a third if we can avoid it. - Mark >> Again, this situation is fluid and as discussions evolve I will provide >> more information when it is appropriate. In the mean-time I would very >> much like everyone to take a calming breath and understand that I am >> taking a very pragmatic view of this concern. > > Thank you! > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > ___ > homenet mailing list > home...@ietf.org > https://www.ietf.org/mailman/listinfo/homenet ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New draft for ALIAS/ANAME type
On Wed, Mar 29, 2017 at 11:14 AM, Pieter Lexis wrote: > Hello Anthony, > > On Wed, 29 Mar 2017 08:51:50 -0500 > Anthony Eden wrote: > >> https://datatracker.ietf.org/doc/draft-dnsop-eden-alias-rr-type/ >> >> This draft describes the ALIAS/ANAME record (aka CNAME-flattening) >> that numerous vendors and DNS providers are now supporting in >> proprietary fashions. I hope that this draft will eventually lead to a >> good mechanism for interop of ALIAS/ANAME records. > > First off, thank you for this. I would love to hear from current implementors > of ALIAS/ANAME/CNAME-flattening what their ideas/critisisms are. > > This said, I have several comments after a first quick read of the document. > > There is no mention of the fact that ALIAS is mostly meant for zone apexes > where other records MUST be present and a CNAME cannot exist. CNAMEs would > cover non-apex usecases for ALIAS. As Tony pointed out, there are use cases for non-apex nodes as well. > > I miss guidance what should happen when an ALIAS record is queried directly > (would it be returned, should it be refused, should it be an empty response?). It's a good point. Our implementation doesn't expose the ALIAS itself as a queryable type, but there is a legitimate argument to allow it. > > I miss words on the interaction between ALIAS records and other (mostly A and > ) records on the same node. +1. In our case we would return both the static records as well as the materialized records. > > Section 3.1 > > "The server will respond with one or more A records", I fail to see why this > cannot be zero or more. Am ALIAS target without A or records should > yield an empty response from the authoritative server. Good point. > > "If the recursive query returns an NXDOMAIN response, then the authoritative > name server MUST return an NXDOMAIN response as well.". If any other records > exist (which is always the case for the apex), or if there are labels > underneath the ALIAS'es name, the authoritative server cannot send out > NXDOMAIN. Also a good point. I actually need to check our implementation to see how it behaves now in this case. > > Section 3.3 > > This section has 2 similar paragraphs, one with should and the other with > MUST. Yes, I am removing the extra paragraph and going with MUST. > > Asking directly for a CNAME for a node that only has an ALIAS record should > yield a response indicating that RRType does not exist at that node. I agree. > > Again, thank you for starting this draft. I support adoption of this draft in > the dnsop WG to facilitate better interop between > ALIAS/ANAME/CNAME-flattening implementors. Thank you for your feedback, I appreciate it. -Anthony -- DNSimple.com http://dnsimple.com/ Twitter: @dnsimple ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-serve-stale
On Wed, Mar 29, 2017 at 2:10 PM, Paul Vixie wrote:
>
>
> Shumon Huque wrote:
> > On Tue, Mar 28, 2017 at 12:20 PM, Paul Vixie > ...
> >
> > speaking of resimprove, i hope you'll include in this draft the idea
> of
> > using delegation-TTL as a delegation-recheck interval, and using an
> > authoritative NXDOMAIN from the delegator as proof that you need to
> run
> > an "rm -rf" in your cache.
> >
> > i bring this up because we need to be able to kill more cached data
> > faster-- the opposite of stretchiness-- for abuse control reasons. if
> > you're going to soften the signaling for cache expiration, you really
> > ought to balance that out with this simple method of also hardening
> it.
> >
> > Perhaps you've forgotten (since you participated in the discussions), but
> > the portion of resimprove that dealt with expunging cached data below the
> > NXDOMAIN boundary was rescued, expanded on, and published as
> > RFC 8020 ("NXDOMAIN: There Really is Nothing Underneath") late last
> > year.
>
> yes, i know that RFC 8020 includes both the idea of stopping downward
> searches when a cached NXD is encountered, and the idea of pruning (like
> "rm -rf" in UNIX) existing cache entries when an NXD is received. those
> changes, in addition to QM, will do much to pacify the DNS data model.
>
> however, it's equally vital for malicious DNS content takedown, that the
> part about remembering the delegation NS TTL and using it to
> periodically revalidate the existence of that delegation, also be
> brought forward. this becomes even more vital if we're making TTL
> stretchy, and i would be happy to see tale's document cover this topic.
> in other words, the prune-and-stop on NXD must be given a new source of
> NXD, which is delegation revalidation. i'd love it if delegations all
> had a one hour or less TTL, at least for public suffixes.
>
Yes, I forgot to comment on that piece in the previous email. I agree
that delegation revalidation should be published also. Among other things,
I think it effectively solves the ghost domain problem that was discussed
during the last IETF and DNS-OARC.
--
Shumon Huque
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-serve-stale
Shumon Huque wrote:
> On Tue, Mar 28, 2017 at 12:20 PM, Paul Vixie ...
>
> speaking of resimprove, i hope you'll include in this draft the idea of
> using delegation-TTL as a delegation-recheck interval, and using an
> authoritative NXDOMAIN from the delegator as proof that you need to run
> an "rm -rf" in your cache.
>
> i bring this up because we need to be able to kill more cached data
> faster-- the opposite of stretchiness-- for abuse control reasons. if
> you're going to soften the signaling for cache expiration, you really
> ought to balance that out with this simple method of also hardening it.
>
> Perhaps you've forgotten (since you participated in the discussions), but
> the portion of resimprove that dealt with expunging cached data below the
> NXDOMAIN boundary was rescued, expanded on, and published as
> RFC 8020 ("NXDOMAIN: There Really is Nothing Underneath") late last
> year.
yes, i know that RFC 8020 includes both the idea of stopping downward
searches when a cached NXD is encountered, and the idea of pruning (like
"rm -rf" in UNIX) existing cache entries when an NXD is received. those
changes, in addition to QM, will do much to pacify the DNS data model.
however, it's equally vital for malicious DNS content takedown, that the
part about remembering the delegation NS TTL and using it to
periodically revalidate the existence of that delegation, also be
brought forward. this becomes even more vital if we're making TTL
stretchy, and i would be happy to see tale's document cover this topic.
in other words, the prune-and-stop on NXD must be given a new source of
NXD, which is delegation revalidation. i'd love it if delegations all
had a one hour or less TTL, at least for public suffixes.
--
P Vixie
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on zone enumeration and the futility of secrecy on authenticated denial
Shumon Huque wrote: > 2017-03-28 12:41 GMT-05:00 Paul Vixie > ... > > summary: all dns content is running naked through the forest covered in > honey. if you put something into the dns, and it gets used, then it's > going to be known. no amount of crypto on dnssec authenticated denial is > going to change that. (nor will the DPRIVE effort, since passive dns > relies on inside-the-RDNS-servers cooperation, such as for example > 'dnstap'). > > ... > > These systems see a lot, no doubt, but they are still limited to data > contributed by the set of participating resolvers. ... DNSDB coverage gets better every year. other passive systems report the same. systems of this kind are vital for both operational security and security research, and are part of a very strong and virtuous cycle. > And as far as I know, they aren't open to inspection by the world > (usually only participating resolvers, researchers, and customers of > the passive DNS service). for the purpose of this thread, that doesn't matter. anyone who wants to enumerate dns content can do so, well enough, given access to one or more passive dns systems, which is more available and also easier than enumeration, especially because it does not rely on active queries, so the zone administrator can't detect it. under nsec5, something that's already harder to do than passive dns, will get harder. this is an irrelevant benefit, with a very relevant cost. the only practical benefit of nsec3 is opt-out, and this was true even before the pre-image enumeration vulnerability was "discovered". nsec3's anti-enumeration capability was merely a necessary "fig leaf" for some cctld operators whose national privacy laws prohibited NSEC-walking. > The fact that systems like this exist, does not invalidate the desire > for the DNS protocol to prevent easy "bulk disclosure" of zone content. yes, it does. > I don't think protocol evolution can be blamed for lack of ubiquitous > DNSSEC deployment. In my experience, most people who haven't > deployed it, don't see any immediate compelling need for it. had we completed the work after nine years, so, ten years ago, and had there been no new flag days since then, i think it would be generally implemented by recursives (validation), authorities (signatures), registries and registrars. and there might be an app or two, such as DANE, in general use. > Another deployment disincentive is that DNSSEC has a generally > bad rap in the larger technical community. Much of it is based on > FUD and misunderstanding. But there are legitimate criticisms that we > ought to be paying more attention to - DNSSEC deployment is littered > with 1024-bit RSA is one. Zone enumeration obviously is another. i can post more exerpts from the dns-security mailing list from 1996, or from dnsind in 2005, if i've failed to convince you. there is no generally perceived benefit from dnssec deployment today, but that is an effect of the nineteen (19) years we have now been "working on it". if there's no market for dnssec itself, then for that reason and to exactly the same extent, there is no market for nsec5. if anyone would like a demo of passive dns, please send me some nameservers, or ip address blocks, or domain names. because, if you put something in the dns, and somebody looks it up (ever), then it is public information. we have got to stop arguing that it can be simultaneously kept secret. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on zone enumeration and the futility of secrecy on authenticated denial
2017-03-28 12:41 GMT-05:00 Paul Vixie : > at DNSOP yesterday i asked that anyone who thought zone enumeration was > a risk and that any crypto change (such as NSEC5) could manage that risk > should please accept a free demonstration of passive dns. > > i realized that i could offer this more broadly. here is *.vix.su, one > of my vanity domains. passive dns works by storing cache miss traffic > (so there is no PII here). DNSDB, whose result is shown below, is one of > about a dozen security-community projects who aggregate these cache > misses into searchable databases. > > summary: all dns content is running naked through the forest covered in > honey. if you put something into the dns, and it gets used, then it's > going to be known. no amount of crypto on dnssec authenticated denial is > going to change that. (nor will the DPRIVE effort, since passive dns > relies on inside-the-RDNS-servers cooperation, such as for example > 'dnstap'). > Hi Paul, I'm quite familiar with DNSDB and similar passive DNS systems and would guess that many in the DNSOP crowd are also. Some years ago, when I worked in the US R&E community, I used DNSDB to enumerate most of the .edu TLD to do DNSSEC deployment statistics and analyses. These systems see a lot, no doubt, but they are still limited to data contributed by the set of participating resolvers. And as far as I know, they aren't open to inspection by the world (usually only participating resolvers, researchers, and customers of the passive DNS service). The fact that systems like this exist, does not invalidate the desire for the DNS protocol to prevent easy "bulk disclosure" of zone content. The DNS privacy considerations RFC for example has a section that provides such arguments - the protocol queries public data, but you have to know what to query for, and mechanisms that permit mass leakage of such data are undesirable. Similarly, the fact that website observatories exist doesn't mean that the web protocol should provide a mechanism to enumerate all website names hosted at a CDN for example. Before DNSSEC, enumerating zone content was only possible by means of online queries of candidate names. NSEC and NSEC3 made that problem strictly worse (walking the NSEC chain, and offline dictionary attack of the NSEC3 chain). NSEC5 restores the pre-DNSSEC property that only online guessing works. Perhaps passive dns will become so prevalent, all-encompassing, and accessible that it isn't worth investing time in doing better than NSEC3, but let's have that discussion as a community. > nsec5 is a work of beauty and wonder. but changing the DNSSEC protocol > every two years is why we're 19 years in and still lack ubiquitous > deployment. adding more complexity would have to pay back more cost than > any new form of authenticated denial could even theoretically do. > I don't think protocol evolution can be blamed for lack of ubiquitous DNSSEC deployment. In my experience, most people who haven't deployed it, don't see any immediate compelling need for it. If cache poisoning and DNS MITM attacks were happening on a large scale (they aren't), that would act as a deployment incentive. If there were a killer app that depended on DNSSEC (perhaps DANE will be that some day down the road), that would also be an incentive. Another deployment disincentive is that DNSSEC has a generally bad rap in the larger technical community. Much of it is based on FUD and misunderstanding. But there are legitimate criticisms that we ought to be paying more attention to - DNSSEC deployment is littered with 1024-bit RSA is one. Zone enumeration obviously is another. Shumon. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] [Errata Verified] RFC6781 (4844)
The following errata report has been verified for RFC6781, "DNSSEC Operational Practices, Version 2". -- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6781&eid=4844 -- Status: Verified Type: Technical Reported by: Marcos Sanz Date Reported: 2016-10-26 Verified by: Joel Jaeggli (IESG) Section: 4.1.2 Original Text - initial: Initial version of the zone. The parental DS points to DNSKEY_K_1. Before the rollover starts, the child will have to verify what the TTL is of the DS RR that points to DNSKEY_K_1 -- it is needed during the rollover, and we refer to the value as TTL_DS. new DNSKEY: During the "new DNSKEY" phase, the zone administrator generates a second KSK, DNSKEY_K_2. The key is provided to the parent, and the child will have to wait until a new DS RR has been generated that points to DNSKEY_K_2. After that DS RR has been published on all servers authoritative for the parent's zone, the zone administrator has to wait at least TTL_DS to make sure that the old DS RR has expired from caches. DS change: The parent replaces DS_K_1 with DS_K_2. Corrected Text -- initial: Initial version of the zone. The parental DS points to DNSKEY_K_1. Before the rollover starts, the child will have to verify what the TTL is of the DS RR that points to DNSKEY_K_1 -- it is needed during the rollover, and we refer to the value as TTL_DS. Also, we refer to the TTL value of the DNSKEY_K_1 RR as TTL_DNSKEY. new DNSKEY: During the "new DNSKEY" phase, the zone administrator generates a second KSK, DNSKEY_K_2. The new DNSKEY RRSet that includes DNSKEY_K_2 is published at the child. After waiting at least TTL_DNSKEY, DNSKEY_K_2 (or the DS RR generated from it, that is DS_K_2) is provided to the parent. DS change: The parent replaces DS_K_1 with DS_K_2. After that DS RR has been published on all servers authoritative for the parent's zone, the zone administrator has to wait at least TTL_DS to make sure that the old DS RR has expired from caches. Notes - I just corrected what is fundamentally flawed. RFC 7583 section 3.3.1 provides a much detailed explanation of the process. -- RFC6781 (draft-ietf-dnsop-rfc4641bis-13) -- Title : DNSSEC Operational Practices, Version 2 Publication Date: December 2012 Author(s) : O. Kolkman, W. Mekking, R. Gieben Category: INFORMATIONAL Source : Domain Name System Operations Area: Operations and Management Stream : IETF Verifying Party : IESG ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] [Errata Rejected] RFC7719 (4611)
The following errata report has been rejected for RFC7719, "DNS Terminology". -- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7719&eid=4611 -- Status: Rejected Type: Technical Reported by: Nikolai Malykh Date Reported: 2016-02-02 Rejected by: Joel Jaeggli (IESG) Section: 2 Original Text - CNAME: "It is traditional to refer to the owner of a CNAME record as 'a CNAME'. This is unfortunate, as 'CNAME' is an abbreviation of 'canonical name', and the owner of a CNAME record is most certainly not a canonical name." (Quoted from [RFC2181], Section 10.1.1) Corrected Text -- CNAME: "It is traditional to refer to the label of a CNAME record as 'a CNAME'. This is unfortunate, as 'CNAME' is an abbreviation of 'canonical name', and the label of a CNAME record is an alias, not a canonical name." (Quoted from [RFC2181], Section 10.1.1) Notes - Incorrect quote from RFC 2181. --VERIFIER NOTES-- Not a technical erratum. is corrected already in https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-05 which should be examined for consistency -- RFC7719 (draft-ietf-dnsop-dns-terminology-05) -- Title : DNS Terminology Publication Date: December 2015 Author(s) : P. Hoffman, A. Sullivan, K. Fujiwara Category: INFORMATIONAL Source : Domain Name System Operations Area: Operations and Management Stream : IETF Verifying Party : IESG ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] [Errata Verified] RFC7816 (4644)
The following errata report has been verified for RFC7816, "DNS Query Name Minimisation to Improve Privacy". -- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7816&eid=4644 -- Status: Verified Type: Technical Reported by: Robert Edmonds Date Reported: 2016-03-24 Verified by: Joel Jaeggli (IESG) Section: 6 Original Text - QNAME minimisation can decrease performance in some cases -- for instance, for a deep domain name (like www.host.group.department.example.com, where host.group.department.example.com is hosted on example.com's name servers). Let's assume a resolver that knows only the name servers of .example. Without QNAME minimisation, it would send these .example name servers a query for www.host.group.department.example.com and immediately get a specific referral or an answer, without the need for more queries to probe for the zone cut. For such a name, a cold resolver with QNAME minimisation will, depending on how QNAME minimisation is implemented, send more queries, one per label. Once the cache is warm, there will be no difference with a traditional resolver. Actual testing is described in [Huque-QNAME-Min]. Such deep domains are especially common under ip6.arpa. Corrected Text -- QNAME minimisation can decrease performance in some cases -- for instance, for a deep domain name (like www.host.group.department.example.com, where host.group.department.example.com is hosted on example.com's name servers). Let's assume a resolver that knows only the name servers of .example.com. Without QNAME minimisation, it would send these .example.com name servers a query for www.host.group.department.example.com and immediately get a specific referral or an answer, without the need for more queries to probe for the zone cut. For such a name, a cold resolver with QNAME minimisation will, depending on how QNAME minimisation is implemented, send more queries, one per label. Once the cache is warm, there will be no difference with a traditional resolver. Actual testing is described in [Huque-QNAME-Min]. Such deep domains are especially common under ip6.arpa. Notes - Changed ".example" to ".example.com". -- RFC7816 (draft-ietf-dnsop-qname-minimisation-09) -- Title : DNS Query Name Minimisation to Improve Privacy Publication Date: March 2016 Author(s) : S. Bortzmeyer Category: EXPERIMENTAL Source : Domain Name System Operations Area: Operations and Management Stream : IETF Verifying Party : IESG ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New draft for ALIAS/ANAME type
Pieter Lexis wrote: > > There is no mention of the fact that ALIAS is mostly meant for zone > apexes where other records MUST be present and a CNAME cannot exist. > CNAMEs would cover non-apex usecases for ALIAS. There are lots of non-apex situations where you can't use a CNAME, e.g. where mail domains and hostnames coincide. (lists.cam.ac.uk, trin.cam.ac.uk, etc.) Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Viking, North Utsire, South Utsire: Cyclonic, becoming southeasterly for a time, 4 or 5, increasing 6 or 7, perhaps gale 8 later, then becoming variable 4 later. Moderate or rough. Fair then rain. Good, becoming moderate or poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-ietf-dnsop-nsec-aggressiveuse-08
Thanks for the review > From: Jouni Korhonen > Reviewer: Jouni Korhonen > Review result: Has Nits > > I think would be ready if it passed IDnits. I found the document good > read and found no sinkholes in it. Pointing up two implementations was > also great. > > The Proto Write-up seems not be up to date with what IDnits says e.g., > when it comes to downrefs, which is what the IDnits complain about. > > A couple of editorials: > > Lines 118-119 says: "This takes this.." I would reword to something > like: >"This document takes using NXDOMAIN information for more effective > caching further." > > Lines 396 and 397 uses "is NOT" and "IS making". I would use lower > case here. No reason to use capitalized and still non-RFC2119 > language. I will update the parts. > Line 407 is would be great to indicate since which version of Unbound > support has been in place. It is my edit mistake. Unbound does not implement "Aggressive use of DNSSEC-validated Cache" now. See: https://mailarchive.ietf.org/arch/msg/dnsop/Iv1mxko-ZtUBkNWPZnnnwT9LR-A # I implemented NSEC only version using Unbound three years ago as a patch. -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New draft for ALIAS/ANAME type
Hello Anthony, On Wed, 29 Mar 2017 08:51:50 -0500 Anthony Eden wrote: > https://datatracker.ietf.org/doc/draft-dnsop-eden-alias-rr-type/ > > This draft describes the ALIAS/ANAME record (aka CNAME-flattening) > that numerous vendors and DNS providers are now supporting in > proprietary fashions. I hope that this draft will eventually lead to a > good mechanism for interop of ALIAS/ANAME records. First off, thank you for this. I would love to hear from current implementors of ALIAS/ANAME/CNAME-flattening what their ideas/critisisms are. This said, I have several comments after a first quick read of the document. There is no mention of the fact that ALIAS is mostly meant for zone apexes where other records MUST be present and a CNAME cannot exist. CNAMEs would cover non-apex usecases for ALIAS. I miss guidance what should happen when an ALIAS record is queried directly (would it be returned, should it be refused, should it be an empty response?). I miss words on the interaction between ALIAS records and other (mostly A and ) records on the same node. Section 3.1 "The server will respond with one or more A records", I fail to see why this cannot be zero or more. Am ALIAS target without A or records should yield an empty response from the authoritative server. "If the recursive query returns an NXDOMAIN response, then the authoritative name server MUST return an NXDOMAIN response as well.". If any other records exist (which is always the case for the apex), or if there are labels underneath the ALIAS'es name, the authoritative server cannot send out NXDOMAIN. Section 3.3 This section has 2 similar paragraphs, one with should and the other with MUST. Asking directly for a CNAME for a node that only has an ALIAS record should yield a response indicating that RRType does not exist at that node. Again, thank you for starting this draft. I support adoption of this draft in the dnsop WG to facilitate better interop between ALIAS/ANAME/CNAME-flattening implementors. Best regards, Pieter -- Pieter Lexis PowerDNS.COM BV -- https://www.powerdns.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-edns-clientid
Ray Bellis writes: > It's effectively the same argument about TXT records - there's plenty of > things that use TXT format, but it's preferred that separate RRTYPEs are > used to indicate the use case. If that's the position the WG would like to take, I'd be fine with that. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-edns-clientid
On 29/03/2017 10:41, Dave Lawrence wrote: > Well yes, but there's another simple test, the limited Expert Review > guidance against duplicate functionality. Both xpf and clientid > provide the functionality of conveying an IP address in an EDNS0 > option. Whilst you're correct that they both carry information that happens to have the same format, they have different semantic intent, and it would IMHO cause confusion if both were carried in a packet with the same option code. It's effectively the same argument about TXT records - there's plenty of things that use TXT format, but it's preferred that separate RRTYPEs are used to indicate the use case. Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-tale-dnsop-edns-clientid
Ray Bellis writes: > I therefore think there's a simple test here: [...] Well yes, but there's another simple test, the limited Expert Review guidance against duplicate functionality. Both xpf and clientid provide the functionality of conveying an IP address in an EDNS0 option. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [homenet] My assessment of .homenet as described during the WG session yesterday.
Hi Michael, There is no policy or technical barrier to proceeding with SOMETHING.arpa. Procedurally that, of course, would necessitate some WG discussion and consensus. Cheers Terry On 30/03/2017, 1:07 AM, "DNSOP on behalf of Michael Richardson" wrote: Terry Manderson wrote: > B) seek a .homenet special use domain WITHOUT the delegation request > AND ask the IETF/IESG/IAB to commence the discussion with the ICANN > community to achieve an insecure delegation > c) seek a .arpa insecure special use delegation > d) go for "B" and if that doesn't work shift to "C" Is there some reason we can not proceed with "C", concurrently with (B). This might cause stub resolvers to have to have two cases (SOMETHING.arpa, and .homenet) eventually, but at least we could deploy and attempt interop with SOMETHING.arpa NOW, and it would more clearly permit "home." to be removed from code. > Again, this situation is fluid and as discussions evolve I will provide > more information when it is appropriate. In the mean-time I would very > much like everyone to take a calming breath and understand that I am > taking a very pragmatic view of this concern. Thank you! -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [homenet] My assessment of .homenet as described during the WG session yesterday.
Hi James, Q1. Both. The root zone, as a registry, is not an IETF registry. Q2. My guess, and I am really guessing here, that if a process were to be created by the ICANN community to accept such requests from the IETF, it would be encompassing of both. Cheers Terry On 30/03/2017, 12:48 AM, "homenet on behalf of james woodyatt" wrote: q1. What precisely about “3” is not covered in IETF policy terms? That the document directs IANA to request a delegation in the root zone? Or that the document directs IANA to request an *insecure* delegation in the root zone, whereas a secure delegation *would* be adequately covered? Or both of these? q2. If the answer to q1 is that both aspects of “3” are not covered in IETF policy terms, and that each one will require a set of collaborative discussions with the ICANN community and new processes that handle each of these situations, are there any expectations about which of the two processes, if there are two and not just one, can be defined in a workable period of time for HOMENET? --james woodyatt smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Errata Rejected] RFC7871 (4736)
RFC Errata System writes: > http://www.rfc-editor.org/errata_search.php?rfc=7871&eid=4736 > Status: Rejected > --VERIFIER NOTES-- > Internet Software Consortium occurs only in the acknowledgements and > while incorrect now it is generally the perogative of the authors to > include in this section what they see fit. were a future version to > be updated it's acknowledgements would probably include the then > current contributors not the previous ones. For the record, I would have been fine with the change. I wasn't the one who added the text originally, but as someone who worked for ISC before the renaming, I probably glossed over the name dozens of times without noticing it needed updating. I don't know if process-wise it is allowable as an errata, but apologies nonetheless for the error. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-02.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations of the IETF. Title : DNS Scoped Data Through Global '_Underscore' Naming of Attribute Leaves Author : Dave Crocker Filename: draft-ietf-dnsop-attrleaf-02.txt Pages : 13 Date: 2017-03-29 Abstract: Formally, any DNS "RR" may occur for any domain name. However some services have defined an operational convention that applies to DNS leaf nodes that have a reserved node name, beginning with an underscore. The underscore construct is used to define a semantic scope for DNS records that are associated with the parent domain. This specification explores the nature of this DNS usage and defines the "DNS Global Underscore Scoped Entry Registry" registry with IANA. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-02 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-02 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] [Errata Verified] RFC7871 (4735)
The following errata report has been verified for RFC7871, "Client Subnet in DNS Queries". -- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7871&eid=4735 -- Status: Verified Type: Technical Reported by: Robert Edmonds Date Reported: 2016-07-08 Verified by: Joel Jaeggli (IESG) Section: 13 Original Text - 7. Due its internal implementation, ANS finds a response that is tailored for the whole /16 of the client that performed the query. 8. ANS adds an ECS option in the response, containing: [...] * SCOPE PREFIX-LENGTH set to 0x30, indicating a /48 network. Corrected Text -- 7. Due its internal implementation, ANS finds a response that is tailored for the whole /48 of the client that performed the query. 8. ANS adds an ECS option in the response, containing: [...] * SCOPE PREFIX-LENGTH set to 0x30, indicating a /48 network. Notes - The prose description in step 7 does not match the ECS option described in step 8. Either both should say "/16" or both should say "/48". Probably /48 was meant, since a /16 would be a huge amount of IPv6 address space. -- RFC7871 (draft-ietf-dnsop-edns-client-subnet-08) -- Title : Client Subnet in DNS Queries Publication Date: May 2016 Author(s) : C. Contavalli, W. van der Gaast, D. Lawrence, W. Kumari Category: INFORMATIONAL Source : Domain Name System Operations Area: Operations and Management Stream : IETF Verifying Party : IESG ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [homenet] My assessment of .homenet as described during the WG session yesterday.
Terry Manderson wrote: > B) seek a .homenet special use domain WITHOUT the delegation request > AND ask the IETF/IESG/IAB to commence the discussion with the ICANN > community to achieve an insecure delegation > c) seek a .arpa insecure special use delegation > d) go for "B" and if that doesn't work shift to "C" Is there some reason we can not proceed with "C", concurrently with (B). This might cause stub resolvers to have to have two cases (SOMETHING.arpa, and .homenet) eventually, but at least we could deploy and attempt interop with SOMETHING.arpa NOW, and it would more clearly permit "home." to be removed from code. > Again, this situation is fluid and as discussions evolve I will provide > more information when it is appropriate. In the mean-time I would very > much like everyone to take a calming breath and understand that I am > taking a very pragmatic view of this concern. Thank you! -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] [Errata Rejected] RFC7871 (4736)
The following errata report has been rejected for RFC7871, "Client Subnet in DNS Queries". -- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7871&eid=4736 -- Status: Rejected Type: Editorial Reported by: Robert Edmonds Date Reported: 2016-07-08 Rejected by: Joel Jaeggli (IESG) Section: GLOBAL Original Text - the Internet Software Consortium Corrected Text -- Internet Systems Consortium Notes - ISC (no "the") was originally founded as Internet Software Consortium, Inc. in 1994 but it has been known as Internet Systems Consortium, Inc. since 2004. --VERIFIER NOTES-- Internet Software Consortium occurs only in the acknowledgements and while incorrect now it is generally the perogative of the authors to include in this section what they see fit. were a future version to be updated it's acknowledgements would probably include the then current contributors not the previous ones. -- RFC7871 (draft-ietf-dnsop-edns-client-subnet-08) -- Title : Client Subnet in DNS Queries Publication Date: May 2016 Author(s) : C. Contavalli, W. van der Gaast, D. Lawrence, W. Kumari Category: INFORMATIONAL Source : Domain Name System Operations Area: Operations and Management Stream : IETF Verifying Party : IESG ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [homenet] My assessment of .homenet as described during the WG session yesterday.
sign it with a bad key or bad DS. this goes to SERVFAIL and its NXDOMAIN. -G On Wed, Mar 29, 2017 at 9:48 AM, james woodyatt wrote: > Hi Terry, > > Clarifying questions here... > > On Mar 28, 2017, at 12:32, Terry Manderson > wrote: > > > My summary of the situation is this. > > 1) .homenet _COULD_ be added to the special use domain registry based on > RFC6761 > > 2) The expected future operation of HOMENET resolution for DNSSEC validating > stub resolvers requires a break in the DNSSEC chain of trust. > > 3) To achieve "2", the document _additionally_ asks IANA to insert an > insecure delegation into the root zone > > > 4) The ask for "3" is not covered in IETF policy terms, in fact it tries to > put an entry into someone else's registry (the root zone), and will require > a set of collaborative discussions with the ICANN community and a new > process that handles this situation. There are no expectations that this > process will be defined in a reasonable time for the uses of HOMENET. > > > q1. What precisely about “3” is not covered in IETF policy terms? That the > document directs IANA to request a delegation in the root zone? Or that the > document directs IANA to request an *insecure* delegation in the root zone, > whereas a secure delegation *would* be adequately covered? Or both of these? > > q2. If the answer to q1 is that both aspects of “3” are not covered in IETF > policy terms, and that each one will require a set of collaborative > discussions with the ICANN community and new processes that handle each of > these situations, are there any expectations about which of the two > processes, if there are two and not just one, can be defined in a workable > period of time for HOMENET? > > --james woodyatt > > > > > ___ > 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
[DNSOP] New draft for ALIAS/ANAME type
After attending the dnsop meeting on Monday I decided it was time I submitted my first ID for review: https://datatracker.ietf.org/doc/draft-dnsop-eden-alias-rr-type/ This draft describes the ALIAS/ANAME record (aka CNAME-flattening) that numerous vendors and DNS providers are now supporting in proprietary fashions. I hope that this draft will eventually lead to a good mechanism for interop of ALIAS/ANAME records. Sincerely, Anthony Eden -- DNSimple.com http://dnsimple.com/ Twitter: @dnsimple ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] BULK RR as optional feature
On Wed, 29 Mar 2017, Woodworth, John R wrote: I am curious why you feel a nameserver unaware of a new record type would ever return it instead of the known type it queried? No, you're right, you'd only get the BULK if you queried for it, and you'd get NXDOMAIN or more likely NODATA for records that might have been synthesized. As Evan points out, this leads to chronically inconsistent DNSSEC. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] BULK RR as optional feature
Evan Hunt wrote: At least, please add some operational advice that BULK is not to be deployed in any domain unless all auth servers for that domain fully implement it. Yes. This is fairly similar to the requirement for DNSSEC support on auth servers, and there wasn't any explicit signalling in the xfer protocol in that case. I think there's a meaningful difference that we expected everyone to upgrade to DNSSEC eventually, while I expect I am far from the only person with no plans to implement this one. As I keep saying, it's an enormous amount of new and different mechanism for a very narrow use case. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] BULK RR as optional feature
Another possibly-crazy thought ... Should BULK be allocated from the metatype range, 128-255? The idea being that this would cause the zone xfer to be rejected by servers that don't understand it. ... but, from looking at BIND's code (I didn't test it) I think this idea wouldn't actually work in practice because BIND only rejects xfers containing explicitly-known metatypes - it treats most of 128-255 as unknown. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Southeast Viking, North Utsire, South Utsire: Cyclonic 4 or 5, becoming southeasterly 5 to 7, perhaps gale 8 later. Moderate or rough. Rain later. Good, becoming moderate or poor later. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] BULK RR as optional feature
Evan Hunt wrote: > > At least, please add some operational advice that BULK is not to be > deployed in any domain unless all auth servers for that domain fully > implement it. Yes. This is fairly similar to the requirement for DNSSEC support on auth servers, and there wasn't any explicit signalling in the xfer protocol in that case. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Southeast Biscay: Easterly or southeasterly 3 or 4. Slight or moderate, becoming moderate or rough. Fair. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] on staleness of code points and code (mentions MD5 commentary from IETF98)
In your letter dated Tue, 28 Mar 2017 19:23:16 +0200 you wrote: >On 28 Mar 2017, at 12:37, Philip Homburg wrote: > >> So if would be best if a validator that implements MD5 would still >> return >> NXDOMAIN is validation fails, but would keep the AD-bit clear even if >> validation >> passes for a domain signed using MD5. > >In the interest of nitpick correctness, please return SERVFAIL there, >not NXDOMAIN :) Indeed. Though if somebody is foolish enough to sign with MD5, maybe they should get a NXDOMAIN :-) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
