Re: [DNSOP] the root is not special, everybody please stop obsessing over it
Tony Finch wrote on 2019-02-15 01:47: ... We have local stealth secondary copies of our zones on our recursive servers which helps to some extent, except when downstream validators want to get the chain of trust. But serve-stale should help. prefetching or leasing or rrset subscription is expensive when viewed from the dns-at-large perspective. we ought to prioritize the information we will need most in the event of a network partition. and the idea that an operator would have to predict where a partition could take place, and add stealth secondaries for the things they know about, is wrong in two ways. it's too much work, and never enough benefit. I wonder if it's worth having different prefetch logic for infrastructure records (NS, DS, glue, etc) to more eagerly keep them warm than leaf records. yes, it obviously is, but only if you intend to use them even if the authority for some of your data is at that moment not reachable. so, serve-stale and hammer attempt to solve the wrong problem. if you're going to use something the way a stealth slave would do, you've got to ask the authority's instructions, and be capable of hearing and trusting NOTIFY events when that data changes for any reason. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] the root is not special, everybody please stop obsessing over it
On Fri, Feb 15, 2019 at 4:59 AM Stephane Bortzmeyer wrote: > On Thu, Feb 14, 2019 at 01:57:14PM -0800, > Paul Vixie wrote > a message of 42 lines which said: > > > the fact that i have to hotwire my RDNS cache with local zone glue > > in order to reach my own servers when my comcast circuit is down or > > i can't currently reach the .SU authorities to learn where VIX.SU > > is, should not only concern, but also embarrass, all of us. > > I agree that this is an issue (as you said, the simple case of "my own > zone" is easily solved by stub and/or forward zones in BIND) but any > solution must take care of phantom domains. If I register > malware-c-and-c-as-a-service.com and it's taken down, the solution > should not make this domain to work after. (Except of course for > resolvers who decided to configure a stub zone for this domain.) > I think in most solutions, if the name servers for " malware-c-and-c-as-a-service.com" and "com" are both unreachable, the domain should continue to resolve. But if "com" is reachable, and says " malware-c-and-c-as-a-service.com" no longer exists, it should go away. -- Bob Harold ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] the root is not special, everybody please stop obsessing over it
On Thu, Feb 14, 2019 at 01:57:14PM -0800, Paul Vixie wrote a message of 42 lines which said: > the fact that i have to hotwire my RDNS cache with local zone glue > in order to reach my own servers when my comcast circuit is down or > i can't currently reach the .SU authorities to learn where VIX.SU > is, should not only concern, but also embarrass, all of us. I agree that this is an issue (as you said, the simple case of "my own zone" is easily solved by stub and/or forward zones in BIND) but any solution must take care of phantom domains. If I register malware-c-and-c-as-a-service.com and it's taken down, the solution should not make this domain to work after. (Except of course for resolvers who decided to configure a stub zone for this domain.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] the root is not special, everybody please stop obsessing over it
Paul Vixie wrote: > unbound has pioneered a bit of this by automatically refetching data that's > near its expiration point. BIND also does this, it's on by default. I'm not a fan of RFC 7706 because I think it's redundant wrt prefetch (HAMMER), NXDOMAIN synthesis, and (to a much smaller extent) serve-stale. > the fact that i have to hotwire my RDNS cache with local zone glue in order to > reach my own servers when my comcast circuit is down or i can't currently > reach the .SU authorities to learn where VIX.SU is, should not only concern, > but also embarrass, all of us. We have local stealth secondary copies of our zones on our recursive servers which helps to some extent, except when downstream validators want to get the chain of trust. But serve-stale should help. I wonder if it's worth having different prefetch logic for infrastructure records (NS, DS, glue, etc) to more eagerly keep them warm than leaf records. Tony. -- f.anthony.n.finchhttp://dotat.at/ Northwest Southeast Iceland: Northeasterly 5 or 6, becoming variable 3 or 4. Rough. Wintry showers. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] the root is not special, everybody please stop obsessing over it
Paul, On Feb 14, 2019, at 1:57 PM, Paul Vixie wrote: > 7706 is wrong headed on a number of levels, but its worst offense is to think > that the root zone is special. Operationally, the root zone actually is special. It is, after all, the starting point of the name space. As far as I can tell, there are 3 ways the root zone is special: 1. How does one obtain name servers for the root zone? How does one obtain name servers for any other zone? 2. Who controls the name servers for the root zone? Who controls the name servers for redbarn.org? 3. What happens if the root zone is unreachable? What happens if redbarn.org is unreachable? 7706 describes one method to improve resiliency, performance, and privacy of root name service, with no modification of the DNS protocol or name servers. It is, of course, possible to do the same thing with any zone, assuming you have enough memory, but few zones generate sufficient interest to do so. Not sure why you’re arguing against it. Could you explain? Regards, -drc signature.asc Description: Message signed with OpenPGP ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] the root is not special, everybody please stop obsessing over it
On Thu, Feb 14, 2019 at 04:05:22PM -0800, Paul Vixie wrote: > nope. because it did not prototype any partial replication. i'm not > going to mirror COM because i need it to reach FARSIGHTSECURITY.COM. I didn't say anybody's going to mirror COM, I said I suspect zone mirroring will find applications other than pre-caching the root. The fact that it isn't a complete solution to the problem space you're interested in at the moment doesn't mean it was useless. That wasn't a major motivation for the work anyway, I don't believe -- my recollection is that it was mainly about reducing garbage traffic, with latency reduction for some resolvers a happy side-effect. Keeping cache data warm and available during network partitions is a largely solved problem; we have prefetch/hammer, we have serve-stale. (Also apparently we have whatever generates all that zombie DNS traffic Geoff discovered back in 2016, but I'd rather avoid perpetuating that mistake, which seems *quite* perpetual enough as it is.) Keeping cache data coherent is less solved: we don't have the trusted invalidation piece you mentioned. I agree that might be a useful line of inquiry. I guess that's the point you were trying to make; I didn't get it immediately because you started off discussing the shortcomings of an RFC that doesn't seem particularly directly related. So let's get specific about the problem and discuss requirements for a solution. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] the root is not special, everybody please stop obsessing over it
Grant Taylor wrote on 2019-02-14 18:27: Please explain how "warm storage" relates to priming issues. Does warm mean that it's something you have queried? Or does it also include pertinent (meta)data for interesting things (but not everything) that you've not yet queried? i don't expect anyone to store anything they have not queried, though it's natural for an implementation to permit an operator to statically define other targets as well, much as mark andrews did with "stub" zones starting in 1990 or so in BIND4. Does "still reach all internet resources on my side of the break" include things that you've not yet queried for? no. while there may be some kind of persistent storage of long term popularity information so that things that were ever warm can be kept warm even if not queried since the last reboot cycle, i do not expect any tree-walking exercises. my long term study of RDNS tells me that there is a high correlation between past and future queries. if some query tries to occur during a connectivity break, it might fail, and in that sense it's a DNS problem we've always had, that i'm not solving. ... How close would something like this be to what you're wanting to see? i think leasing behaviour is expensive on a network-wide basis, and should be limited to high-value data, by which i mean metadata needed to reach and trust name servers. so, DS/NS, DNSKEY/RRSIG, and related /A. i do not foresee remembering non-metadata information, no matter how popular, since it's in a content operator's power to put a copy of their DNS infrastructure inside any region that also has a copy of its services. it's only third party metadata, like the delegation and trust chain, that is an unmanageable risk today. also note, i would not propose invalidation on its own merits, because the cost of the data-state and trust-state is too high. however, if we have to maintain that state anyway, for leasing, then invalidation is approximately free, depending on the priorities of the authority server operator. therefore, it becomes a package deal, one stone, two birds. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] the root is not special, everybody please stop obsessing over it
You are welcome. I think, modulo minor differences in terminology, we are saying pretty much the same thing. pragmatically, DNS infrastructure dependencies can not be maintained and work on data resiliency is where the useful work lies. /Wm On Thu, Feb 14, 2019 at 5:51 PM Paul Vixie wrote: > > > william manning wrote on 2019-02-14 17:35: > > so, you would like the DNS to be resilient enough to "see" what was > > topologically reachable and build a connected graph of those assets? > > no. that's not possible, and not desireable in any case. > > > I think that has been done, both academically and in a more limited way, > > commercially, but its not called DNS so as not to upset the DNS mafia. > > Or do you want something more restrictive than that? > > i want the metadata i need to reach and trust assets on my side of any > connectivity loss event, to be kept in warm storage, and made subject to > trusted invalidation on an opportunistic basis, at the discretion of the > authority operators who own the data i have warm copies of. > > in practice this means DS/NS and DNSKEY/RRSIG and /A from my static > trust anchor(s) down to any data i used recently or frequently (or by > some other priority scheme), and i want it to look a bit like the single > transaction mode of IXFR plus the single transaction mode of NOTIFY. > > no topology information as to actual connectivity will be modeled or > estimated or needed. what matters is whether i can still reach all > internet resources on my side of a break in connectivity (whether local > or regional or distant), without needing any information that's > otherwise only available on the far side of the connectivity break. > > thanks for asking; i am happy to clarify. DNS infrastructure should not > be centralized, even if its content remains centrally coordinated by > ICANN. (block chain people keep telling me that ICANN will be obsolete, > but i'm not taking a position on that, only on data resiliency.) > > -- > P Vixie > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] the root is not special, everybody please stop obsessing over it
On 2/14/19 6:51 PM, Paul Vixie wrote: i want the metadata i need to reach and trust assets on my side of any connectivity loss event, to be kept in warm storage, and made subject to trusted invalidation on an opportunistic basis, at the discretion of the authority operators who own the data i have warm copies of. Please explain how "warm storage" relates to priming issues. Does warm mean that it's something you have queried? Or does it also include pertinent (meta)data for interesting things (but not everything) that you've not yet queried? in practice this means DS/NS and DNSKEY/RRSIG and /A from my static trust anchor(s) down to any data i used recently or frequently (or by some other priority scheme), and i want it to look a bit like the single transaction mode of IXFR plus the single transaction mode of NOTIFY. no topology information as to actual connectivity will be modeled or estimated or needed. what matters is whether i can still reach all internet resources on my side of a break in connectivity (whether local or regional or distant), without needing any information that's otherwise only available on the far side of the connectivity break. Does "still reach all internet resources on my side of the break" include things that you've not yet queried for? I'm wondering if a fancier cache of some sort would suffice. Specifically I wonder if BIND (et al) can maintain a FIFO (like) list of QNAMEs, moving the current QNAME to the start of the list, and proactively refreshing the first 10 / 100 / 1000 / pick a number in such a way as to not alter the list position when refreshing. This obviously has a priming problem as a QNAME won't be subject for refresh until /after/ it has been queried the first time. This is why I question your use of the word "warm". Perhaps this can be implemented as part of the existing garbage collection process that remove expired cache entries. If the data to be purged is in the FIFO, then refresh it and cache the results without moving it to the head of the FIFO. The other thing that I might add to this is something to artificially prime the cache by querying for specific names off of a user definable list. How close would something like this be to what you're wanting to see? This would re-use existing mechanism and methodology. It wouldn't see changes in data until after cache expiration. But this is SoP for caches now. thanks for asking; i am happy to clarify. DNS infrastructure should not be centralized, even if its content remains centrally coordinated by ICANN. (block chain people keep telling me that ICANN will be obsolete, but i'm not taking a position on that, only on data resiliency.) -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] the root is not special, everybody please stop obsessing over it
william manning wrote on 2019-02-14 17:35: so, you would like the DNS to be resilient enough to "see" what was topologically reachable and build a connected graph of those assets? no. that's not possible, and not desireable in any case. I think that has been done, both academically and in a more limited way, commercially, but its not called DNS so as not to upset the DNS mafia. Or do you want something more restrictive than that? i want the metadata i need to reach and trust assets on my side of any connectivity loss event, to be kept in warm storage, and made subject to trusted invalidation on an opportunistic basis, at the discretion of the authority operators who own the data i have warm copies of. in practice this means DS/NS and DNSKEY/RRSIG and /A from my static trust anchor(s) down to any data i used recently or frequently (or by some other priority scheme), and i want it to look a bit like the single transaction mode of IXFR plus the single transaction mode of NOTIFY. no topology information as to actual connectivity will be modeled or estimated or needed. what matters is whether i can still reach all internet resources on my side of a break in connectivity (whether local or regional or distant), without needing any information that's otherwise only available on the far side of the connectivity break. thanks for asking; i am happy to clarify. DNS infrastructure should not be centralized, even if its content remains centrally coordinated by ICANN. (block chain people keep telling me that ICANN will be obsolete, but i'm not taking a position on that, only on data resiliency.) -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] the root is not special, everybody please stop obsessing over it
so, you would like the DNS to be resilient enough to "see" what was topologically reachable and build a connected graph of those assets? I think that has been done, both academically and in a more limited way, commercially, but its not called DNS so as not to upset the DNS mafia. Or do you want something more restrictive than that? /Wm On Thu, Feb 14, 2019 at 4:05 PM Paul Vixie wrote: > > > Evan Hunt wrote on 2019-02-14 15:56: > > On Thu, Feb 14, 2019 at 01:57:14PM -0800, Paul Vixie wrote: > >> indeed nothing which treats the root zone as special is worth > >> pursuing, since many other things besides the root zone are also > >> needed for correct operation during network partition events. > > > > This point is well taken, but sometimes the root zone is a useful > > test case for innovations that might be more generically useful > > later. It's relatively small, relatively static, *XFR accessible, > > signed but uses NSEC not NSEC3, etc. It's pleasantly free of > > annoyances. > > it's distraction value, where countries lacking root server _operators_ > of their own, feel diminished thereby, and where technology solutions > that affect the root zone in some way, feel unduly relevant... makes it > an _unuseful_ test case. recall that and DS came to every other > zone in the DNS before it was grudgingly admitted into the root zone. > > we have to stop using the root zone as any kind of test case. it's not > special and should be treated unspecially. any technology which focuses > on it should be suspected immediately of "shiny object syndrome." > > > So, zone mirroring fell out of 7706, and I suspect it will > > eventually have broader applications than just local root cache. > > nope. because it did not prototype any partial replication. i'm not > going to mirror COM because i need it to reach FARSIGHTSECURITY.COM. we > needed to focus on partial replication, and avoid any solution that > would only work for small zones that changed infrequently, so as to > avoid wasting years of opportunity on a solution that changed nothing > and led nowhere. > > > I think some of the early work on aggressive negative caching was > > root-specific as well. > > no. in fact, the opposite was true. the first ANC was OTWANC (off the > wire ANC), which had to be specified as part of DLV, which was > instigated in the first place principally because noone knew how many > more years we'd have to wait before a DS RR could be placed into the > root zone. > > > I wouldn't assume an idea is bad just because it's currently focused > > on the root, it might not always be. > > for reasons stated above, there are _no_ counterexamples showing that a > focus on root-specific technology ever did any good, and a plethora of > examples where focus on root-specific technology did some lasting harm. > > therefore, our assumption of any root-specific proposal should be, until > and unless proved otherwise on a case by case basis, that it's "shiny > object syndrome", rather than a legitimate engineering exercise. > > -- > P Vixie > > ___ > 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] the root is not special, everybody please stop obsessing over it
Evan Hunt wrote on 2019-02-14 15:56: On Thu, Feb 14, 2019 at 01:57:14PM -0800, Paul Vixie wrote: indeed nothing which treats the root zone as special is worth pursuing, since many other things besides the root zone are also needed for correct operation during network partition events. This point is well taken, but sometimes the root zone is a useful test case for innovations that might be more generically useful later. It's relatively small, relatively static, *XFR accessible, signed but uses NSEC not NSEC3, etc. It's pleasantly free of annoyances. it's distraction value, where countries lacking root server _operators_ of their own, feel diminished thereby, and where technology solutions that affect the root zone in some way, feel unduly relevant... makes it an _unuseful_ test case. recall that and DS came to every other zone in the DNS before it was grudgingly admitted into the root zone. we have to stop using the root zone as any kind of test case. it's not special and should be treated unspecially. any technology which focuses on it should be suspected immediately of "shiny object syndrome." So, zone mirroring fell out of 7706, and I suspect it will eventually have broader applications than just local root cache. nope. because it did not prototype any partial replication. i'm not going to mirror COM because i need it to reach FARSIGHTSECURITY.COM. we needed to focus on partial replication, and avoid any solution that would only work for small zones that changed infrequently, so as to avoid wasting years of opportunity on a solution that changed nothing and led nowhere. I think some of the early work on aggressive negative caching was root-specific as well. no. in fact, the opposite was true. the first ANC was OTWANC (off the wire ANC), which had to be specified as part of DLV, which was instigated in the first place principally because noone knew how many more years we'd have to wait before a DS RR could be placed into the root zone. I wouldn't assume an idea is bad just because it's currently focused on the root, it might not always be. for reasons stated above, there are _no_ counterexamples showing that a focus on root-specific technology ever did any good, and a plethora of examples where focus on root-specific technology did some lasting harm. therefore, our assumption of any root-specific proposal should be, until and unless proved otherwise on a case by case basis, that it's "shiny object syndrome", rather than a legitimate engineering exercise. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] the root is not special, everybody please stop obsessing over it
On Thu, Feb 14, 2019 at 01:57:14PM -0800, Paul Vixie wrote: > indeed nothing which treats the root zone as special is worth pursuing, > since many other things besides the root zone are also needed for > correct operation during network partition events. This point is well taken, but sometimes the root zone is a useful test case for innovations that might be more generically useful later. It's relatively small, relatively static, *XFR accessible, signed but uses NSEC not NSEC3, etc. It's pleasantly free of annoyances. So, zone mirroring fell out of 7706, and I suspect it will eventually have broader applications than just local root cache. I think some of the early work on aggressive negative caching was root-specific as well. I wouldn't assume an idea is bad just because it's currently focused on the root, it might not always be. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] the root is not special, everybody please stop obsessing over it
On Thu, Feb 14, 2019 at 01:57:14PM -0800, Paul Vixie wrote: > unbound has pioneered a bit of this by automatically refetching data > that's near its expiration point. [...] > _that_ would be complexity worth its cost. 7706 was not. HAMMER is not. I'm confused, what's the difference between HAMMER and the thing you said? (Which BIND also does, incidentally.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] the root is not special, everybody please stop obsessing over it
Mark Andrews wrote on 2019-02-14 14:13: ... the fact that i have to hotwire my RDNS cache with local zone glue in order to reach my own servers when my comcast circuit is down or i can't currently reach the .SU authorities to learn where VIX.SU is, should not only concern, but also embarrass, all of us. Having the local recursive server having a copy of the local zones was always part of DNS’s deployment model. Having authoritative servers not be recursive servers is not the same as recursive servers not being authoritative for some zones. i didn't expect you to need the broader example. the narrow example where i can't find my own zones is trivial. it's when i can't find other services whose dns is authoritatively served within my isp or my region, because even though i have connectivity within that isp or that region, there is a political or physical connectivity break between that isp or that region and the rest of the world, for example, the servers for TLD's and 2LD's and 3LD's whose delegators are outside my connectivity. One thing we missed when adding NOTIFY was adding a NOTIFY-ALSO RRset. In named we work around this by having a also-notify clause in the zone’s configuration clause. that won't help. an authority server must have a protocol by which they can, at their own discretion, opportunistically invalidate prior answers, and which can be trusted by the RDNS servers hearing those invalidation messages. DNS RRsets need two TTLs. 1) refresh after in case we need to update. 2) stop believing this result after. With a little bit of EDNS negotiation both can be transmitted in a response. that won't help the case which is more common than connectivity splits, which is where the old data has become harmful (key compromised, server or network offline, emergency renumber or rehoming or rekeying required). let's stop thinking of this as a root problem or a TLD problem. the metadata an RDNS will need to reach and trust servers it can reach, may be on the wrong side of a network partition. that includes the entire NS/DS and DNSKEY/RRSIG chain, plus A/ glue. we need partial zone authority, like a mini-slave, where the RDNS has _subscribed_ to the content it is keeping, and has a potential trust relationship with the owner of that data. we can argue about whether it's like mini-IXFR in which case it can answer authoritatively for the partial data it has leased. but we should not be talking about second TTL's, or root-only solutions like 7706. vixie -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] the root is not special, everybody please stop obsessing over it
> On 15 Feb 2019, at 8:57 am, Paul Vixie wrote: > > 7706 is wrong headed on a number of levels, but its worst offense is to think > that the root zone is special. we need dns to have leases on its delegation > chain including glue and dnssec metadata. everything you might need to use in > order to reach a zone authority and trust its results should be kept warm. > the owner of the data you've leased must have the ability to reach out and > invalidate it in a trusted way. > > having .CN's delegation data resident because of 7706 doesn't help you reach > your own EXAMPLE.CN name servers if the network outage you were concerned > about is inside china rather than between china and the rest of the world. > > NFS gave an example of how to solve this, 25 years ago, with NQLEASE. i am > not asking for new computer science, only application of what's already well > understood outside the DNS community, as to keeping the hot side hot. > > unbound has pioneered a bit of this by automatically refetching data that's > near its expiration point. we should work from there outward, by > standardizing it, prioritizing delegation and dnssec metadata, and exploring > ways that the .CN servers could invalidate old NS RRset or DS RRset data (or > indeed DNSKEY and RRSIG) if it was willing to do the work of remembering who > it had handed the now-invalid data to and what trust markers would be needed > to get an RDNS to accept some new form of NOTIFY to purge its cache. > > _that_ would be complexity worth its cost. 7706 was not. HAMMER is not. > indeed nothing which treats the root zone as special is worth pursuing, since > many other things besides the root zone are also needed for correct operation > during network partition events. > > the fact that i have to hotwire my RDNS cache with local zone glue in order > to reach my own servers when my comcast circuit is down or i can't currently > reach the .SU authorities to learn where VIX.SU is, should not only concern, > but also embarrass, all of us. Having the local recursive server having a copy of the local zones was always part of DNS’s deployment model. Having authoritative servers not be recursive servers is not the same as recursive servers not being authoritative for some zones. One thing we missed when adding NOTIFY was adding a NOTIFY-ALSO RRset. In named we work around this by having a also-notify clause in the zone’s configuration clause. DNS RRsets need two TTLs. 1) refresh after in case we need to update. 2) stop believing this result after. With a little bit of EDNS negotiation both can be transmitted in a response. > vixie > > ___ > 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
