Re: [DNSOP] Priming query transport selection

ray.bel...@nominet.org.uk wrote: > >> The text in RFC 2671, presented as a hint, could deal to similar issues >> with the TCP transport for DNS (working to change SHOULD for MUST). > > Can you elaborate on what you mean? > > I presume you're aware of my draft-ietf-dnsext-dns-tcp-requirements ?

Re: [DNSOP] Priming query transport selection

> Why would glue records be signed? That's not normal in DNSSEC, AFAIK. To correct my statement, the following query shows that glue records may be signed dig soa se @a.ns.se + dnssec wich has a response size of 2944 bytes. However, most of this is Additional Section RRSIGS, and dig soa se @

Re: [DNSOP] Priming query transport selection

- Original Message - From: "Olafur Gudmundsson" To: Sent: Wednesday, January 13, 2010 6:19 PM Subject: [DNSOP] Priming query transport selection > 26 signed glue records will require about 5K answer if each RRSet is > signed by a single 1024 bit RSA key. > This wil

Re: [DNSOP] Priming query transport selection

* Jim Reid: > On 15 Jan 2010, at 13:20, Florian Weimer wrote: > >> DO is rather pointless because the priming response cannot be >> validated anyway (even if ROOT-SERVERS.NET were secure, which is >> currently not planned). > > It's not pointless. Validating the priming response requires two > ope

Re: [DNSOP] Priming query transport selection

On 15 Jan 2010, at 13:20, Florian Weimer wrote: DO is rather pointless because the priming response cannot be validated anyway (even if ROOT-SERVERS.NET were secure, which is currently not planned). It's not pointless. Validating the priming response requires two operations. The first of the

Re: [DNSOP] Priming query transport selection

* Jim Reid: > The preferred approach might probably be along these lines: > [1] EDNS0 + DO with a buffer of 5-8K (ish) > [2] TCP + DO when [1] fails > [3] EDNS0 + DO + 1.5K (ish) buffer if [2] fails > [4] EDNS0 (no DO) with a 1.5K (ish) buffer > [5] Vanilla UDP (no ED

Re: [DNSOP] Priming query transport selection

Olafur Gudmundsson writes: > Proposed replacement text: >A priming query MUST use a QNAME of "." and a QTYPE of NS, QCLASS of IN, >with RD bit set to 0, the source port of the query should be randomly >selected [RFC5452]. >A DNSSEC aware resolver SHOULD sent the priming query over

Re: [DNSOP] Priming query transport selection

> The text in RFC 2671, presented as a hint, could deal to similar issues > with the TCP transport for DNS (working to change SHOULD for MUST). Can you elaborate on what you mean? I presume you're aware of my draft-ietf-dnsext-dns-tcp-requirements ? > From BIND ARM 9.7.0 > > ---

Re: [DNSOP] Priming query transport selection

ray.bel...@nominet.org.uk wrote: > >> EDNS0 RFC restricts EDNS0 to 4096 bytes, number of implementations >> will not send more even if client ask for it. Firewalls will >> enforce this. > > RFC 2671 enforces no such limit - the strict limit is 65535, and §4.5.5 > has a hint that 4K might be a re

Re: [DNSOP] Priming query transport selection

On 14 jan 2010, at 17.58, Patrik Fältström wrote: > On 14 jan 2010, at 10.38, ray.bel...@nominet.org.uk wrote: > >>> EDNS0 RFC restricts EDNS0 to 4096 bytes, number of implementations >>> will not send more even if client ask for it. Firewalls will >>> enforce this. >> >> RFC 2671 enforces no su

Re: [DNSOP] Priming query transport selection

On Jan 14, 2010, at 7:58 AM, Patrik Fältström wrote: > > Please do not start talking about enforcing some fixed limit that we will > laugh about 10 years from now... And if you talk about a limit, pick > something very large (like 65535 that seems to be already chosen). > > It is enough proble

Re: [DNSOP] Priming query transport selection

On Wed, Jan 13, 2010 at 09:53:16PM +, Jim Reid wrote: > On 13 Jan 2010, at 21:35, Alex Bligh wrote: > > >You've eliminated TCP fallback for non-DNSSEC supporting clients. > > So add that to the list: > [6] TCP (no EDNS0) if [5] fails. > dnssec is just the first extention to re

Re: [DNSOP] Priming query transport selection

On 14 jan 2010, at 10.38, ray.bel...@nominet.org.uk wrote: >> EDNS0 RFC restricts EDNS0 to 4096 bytes, number of implementations >> will not send more even if client ask for it. Firewalls will >> enforce this. > > RFC 2671 enforces no such limit - the strict limit is 65535, and §4.5.5 > has a hi

Re: [DNSOP] Priming query transport selection

> EDNS0 RFC restricts EDNS0 to 4096 bytes, number of implementations > will not send more even if client ask for it. Firewalls will > enforce this. RFC 2671 enforces no such limit - the strict limit is 65535, and §4.5.5 has a hint that 4K might be a reasonable amount of state to maintain for fr

Re: [DNSOP] Priming query transport selection

On Jan 13, 2010, at 2:41 PM, Olafur Gudmundsson wrote: > At 16:16 13/01/2010, Jim Reid wrote: >> On 13 Jan 2010, at 20:49, Alex Bligh wrote: >> >>> Current operational practice would result in DO clear packets >>> fitting within 4096 bytes, so no need for TCP when DO is clear. >> >> I don't thi

Re: [DNSOP] Priming query transport selection

Well having TCP used for all priming queries would make me feel better as TCP traffic is harder to forge. So let's forget about dnssec an do everything over TCP? But seriously DNSSEC signed and validated data should protect the the resolver from going to the forged addres

Re: [DNSOP] Priming query transport selection

At 16:16 13/01/2010, Jim Reid wrote: On 13 Jan 2010, at 20:49, Alex Bligh wrote: Current operational practice would result in DO clear packets fitting within 4096 bytes, so no need for TCP when DO is clear. I don't think that's always the case Alex. See the lengthy discussion in this list abo

Re: [DNSOP] Priming query transport selection

What does a DNSSEC-protected priming query gain you? I was about to ask the same question. Accepting any old priming query and having a root SEP configured, if the query is right all things work. If the query is wrong/forged you won't get anywhere any how. (Without go

Re: [DNSOP] Priming query transport selection

At 16:33 13/01/2010, Edward Lewis wrote: At 13:19 -0500 1/13/10, Olafur Gudmundsson wrote: The benefit is that a single query can retrieve the signed root NS set and all the signed glue records. I am not certain that the cost of doing TCP for this is worth the benefit of getting a signed pri

Re: [DNSOP] Priming query transport selection

On 13 Jan 2010, at 21:35, Alex Bligh wrote: You've eliminated TCP fallback for non-DNSSEC supporting clients. So add that to the list: [6] TCP (no EDNS0) if [5] fails. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listin

Re: [DNSOP] Priming query transport selection

--On 13 January 2010 21:35:48 + Alex Bligh wrote: Sure, clients should as a general rule try getting UDP to work, but I think preventing them falling back to UDP unless they are prepared ^^^ - TCP to take the overhead of adding DO set is not righ

Re: [DNSOP] Priming query transport selection

At 13:19 -0500 1/13/10, Olafur Gudmundsson wrote: The benefit is that a single query can retrieve the signed root NS set and all the signed glue records. I am not certain that the cost of doing TCP for this is worth the benefit of getting a signed priming response. I agree with section 2.4

Re: [DNSOP] Priming query transport selection

--On 13 January 2010 21:16:49 + Jim Reid wrote: On 13 Jan 2010, at 20:49, Alex Bligh wrote: Current operational practice would result in DO clear packets fitting within 4096 bytes, so no need for TCP when DO is clear. I don't think that's always the case Alex. See the lengthy discussi

Re: [DNSOP] Priming query transport selection

At 15:01 13/01/2010, Alex Bligh wrote: --On 13 January 2010 13:19:30 -0500 Olafur Gudmundsson wrote: Going forward I think this is a bad recommendation. I would like to propose that the document take the plunge of recommending that modern DNSSEC capable resolvers perform the priming query o

Re: [DNSOP] Priming query transport selection

On 13 Jan 2010, at 20:49, Alex Bligh wrote: Current operational practice would result in DO clear packets fitting within 4096 bytes, so no need for TCP when DO is clear. I don't think that's always the case Alex. See the lengthy discussion in this list about datagram fragmentation and broke

Re: [DNSOP] Priming query transport selection

I apologize for cross-posting due to topical overlap. Please confine follow-up messages to the appropriate list. In the message to DNSOP regarding draft-ietf-dnsop-resolver-priming-02 archived at , Olafur Gudmundsson scratched at

Re: [DNSOP] Priming query transport selection

--On 13 January 2010 20:34:49 + Jim Reid wrote: An EDNS0 ignorant resolver MUST issue the priming query over UDP. I presume you mean DNSSEC ignorant. That's implicit. The language was in Olafur's original text BTW... If a resolver doesn't speak EDNS0, it can't set the DO bit. Which m

Re: [DNSOP] Priming query transport selection

On 13 Jan 2010, at 20:01, Alex Bligh wrote: An EDNS0 ignorant resolver MUST issue the priming query over UDP. I presume you mean DNSSEC ignorant. That's implicit. The language was in Olafur's original text BTW... If a resolver doesn't speak EDNS0, it can't set the DO bit. Which means the

Re: [DNSOP] Priming query transport selection

--On 13 January 2010 19:19:40 + Jim Reid wrote: Priming queries from DNSSEC-ignorant resolvers An EDNS0 ignorant resolver MUST issue the priming query over UDP. I presume you mean DNSSEC ignorant. -- Alex Bligh ___ DNSOP mailing list DNSOP@i

Re: [DNSOP] Priming query transport selection

--On 13 January 2010 13:19:30 -0500 Olafur Gudmundsson wrote: Going forward I think this is a bad recommendation. I would like to propose that the document take the plunge of recommending that modern DNSSEC capable resolvers perform the priming query over TCP. ... By making this change s

Re: [DNSOP] Priming query transport selection

On 13 Jan 2010, at 18:19, Olafur Gudmundsson wrote: I would like to propose that the document take the plunge of recommending that modern DNSSEC capable resolvers perform the priming query over TCP. I'm not sure it's a good idea to encourage more TCP traffic to the root servers or make tha

[DNSOP] Priming query transport selection

Draft http://tools.ietf.org/html/draft-ietf-dnsop-resolver-priming-02 says "2.1. Parameters of a Priming Query A priming query SHOULD use a QNAME of "." and a QTYPE of NS. The priming query MUST be sent over UDP (section 6.1.3.2 of [RFC1123]). The UDP source port SHOULD be randomly se