Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-key-timing-05.txt
On Sep 18, 2014, at 11:51 AM, Tim Wicinski wrote: > This document has been in WGLC and the working group has done an iteration on > the document. The authors merged in several sets of changes, first back in > July, and recently from the feedback from the working group reviewers and > editors.The opinion is that this version reflects all suggestions and is > ready to move forward again. > > Since the editorial changes are more than we originally expected, we're going > to open up a Working Group Last Call on this document for another 2 weeks. We > urge folks to read over the differences in the documents. > > This last call will end on October 2nd, 2014. I did a clean read, and it feels *much* better than the early drafts. I have a small number of editorial comments, but some bigger questions as well. I strongly suspect the questions can be answered by small additions to the draft. At the beginning of 2.1: For ZSKs, the issue for the zone operator/signer is to ensure that any caching validator has access to a particular signature that corresponds to a valid ZSK. "that corresponds to" seem wrong here. The following may be more accurate (or it might be wrong...): For ZSKs, the issue for the zone operator/signer is to ensure that any caching validator has access to a particular signature has access to the corresponding valid ZSK. In 2.2, it says "It is important to note that this does not preclude the development of key rollover logic"; I can't figure out what "this" refers to. There are a bunch of things in the two preceding paragraphs that it might mean. The introduction to 3.1 caught me, and I can't figure out whether or not it is right. A DNSSEC key contributes two pieces of information to the validation process: the DNSKEY itself and the data created from it. In the case of the validation of an RR, the data created from the DNSKEY is the RRSIG. Where there is a need to validate a chain or trust, the data created from the DNSKEY is the DS. In this section, the term "associated data" refers to the RRSIGs created from a DNSKEY when discussing a ZSK, or to the DNSKEY's corresponding DS record when referring to a KSK. Is the "associated data" for a KSK really just the DS? Shouldn't any RRSIG over the ZSK that was created by the DSKEY also be "associated data"? Also in 3.1: Ready The DNSKEY or its associated data have been published for long enough to guarantee that any previous versions of the DNSKEY and/or associated data have expired from caches. This is discussing a new key. What is the "previous version"? Section 3.3.5 is really important to some readers, but it could easily be lost. There should be a sentence near the end of 1.1 that says "Note that introduction of first keys is different than rolling a key; see Section 3.3.5 for more information about that topic." Section 6 really should be Section 1.4. The paragraphs will make it much easier for someone reading the document who exclaims (to no one in particular) "they didn't consider X" as they are reading the meat of the document to understand that the authors probably did think about it, but chose to not include it. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
On Mon, 22 Sep 2014, bert hubert wrote: Feedback welcome! I note that there has been discussion on EDNS0 probing and other fancy things, but please note that this feature is needed to solve a problem we have today. This means it can't involve upgrades to infrastructure except for that operated by the people with the problem - authoritative servers. If we can do this with auth only changes in a sane way, I'm all for it. But if a decent solution requires recursor updates, we should not leave that solution space out of scope. A bandaid for those that need this today is to delegate the A record of the apex and the www record to the CDN, and MX, NS and SRV records to their own infrastructure. And to refrain from using the apex A/ for any other service. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
Based on the discussions here (thanks!), I've now written this up as: https://github.com/PowerDNS/pdns/blob/alias/pdns/docs/alias.md The ALIAS record The ALIAS record leads authoritative servers to synthesize A or records in case these are not present. The source of the synthesized A or record is specified by the target of the ALIAS record. etc.. Feedback welcome! I note that there has been discussion on EDNS0 probing and other fancy things, but please note that this feature is needed to solve a problem we have today. This means it can't involve upgrades to infrastructure except for that operated by the people with the problem - authoritative servers. Bert On Sun, Sep 21, 2014 at 01:52:22PM +0200, bert hubert wrote: > Hi everybody, > > Your input on the initial implementation described below would be most > appreciated. I see this as a dns operations issue since it does not > describe an on-the wire change, except when we do AXFR perhaps. It is > mostly a feature. > > However, even features could have interoperability issues, and it would be > nice if we were aligned. > > The last forwared paragraph below says "Please let us know your thoughts > based on the semantics outlined above. Would this work for you? Do you > miss anything? Is there a need for multiple ALIAS statements for load > balancing? Are we needlessly incompatible with existing implementations? > Is there standardization work we could align against?" > > Thanks! > > Bert > > - Forwarded message from bert hubert - > > Date: Sun, 21 Sep 2014 12:54:07 +0200 > From: bert hubert > To: pdns-us...@mailman.powerdns.com > Subject: [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS > > Hi everybody, > > Based on strong user interest, we are fast-tracking the implementation of > ALIAS/ANAME records, to solve the 'CNAME at apex' problem. Because of the > fast-tracking, we need rapid feedback to see if we got it right (see the end > of the mail for details). > > In short, you can CNAME 'www.yourdomain.com' to a CDN or somewhere else, but > you can't CNAME 'yourdomain.com', since that breaks DNS. This blogpost by > CloudFlare expands on the problem: > https://support.cloudflare.com/hc/en-us/articles/200169056-CNAME-Flattening-RFC-compliant-support-for-CNAME-at-the-root > > Today, we implemented ALIAS support as an experimental PowerDNS feature, > which allows the following: > > $ORIGIN example.com. > @ IN SOA ns1 ahu 2014091619 7200 3600 1209600 3600 > @ IN NS ns1 > @ IN NS ns2 > www IN CNAME xs.powerdns.com. > ns1 IN A 1.2.3.4 > ns2 IN A 4.3.2.1 > @ IN ALIAS www.powerdns.com. > @ IN MX 25 outpost.ds9a.nl. > elsewhere IN CNAME @ > > The branch can be found on https://github.com/PowerDNS/pdns/tree/alias and > we should have packages soon. > > The current semantics for the ALIAS pseudo-record are that they only match > if no real record did. So in the case above, an MX query for example.com > would return "25 outpost.ds9a.nl". But a query for would return the > IPv6 address obtained by following the www.powerdns.com CNAME chain to > xs.powerdns.com. This also works for all other record types, btw. > > Our implementation uses a defined resolver to look up the actually requested > record, and adds the data found to the packet built so far. This means that > querying 'elsewhere.example.com' will include a CNAME to example.com, which > in turn will lead to processing of the ALIAS record. > > Finally, for TTL, we currently use what the resolver gave us. But perhaps we > could use the TTL of the ALIAS record instead, or as a maximum? Or minimum? > > Please let us know your thoughts based on the semantics outlined above. > Would this work for you? Do you miss anything? Is there a need for multiple > ALIAS statements for load balancing? Are we needlessly incompatible with > existing implementations? Is there standardization work we could align > against? > > Your input is highly welcome! > > Bert > > PS: the above is currently not yet supported for DNSSEC domains! > > -- > PowerDNS Website: http://www.powerdns.com/ > Contact us by phone on +31-15-7850372 > > ___ > Pdns-users mailing list > pdns-us...@mailman.powerdns.com > http://mailman.powerdns.com/mailman/listinfo/pdns-users > > > - End forwarded message - > > ___ > 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] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
On Mon, Sep 22, 2014 at 01:37:03PM -0400, Olafur Gudmundsson wrote: > I’m getting confused about what the exact semantics of the proposed > mechanisms are. We're here to figure those out. Thanks for your input Olafur, appreciated! > > Q1: The intent is that ALIAS/ANAME/etc are a fallback rewrite operation if > the name does not have the type asked for? The intent is to solve the 'CNAME at apex'-problem. The implementation needs to keep SOA, NS etc alive, but override at least A and . Hence the fallback, to retain SOA and NS. > Q2: Is there a good reason to restrict this to just the apex of a zone? No, and it isn't implemented like that right now. > Q3: Is there a good reason to restrict the target of A* to be in-zone ? No, since the specific use-case is to hand off to a CDN name, which is unlikely to be in-zone. > Q4: Is there a good reason to restrict this to specific types? (Think about > DANE cases with names like _443._tcp.@apex) I think Tony's input that you might end up with an incompatible SPF if you fall-through for MX makes a good case to restrict to 'address records', currently A and . The open questions are: what to do on an ANY query? You can't proxy on an ANY query to auth as an ANY query to a resolver since the semantics are different. ANY queries are fragile enough as is, but to maintain any semblance of working, an ANY query hitting an ALIAS type should be proxied on as an A and an query, and both should be tacked on to the answer. Bert > > > On Sep 22, 2014, at 6:03 AM, Tony Finch wrote: > > > I can see roughly three ways this might be done, in order of increasing > > complexity... > > > > (1) Master-only. The master observes an ANAME record at the apex of a zone > > it loads and uses it to periodically refresh the relevant records in the > > zone (as if you had a cron job running dig | magic | nsupdate). > > > > Disadvantage: potentially lots of XFR traffic if the TTLs are low. > > Disadvantage: if the target is a CNAME what does the master do? > It either need to know ALL possible types that may exist or use NSECx record > to determine what exists. > Possible disadvantage: Master/master signer needs access to resolver to > access out of zone-data. > > Further disadvantage: if the A* target is out of zone at a CDN then the > answers the “master” gets back reflect its > location. > > > > > (2) Authority-only: All authority servers recognize ANAME records, > > PowerDNS style. > > > > Disadvantage: all authority servers need DNSSEC private keys. > > Not an absolute requirement, we could play type code tricks that allow master > server to store > A* target records as different types but servers know that to check for them > if A* exists. > Disadvantage: All authority serves supporting A* need to know about type > translation and signers need to know to perform actions. > > > > > (3) DNAME-style: Authority servers and resolvers recognize ANAME records. > > ANAME-aware servers (auth and rec) return the synthesized records for > > backwards compatibility, without signatures. For DNSSEC purposes the > > signed ANAME goes in the answer section and the original signed target > > goes in the additional section. > > > > Disadvantages: forklift upgrade; DNSSEC codepoint rollover. > > > > You mean DNSKEY alg code points,? > We only have 5 popular algorithms so that is not a big deal? > > Olafur > > > ___ > 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] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
I’m getting confused about what the exact semantics of the proposed mechanisms are. Q1: The intent is that ALIAS/ANAME/etc are a fallback rewrite operation if the name does not have the type asked for? Q2: Is there a good reason to restrict this to just the apex of a zone? Q3: Is there a good reason to restrict the target of A* to be in-zone ? Q4: Is there a good reason to restrict this to specific types? (Think about DANE cases with names like _443._tcp.@apex) On Sep 22, 2014, at 6:03 AM, Tony Finch wrote: > I can see roughly three ways this might be done, in order of increasing > complexity... > > (1) Master-only. The master observes an ANAME record at the apex of a zone > it loads and uses it to periodically refresh the relevant records in the > zone (as if you had a cron job running dig | magic | nsupdate). > > Disadvantage: potentially lots of XFR traffic if the TTLs are low. Disadvantage: if the target is a CNAME what does the master do? It either need to know ALL possible types that may exist or use NSECx record to determine what exists. Possible disadvantage: Master/master signer needs access to resolver to access out of zone-data. Further disadvantage: if the A* target is out of zone at a CDN then the answers the “master” gets back reflect its location. > > (2) Authority-only: All authority servers recognize ANAME records, > PowerDNS style. > > Disadvantage: all authority servers need DNSSEC private keys. Not an absolute requirement, we could play type code tricks that allow master server to store A* target records as different types but servers know that to check for them if A* exists. Disadvantage: All authority serves supporting A* need to know about type translation and signers need to know to perform actions. > > (3) DNAME-style: Authority servers and resolvers recognize ANAME records. > ANAME-aware servers (auth and rec) return the synthesized records for > backwards compatibility, without signatures. For DNSSEC purposes the > signed ANAME goes in the answer section and the original signed target > goes in the additional section. > > Disadvantages: forklift upgrade; DNSSEC codepoint rollover. > You mean DNSKEY alg code points,? We only have 5 popular algorithms so that is not a big deal? Olafur ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
On Mon, Sep 22, 2014 at 7:06 AM, Tony Finch wrote: > The fun bit is that an auth server implementing some kind of proxying > ANAME is in a position very like Google and OpenDNS. That is, if the > target of the ANAME is a hostname provided by Akamai or CloudFlare or > whoever, and if the auth server is going to proxy the answer faithfully, > then it has to implement client-subnet. I wonder if the best thing to do would be to define an ANAME/NAME that can be negotiated by resolvers. If the resolver supports it (it can let the auth know via EDNS0) then the ANAME/NAME is returned without resolution. If the resolver doesn't support it, then a synthetic A/ can be returned. -- Colm ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
Andrew Sullivan wrote: > On Sun, Sep 21, 2014 at 03:52:13PM -0700, Paul Vixie wrote: > > > if it caches, does it implement "client subnet"? > > It sort of has to, not that it will necessarily be useful. An > important use case is CDNs, and since you probably want to do stupid > DNS tricks based on the source of the query, you better do client > subnet with it. (Of course, statistically speaking right now that > means, "Works for Google and OpenDNS and not really anyone else.") The fun bit is that an auth server implementing some kind of proxying ANAME is in a position very like Google and OpenDNS. That is, if the target of the ANAME is a hostname provided by Akamai or CloudFlare or whoever, and if the auth server is going to proxy the answer faithfully, then it has to implement client-subnet. Tony. -- f.anthony.n.finchhttp://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC and ALIAS/ANAME apex record in PowerDNS
On Sep 21, 2014, at 11:14 AM, bert hubert wrote: > On Sun, Sep 21, 2014 at 08:13:46AM -0700, Paul Hoffman wrote: >>> PS: the above is currently not yet supported for DNSSEC domains! >> >> Can you say (much) more about that aside? Does it mean that the server >> will fail to load the zone if there is DNSSEC records and ALIAS >> pseudo-records? Or that the DNSSEC gets broken? Or that the ALIAS gets >> broken? Or... ? > > In the current branch, it will load the zone, but neglect to add signatures > for the proxied records. In other words, if you do DNSSEC, it will load the > zone but make you BOGUS. Far be it from me to tell you want to do with your UI, but that seems like a worse choice than refusing to load the zone and giving an error that indicates that the zone file is misconfigured. In specific, when the operator will discover that the zone is bogus because someone else tell them, they will stare at the zone file and see nothing wrong. > This is not a fundamental problem as long as we have keys. If you don't have > the keys, we can't sign any how. We'll add the signing code shortly, we just > haven't typed it in yet. I'm not sure what that paragraph means at all. > An interesting opening is that we'd be signing potentially unsigned data > this way. Potentially, we should check for the AD bit. But first let's see > how this idea fits. It is seeming to fit, so discussing the DNSSEC implications of it seems appropriate to do now. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
On 22 September 2014 12:27, Tony Finch wrote: > Dick Franks wrote: > > On 22 September 2014 11:03, Tony Finch wrote: > > > > > > (1) Master-only. The master observes an ANAME record at the apex of a > zone > > > it loads and uses it to periodically refresh the relevant records in > the > > > zone (as if you had a cron job running dig | magic | nsupdate). > > > > > > Disadvantage: potentially lots of XFR traffic if the TTLs are low. > > > > Why would TTL be relevant here? > > > > Is the master not acting as a "partial slave" for the target RRs? > > In which case, the timing should depend on the SOA refresh period. > > Yes, you could do it that way. But a lot of people want changes to take > effect quickly. > > So whenever TTL times out, master does validated lookup of each ANAME target, resigns, updates zone, notifies own slaves, services XFRs. Someone beyond your direct control sets a short TTL (0 or 1) in ANAME target RRs and your master is in deep, deep [trouble] !! Thinking about it, (target side) SOA refresh is not much better. > And I forgot to cover the effects that client-subnet might have ... > > I do not know either Rs Dick ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
On Sun, Sep 21, 2014 at 03:52:13PM -0700, Paul Vixie wrote: > does the ANAME(/ALIAS) server proxy every request, so, no caching? Some people have tried to implement it that way. This is an excellent way to DoS your server, it turns out (rumour has it that someone learned that in production; but if you make a fairly simple performance model you can derive this result on paper). > if it caches, does it implement "client subnet"? It sort of has to, not that it will necessarily be useful. An important use case is CDNs, and since you probably want to do stupid DNS tricks based on the source of the query, you better do client subnet with it. (Of course, statistically speaking right now that means, "Works for Google and OpenDNS and not really anyone else.") > proxied request times out (or servfails), does the original authority > request also time out (or servfail?) and i wonder-- if the proxy request > returns NXDOMAIN, what does the authority answer with? There are use cases where the "right" answer is to extend the cache value you had, even though the TTL has expired. In other cases, you should just pass on whatever you got, so you're working like a cache. > what the implementers of this nonstandard feature seem to want is > cname-and-other-data, by which i mean, a requester-visible alias that > can live at the apex, and then have its target resolved in the > requester's context. i'm not sure how best to do it, but i'm not liking > the implications of always-proxy nor proxy-with-cache. Yes. For what it's worth, at Dyn we've come up with four different designs for this functionality, every one of which has some compromise that has caused my product people to say, "No, not like that." I am increasingly convinced that this feature is one of those well-known ponies. A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
Dick Franks wrote: > On 22 September 2014 11:03, Tony Finch wrote: > > > > (1) Master-only. The master observes an ANAME record at the apex of a zone > > it loads and uses it to periodically refresh the relevant records in the > > zone (as if you had a cron job running dig | magic | nsupdate). > > > > Disadvantage: potentially lots of XFR traffic if the TTLs are low. > > Why would TTL be relevant here? > > Is the master not acting as a "partial slave" for the target RRs? > In which case, the timing should depend on the SOA refresh period. Yes, you could do it that way. But a lot of people want changes to take effect quickly. And I forgot to cover the effects that client-subnet might have ... Tony. -- f.anthony.n.finchhttp://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
On 22 September 2014 11:03, Tony Finch wrote: > I can see roughly three ways this might be done, in order of increasing > complexity... > > (1) Master-only. The master observes an ANAME record at the apex of a zone > it loads and uses it to periodically refresh the relevant records in the > zone (as if you had a cron job running dig | magic | nsupdate). > > Disadvantage: potentially lots of XFR traffic if the TTLs are low. > > Why would TTL be relevant here? Is the master not acting as a "partial slave" for the target RRs? In which case, the timing should depend on the SOA refresh period. No reason to do XFR. Each (assuming these to be plural) ANAME target could be resolved independently. Rs Dick ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
>(1) Master-only. The master observes an ANAME record at the apex of a zone >it loads and uses it to periodically refresh the relevant records in the >zone (as if you had a cron job running dig | magic | nsupdate). I have implemented something like this, with master file syntax foo IN A [rmtip:bar.remote] The implementation fetches any A and records from bar.remote and invents local A and records. It rechecks every hour or so. >Disadvantage: potentially lots of XFR traffic if the TTLs are low. My crock manages the zone serial numbers and only changes the serial number and does a notify if the zone changes. It's all done in python scripts on top of NSD. It doesn't do DNSSEC yet but I don't see any problems since the zones that NSD sees are ordinary zones. I agree that Paul's suggestion to limit this to references within the zone would make it useless in practice unless it also resolved CNAMEs, which turns it back into the more complicated case. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
Doug Barton wrote: > > https://tools.ietf.org/html/draft-barton-clone-dns-labels-fun-profit I am confused by the use "label" in that document. Do you really mean a single component of a domain name wherever you say "label"? Tony. -- f.anthony.n.finchhttp://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
I can see roughly three ways this might be done, in order of increasing complexity... (1) Master-only. The master observes an ANAME record at the apex of a zone it loads and uses it to periodically refresh the relevant records in the zone (as if you had a cron job running dig | magic | nsupdate). Disadvantage: potentially lots of XFR traffic if the TTLs are low. (2) Authority-only: All authority servers recognize ANAME records, PowerDNS style. Disadvantage: all authority servers need DNSSEC private keys. (3) DNAME-style: Authority servers and resolvers recognize ANAME records. ANAME-aware servers (auth and rec) return the synthesized records for backwards compatibility, without signatures. For DNSSEC purposes the signed ANAME goes in the answer section and the original signed target goes in the additional section. Disadvantages: forklift upgrade; DNSSEC codepoint rollover. Tony. -- f.anthony.n.finchhttp://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
bert hubert wrote: > > The current semantics for the ALIAS pseudo-record are that they only match > if no real record did. Why not restrict it to A and ? I forsee problems with zones that have MX and ALIAS at the apex which accidentally get the wrong SPF record, for example. Tony. -- f.anthony.n.finchhttp://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
