Sean Wells | 1 Aug 02:51 2011
Picon

DNSSEC Response caching

Hi,


In RFC 4035, section 4.5, Response Caching:

A security-aware resolver SHOULD cache each response as a single atomic entry containing the entire answer, including the named RRset and any associated DNSSEC RRs. The resolver SHOULD discard the entire atomic entry when any of the RRs contained in it expire.

DNSSEC  RRs here includes NSECs also. For example, when processing a wildcard answer response, NSEC also should be taken into consideration when determining the TTL of the "atomic" entry. In section 5.3.3, the discussion about setting the TTL does not explicitly mention this case (or other cases where the response contains NSEC). I guess this is just a trivial omission. Can someone clarify ?

-regards 
Sean
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext
weiler | 4 Aug 15:52 2011

Re: dnssec-bis-updates and the CD bit (fwd)

[I sent this to namedroppers by mistake, having just hit "reply all" and 
not checked the headers closely enough.  Some of you will see it as a 
duplicate.]

On Mon, 1 Nov 2010, Florian Weimer wrote:

> Anyway, I have no problems with the text as-is (in -11, don't know if
> that's current).  Note however that the more or less explicit
> recommendation to set CD by default has security implications: you no
> longer profit from more stringent validation at an upstream validator.
> This should be mentioned in the Security Considerations.

I missed this when preparing -13.  I'm submitting a new version now that 
incorporates this suggestion.

> I think this is a very minor issue because even with the CD fixes, the
> protocol more or less requires that your forwarder has a superset of
> your own trust anchors.  Therefore, the situation that the forwarders
> perform more stringent checks is not a relevant scenario.

I don't understond why a forwarder must have "a superset of your own trust 
anchors", but I don't think that understanding is key to the point in the first 
paragraph I quoted above.

-- Sam
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Ray Bellis | 5 Aug 15:55 2011
Picon

dnssec-bis-updates - EDNS buffer size in responses

I'm bouncing this here at Peter Koch's request, following discussion on the DNSSEC Deployment List that
was prompted by the observation that the responses from Google's recursive service contain an EDNS
buffer size indication of 512 bytes.

Currently, RFC 4035, §3 says:

" A security-aware name server MUST support the EDNS0 ([RFC2671])
  message size extension, MUST support a message size of at least 1220
  octets, and SHOULD support a message size of 4000 octets."

However the response buffer size indicates the receive buffer size of the _server_, i.e. how big a _query_
it can receive.

There's no need for the EDNS buffer size supplied in the _response_ to adhere to this recommended minimum.

So far as I can see DNSSEC makes no difference to the size of requests, except for the overhead of the OPT RR
itself, and that's moot since without that RR there's no buffer size indication anyway.

Ray

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Edward Lewis | 5 Aug 16:25 2011

Re: dnssec-bis-updates - EDNS buffer size in responses

1) OPT RR is not unique to DNSSEC.  (I'm just stating the obvious.)

2) *MUST support* a message size of X doesn't 
mean it has to say that (X) in the EDNS0 buffer 
size.

The word "support" is way too fuzzy to be 
included in a requirement.  I'm not sure that 
specifying a value less than 1220 is a violation 
if the server could do 1220 "if it wanted to".

3) Does the 512 value in the Google server 
response cause a demonstrable operational 
problem?  (I.e., or is the issue just that this 
situation seems to be a violation of the written 
specification?)

At 13:55 +0000 8/5/11, Ray Bellis wrote:
>I'm bouncing this here at Peter Koch's request, 
>following discussion on the DNSSEC Deployment 
>List that was prompted by the observation that 
>the responses from Google's recursive service 
>contain an EDNS buffer size indication of 512 
>bytes.
>
>Currently, RFC 4035, §3 says:
>
>" A security-aware name server MUST support the EDNS0 ([RFC2671])
>   message size extension, MUST support a message size of at least 1220
>   octets, and SHOULD support a message size of 4000 octets."
>
>However the response buffer size indicates the 
>receive buffer size of the _server_, i.e. how 
>big a _query_ it can receive.
>
>There's no need for the EDNS buffer size 
>supplied in the _response_ to adhere to this 
>recommended minimum.
>
>So far as I can see DNSSEC makes no difference 
>to the size of requests, except for the overhead 
>of the OPT RR itself, and that's moot since 
>without that RR there's no buffer size 
>indication anyway.
>
>Ray
>
>_______________________________________________
>dnsext mailing list
>dnsext <at> ietf.org
>https://www.ietf.org/mailman/listinfo/dnsext

--

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

I'm overly entertained.
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Mark Andrews | 5 Aug 16:42 2011

Re: dnssec-bis-updates - EDNS buffer size in responses


In message <98B08575-2259-40DD-864A-BA57F498BEEE <at> nominet.org.uk>, Ray Bellis wr
ites:
> I'm bouncing this here at Peter Koch's request, following discussion on the
> DNSSEC Deployment List that was prompted by the observation that the respo
> nses from Google's recursive service contain an EDNS buffer size indication
>  of 512 bytes.
> 
> Currently, RFC 4035, =A73 says:
> 
> " A security-aware name server MUST support the EDNS0 ([RFC2671])
>   message size extension, MUST support a message size of at least 1220
>   octets, and SHOULD support a message size of 4000 octets."
> 
> However the response buffer size indicates the receive buffer size of the _
> server_, i.e. how big a _query_ it can receive.
> 
> There's no need for the EDNS buffer size supplied in the _response_ to adhe
> re to this recommended minimum.
> 
> So far as I can see DNSSEC makes no difference to the size of requests, exc
> ept for the overhead of the OPT RR itself, and that's moot since without th
> at RR there's no buffer size indication anyway.
> 
> Ray

Just because you see a value less than 1220, it doesn't mean that you are
not 100% compliant with this code.  In the thread this came from there
was evidence that the nameservers in question *do* support EDNS at the
required size.

"support" does not mean "will always emit".  These is no MUST NOT emit
EDNS queries/responses with a EDNS UDP size less that 1220.

Mark
--

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka <at> isc.org
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Ray Bellis | 5 Aug 18:34 2011
Picon

Re: dnssec-bis-updates - EDNS buffer size in responses

> The word "support" is way too fuzzy to be
> included in a requirement. 

[see below]

>  I'm not sure that
> specifying a value less than 1220 is a violation
> if the server could do 1220 "if it wanted to".

I don't think I want to go there.

> 3) Does the 512 value in the Google server
> response cause a demonstrable operational
> problem?  (I.e., or is the issue just that this
> situation seems to be a violation of the written
> specification?)

The latter.  It was suggested (not by me) that _responding_ with a value of 512 was "dodgy" because it
violates the 1220 value from RFC 4035.

My argument is that this value is mostly irrelevant in responses, in so much as it relates to the server's
_inbound_ buffer size for UDP requests.

PK suggested that the wording might be clarified in dnssec-bis-updates.

I'd suggest that "support" is actually fine in context - it's just that it's being interpreted too widely to
apply both to responses and requests.  2671-bis is relatively clear on the difference.

Ray

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Peter Koch | 8 Aug 13:37 2011
Picon

Re: dnssec-bis-updates - EDNS buffer size in responses

On Fri, Aug 05, 2011 at 10:25:22AM -0400, Edward Lewis wrote:

> 2) *MUST support* a message size of X doesn't 
> mean it has to say that (X) in the EDNS0 buffer 
> size.
> 
> The word "support" is way too fuzzy to be 
> included in a requirement.  I'm not sure that 
> specifying a value less than 1220 is a violation 
> if the server could do 1220 "if it wanted to".

this comes close to the point that lead to the suggestion to
continue the discussion in this venue.  "support"
isn't clear enough about the direction and there's
little benefit yet if an authoritative server or
a recursive server on the client facing side would be
able to handle larger packets than 512 payload.
The DNSSEC specification demands that a DO be sent back
in the response, thus an EDNS OPT RR has to be present and
therefore a payload size value must be chosen anyway.

There's little point in understatement here, either.

So, the potential clarification would emphasize that
"support" means 'generating or handling responses'
in section 3 of RFC 4035.

> 3) Does the 512 value in the Google server 
> response cause a demonstrable operational 
> problem?  (I.e., or is the issue just that this 
> situation seems to be a violation of the written 
> specification?)

Probably not in this case, but DNS Dynamic Update messages
might change the picture.

-Peter
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Ralph Droms | 12 Aug 23:35 2011
Picon

A6 to Historic

There has been a discussion on the 6man mailing list about moving A6 records to Historic.  I'd like to get
input from dnsext about the re-designation.

ipv6 <at> ietf.org is bcc:ed; please reply to dnsext.

Thanks

- Ralph

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Mykyta Yevstifeyev | 13 Aug 10:54 2011
Picon

RFC 6195, IANA and HINFO DNS RRs

Hello all,

Looking through IANA MOA (http://www.iana.org/protocols/), I've noticed 
two interesting registries: "Machine Names" and "OS Names".  For the 
first, no reference was defined, neither was the assignment policy.  The 
second listed RFC 952 as reference and FCFS (see RFC 5226) as assignment 
policy spelled out there, even though RFC 952 says nothing about 
assigning OS names and pointed to RFC 943, "Assigned Numbers".  These 
two registries were grandfathered from this series of RFCs called 
"Assigned Numbers"; however, I've recalled that there is HINFO DNS RR 
which seemed to use similar parameters.

Having looked through RFC 6195, "DNS IANA Considerations", I found 
absolutely nothing which would clarify the situation with these two 
parameters.  Section 3.3.2 of RFC 1035, though, says:

> 3.3.2. HINFO RDATA format
>
>      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>      /                      CPU                      /
>      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>      /                       OS                      /
>      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>
> where:
>
> CPU             A<character-string>  which specifies the CPU type.
>
> OS              A<character-string>  which specifies the operating
>                  system type.
>
> Standard values for CPU and OS can be found in [RFC-1010].
>
> HINFO records are used to acquire general information about a host.  The
> main use is for protocols such as FTP that can use special procedures
> when talking between machines or operating systems of the same type.

RFC 1010 actually contained the list of then-assigned parameters, 
pointing to RFC 810 (which had been updated by RFC 952 and also used 
these two parameters).

These two registries are still being quite obscure, you may see; so what 
I propose is to formalize the procedures for assigning the 2 identifiers 
in context of DNS HINFO resource records, writing the document updating 
RFC 6195 and 952.  So any thoughts on this?

Mykyta Yevstifeyev
_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

Jim Reid | 13 Aug 12:27 2011

Re: RFC 6195, IANA and HINFO DNS RRs

On 13 Aug 2011, at 09:54, Mykyta Yevstifeyev wrote:

> These two registries are still being quite obscure, you may see; so  
> what I propose is to formalize the procedures for assigning the 2  
> identifiers in context of DNS HINFO resource records, writing the  
> document updating RFC 6195 and 952.  So any thoughts on this?

Don't bother. HINFO is essentially dead. Pretty much nothing uses it.  
I doubt any software queries for HINFO records. Few zones, if any,  
publish them.

A couple of <character string>s form the RDATA for HINFO. These  
strings don't need or deserve a registry. It simply doesn't matter  
what goes into these strings provided they comply with the wire  
protocol. I am struggling to see why such a registry could be needed  
or why some application would want to care enough to check the result  
of an HINFO lookup against a list of formally registered strings.

RFC1700 was the last reference to a list of names for HINFO records.  
[Interestingly, it imposes limitations on character set and length of  
the names that do not apply to DNS <character-string>s.] That 17 year  
old list contains a remarkable list of long-dead platforms: Gould,  
Pyramid, DEC, Tops-10, SunOS, Multics, etc. I suppose that graveyard  
might have some historical curiosity. Bringing it up to date and  
maintaining it seems pointless though.

What's the use case that's provoked your interest in DNS archeology?

_______________________________________________
dnsext mailing list
dnsext <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsext


Gmane