Re: [DNSOP] Another suggestion for any
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. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
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 -- Section 3.7.1 says only that a QTYPE of * matches all RR types, whereas Section 5.3.3 (Algorithm) says to return the answer or the data if it's in the cache, but this is ambiguous with respect to QTYPE=* (other than the highly-improbable case that we have RRsets for every possible RR type, how can we know we have the answer/the data in our cache, given that the QTYPE matches all RR types at the node and there might be other RRsets extant which don't happen to be cached at the time? Is an answer really the answer if we can't be sure that it satisfies the matching rule of the QTYPE definition?). People cite the examples of Section 6.2.2 as definitive evidence that QTYPE=* queries can always be satisfied by whatever happens to be laying around in a cache, but they don't seem to notice that those were *non-recursive* queries in the examples, and it's their *non-recursiveness* that gives rise to the lack of rigor in returning a response (as it is whenever a non-recursive query is sent to a DNS entity that doesn't happen to be authoritative for the relevant zone). The required fetching behavior of a caching resolver in response to a *recursive* QTYPE=* query, is basically undefined by RFC 1034. Common practice is to treat QTYPE=* queries as effectively non-recursive, despite RD being set to 1, if *any* relevant RRset exists in the cache. Possibly, this is because the Section 6.2.2 examples were misunderstood. Or, simply because it was easier to code that way. A more modern concern would be that this rigor could be abused for possible DoS attacks. But, at this point in DNS histor y, I doubt we can roll back the clock and force everyone to be rigorous in fetching answers for QTYPE=* queries. So the answers are inherently unreliable, and that situation is not likely to change, unless and until someone invents an ALL QTYPE/RR-type/meta-type. - Kevin -Original Message- From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Paul Wouters Sent: Monday, March 09, 2015 10:48 AM To: D. J. Bernstein Cc: dnsop@ietf.org; dns-operati...@dns-oarc.net Subject: Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards On Mon, 9 Mar 2015, D. J. Bernstein wrote: My qmail software is very widely deployed (on roughly 1 million SMTP server IP addresses) and, by default, relies upon ANY queries in a way that is guaranteed to work by the mandatory DNS standards. And you've been told for two decades that this was wrong? Specifically, query type ANY matches all RR types for that node on that server. Wrong, query type ANY matches all RR types CURRENTLY IN THE CACHE. So the result of qmail's ANY query is completely meaningless and qmail cannot derive any conclusion from the absence of any record from that query. So if the MX or record has expired from the cache but another RRtype with larger TTL (say NS) is still in there, your ANY query will fail to find records. qmail with this feature is broken. Additionally, Tony Finch did a write up of qmail's ANY problems too: https://fanf.livejournal.com/10.html In new software today I would sacrifice these efficiency benefits for the sake of simplicity, but this doesn't mean that I'm going to frivolously inflict retroactive punishment upon administrators who have installed standards-compliant software and done nothing wrong. You have had 10 years to fix it. Luckilly, I believe most distributions shipping qmail add the patch to fix this already. I understand how a sufficiently large site might acquire the impression that it can safely take radical action at its own whim, violating the existing protocol standards Uhm, we pointd out qmail's _bug_ for a decade. I'm quite sure even you do not need to interop with BIND4 anymore. Apparently Firefox recently deployed ANY queries. I haven't looked at the details but I gather that they're related to the well-known annoyances of handling etc. Firefox was browbeaten into reverting this change on the basis of highly questionable claims regarding amplification: It can return enormous result sets, and some authoritative servers have taken to refusing ANY queries because of the frequency with which such queries show up in amplification attacks - I'm concerned about amplification and the perception thereof by security monitors. No, they were also told that ANY queries only return data from the cache, and using ANY queries means you might miss actual A or records. This has nothing to do with ANY queries and amplification. The common theme of CNAME/MX/A and A/ is that there's widepread interest in being able to easily retrieve multiple record types. What I'm saying is not that
Re: [DNSOP] CloudFlare policy on ANY records changing
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. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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 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? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on dnsop-qname-minimisation-02
On Mar 11, 2015, at 9:02 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Wed, Mar 11, 2015 at 12:35:29AM -0400, Shumon Huque shu...@gmail.com wrote a message of 400 lines which said: Are we standardizing on the british spelling of minimisation in preference to the americanized minimization? Bikeshedding is postponed until Working Group Last Call :-) Or beyond. The RFC Editor allows both types of spelling, and they will make it consistent. I'd prefer the simpler The problem statement is described in ... The term exposed in my mind carries a more sensational connotation, but I might be nitpicking. Advice from english writers here? +1 to Shumon: exposed is more sensational, and not appropriate here. The idea is to minimize the form of the query name sent by the resolver, by including only the minimum number of rightmost labels needed in outbound queries to authoritative servers. Additional labels are prepended to the query name for subsequent queries as responses and referrals are obtained. Rigorous but may be too long and convoluted? I prefer rigor, and it is not convoluted. Under current practice, when a resolver receives the query What is the record for www.example.com?, it sends to the root (assuming a cold resolver, whose cache is empty) the very same question. Under current practice implies a description of what is currently being done before this new resolution method is introduced. When in fact this paragraph is describing the new method. No, not at all. It describes the current practice. Under the new (qname minimisation), the resolver would send only com to the root. +1 to Stephane here. To do such minimisation, the resolver needs to know the zone cut [[54]RFC2181]. Zone cuts do not necessarily exist at every label boundary. If we take the name www.foo.bar.example, it is possible This makes it sound like minimisation requires a resolver to apriori know the zone cuts. This is not necessarily correct. A resolver can learn the zone cuts in the process of adding labels and doing normal iterative resolution. Yes, it is explained later. It would be better to say as described later right after the reference to RFC 2181 so that the reader doesn't think therefore I can't do this. We want the document to not only describe the practice, but also to encourage it. 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). Do note the use of NS is not mandatory. See section 3, the paragraph starting with Another way to deal with such broken name servers (which you mention later) and also section 3, 1st paragraph about the statistics of qtypes. My strong preference is that this document only deal with qname minimization. If someone wants to extend that to qtype minimization, which covers a different threat model, that should be done in a different document. This should more precisely define which types of forwarders will get less data. I think you mean the forwarders upstream of the resolver performing qname minimization, rather than forwarders that might exist between the client and the minimizing resolver. They are not typically called forwarders (see the discussion about draft-hoffman-dns-terminology) Different thread. :-) This suggested workaround doesn't help with all forms of broken servers. Nothing deals with all the brokenness found on the Internet. +1, and unnecessary to state. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Another suggestion for any
tl;dr: I am thinking of the principle of least surprise, for the use case of interactive dig users. Here's why: Asking ANY to a recursive resolver, the expected behavior is whatever is in the cache (which could be a subset of the real RRsets, and possibly empty even though RRs exist on corresponding auth servers). No-error, no-data in this circumstance would not be unexpected, and would not be a cause for concern. Asking ANY to an auth server, the expected behavior is everything at this node. At 3am, when investigating a problem with a domain, if I unwittingly type ANY as the type, I don't want to have to think about or remember that the behavior changed, and that the no-error, no-data answer really means deprecated. I would be happy if the differential behavior were refused or notimpl, in this specific corner case (RD=1, to an auth server). Maybe that compromise is sufficient? It would still accomplish Olafur's goal. Brian On Wed, Mar 11, 2015 at 2:00 AM, Paul Vixie p...@redbarn.org wrote: Brian Dickson 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 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] Comments regarding the NSEC5
On Mar 11, 2015, at 9:39 AM, Jan Včelák jan.vce...@nic.cz wrote: NSEC5 proof is the FDH of domain name. NSEC5 hash is SHA-256 of NSEC5 proof. I will clarify that. Why not just do something simpler? The only thing NSEC5 really differs in a way that counts is not in the NSEC record but really just the DNSKEY handling, having a separate key used for signing the NSEC* records. So why define NSEC5 at all. Instead, just specify a separate flag for the DNSKEY record, NSEC-only, sign the NSEC3 dynamically, bada bing, bada boom, done! For old resolvers, they just ignore the flag and treat it like any other DNSKEY record, and since the valid names are signed with the other key, while the NSEC* are signed with this key, it works just fine. For upgraded resolvers, they follow the convention and only will accept RRSIGs for NSEC/NSEC3 with that DNSKEY record. And then on the authority side, you just dynamically generate and sign the NSEC3 record that says H(name)-1 to H(name)+1 has no valid record and sign that with the NSEC-only key. This way, you gain the protection against enumeration and the limited damage on key compromise property when validated by upgraded resolvers, and you still get the protection against enumeration when the resolver isn't upgraded, and you don't need to upgrade the resolver in order for this to be deployed. -- Nicholas Weaver it is a tale, told by an idiot, nwea...@icsi.berkeley.edufull of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS Terminology: Glue
I guess glue in the scope of the zone data may be a proper subset of glue in the scope of the message. What if zone A has the name server's name below the cut fall in the bailiwick of zone B, and both zones are hosted in one authoritative name server? If that authoritative name server is allowed to place the address (in zone B) of the name server (zone cut in zone A) in a referral response, is that a case of glue in the message but not glue in the zone data? Best regards, Zheng Wang 发件人：Niall O'Reilly niall.orei...@ucd.ie 发送时间：2015-03-12 08:07 主题：[DNSOP] DNS Terminology: Glue 收件人：Paul Hoffmanpaul.hoff...@vpnc.org 抄送：IETF DNSOP WGdnsop@ietf.org Hi. In http://www.ietf.org/id/draft-hoffman-dns-terminology-02.txt, glue is defined as follows. Glue records -- Resource records which are not part of the authoritative data, and are address resource records for the servers listed in the message. They contain data that allows access to name servers for subzones. (Definition from RFC 1034, section 4.2.1) Reference to the message seems to be a distraction here. The cited source defines (and motivates) glue records, in a section which specifies [t]he data that describes a zone, as follows [...] a zone contains glue RRs which are not part of the authoritative data, and are address RRs for the servers. These RRs are only necessary if the name server's name is below the cut, and are only used as part of a referral response. I think that placing the definition of glue in the scope of the message rather than in that of the zone data is likely to lead to confusion. Best regards, Niall O'Reilly ___ 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] DNS Terminology: Glue
On Mar 12, 2015, at 6:53 AM, Phillip Hallam-Baker ph...@hallambaker.com wrote: Its a bug in the spec. The terminology document is the wrong place to deal with bugs in the spec. We are happy to list differences of opinion about what a term means if they appear in different RFCs, but not to try to fix bugs. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
Paul Wouters writes: So if the MX or record has expired from the cache but another RRtype with larger TTL (say NS) is still in there, your ANY query will fail to find records. The client is behaving correctly. The ANY query isn't guaranteed to find the MX, but you're wrong in claiming that the client is relying on this. I realize that you don't understand how this type of DNS client works, so let me go through the details, slowly, covering (1) why the queries reliably produce the desired information and (2) why QTYPE=ANY ends up reducing the number of queries that the authoritative server has to handle for producing this information. The client begins with an ANY query to the cache. There are several possibilities for the cache state at this moment: * maybe there's nothing; * maybe there's an MX record; * maybe there's an A record; * maybe there's some other regular record, such as NS; * maybe there's a mix of regular records; * maybe there's a CNAME record; * etc. In the nothing case, the cache forwards the query to the server. This could end up retrieving, e.g., an MX set, an A set, and an NS set; it could end up retrieving a CNAME; there are many possibilities. The cache then returns whatever it has to the client. The client notices failure cases (such as SERVFAIL) and, in those cases, defers mail delivery. Let's now focus on what happens in the success cases. If the cache returns a CNAME: The client sees the CNAME, replaces the original name with the CNAME, and starts over. If the cache returns, e.g., an NS record: The client sees this record and concludes that there _isn't_ a CNAME. This conclusion is justified by the rule that a name can't have CNAME together with regular records. An administrator who sets up a single name with both CNAME and NS (or CNAME and MX, etc.) is entirely at fault for the resulting confusion. The client then sends an MX query to the cache. Again failures are caught and defer mail delivery. The most common success case is that the cache has an MX set at this point; the client sees the MX set and acts accordingly. (The A that the MX points to is normally cached too.) If there's a successful response without an MX (case 5 described in http://cr.yp.to/djbdns/notes.html#response-parsing) then the client correctly concludes that there isn't an MX and falls back to an A query for the original name. To summarize, this type of ANY-MX-A client correctly sees whether there's a CNAME, correctly sees whether there's an MX, and (when there isn't an MX) correctly sees whether there's an A. If there's a server failure (e.g., NOTIMP) or cache failure, the client correctly defers mail delivery. A comprehensive efficiency analysis requires detailed measurements for many years at many sites, but spot checks have consistently shown that the following cases are most important: * Most common: MX in server and in cache. The ANY-MX-A client ends up generating 0 queries to the server: the cache answers ANY with MX, and answers MX with MX. For comparison, a CNAME-MX-A client would also end up sending 0 queries to the server _if_ the cache were smart enough to use the MX as a reason to deny CNAME. But typical caches aren't that smart, so this type of client would end up sending 1 query to the server. An MX-A client uninterested in CNAME would end up sending 0 queries to the server. * MX in server but not in cache. The ANY-MX-A client ends up generating 1 query to the server: the server answers ANY with MX (and typically A), and then the cache answers MX with MX. For comparison, a CNAME-MX-A client would end up generating 2 queries to the server: the server answers CNAME with no data, then answers MX with MX. An MX-A client uninterested in CNAME would end up sending 1 query to the server: the server answers MX with MX. * A in server and in cache, no MX in server: The ANY-MX-A client ends up sending 1 query to the server. The cache answers ANY with A; the server answers MX with no data; the cache answers A with A. For comparison, a CNAME-MX-A client would end up generating 2 queries to the server (or 1 if the cache is smarter): the server answers CNAME with no data; the server answers MX with no data; the cache answers A with A. An MX-A client uninterested in CNAME would end up sending 1 query to the server. The server answers MX with no data, and the cache answers A with A. * A in server, nothing in cache: The ANY-MX-A client ends up sending 2 queries to the server. The server answers ANY with A; the server answers MX with no data; the cache answers A with A. For comparison, a CNAME-MX-A client would end up generating 3 queries to the server: the server answers CNAME with no data; the server answers MX with no data; the server answers A with A. An MX-A client uninterested in
Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
Packet size is harder to analyze. ANY often pulls some records that aren't used, and if the site isn't configured carefully then ANY can even end up falling back to TCP, costing bytes _and_ packets. On the other hand, there are a huge number of Internet sites that don't have a noticeable volume of unusual records and don't need TCP, and there's a clear traffic win for every skipped query and skipped no-data response. My guess is that with DNSSEC, this will be common, as often times the domain apex is where the email would be sent. For my personal domain, that’s @flame.orghttp://flame.org, and weighs in at 1758 bytes to an ANY query right now. Once this is done, the MX target then needs to be followed of course (or targets in the case of a failure to connect.) In the following, I’m using ESND0. If this isn’t true, we all know anything 512 bytes as a response was a TCP hit. I’m not as scared of TCP hits as others may be, but I do think they should be avoided when practical. ANY comes in as 1769 with or without DNSSEC. Had it asked for the MX directly, it would have gotten 60 bytes without DNSSEC, and 229 with. If there was no MX record, I assume then another query would be issued for the and A records. That’s two more queries, but both of which would be smallish in comparison to the ANY query. The DNSSEC keys nearly always dominate ANY queries at the apex. I’m happy we are discussing issues with ANY queries, and the fairly small number of clients that use them. I would have to see hard numbers collected over a lot of data showing where the ANY query was actually better than following the MX, , A path. Until data is collected from how people set up zones today, I’m not sure I can say one is better than the other, other than as a feeling that it might help reduce queries but I’m not sure it reduces bandwidth. What problem are we specifically trying to solve here again? —Michael ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Definition of validating resolver
* Ted Lemon: On Mar 8, 2015, at 6:31 PM, Ralf Weber d...@fl1ger.de wrote: I was told that the difference is that a security aware resolver does not validate, but instead relies on the Validating Stub Resolver to protect the user. So it would handle all the DNSSEC processing to the authoritative and would store the records with signatures in the cache, but it wouldn't check if they are valid. Doesn't this create an opportunity for a DoS attack based on poisoning the cache with a record that won't validate? Yes, but that's inherent to DNSSEC and not specific to this configuration. For instance, you might cache bad glue records, which also prevents using DNSSEC to see that they are bad. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CloudFlare policy on ANY records changing
* Tony Finch: I also tried a stupid hack to send an ANY RR in the response. BIND's resolver treats this as a FORMERR and returns SERVFAIL to the client. What about introducing a new non-meta RR type for this purpose? It would not increase the response size by much. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS Terminology: Glue
On Mar 12, 2015, at 5:07 AM, Niall O'Reilly niall.orei...@ucd.ie wrote: In http://www.ietf.org/id/draft-hoffman-dns-terminology-02.txt, glue is defined as follows. Glue records -- Resource records which are not part of the authoritative data, and are address resource records for the servers listed in the message. They contain data that allows access to name servers for subzones. (Definition from RFC 1034, section 4.2.1) Reference to the message seems to be a distraction here. The cited source defines (and motivates) glue records, in a section which specifies [t]he data that describes a zone, as follows [...] a zone contains glue RRs which are not part of the authoritative data, and are address RRs for the servers. These RRs are only necessary if the name server's name is below the cut, and are only used as part of a referral response. I think that placing the definition of glue in the scope of the message rather than in that of the zone data is likely to lead to confusion. Quite right. We'll fix this in the next draft. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] CloudFlare policy on ANY records changing
On Thu, Mar 12, 2015 at 11:38:04PM +, Darcy Kevin (FCA) wrote: So you're thinking it's more likely that we'll get folks to understand this new type, that's designed to frustrate QTYPE=* queries in a more-or-less graceful way, than it is to convince them to stop making QTYPE=* queries in the first place? They don't need to understand it, they just need to be able to receive it without choking. This could be a pretty brilliant solution, actually: If you're authoritative for a signed zone and you receive a query of type ANY, return the applicable NSEC/NSEC3; if the zone is *not* signed, synthesize a response containing a single RR with a type from the private use range (e.g. TYPE65531 or whatever), zero length rdata, and a long TTL. The resolver would get an answer, so it stops asking; it would *not* cache the answer as an empty node, so subsequent queries for other qtypes can still resolve. I like this better than any of the prior suggestions. (It doesn't address qmail's problem, but that's a lost cause no matter which method is chosen.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
On Wednesday, March 11, 2015 09:52:55 AM Nicholas Weaver wrote: Why not just do something simpler? The only thing NSEC5 really differs in a way that counts is not in the NSEC record but really just the DNSKEY handling, having a separate key used for signing the NSEC* records. So why define NSEC5 at all. Instead, just specify a separate flag for the DNSKEY record, NSEC-only, sign the NSEC3 dynamically, bada bing, bada boom, done! This would not work. Anyone holding the NSEC-only private key could fake denying answers for the zone. So if your zone is slaved by a less-trusted party, they could still manipulate your zone. This is not possible with NSEC5. Jan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] comments on dnsop-qname-minimisation-02
On Wed, 11 Mar 2015 16:50:07 +, Paul Hoffman wrote: I'd prefer the simpler The problem statement is described in ... The term exposed in my mind carries a more sensational connotation, but I might be nitpicking. Advice from english writers here? +1 to Shumon: exposed is more sensational, and not appropriate here. Indeed, exposed is inappropriate; so is described. Reference to _describing_ the problem statement (perhaps as elegant or clumsy; long-winded or concise) isn't what's needed here. I suggest any one of presented, declared, or specified. ATB Niall O'Reilly ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] DNS Terminology: Glue
Hi. In http://www.ietf.org/id/draft-hoffman-dns-terminology-02.txt, glue is defined as follows. Glue records -- Resource records which are not part of the authoritative data, and are address resource records for the servers listed in the message. They contain data that allows access to name servers for subzones. (Definition from RFC 1034, section 4.2.1) Reference to the message seems to be a distraction here. The cited source defines (and motivates) glue records, in a section which specifies [t]he data that describes a zone, as follows [...] a zone contains glue RRs which are not part of the authoritative data, and are address RRs for the servers. These RRs are only necessary if the name server's name is below the cut, and are only used as part of a referral response. I think that placing the definition of glue in the scope of the message rather than in that of the zone data is likely to lead to confusion. Best regards, Niall O'Reilly ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
On 03/12/2015 11:15 AM, Jan Včelák wrote: On Wednesday, March 11, 2015 09:52:55 AM Nicholas Weaver wrote: Why not just do something simpler? The only thing NSEC5 really differs in a way that counts is not in the NSEC record but really just the DNSKEY handling, having a separate key used for signing the NSEC* records. So why define NSEC5 at all. Instead, just specify a separate flag for the DNSKEY record, NSEC-only, sign the NSEC3 dynamically, bada bing, bada boom, done! This would not work. Anyone holding the NSEC-only private key could fake denying answers for the zone. So if your zone is slaved by a less-trusted party, they could still manipulate your zone. This is not possible with NSEC5. They can still respond with SERVFAIL instead of supplying a signed answer, achieving roughly the same result. A better argument would be support for opt out, where signatures from the online key could introduce unauthorized positive answers. It's still not a very strong argument, admittedly. The DNS software itself is likely signed by a key which is kept online (more or less). Online keys are less threatening than they used to be, and we aren't even talking about long-term keys baked into software, but short/medium-term keys which are easily replaced. And does anyone actually use opt out with NSEC3? -- Florian Weimer / Red Hat Product Security ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
