Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt
Evan Hunt wrote: > > No, an ANAME-aware resolver would ignore those records, re-query for > the ANAME target, and validate the response from there - same as it does > now with a CNAME. As long as the ANAME is validly signed, it's just a > chain query. That only works if the downstream resolvers (stubs etc.) are not validating. (Or maybe if they are ANAME-aware but the upstream resolver has no way of knowing that.) Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Malin, Hebrides: Southwest, veering northwest 5 to 7, occasionally gale 8 at first in Hebrides, then perhaps gale 8 later. Rough or very rough, becoming high later in west. Rain then snow showers. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt
On Sat, Feb 03, 2018 at 12:20:34PM +0100, Stefan Bühler wrote: > This advise suggests that if the auth server has access to the zone's > private key and can sign responses on the fly, ANAME works with signed > zones. > > But it doesn't! Because ANAME-aware recursive resolvers will replace > the signed records with unsigned ones. No, an ANAME-aware resolver would ignore those records, re-query for the ANAME target, and validate the response from there - same as it does now with a CNAME. As long as the ANAME is validly signed, it's just a chain query. > I'd also suggest to relax the "MUST re-query" requirement if the > resolver used ECS - because it means the auth server had a good chance > to respect the network topology (this is unrelated to signed zones). It's the same requirement as for CNAME. Putting full trust in a chain returned by an auth server risks cache poisoning. (Not even necessarily malicious; the auth might simply be serving information that's outdated.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt
Hi again, On 01/26/2018 09:09 PM, Evan Hunt wrote: >> I have concerns about the resolver replacing A/ records in signed >> zones as it breaks validation. > > What do you mean by "the resolver" in this case? The "recursive resolver". >> If a resolver understanding ANAME is queried using the DO=1 flag it >> shouldn't touch the A/ records, because it already knows the >> requestor would through them away. > > It doesn't *know*. DO=1 doesn't mean the client is validating; it means the > client understands RRSIG. Well, better safe than sorry. Tony Finch had a more detailed suggestion which sounds good to me. > The draft already advises that ANAME will break validation unless the > validator is ANAME-aware or the auth server has access to the zone's > private key and can sign responses on the fly. (This suggests to me that > the use of ANAME in signed zones will probably be limited at first.) This advise suggests that if the auth server has access to the zone's private key and can sign responses on the fly, ANAME works with signed zones. But it doesn't! Because ANAME-aware recursive resolvers will replace the signed records with unsigned ones. If the next client (which queried the ANAME-aware recursive resolver, but isn't ANAME-aware itself) tries to validate the answer it will reject the address records, and won't be able to resolve them again with ANAME. Which means in the current proposal you can't use ANAME in a signed zone unless you know that ALL validating clients are either ANAME-aware or don't have a ANAME-aware recursive resolver in the chain to the auth. >> This also means a caching resolver should store the original A/ >> records (and not the ones resolved through ANAME) in the cache. > > Certainly. > >> With this change I don't think it makes sense to say "a resolver MUST >> re-query", I'd use "a resolver SHOULD re-query if it didn't use ECS and >> the query didn't use DO=1". > > I'm sorry, I'm not getting this. Please explain further, particularly > with an expansion of the word "it"? "it" as "the resolver". I think the text suggested by Tony Finch covers the DO=1 part. I'd also suggest to relax the "MUST re-query" requirement if the resolver used ECS - because it means the auth server had a good chance to respect the network topology (this is unrelated to signed zones). cheers, Stefan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt
I've been pondering DNSSEC and additional data. I think it's currently the case for additional section processing in general that if (say) an RRset isn't present, then nothing is added to the additional section. I think it would be better to add an NSEC(3) proof of nonexistence if the relevant zone is signed. The ANAME draft is consistent with traditional behaviour. I vaguely wonder if it would be worth encouraging additional section PNEs, or if it would be wedging too much into the spec. One reason not to beef it up in this way is that, as currently written, ANAME generally doesn't require two upstream queries for one incoming query - if the other address type isn't cached the server can just omit it. The exception is a dynamic signed PNE where the server has to ensure the type bitmap is correct. On the other hand, if it is beefed up then an ANAME query effectively becomes the mythical one-message A+ query. I dunno if this counts in favour or against :-) Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Hebrides, Bailey, Fair Isle, Faeroes, Southeast Iceland: Cyclonic at first in Fair Isle, otherwise northerly or northwesterly 6 to gale 8, occasionally severe gale 9. Very rough or high. Squally wintry showers. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt
I realised that the primary/secondary split I talked about in my previous message turned out to be the wrong idea. There were lots of complicating issues that made it clear that auth server ANAME behaviour does not cleanly follow the traditional primary/secondary split. Instead I think the split should be between active ANAMEs, where an auth server fetches address records from the target, and passive ANAMEs, where the server just uses the addresses it got from the master file or zone transfer etc. A server can be active if it has the private signing keys or if the zone is unsigned. It has to be passive if the zone is signed and it lacks keys. It doesn’t matter how the zone contents are provided to the server. I still think it would be helpful to have separate sections in the spec for active and passive auth servers. This active/passive split could also be extended to recursive servers, tho the logic is a bit different. (See previous message for details.) I don’t know whether or not it makes sense to have auth servers be similarly sensitive to DO and CD. Tony. -- f.anthony.n.finchhttp://dotat.at ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt
I have read through the draft. I like it a lot and I really want this feature! I've quoted bits of it below (indented) and added my comments and questions. Warning, this is nearly 1400 words... 1. Introduction Is it worth explicitly mentioning the case of subdomains such as `department.example.edu` that have an MX and a web site at the same domain? 2. The ANAME Resource Record Only one ANAME can be defined per . An ANAME RRset MUST NOT contain more than one resource record. Thinking out loud, I quite like the idea of relaxing this requirement, but then I imagine what happens to the unlucky resolver that is presented with a huge ANAME RRset... 3. Authoritative Server Behavior Should the intro to this section say that the auth server is expected to cache the address records, not resolve them each time? I think this auth section needs to be split into separate sections for primary and secondary authoritative servers: primary servers do ANAME target address record lookups (and have DNSSEC private keys for signed zones); secondary servers passively receive ANAME + address records via AXFR/IXFR, and do no lookups or signing. In the secondary case, the cache logic is a bit different. The upstream primary is responsible for implementing the TTL logic, but it only needs to notify the secondaries when the records actually change. 3.1. Address records returned with ANAME Address records with expired TTLs MUST NOT be used to answer address queries until refreshed by sending a new query to the ANAME . Can we make this a SHOULD NOT to allow for authoritative service to continue working during an outage (serve-stale)? If resolution of the ANAME yields no address records due to NODATA or NXDOMAIN, then the authoritative server MUST return only the ANAME record. If the query was for a specific address type, then the response MUST also include the SOA as in a normal NODATA response, along with NSEC or NSEC3 if applicable. I think it might be clearer if this paragraph is moved up to the start of section 3.1 following the A and paras. You can then tie it more directly to the presence/absence wording for each addr type. If resolution of the ANAME yields no address records due to some other failure, and the query was for a specific address type, the response MUST include the ANAME record and set the RCODE to SERVFAIL. It would be nice to allow for serve-stale here too. 3.2. Coexistence with other types If the zone is configured with an A or RRset at the same DNS node as ANAME, then the ANAME is considered to have already been expanded. If during query processing any address records are found at the same node as an ANAME RR, then the ANAME RR MUST NOT be further expanded by the authoritative server. I think this should be conditional on whether the server is primary or secondary wrt this zone. (The "already present" case sort of implies secondary, but I think the difference should be more explicit.) In the primary case I wonder if it would make sense for the server to include the address records in the zone's persistent storage. It's mildly tricky, tho, because: (a) The server needs to distinguish between the case where it is loading from a master file and it really is the primary, or it's loading a master file that has been provisioned by some other system that expands ANAME (i.e. it looks like a trad primary but it's functionally a secondary that just isn't using AXFR/IXFR), (b) What if the server starts off with a zone that lacks ANAME address records, but they get subsequently added by an UPDATE? (c) When it is loading a zone without ANAME address records, how does it know that it is supposed to be a primary and resolve the ANAME target, or that it ought to behave like a secondary but the ANAME resolver found no records at the target? (d) A primary that supports ANAME and ECS may need to persist the ECS metadata in the zone file, and if that is the case there should be a presentation format for ECS options and associated variant RRsets. This is a horrible can of worms. >From the server config / ops point of view it probably makes sense to have a `resolve-aname-addresses` option which defaults to `on` for a master/primary zone and off for a slave/secondary zone. Like other types, ANAME MUST NOT exist below a DNAME, Should this mention occlusion? 3.3. DNSSEC signing If the server does not have access to the private zone-signing key then it MAY return unsigned address records, but this is NOT RECOMMENDED I think it would be better if this is a MUST NOT - either the server is a primary and has the signing keys, or it's a secondary that receives pre-re-signed address records from a primary. Implementers MAY allow address records associated with the ANAME to be populated and signed by the primary server, then sent along with their RRSIGs to secondaries via zone transfer. I would upgrade this to a SHOU
Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt
On Fri, Jan 26, 2018 at 01:51:38PM +0100, Bjørn Mork wrote: > Is there a need to explictly modify MX and NS records, allowing them to > point to an ANAME? Or is this already covered by the mandatory A or > records for the ANAME ? It certainly would be reasonable for MX. I have feelings of unease about NS, but I'm not sure whether they're well-founded. (I'd welcome further discussion on this topic, if anyone has thoughts.) > Should there be a section dealing with using an ANAME owner as a > target of other RRs? This could probably be made very simple by saying > that an ANAME owner is allowed wherever an A or owner is. Yes, that would be a reasonable way to put it, with maybe a carve-out for NS. I'm going to wait for further discussion, either here or with my co-authors, before I try to revise the text, though. > >Only one ANAME can be defined per . An ANAME RRset > >MUST NOT contain more than one resource record. > > Is there a technical reason for this? I can easily see usecases for > multiple ANAMEs. E.g using more than one CDN provider for a given > . I can see use cases for it too, but it leads to a rapid combinatoric explosion in complexity. Which A/ records do you return if you can't get all of them? How do you signal that your response is incomplete? We decided to dodge the issue; it's complicated enough already. And after all people do get along with CNAMEs, and those can't be multiple either. > >When an ANAME record is present at a DNS node and a query is received > >by an authoritative server for type A or , the authoritative > >server returns the ANAME RR in the answer section. > > Is this a MUST, SHOULD or "may occasionally do"? MUST, thanks. > > >Because not all querying resolvers understand ANAME, the > >authoritative server MUST also return address records, as described > >below. > .. > >If resolution of the ANAME yields no address records due to > >NODATA or NXDOMAIN, then the authoritative server MUST return only > >the ANAME record. If the query was for a specific address type, then > >the response MUST also include the SOA as in a normal NODATA > >response, along with NSEC or NSEC3 if applicable. > > Aren't these requirments conflicting? The exceptions were meant to be covered by "as described below", but I'll clarify this. > > 3.2. Coexistence with other types > > Is it really necessary to summarize the CNAME and DNAME rules here? > AFAICS, they are generic and not modified in any way by the introduction > of ANAME. Admittedly there's nothing here that you couldn't deduce by reading other RFCs, but I think it improves the spec to be clear and explicit about how this new alias record fits in with existing rules for other alias records. > Maybe include the one ANAME per RRset restriction in this section, if > that is kept? I prefer to have such limitations specified along with the RR format. I don't mind repeating the admonition, but this section is about coexistence with other types, so it doesn't seem like a good fit here. > >If the server does not have access to the private zone-signing key > >then it MAY return unsigned address records, but this is NOT > >RECOMMENDED > > 'NOT RECOMMENDED' is too weak here. The section conflicts with RFC4035: > [...] > Suggested alternative text > > The server MUST NOT return unsigned address records. > > > > unless every resolver with access to the zone is known to > >support ANAME (as might be the case in a split-horizon deployment > >where ANAME records are only served to an internal network with its > >own resolvers). > > I fail to see the relevance of this. You don't need an RFC to tell you > what you can do on your private network. Although I guess an 'internal > network with its onw resolvers' using a CDN to provide service might > exist, I find this example really confusing. It looks like a bad excuse > for the RFC4035 violation. Which nobody is going to care about on your > 'internal network' anyway. > > I suggest removing this. We were trying to address an existing use case. Your point is well taken that internal networks can violate specifications if they want to, but we wanted to address the concerns of people with existing deployments. > >Validating resolvers which do not yet implement ANAME will not be > >able to validate the A and responses included with an ANAME > >response unless those responses are validly signed by a DNSKEY at the > >apex of the zone in which the ANAME resides. Passing along the > >RRSIGs associated with the original A and RRsets from the ANAME > > will not be sufficient for DNSSEC validation. > > Does this say anything useful at all? There is nothing ANAME specific > here. I suggest removing this as well. > > The "which do not yet implement ANAME" is confusing at best. Resolvers > having implemented ANAME will be equally unable to
Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt
> I have concerns about the resolver replacing A/ records in signed > zones as it breaks validation. What do you mean by "the resolver" in this case? > If a resolver understanding ANAME is queried using the DO=1 flag it > shouldn't touch the A/ records, because it already knows the > requestor would through them away. It doesn't *know*. DO=1 doesn't mean the client is validating; it means the client understands RRSIG. The draft already advises that ANAME will break validation unless the validator is ANAME-aware or the auth server has access to the zone's private key and can sign responses on the fly. (This suggests to me that the use of ANAME in signed zones will probably be limited at first.) > This also means a caching resolver should store the original A/ > records (and not the ones resolved through ANAME) in the cache. Certainly. > With this change I don't think it makes sense to say "a resolver MUST > re-query", I'd use "a resolver SHOULD re-query if it didn't use ECS and > the query didn't use DO=1". I'm sorry, I'm not getting this. Please explain further, particularly with an expansion of the word "it"? > But I'd add "a resolver MUST include ANAME > RRset in respones to queries for A/". Yes, I'd been assuming it would. If I forgot to mention it in the draft, I'll fix that. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt
Is there a need to explictly modify MX and NS records, allowing them to point to an ANAME? Or is this already covered by the mandatory A or records for the ANAME ? I believe this needs to be discussed in the light of the RFC2181 wording: | The domain name used as the value of a NS resource record, or part of | the value of a MX resource record must not be an alias. Is the ANAME owner an alias? Should there be a section dealing with using an ANAME owner as a target of other RRs? This could probably be made very simple by saying that an ANAME owner is allowed wherever an A or owner is. >Only one ANAME can be defined per . An ANAME RRset >MUST NOT contain more than one resource record. Is there a technical reason for this? I can easily see usecases for multiple ANAMEs. E.g using more than one CDN provider for a given . >When an ANAME record is present at a DNS node and a query is received >by an authoritative server for type A or , the authoritative >server returns the ANAME RR in the answer section. Is this a MUST, SHOULD or "may occasionally do"? >Because not all querying resolvers understand ANAME, the >authoritative server MUST also return address records, as described >below. .. >If resolution of the ANAME yields no address records due to >NODATA or NXDOMAIN, then the authoritative server MUST return only >the ANAME record. If the query was for a specific address type, then >the response MUST also include the SOA as in a normal NODATA >response, along with NSEC or NSEC3 if applicable. Aren't these requirments conflicting? There is also an exception for DNSSEC signing failures, where the server is allowed to return only the ANAME. I guess the "as described below" can be interpreted as a condition for the MUST, but I believe the exceptions should be made clear along with the requirement. Or at least make it clear that exceptions will follow. E.g: "...MUST also return address records, except as noted below" But if A or aren't really required after all, then why pretend they are? > 3.2. Coexistence with other types > >If the zone is configured with an A or RRset at the same DNS >node as ANAME, then the ANAME is considered to have already been >expanded. If during query processing any address records are found >at the same node as an ANAME RR, then the ANAME RR MUST NOT be >further expanded by the authoritative server. > >ANAME MUST NOT coexist with CNAME or any other RR type that restricts >the types with which it can itself coexist. > >Like other types, ANAME MUST NOT exist below a DNAME, but it can >coexist at the same node; in fact, the two can be used cooperatively >to redirect both the owner name (via ANAME) and everything under it >(via DNAME). > >ANAME can freely coexist at the same owner name with any other RR >type. Is it really necessary to summarize the CNAME and DNAME rules here? AFAICS, they are generic and not modified in any way by the introduction of ANAME. Maybe include the one ANAME per RRset restriction in this section, if that is kept? > > 3.3. DNSSEC signing > >If the zone in which the ANAME resides is DNSSEC-signed, and if the >server has access to its private zone-signing key, then the A and > RRsets MUST be signed, either in advance when populating the A/ > answers for the ANAME records, or "on the fly" when responding >to a query. > >If the server does not have access to the private zone-signing key >then it MAY return unsigned address records, but this is NOT >RECOMMENDED 'NOT RECOMMENDED' is too weak here. The section conflicts with RFC4035: | For each authoritative RRset in a signed zone, there MUST be at least | one RRSIG record that meets the following requirements: |... Suggested alternative text The server MUST NOT return unsigned address records. > unless every resolver with access to the zone is known to >support ANAME (as might be the case in a split-horizon deployment >where ANAME records are only served to an internal network with its >own resolvers). I fail to see the relevance of this. You don't need an RFC to tell you what you can do on your private network. Although I guess an 'internal network with its onw resolvers' using a CDN to provide service might exist, I find this example really confusing. It looks like a bad excuse for the RFC4035 violation. Which nobody is going to care about on your 'internal network' anyway. I suggest removing this. >Validating resolvers which do not yet implement ANAME will not be >able to validate the A and responses included with an ANAME >response unless those responses are validly signed by a DNSKEY at the >apex of the zone in which the ANAME resides. Passing along the >RRSIGs associated with the original A and RRsets from the ANAME > wi
Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt
Hi! I have concerns about the resolver replacing A/ records in signed zones as it breaks validation. If a resolver understanding ANAME is queried using the DO=1 flag it shouldn't touch the A/ records, because it already knows the requestor would through them away. This also means a caching resolver should store the original A/ records (and not the ones resolved through ANAME) in the cache. With this change I don't think it makes sense to say "a resolver MUST re-query", I'd use "a resolver SHOULD re-query if it didn't use ECS and the query didn't use DO=1". But I'd add "a resolver MUST include ANAME RRset in respones to queries for A/". cheers, Stefan ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt
On Thu, Jan 25, 2018 at 11:51:30PM +, Wessels, Duane wrote: > As an example, consider an ANAME record with TTL 3600 and a corresponding > record with TTL 86400. You'd want the to expire no later than the ANAME did, because the ANAME might have been updated to point to some other name by then. > I'm suggesting its just as acceptable to return the record with TTL > counting down from 86400, but after 3600 seconds it is ejected/marked > stale/whatever from the ANAME-implementing authoritative server. > > Unbound does that with its cache-max-ttl setting. > > If you do it this way then the consumers of the data (including > ANAME-unaware clients) get to cache it for the original TTL. That's exactly what I'm trying to prevent. With an ANAME-aware resolver, the address returned by the auth is ignored, the resolver chases the answer for itself, and records are all cached with their original TTLs. The ANAME answer and the target answers expire when they should, just as with a CNAME now. In your example, the ANAME expires after 3600 seconds, so we re-query to refresh it. If it's changed, then we follow it to get a new , but if it hasn't changed, then since we already have the cached, there's no need to chase it again. But with an ANAME-unaware resolver, it asked for an address, got one, and will cache it for whatever TTL you sent it. If your ANAME has a one-hour TTL, then you wouldn't want to send a higher TTL than that; you'd just overriding the ANAME TTL. > It seems to me that ANAME gives auth servers resolver-like properties, so > why wouldn't that apply there as well? Yes, fair point. I'll try to come up with text to address this. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt
> On Jan 25, 2018, at 3:27 PM, Evan Hunt wrote: > > On Thu, Jan 25, 2018 at 10:05:24PM +, Wessels, Duane wrote: >> Why does the draft mandate initial TTL behavior? The important aspect >> would seem to be how long the data can be kept in cache, not what the >> (initial) TTL value is. As I noted in the previous message, Unbound's >> cache-max-ttl works that way and I think it has some nice properties. > > I'm not sure I understand the distinction you're making. When you first > cache something, its TTL represents the length of time that data can be > kept in the cache, and it counts down from there to zero. That's what > I meant by the initial TTL. As an example, consider an ANAME record with TTL 3600 and a corresponding record with TTL 86400. I'm suggesting its just as acceptable to return the record with TTL counting down from 86400, but after 3600 seconds it is ejected/marked stale/whatever from the ANAME-implementing authoritative server. Unbound does that with its cache-max-ttl setting. If you do it this way then the consumers of the data (including ANAME-unaware clients) get to cache it for the original TTL. > >> Also in this new text I'm not sure what to make of "intermediate and address >> records." If "and" is truly intentional in this phrase then I think >> intermediate should be better defined, or examples given. > > Suppose ANAME (TTL 3600) points to a CNAME (TTL 30) which points to a CNAME > (TTL 5) which points to an A (TTL 86400). The response would contain ANAME > with TTL 3600 and, because of the intermediate CNAME, A with TTL 5. > > Suggestions welcome for a clearer way to phrase this. I now notice that intermediate is sort of defined at the end of section 3. Perhaps that is sufficient. I guess we don't have a good collective term for CNAME/DNAME/ANAME yet. > >>> Address records with expired TTLs MUST NOT be used to answer >>> address queries until refreshed by sending a new query to the ANAME >>> . >>> >>> [...] >>> >>> If resolution of the ANAME yields no address records due to >>> some other failure, and the query was for a specific address type, >>> the response MUST include the ANAME record and set the RCODE to >>> SERVFAIL. >> >> If the authoritative server has address records, which then expire, and >> cannot be refreshed, I read this as saying the later response must be >> SERVFAIL. > > For A or queries, that is the intent. An explicit query for type ANAME > would still be answered. > >> That seems in contradiction with the ideas of draft-serve-stale which says >> "stale bread is better than no bread" and "Several major recursive resolver >> operations currently use stale data for answers in some way ... Their >> collective operational experience is that it provides significant benefit >> with minimal downside." > > This seems like a job for the resolver, not the auth server. In the long > term my hope is that resolvers will implement ANAME, chase the answers > themselves, and then decide whether to serve stale records or not. > However, I guess we can relax this requirement if the auth server is > configured for serve-stale. It seems to me that ANAME gives auth servers resolver-like properties, so why wouldn't that apply there as well? DW ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt
On Thu, Jan 25, 2018 at 10:05:24PM +, Wessels, Duane wrote: > Why does the draft mandate initial TTL behavior? The important aspect > would seem to be how long the data can be kept in cache, not what the > (initial) TTL value is. As I noted in the previous message, Unbound's > cache-max-ttl works that way and I think it has some nice properties. I'm not sure I understand the distinction you're making. When you first cache something, its TTL represents the length of time that data can be kept in the cache, and it counts down from there to zero. That's what I meant by the initial TTL. > Also in this new text I'm not sure what to make of "intermediate and address > records." If "and" is truly intentional in this phrase then I think > intermediate should be better defined, or examples given. Suppose ANAME (TTL 3600) points to a CNAME (TTL 30) which points to a CNAME (TTL 5) which points to an A (TTL 86400). The response would contain ANAME with TTL 3600 and, because of the intermediate CNAME, A with TTL 5. Suggestions welcome for a clearer way to phrase this. > >Address records with expired TTLs MUST NOT be used to answer > >address queries until refreshed by sending a new query to the ANAME > >. > > > > [...] > > > >If resolution of the ANAME yields no address records due to > >some other failure, and the query was for a specific address type, > >the response MUST include the ANAME record and set the RCODE to > >SERVFAIL. > > If the authoritative server has address records, which then expire, and > cannot be refreshed, I read this as saying the later response must be > SERVFAIL. For A or queries, that is the intent. An explicit query for type ANAME would still be answered. > That seems in contradiction with the ideas of draft-serve-stale which says > "stale bread is better than no bread" and "Several major recursive resolver > operations currently use stale data for answers in some way ... Their > collective operational experience is that it provides significant benefit > with minimal downside." This seems like a job for the resolver, not the auth server. In the long term my hope is that resolvers will implement ANAME, chase the answers themselves, and then decide whether to serve stale records or not. However, I guess we can relax this requirement if the auth server is configured for serve-stale. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt
I asked some questions about the -00 of this draft back in October which I don't think were addressed: https://mailarchive.ietf.org/arch/msg/dnsop/Pc8iGemfjO2FsNV-MNd5n6eKvUc/?qid=c250bacc5206b035878ddcb9036b9e53 I'll try to ask them again based on the current text: >The initial >TTL for locally-cached address records MUST be set to the minimum of >the ANAME TTL and the TTLs of the intermediate and address records >retrieved during ANAME <> resolution. Why does the draft mandate initial TTL behavior? The important aspect would seem to be how long the data can be kept in cache, not what the (initial) TTL value is. As I noted in the previous message, Unbound's cache-max-ttl works that way and I think it has some nice properties. Also in this new text I'm not sure what to make of "intermediate and address records." If "and" is truly intentional in this phrase then I think intermediate should be better defined, or examples given. >Address records with expired TTLs MUST NOT be used to answer >address queries until refreshed by sending a new query to the ANAME >. > > [...] > >If resolution of the ANAME yields no address records due to >some other failure, and the query was for a specific address type, >the response MUST include the ANAME record and set the RCODE to >SERVFAIL. If the authoritative server has address records, which then expire, and cannot be refreshed, I read this as saying the later response must be SERVFAIL. That seems in contradiction with the ideas of draft-serve-stale which says "stale bread is better than no bread" and "Several major recursive resolver operations currently use stale data for answers in some way ... Their collective operational experience is that it provides significant benefit with minimal downside." > In this case, the master server MUST respect the TTLs of the address records, Suggest s/master/primary/ to be consistent with previous text. DW > On Jan 11, 2018, at 9:25 PM, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the IETF. > >Title : Address-specific DNS Name Redirection (ANAME) >Authors : Evan Hunt > Peter van Dijk > Anthony Eden > Filename: draft-ietf-dnsop-aname-01.txt > Pages : 12 > Date: 2018-01-11 > > Abstract: > This document defines the "ANAME" DNS RR type, to provide similar > functionality to CNAME, but only redirects type A and queries. > Unlike CNAME, an ANAME can coexist with other record types. The > ANAME RR allows zone owners to redirect queries for apex domain names > in a standards compliant manner. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-aname-01 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-aname-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-aname-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt
Comments on the latest ANAME draft: In Section 3.1, "records retrieved during ANAME <> resolution" looks like a typo. Should "<>" be ""? Also in Section 3.1, the first five paragraphs could be more explicit about resolving and adding address records instead of specifically A and/or (other than as examples). Also in Section 3.1, the final paragraph will result in universal SERVFAIL responses if an ANAME target is in a misconfigured signed zone, even if the zone containing the ANAME is _not_ signed (and a corresponding traffic spike from ANAME-ignorant resolvers). In Section 4, "resolution fails" should be better defined. Specifically, may resolvers use server-provided records if their own query results in NODATA or NXDOMAIN? I think zone transfer considerations merit their own section, rather than being buried in and mixed with DNSSEC in 3.3. And because of those considerations, I consider it a mistake to prohibit secondary servers from resolving ANAME targets when there are address records at the same node as is required by Section 3.2. Behavior in error cases, including those stemming from ANAME-ignorant participants, seems to be much more preferable if such address records are treated as fallback data occluded during healthy operation: 1. *ANAME-ignorant primary, ANAME-aware secondary*: The secondary will have access to fallback data from the zone, but will only include it in responses when its own ANAME target resolution fails. The secondary can thus provide better answers to ANAME-ignorant clients when responses for the ANAME target are tailored. 2. *ANAME-aware primary, ANAME-ignorant secondary*: Including expanded records in the transferred zone data results in stretching ANAME TTLs and failing to update anything until secondary refresh, but /not/ including them would almost completely suppress ANAME functionality. I think the tradeoffs here need further analysis; more on that below. 3. *Address-including zone, address-lacking target*: An ALIAS-aware server will be able to locally resolve answers from the target name for address types that it has (e.g., A), while still providing nonempty answers from the zone for those it lacks (e.g., ). At least Oracle [Dyn] customers actually prefer such behavior, as I mentioned in https://www.ietf.org/mail-archive/web/dnsop/current/msg20061.html . But note that it requires authoritative servers to override NODATA responses to ANAME target resolution, changing the last two paragraphs of Section 3.1. 4. *Address-ignorant primary, address-aware secondary*: Assuming that a new address record has been defined that the primary does not know of, the secondary will be able to include locally-resolved data for it, whether or not zone data includes the new type. In cases where the zone data just hasn't been updated, this behavior is better than assuming it has been pre-expanded to an empty set. 5. *Address-aware primary, address-ignorant secondary*: Assuming that a new address record has been defined which the primary knows of but the secondary does not, the transferred zone data should include pre-expanded answers of the type so the secondary has them available for its responses (since it doesn't know to look them up on its own). This informs the question from case 2 above, but does not completely resolve it (see below). 6. And layering DNSSEC on top of the above (i.e., assuming the ANAME-containing zone is signed), *ANAME-aware secondary without a zone-signing private key*: I agree that there is no reason for a secondary to respond with data that it cannot sign, but it should still include signed (fallback) data that ANAME-aware clients will attempt to override with local resolution. But how is the XFR server to know if the XFR client can add valid signatures? Regarding zone transfers in which the secondary server is ignorant of ANAME altogether, or the inclusion of a new address type, it seems clear that primary servers capable of pre-expansion should do so. But in my mental model, there's a distinction between static in-zone fallback data and data that was resolved upstream (the latter subject to TTL decrementing and local refreshes, the former not), and ANAME-aware zone transfers should preserve the distinction even though resolution responses won't. There's also the practical matter of zone serial, which controls zone transfers but SHOULD NOT be updated by changes in non-zone data like ALIAS target answers. With all that in mind, I think ANAME will need to update the definition of AXFR and IXFR, and IXFR in particular is likely to give ANAME a hard time: @ SOA serial= ; PROBLEM 1! ; Use of an already-known serial (since static zone contents have not changed). ; This may confuse ANAME-ignorant servers into ignoring the XFR altogether. @ SOA serial= ; PROBLEM 2! ; Th
Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt
On Fri, Jan 12, 2018 at 12:25 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the > IETF. > > Title : Address-specific DNS Name Redirection (ANAME) > Authors : Evan Hunt > Peter van Dijk > Anthony Eden > Filename: draft-ietf-dnsop-aname-01.txt > Pages : 12 > Date: 2018-01-11 > > Abstract: >This document defines the "ANAME" DNS RR type, to provide similar >functionality to CNAME, but only redirects type A and queries. >Unlike CNAME, an ANAME can coexist with other record types. The >ANAME RR allows zone owners to redirect queries for apex domain names >in a standards compliant manner. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-aname-01 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-aname-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-aname-01 > > One minor typo: "AANME" once in section 5 should be "ANAME" -- Bob Harold ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
