Re: [DNSOP] I-D Action: draft-ietf-dnsop-edns-key-tag-02.txt
(speaking for myself only) In 5.1, I would think that I'd prefer a standard size, but that doesn't mean I should rely on it. For the moment on 5.3.1 . Maybe some text that "an implementer SHOULD sort their tags" but that mean that one can expect them that way. tim On Thu, Jul 14, 2016 at 10:02 PM, Paul Hoffman wrote: > On 11 Jul 2016, at 7:50, Bob Harold wrote: > > 5.1. Query Format >> What if the key tag is less than 0x1000 hex or 4096 decimal - Should the >> resulting hex have leading zeros (always 4 characters?) or not? >> For example, would 4095 decimal be _ta-0fff or _ta-fff ? (I prefer >> always >> 4 characters hex, but it is your doc.) >> > > It is a WG doc, not our doc. Do others have a preference on this? > > 5.3.1. Interaction With Aggressive Negative Caching >> I would prefer that the tags always be sorted. No big deal for two tags, >> but if there was a compromise or mistake during a rollover, there might be >> three keys and the savings in records might be significant. If you decide >> to specify sorting, I think it would go in section 5.1 and not in 5.3.1. >> > > Would the "savings in records" really be significant? The problems caused > by people not consistently sorting could make things worse, not better. > Related: there might be other reasons for three tags, such as during an > algorithm rollover. > > --Paul Hoffman > > > ___ > 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-edns-key-tag-02.txt
On 11 Jul 2016, at 7:50, Bob Harold wrote: 5.1. Query Format What if the key tag is less than 0x1000 hex or 4096 decimal - Should the resulting hex have leading zeros (always 4 characters?) or not? For example, would 4095 decimal be _ta-0fff or _ta-fff ? (I prefer always 4 characters hex, but it is your doc.) It is a WG doc, not our doc. Do others have a preference on this? 5.3.1. Interaction With Aggressive Negative Caching I would prefer that the tags always be sorted. No big deal for two tags, but if there was a compromise or mistake during a rollover, there might be three keys and the savings in records might be significant. If you decide to specify sorting, I think it would go in section 5.1 and not in 5.3.1. Would the "savings in records" really be significant? The problems caused by people not consistently sorting could make things worse, not better. Related: there might be other reasons for three tags, such as during an algorithm rollover. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] https://tools.ietf.org/html/draft-bellis-dnsext-multi-qtypes-02
On 14 July 2016 at 09:51, Ray Bellis wrote: > > > On 12/07/2016 14:35, John Dickinson wrote: > > You say that “ A caching recursive server receiving a Multiple QTYPE > > Option SHOULD attempt to fill its positive and negative caches with > > all of the specified RR types before returning its response to the > > client.” won’t this run the risk of delaying a response to the > > client? > > That's maybe a little strong - it could probably be weakened to "MAY". > I think one part of the value of this over ANY is that it is more clearly specified that you can expect to get the records you requested. If you downgrade that SHOULD to a MAY, then I think it's reasonable to add a flag for mandatory processing, so that a client can specify that it's willing to wait for a complete answer to be compiled. > > > You say a server can “omit some (or all) of the records for the > > additional RR types” in the case of truncation. Given the previous > > quote, how should a caching recursive server behave in this case? > > Query again for the missing QTYPES or switch to TCP? > > I think either would be acceptable. The server shouldn't actually set > the TC bot in those cases, so the client wouldn't be expected to > automatically failover to TCP. > This was my understanding from reading the current text. If more people feel the expected behaviour is ambiguous then perhaps we can spell that out. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DS records and validating resolvers
Einar Bjarni Halldórsson wrote: > > If there are multiple DS records in a parent, with different key tags, > where only one of the DS records has a corresponding DNSKEY record in > the child zone that correctly signs the DNSKEY RRSET, will validating > resolvers ignore the other DS records or could they cause responses from > the child to become invalid? Normally any individual DS record is sufficient to authenticate the DNSKEY RRset - the others can be ignored. However if there are DS records of multiple different algorithms then at least one DS record of each algorithm must authenticate the DNSKEY RRset. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Humber, Thames: Northwest 4 or 5, becoming variable 3 or 4, becoming southwest 4 or 5 later. Slight or moderate, occasionally smooth. Fair. Good.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DS records and validating resolvers
One DS +DNSKEY is sufficient, others are ignored as they can be for past or future keys. The only exception is when the DS records are for multiple algorithms some implementations demand that all algorithms are working Olafur On Thu, Jul 14, 2016 at 12:20 PM, Einar Bjarni Halldórsson wrote: > Hi, > > I’ve looked and could not find an answer to my question anywhere. > > If there are multiple DS records in a parent, with different key tags, > where only one of the DS records has a corresponding DNSKEY record in the > child zone that correctly signs the DNSKEY RRSET, will validating resolvers > ignore the other DS records or could they cause responses from the child to > become invalid? > > .einar > ISNIC > ___ > 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
[DNSOP] DS records and validating resolvers
Hi, I’ve looked and could not find an answer to my question anywhere. If there are multiple DS records in a parent, with different key tags, where only one of the DS records has a corresponding DNSKEY record in the child zone that correctly signs the DNSKEY RRSET, will validating resolvers ignore the other DS records or could they cause responses from the child to become invalid? .einar ISNIC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] https://tools.ietf.org/html/draft-bellis-dnsext-multi-qtypes-02
On 12/07/2016 14:35, John Dickinson wrote: > Hi, > > I think that a bit more should be said on the problem statement in > the introduction. > > I might have missed it, but what entity originates the query? Stub or > resolver? It's suitable for both. It could perhaps benefit from being spelled out more explicitly. > You say that “ A caching recursive server receiving a Multiple QTYPE > Option SHOULD attempt to fill its positive and negative caches with > all of the specified RR types before returning its response to the > client.” won’t this run the risk of delaying a response to the > client? That's maybe a little strong - it could probably be weakened to "MAY". > You say a server can “omit some (or all) of the records for the > additional RR types” in the case of truncation. Given the previous > quote, how should a caching recursive server behave in this case? > Query again for the missing QTYPES or switch to TCP? I think either would be acceptable. The server shouldn't actually set the TC bot in those cases, so the client wouldn't be expected to automatically failover to TCP. > I am also wondering how this interacts with > https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-03? I've no idea (yet) - that didn't exist when I wrote it :p Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
