Re: [DNSOP] Another suggestion for any
On Wed, Mar 11, 2015 at 07:12:55AM -0700, Paul Hoffman wrote: On Mar 11, 2015, at 2:00 AM, Paul Vixie p...@redbarn.org wrote: djb doesn't want QTYPE=ANY deprecated in any form. olafur doesn't want to do_ANY, under any conditions. so i'm baffled by why you're offering this alternative? Neither djb nor Olafur are automatically the consensus of this WG. None of us are. mostly-ot I've had trouble emailing djb about this and received bounces from his mailer, so feel trustrated trying to have a conversation that includes him at least. /mostly-ot This does seem to fall into the whole undefined category just like many people feel that TCP is optional where my reading of 1035 4.2.2 defines how queries over TCP should be performed. At the most recent NANOG John Kristoff presented on the TCP part: https://www.nanog.org/sites/default/files/nanog63-dnstrack-kristoff-dnstcp.pdf There is a gap, neither positive or negative in the behavior of these things, which I'm sure will rage along for a bit re: ANY, TCP, etc... I'm working on a project right now that should collect some data and help better study the behavior of systems. once it's ready, I will share more data. If you are a researcher or PHD candidate interested in DNS, please contact me off-list. - jared -- Jared Mauch | pgp key available via finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on dnsop-qname-minimisation-02
On Wed, Mar 11, 2015 at 10:43 AM, Bob Harold rharo...@umich.edu wrote: On Wed, Mar 11, 2015 at 12:35 AM, Shumon Huque shu...@gmail.com wrote: ... One thing this document doesn't make clear is that the algorithm being presented not only minimizes the query name, but also hides the query type until it reaches the target zone (by using the NS query type rather than the actual type). A pure query name minimization algorithm can just strip off labels and issue normal queries with the requested query type. I've implemented the latter algorithm and it works fine (with well behaved authoritative servers). I agree with the goal of additionally providing privacy for the query type, but the document should explicitly state that, very early on. The term 'qname minimization' also doesn't include in it the idea of qtype hiding, but I don't have a suggestion for a better term. ... Could I suggest query minimization as a term to include both qname and qtype minimization? The term might be a little too vague, but what do others think? I had also thought of 'query minimization', but I think that it risks being misinterpreted as minimization of the number of queries, so it might not be better. Shumon Huque ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
On 11.3.2015 17:30, Florian Weimer wrote: On 03/11/2015 05:19 PM, Jan Včelák wrote: It's not clear if the security goals make sense. What do zone operators gain if zone enumeration attacks are moved from offline to online, other than a need to provision additional server capacity? It's not that they can block resolution requests from large resolvers if a part of their client population participates in aggressive enumeration. It dependes whether you see zone enumeration as a problem. If I really want to enumerate a zone, I will just send my dictionary as queries, possibly through open resolvers. People are reckless like that. At least with NSEC3, polite attackers can do some of the processing off-line, without punishing authoritative servers or resolvers. NSEC5 takes away that option. Do the existing enumerators care? Who knows. I really can't tell. I don't know. Section 4 says, “NSEC5 hash is an SHA-256 hash function as specified in [RFC6234].” Are you sure that's right? You mean the reference to the RFC? Yes, I think it's right. Or am I missing something? I'm guessing, but “NSEC5 hash” is probably what involves FDH. Based on your comment,s it's clearly *not* SHA-256, contrary to what I quoted above. NSEC5 proof is the FDH of domain name. NSEC5 hash is SHA-256 of NSEC5 proof. I will clarify that. We deal with NSEC5 proofs and NSEC5 hashes (see the Terminology section). The NSEC5 proof is the FDH (can be comptuted only by the holder of the NSEC5 private key); the NSEC5 hash is an SHA-256 hash of the NSEC5 proof (everyone can compute it, if they know the NSEC5 proof). So in your notation, an NSEC5 RR owner name should be: Base32hex(SHA-256(FDH(Wire-Encode(owner name), privkey))) And the inner part (without the Base32 encoding) is the NSEC5 hash? Or is the SHA-256 hash skipped? Yes, the SHA-256(...) is the NSEC5 hash. The input is NSEC5 proof. Jan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
On 03/11/2015 05:19 PM, Jan Včelák wrote: It's not clear if the security goals make sense. What do zone operators gain if zone enumeration attacks are moved from offline to online, other than a need to provision additional server capacity? It's not that they can block resolution requests from large resolvers if a part of their client population participates in aggressive enumeration. It dependes whether you see zone enumeration as a problem. If I really want to enumerate a zone, I will just send my dictionary as queries, possibly through open resolvers. People are reckless like that. At least with NSEC3, polite attackers can do some of the processing off-line, without punishing authoritative servers or resolvers. NSEC5 takes away that option. Do the existing enumerators care? Who knows. Section 4 says, “NSEC5 hash is an SHA-256 hash function as specified in [RFC6234].” Are you sure that's right? You mean the reference to the RFC? Yes, I think it's right. Or am I missing something? I'm guessing, but “NSEC5 hash” is probably what involves FDH. Based on your comment,s it's clearly *not* SHA-256, contrary to what I quoted above. We deal with NSEC5 proofs and NSEC5 hashes (see the Terminology section). The NSEC5 proof is the FDH (can be comptuted only by the holder of the NSEC5 private key); the NSEC5 hash is an SHA-256 hash of the NSEC5 proof (everyone can compute it, if they know the NSEC5 proof). So in your notation, an NSEC5 RR owner name should be: Base32hex(SHA-256(FDH(Wire-Encode(owner name), privkey))) And the inner part (without the Base32 encoding) is the NSEC5 hash? Or is the SHA-256 hash skipped? You really need to make this explicit. I agree that the description is insufficient. We will fix that. Thanks. -- Florian Weimer / Red Hat Product Security ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
Hello Florian, On 11.3.2015 12:01, Florian Weimer wrote: do you plan to submit this to an IETF working group, or as an individual submission? We plan to submit the draft as an individual submission. It's not clear if the security goals make sense. What do zone operators gain if zone enumeration attacks are moved from offline to online, other than a need to provision additional server capacity? It's not that they can block resolution requests from large resolvers if a part of their client population participates in aggressive enumeration. It dependes whether you see zone enumeration as a problem. NSEC5 is designed as an alternative to NSEC/NSEC3, not a replacement. If you consider the data in your zone public, use NSEC. If you need Opt-Out, use NSEC3. If you don't want attackers to enumerate your zone, use NSEC5 (or disable DNSSEC [sic]). And you are right, NSEC5 creates additional performance capacity requirement. Everything comes at a price. Section 4 says, “NSEC5 hash is an SHA-256 hash function as specified in [RFC6234].” Are you sure that's right? You mean the reference to the RFC? Yes, I think it's right. Or am I missing something? In any case, most references to “NSEC5 hash” are underspecified. For example, in section 9.1, “The owner name of the NSEC5 RR is the NSEC5 hash of the original owner name encoded in Base32hex without padding, prepended as a single label to the zone name”, could be read in various different ways. It seems that Base32hex(SHA-256(Wire-Encode(owner name))) is meant, but it could also be read as SHA-256(Base32hex(owner name)) or something like that. OK. You are right. It is underspecified. In addition, there is an error in the quoted text. Therefore both of your interpretations are incorrect. I will fix that. We deal with NSEC5 proofs and NSEC5 hashes (see the Terminology section). The NSEC5 proof is the FDH (can be comptuted only by the holder of the NSEC5 private key); the NSEC5 hash is an SHA-256 hash of the NSEC5 proof (everyone can compute it, if they know the NSEC5 proof). So in your notation, an NSEC5 RR owner name should be: Base32hex(SHA-256(FDH(Wire-Encode(owner name), privkey))) There does not seem to be anything in the draft that describes how the RDATA of the NSEC5PROOF is computed. I think the intent is that it contains SHA-256(Wire-Encode(NSEC5 owner name)), and the validation is performed using a separate RRSIG record, signed with the NSEC5KEY public key. However, section 9.2 does not mention that the NSEC5PROOF record is accompanied by an RRSIG RRset. A few sentences are in 7.1. (NSEC5PROOF RDATA Wire Format): Owner Name Hash is a variable sized sequence of binary octets encoding the NSEC5 proof corresponding to the owner name. It's the NSEC5 proof. Again, in your notation: FDH(Wire-Encode(owner name), privkey)) I agree that the description is insufficient. We will fix that. The rollover mechanism in section 9.3 does not work reliably. The old public key must be kept around until the TTL on the old NSEC5 and NSEC5PROOF RRs have expired (after the authoritative servers stopped serving them). The old public key cannot be removed immediately. It must be possible to re-fetch it in case a caching resolver expired it for some reason. You are right. This is wrong. I will fix that. In Section 11.1, “at least one of the keys MUST validate”: This MUST is misleading because the section is about validator behavior, it needs to be lower case because this section cannot establish constraints on validator input. There needs to be some discussion regarding the TTL on the NSEC5PROOF record, the validator should not accept arbitrary values there. Good point. These days, online signatures should really use a non-deterministic signature scheme. The deterministic FDH algorithm is very difficult to implement correctly. But it is not actually referenced in the draft, there are no protocol elements that use FDH values. NSEC5 relies on deterministic signature scheme for NSEC5 proofs. We can't really use non-deterministic scheme, because we need exactly one valid signature for a domain name and a key. If the signature scheme allowed to issue two different valid signatures for one input, the slave servers could cheat on the client. Because that would render different NSEC5 hashes and thus different positions in the NSEC5 chain. Why is the FDH difficult to implement? Take a look at Appendix A. in our draft. I also wrote a reference implementation for FDH in OpenSSL and GnuTLS/Nettle. You can take a look at it and review the code (nobody did it yet): https://gitlab.labs.nic.cz/knot/nsec5-crypto As specified in the draft, the NSEC5 protocol still exposes the chain of SHA-256 hashes of owner names. It does not offer better protection against offline dictionary attacks than NSEC3. Not really. The chain is build from NSEC5 hashes. And the client cannot compute the NSEC5 hash without having the NSEC5 proof. And
Re: [DNSOP] Comments regarding the NSEC5
On Mar 11, 2015, at 9:39 AM, Jan Včelák jan.vce...@nic.cz wrote: On 11.3.2015 17:30, Florian Weimer wrote: On 03/11/2015 05:19 PM, Jan Včelák wrote: It's not clear if the security goals make sense. What do zone operators gain if zone enumeration attacks are moved from offline to online, other than a need to provision additional server capacity? It's not that they can block resolution requests from large resolvers if a part of their client population participates in aggressive enumeration. It dependes whether you see zone enumeration as a problem. If I really want to enumerate a zone, I will just send my dictionary as queries, possibly through open resolvers. People are reckless like that. At least with NSEC3, polite attackers can do some of the processing off-line, without punishing authoritative servers or resolvers. NSEC5 takes away that option. Do the existing enumerators care? Who knows. I really can't tell. I don't know. Proposal: until there is evidence that there is a community that needs the features of NSEC5 that cannot be easily replicated in NSEC3, this WG does not consider a protocol change that would require every resolver to be updated. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CloudFlare policy on ANY records changing
Evan Hunt e...@isc.org wrote: On Wed, Mar 11, 2015 at 12:13:42PM +, Tony Finch wrote: These are signed zones so the answer has to validate. ... they are? I thought the proposal was to restrict/deprecate qtype=ANY for all zones, not just signed ones. At least some of them are signed :-) But you are right it needs to work for unsigned zones. NOERROR/NODATA responses to ANY will not work well. I did a quick test consisting of: dig any non.terminal # initially empty (echo 'update add non.terminal 3600 in txt braaains'; echo send) | nsupdate -l dig txt non.terminal For both signed and unsigned zones, the first query make BIND create a negtive cache entry which covers all types, so it doesn't recurse for the second query. This will make qmail fail deliveries with a permanent error. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ South Utsire, Forties, Cromarty, Forth, Tyne, Dogger: Southerly or southeasterly 6 to gale 8, occasionally severe gale 9 in Forties, Cromarty and Forth, becoming variable 4 for a time. Moderate or rough, occasionally very rough at first in Forties, Cromarty and Forth. Rain for a time. Good, becoming moderate or poor for a time. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Another suggestion for any
On Tue, Mar 10, 2015 at 08:13:04PM -0700, Brian Dickson wrote: Okay, thinking about this a bit more... Recursive vs authoritative, RD=0 vs RD=1. In all combinations of the above, do the new thing, except for one corner case: if(RD==1 I_AM_AUTHORITY) then do_ANY (Which happens to be the default if someone uses dig against an auth server). Which means that authoritative servers who were _already_ seeing abuse with RD=1 and ANY would be told they have to reply to them; but some operators of authoritative servers have been dropping those on the floor for some time on the principle that you shouldn't be asking an authoritative server with the RD bit set. Either ANY is something we think needs support or it is not. If we think it's really not something that needs support, then we should say so and be done with it. In any case, I don't like all this conditional logic around ANY. It seems to me likely to make code bases brittle and hard to change, new implementations to be hard to get right, and to make operations troubleshooting much harder because you have to cover more cases. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CloudFlare policy on ANY records changing
On Mar 10, 2015, at 8:05 PM, Paul Vixie p...@redbarn.org wrote: we are, in this case, defining a protocol. our goal is to get the client to stop asking the ANY question. if we send is a signal that sounds right (REFUSED, for example) but merely has the effect of go to next server then we're losing. if we're serious about redefining ANY as a meta-query, then answering with RCODE=0/ANCOUNT=0 is correct. (as it would be for RD=0 queries against an RA=1 server.) but whatever we do, any new reaction to QTYPE=ANY has to ensure that the client gives up, and stops asking. I for one am concerned about doing away with QTYPE=ANY and would like to see something more along the lines of authorities returning results so dig +trace works for diagnosis. Perhaps building better tools for this which might remove my concern around ANY, that way it can iterate through various QTYPEs for me. - jared ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CloudFlare policy on ANY records changing
Tony Finch wrote: Evan Hunt e...@isc.org wrote: I'm concerned that a NOERROR/NODATA for qtype=ANY, once cached, would be identical to the cache representation of an empty nonterminal node, and that all subsequent queries for any other qtype would then be answered with the cached NODATA. These are signed zones so the answer has to validate. Perhaps the answer should be just the NSEC(3) and RRSIG(NSEC(3)) records matching the QNAME, which is a plausible way to say, yes we have records here even though this answer doesn't contain them. i love this plan. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Comments regarding the NSEC5
Hi Jan, do you plan to submit this to an IETF working group, or as an individual submission? It's not clear if the security goals make sense. What do zone operators gain if zone enumeration attacks are moved from offline to online, other than a need to provision additional server capacity? It's not that they can block resolution requests from large resolvers if a part of their client population participates in aggressive enumeration. Section 4 says, “NSEC5 hash is an SHA-256 hash function as specified in [RFC6234].” Are you sure that's right? In any case, most references to “NSEC5 hash” are underspecified. For example, in section 9.1, “The owner name of the NSEC5 RR is the NSEC5 hash of the original owner name encoded in Base32hex without padding, prepended as a single label to the zone name”, could be read in various different ways. It seems that Base32hex(SHA-256(Wire-Encode(owner name))) is meant, but it could also be read as SHA-256(Base32hex(owner name)) or something like that. There does not seem to be anything in the draft that describes how the RDATA of the NSEC5PROOF is computed. I think the intent is that it contains SHA-256(Wire-Encode(NSEC5 owner name)), and the validation is performed using a separate RRSIG record, signed with the NSEC5KEY public key. However, section 9.2 does not mention that the NSEC5PROOF record is accompanied by an RRSIG RRset. The rollover mechanism in section 9.3 does not work reliably. The old public key must be kept around until the TTL on the old NSEC5 and NSEC5PROOF RRs have expired (after the authoritative servers stopped serving them). The old public key cannot be removed immediately. It must be possible to re-fetch it in case a caching resolver expired it for some reason. In Section 11.1, “at least one of the keys MUST validate”: This MUST is misleading because the section is about validator behavior, it needs to be lower case because this section cannot establish constraints on validator input. There needs to be some discussion regarding the TTL on the NSEC5PROOF record, the validator should not accept arbitrary values there. These days, online signatures should really use a non-deterministic signature scheme. The deterministic FDH algorithm is very difficult to implement correctly. But it is not actually referenced in the draft, there are no protocol elements that use FDH values. As specified in the draft, the NSEC5 protocol still exposes the chain of SHA-256 hashes of owner names. It does not offer better protection against offline dictionary attacks than NSEC3. Florian -- Florian Weimer / Red Hat Product Security ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Another suggestion for any
Brian Dickson mailto:brian.peter.dick...@gmail.com Wednesday, March 11, 2015 11:13 AM On Sun, Mar 8, 2015 at 2:55 PM, Brian Dickson brian.peter.dick...@gmail.com mailto:brian.peter.dick...@gmail.com wrote: Hey, everyone, [snip] dig-friendly. Okay, thinking about this a bit more... Recursive vs authoritative, RD=0 vs RD=1. In all combinations of the above, do the new thing, except for one corner case: if(RD==1 I_AM_AUTHORITY) then do_ANY (Which happens to be the default if someone uses dig against an auth server). djb doesn't want QTYPE=ANY deprecated in any form. olafur doesn't want to do_ANY, under any conditions. so i'm baffled by why you're offering this alternative? -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
Darcy Kevin (FCA) kevin.da...@fcagroup.com wrote: Regarding the statement query type ANY 'matches all RR types CURRENTLY IN THE CACHE'. Actually, there's nothing in RFC 1034 that clearly *mandates* this behavior It is sort-of specified in the algorithm in section 4.3.2 which says, 4. Start matching down in the cache. If QNAME is found in the cache, copy all RRs attached to it that match QTYPE into the answer section. That applies to RD=0 queries. For RD=1, section 5.3.3 says, 1. See if the answer is in local information, and if so return it to the client. This is usually understood to mean what you would get from an RD=0 query. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Northwest Fitzroy, Sole: Southwesterly, backing southeasterly for a time, 4 or 5 increasing 6 to gale 8. Moderate or rough, becoming very rough later in west. Occasional rain, fog patches. Moderate or good, occasionally very poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Another suggestion for any
In message 20150311162220.ga18...@puck.nether.net, Jared Mauch writes: On Wed, Mar 11, 2015 at 07:12:55AM -0700, Paul Hoffman wrote: On Mar 11, 2015, at 2:00 AM, Paul Vixie p...@redbarn.org wrote: djb doesn't want QTYPE=ANY deprecated in any form. olafur doesn't want to do_ANY, under any conditions. so i'm baffled by why you're offering this alternative? Neither djb nor Olafur are automatically the consensus of this WG. None of us are. mostly-ot I've had trouble emailing djb about this and received bounces from his mailer, so feel trustrated trying to have a conversation that includ es him at least. /mostly-ot This does seem to fall into the whole undefined category just like many people feel that TCP is optional where my reading of 1035 4.2.2 defines how queries over TCP should be performed. RFC 1123, Section 6.1.3.2 Transport Protocols, introduced the SHOULD with the current well known description. *SHOULD This word or the adjective RECOMMENDED means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. If you read that along with Section 6.1.3.2 I don't see how any vendor could ship a recursive DNS server that doesn't support TCP. I can understand how you could ship a authoritative server where you have full control over the data you are sending. Mark At the most recent NANOG John Kristoff presented on the TCP part: https://www.nanog.org/sites/default/files/nanog63-dnstrack-kristoff-dnstcp.pd f There is a gap, neither positive or negative in the behavior of these things, which I'm sure will rage along for a bit re: ANY, TCP, etc... I'm working on a project right now that should collect some data and help better study the behavior of systems. once it's ready, I will share more data. If you are a researcher or PHD candidate interested in DNS, please contact me off-list. - jared -- Jared Mauch | pgp key available via finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-chain-query-02.txt
Paul Wouters p...@nohats.ca wrote: On Tue, 10 Mar 2015, Tony Finch wrote: All of those require round trips. No they do not. Please stop repeating this falsehood. paul@bofh:~$ sudo unbound-control flush_zone nohats.ca paul@bofh:~$ dig a +dnssec www.nohats.ca @127.0.0.1 Oh come on, surely you understand the difference between a protocol requirement and an implementation artifact. I agree that current validators use too many round trips, but that is not because of problems in the protocol. Yes you can blindly send a bunch of parallel udp queries on every dot and hope the last one you need didn't take too long or drop. Or you can use TCP and send the whole lot in a single packet. Yes, that is what this draft recommends. Are you agreeing with me? Sorry, by send the whole lot I mean the client can bundle up half a dozen queries (each a separate DNS message) into one TCP packet. Most existing recursive servers will process these queries serially, but as Mark Andrews pointed out, if you send the original query before the queries for the DS+DNSKEY chain, the first query will prime the cache so the later queries can be answered immediately, for a 1RTT response. Sending a number of queries, and then when finding out you are still lacking some information, sending out another number of queries, is not the same as sending 1 query and getting a dns answer packet back that in itself completely validates. But with the existing DNS protocol you can send out queries for everything you need up front. If you use edns-chain-query there are still situations where you have to ask follow-up queries, in pretty much the same cases as without the extension. You can implement the API you want without edns-chain-query. I have looked at several validators, and they all have network logic intertwined with the validation logic. None of the ones I looked at currently have a function which can take a chain of RRsets and validate them, the kind of function edns-chain-query would need. Once you have such a function it's fairly easy to do 1 RTT query and validation without edns-chain-query, and you want to do that anyway for compatibility with old servers. I'm happy to add a section of recommendations for adding common related records such as IPSECKEY, TLSA, SSHFP or what not. It does mention CNAME/DNAME and I'm happy to add an entry about SRV and MX. Would that address your concerns? Well, it would fix an omission. Should the draft list those RRTYPEs it should consider including? If so, should the draft list these in weighted order? Does this include _prefix locations? (eg like for TLSA) Which records do you think should be considered? You misunderstand what I mean. I am not suggesting adding answers for questions that were not asked. I mean dealing with situations where the DNS protocol (ignoring DNSSEC) requires follow-up queries that the client cannot predict in advance, and which therefore require a second round trip. For example, if I ask for: dotat.at in mx ? I may have to make follow-up queries regarding the target of the MX record(s), and they have to be a second round trip. This also applies to CNAME, DNAME, SRV, NS, maybe others. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ South Utsire, Southeast Forties: Southwesterly 4 or 5, becoming variable 3 or 4, then southeasterly 6 to gale 8 later. Moderate or rough. Fair. Good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
