headers
Olaf Kolkman | 1 Mar 2004 08:35
Picon
Favicon

DNSEXT list policy


- List Purpose

  namedroppers <at> ops.ietf.org is the mailing list for the IETF DNSEXT
  working group.  

  See <http://www.ietf.org/html.charters/dnsext-charter.html> for the
  wg charter.  Messages should be on topics appropriate to the dnsext
  wg, which are various discussion of the DNS protocols or
  administrivia of the WG itself.

- Specific items that are not not appropriate for posting

  Calls for papers, announcements of events not directly relevant to
  the DNS protocols, etc. are not appropriate.  

  Discussion of problems with particular implementations,
  announcements of releases, sites' misconfigurations, pleas for help
  with specific implementations, etc.  should be done on mailing lists
  for the particular implementations.

  There is a working group for dns operational practice, DNSOP, whose
  charter can be found at
  <http://www.ietf.org/html.charters/dnsop-charter.html>. Items
  relevant to the DNSOP charter are to be discussed on the DNSOP
  mailinglist.

  Discussion about the quality of implementations is outside the scope
  of this list.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Derek Atkins | 2 Mar 2004 06:24
Favicon

Re: LLMNR and Rendezvous TTL disagreement, a modest proposal

Andras Salamon <andras <at> dns.net> writes:

> On Thu, Feb 26, 2004 at 12:56:46AM -0800, Bernard Aboba wrote:
>> If there is to be a "compromise" I believe that it should be
>> to set TTL=255 on responses and (optionally) check on the sender, while
>> *always* setting TTL=1 on queries.
>
> Sounds reasonable to me.

But now you're open to smurf attacks, where I send a LLMNR request to
a responder, setting YOUR ip address as the source, and setting the
TTL to make sure the packet arrives "properly".  Or do we just not
care about this?

I can make sure you send the packet, and with TTL=255 the response
will always make it back to the "sender" (which is YOUR ip address in
this case).

So, what is the threat(s) we're trying to solve?  In particular, what
threat does TTL=255 on responses actually solve?

-derek

--

-- 
       Derek Atkins                 617-623-3745
       derek <at> ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jakob Schlyter | 3 Mar 2004 12:08
Picon

draft-ietf-dnsext-nsec-rdata-04

I've just submitted an updated version of this draft to the drafts editor.
For those who want to read it now, you can find a copy (and a diff against
-03) at the following location:

http://www.rfc.se/~jakob/ietf/draft-ietf-dnsext-nsec-rdata-04.txt
http://www.rfc.se/~jakob/ietf/draft-ietf-dnsext-nsec-rdata-04.wdiff

	jakob

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Permalink | Reply | 0 comments |
headers
Scott Rose | 4 Mar 2004 14:37
Favicon

comment on NSEC RDATA format draft -04

Just one minor comment on draft-ietf-dnsext-nsec-data-04 Section 2.  The
text states that there are no special TTL requirements for the NSEC RR.
However, in the new DNSSECbis specs, we have the following suggestion for
TTL values (records draft-07):

   The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
   field. This is in the spirit of negative caching [RFC2308].

Minor difference since the above is a suggestion, and there are no real
special requirements for the TTL.  I think the NSEC data draft should
include the above for consistancy.

Scott

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Permalink | Reply | 1 comment |
headers
Barry Desborough | 6 Mar 2004 15:03
Picon

DNS SRV Clarification sought


Hello, being new to rfc2782, I have a number of questions.
I would be grateful for any enlightenment anyone could provide.

Regards

Barry Desborough
Barry.Desborough <at> wanadoo.fr

SRV RR FORMAT

From rfc2782 page 2

"The format of the SRV RR

   Here is the format of the SRV RR, whose DNS type code is 33:

        _Service._Proto.Name TTL Class SRV Priority Weight Port Target"

But rfc1035 page 29 describes the generic RR header as being

        NAME TYPE CLASS TTL RDLENGTH RDATA

According to 1035, and assuming that 'SRV' refers to TYPE,
(not specified in 2782), it seems that the SRV RR should be

        _Service._Proto.Name SRV Class TTL RDLENGTH 
            Priority Weight Port Target

where   _Service._Proto.Name corresponds to NAME
(Continue reading)

Permalink | Reply | 8 comments |
headers
bill | 6 Mar 2004 15:57

Re: comment on NSEC RDATA format draft -04

> 
> Just one minor comment on draft-ietf-dnsext-nsec-data-04 Section 2.  The
> text states that there are no special TTL requirements for the NSEC RR.
> However, in the new DNSSECbis specs, we have the following suggestion for
> TTL values (records draft-07):
> 
>    The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
>    field. This is in the spirit of negative caching [RFC2308].
> 
> Minor difference since the above is a suggestion, and there are no real
> special requirements for the TTL.  I think the NSEC data draft should
> include the above for consistancy.
> 
> Scott

	ack.  this is a reasonable thing to do.

--bill

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Permalink | Reply | 0 comments |
headers
Greg Hudson | 6 Mar 2004 16:31
Picon
Favicon

Re: DNS SRV Clarification sought

On Sat, 2004-03-06 at 09:03, Barry Desborough wrote:
> From page 3 of rfc2782
>         Compute the sum of the weights of those RRs, and with each RR
>         associate the running sum in the selected order. Then choose a
>         uniform random number between 0 and the sum computed
>         (inclusive)

> Random number case 0 1 2 3
> 1st contact                 1 1 2 2
> 2nd contact                2 2 1 1

You appear to be computing a random integer, rather than a random real
number, as was intended.  If you choose a random real number, you'll get
the appropriate distribution (a server with weight 2 is chosen twice as
often with a server of weight 1).

I would have much preferred a statement which used random integers
(which is something you can actually do on a computer), but the working
group was having a little trouble coming up with an algorithm statement
that actually worked, so we decided to go with one which we strongly
believed was correct even if it wasn't very clear and which didn't
translate easily into code.

It's particularly galling to me that we didn't even state explicitly
what kind of number is to be chosen (integer, rational, computable,
real, complex...), and then we threw in this parenthetical note
"(inclusive)" which actually has no effect on the outcome if real
numbers are being chosen.

> If what is meant by 1st contact is the 1st successful attempt to
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andras Salamon | 6 Mar 2004 18:08

Re: DNS SRV Clarification sought

On Sat, Mar 06, 2004 at 03:03:22PM +0100, Barry Desborough wrote:
>    Here is the format of the SRV RR, whose DNS type code is 33:
>         _Service._Proto.Name TTL Class SRV Priority Weight Port Target"
> 
> But rfc1035 page 29 describes the generic RR header as being
>         NAME TYPE CLASS TTL RDLENGTH RDATA

RFC1035 deals with the on-the-wire encoding, while the SRV text
above seems to be related to the usual BIND-style zone file format.
The examples in RFC 2782 bear this out.  However, re-reading RFC 2782
and RFC 2052, I could not determine a definitive on-the-wire encoding
of SRV records -- this seems to be undefined.  Presumably, implementors
have just looked at how BIND returns SRV records and gone with that.

> According to 1035, and assuming that 'SRV' refers to TYPE,
> (not specified in 2782),

The section "Usage rules" mentions QTYPE=SRV, and there is further text
    the SRV RR, whose DNS type code is 33
and
    The IANA has assigned RR type value 33 to the SRV RR
which seems to tie SRV to TYPE, although perhaps not very directly.

> Q5) Does anyone have any DNS SRV sniffer trace they could send
> directly to me to throw more light on the message format?

I tried to find an online deployment of SRV records to feed to tcpdump,
but the closest I came was an SOA record for _tcp.microsoft.com (one of
the authors of RFC 2782 was at Microsoft).  Neither vix.com or troll.no
appear to have _tcp subdomains.  Does anyone actually have a deployment
(Continue reading)

Permalink | Reply | 5 comments |
headers
Greg Hudson | 6 Mar 2004 18:29
Picon
Favicon

Re: DNS SRV Clarification sought

On Sat, 2004-03-06 at 12:08, Andras Salamon wrote:
> I tried to find an online deployment of SRV records to feed to tcpdump,
> but the closest I came was an SOA record for _tcp.microsoft.com (one of
> the authors of RFC 2782 was at Microsoft).  Neither vix.com or troll.no
> appear to have _tcp subdomains.  Does anyone actually have a deployment
> of SRV outside pseudo-DNS dynamic zones tied to DHCP servers?

We appear to have:

_sip._tcp.mit.edu
_sip._udp.mit.edu
_sip._tcp.sipxchange.mit.edu
_sip._udp.sipxchange.mit.edu
_kerberos._udp.athena.mit.edu
_kerberos-master._udp.athena.mit.edu
_kerberos-adm._tcp.athena.mit.edu

--
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Permalink | Reply | 1 comment |
headers
Paul Vixie | 6 Mar 2004 19:37

Re: DNS SRV Clarification sought

> From rfc2782 page 2
> 
> "The format of the SRV RR
> 
>    Here is the format of the SRV RR, whose DNS type code is 33:
> 
>         _Service._Proto.Name TTL Class SRV Priority Weight Port Target"
> 
> But rfc1035 page 29 describes the generic RR header as being
> 
>         NAME TYPE CLASS TTL RDLENGTH RDATA
> ...
> Q1) Which rfc is correct?

both.  rdlength is a protocol element describing rdata.  the <rdlength,rdata>
tuple is used to represent the rr data, which in this case is itself a tuple:
<Priority,Weight,Port,Target>.  in "dns master file" format as entered into
zone files and as displayed by utilities such as "dig", rdlength is used to
encode and decode the rr data but is never specified or displayed directly.

> Q2) Why is _Service._Proto.Name repeated in the query _and_ in the SRV RR?
> Could not the contents of Target have been be reported in the NAME field 
> and the Target field be dispensed with?

because the names of the servers capable of responding to requests may not
have names equal or similar to the name of the service.  this is analagous
to MX records, where the target name can be a service provider even though
the query name is that of a customer.

> ...
(Continue reading)

Permalink | Reply | 0 comments |

Gmane