headers
Mark Andrews | 1 Aug 2006 02:07

Re: comments about SRV


> Dave Crocker wrote:
> > Ed,
> > 
> > Edward Lewis wrote:
> >> At 3:29 PM -0700 7/24/06, Dave Crocker wrote:
> >>
> >>> SRV "breaks" wildcard.  Should we deprecate SRV?
> >> It's not the SRV record that breaks wildcard.
> > 
> > Right.  I didn't mean the RR broke it.
> > 
> > I meant that the *specification* for SRV includes definition of underscore
> > naming and that the use of the underscore naming convention -- defining whe
> re to
> > place the SRV RR's -- *does* cause wildcarding not to work.
> 
> Can you please explain in more detail what you mean here, and preferably
> give examples? I don't think anyone is saying there is no room to improve
> SRV, but if it's demonstrably broken then fixing it needs to move up the
> priority list, hopefully before DNSSEC N gets wide[r] deployment.

	A better description is that the expected usage pattern
	doesn't work with wildcards.  It does however work with all
	published names provided there is enough space for the
	prepended labels.

	In most cases the issues can be solved by just publishing
	the names in use rather than depending apon a wildcard to
	match.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dave Crocker | 1 Aug 2006 02:19

Re: comments about SRV


Mark Andrews wrote:
>>> I meant that the *specification* for SRV includes definition of underscore
>>> naming and that the use of the underscore naming convention -- defining whe
>> re to
>>> place the SRV RR's -- *does* cause wildcarding not to work.
>> Can you please explain in more detail what you mean here, and preferably
>> give examples? I don't think anyone is saying there is no room to improve
>> SRV, but if it's demonstrably broken then fixing it needs to move up the
>> priority list, hopefully before DNSSEC N gets wide[r] deployment.
> 
> 	A better description is that the expected usage pattern
> 	doesn't work with wildcards.  It does however work with all
> 	published names provided there is enough space for the
> 	prepended labels.

Thank you.  Yes.

That is *much* better wording for what I meant.

d/
--

-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Vixie | 1 Aug 2006 08:30

respsize-04 has landed in the repo

see here:

http://tools.ietf.org/wg/dnsop/draft-ietf-dnsop-respsize/draft-ietf-dnsop-respsize-04.txt

i'll say again, this deserves a re-read, since it's almost a re-write vs. -03.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
Permalink | Reply | 4 comments |
headers
Robert Story | 1 Aug 2006 19:07

Re: respsize-04 has landed in the repo

On 01 Aug 2006 06:30:02 +0000 Paul wrote:
PV> http://tools.ietf.org/wg/dnsop/draft-ietf-dnsop-respsize/draft-ietf-dnsop-respsize-04.txt

A few comments..

- The abstract states that this document explains the issues, but it
goes beyond that. I suggest :

      ...
      document explains the operational issues caused by, or related to
      this response size limit [and suggests ways to best use the
      limited space available in response packets.]

- What's the significance of the XXX before 4.4?

- Isn't source code usually included in an appendix, as opposed to the
body of the document?

--

-- 
Robert Story
SPARTA
Permalink | Reply | 0 comments |
headers
Joe Abley | 1 Aug 2006 21:37

Re: respsize-04 has landed in the repo


On 1-Aug-2006, at 02:30, Paul Vixie wrote:

> i'll say again, this deserves a re-read, since it's almost a re- 
> write vs. -03.

Comments interspersed with text, below.

Apologies in advance for being an amateur grammarian. People with  
real linguistic training should feel free to smack me down with  
prejudice.

Is it the intention that this draft ultimately be published in the  
BCP series?

>                                     Abstract
>
>       With a mandated default minimum maximum message size of 512  
> octets,
>       the DNS protocol presents some special problems for zones  
> wishing to
>       expose a moderate or high number of authority servers (NS  
> RRs).  This
>       document explains the operational issues caused by, or  
> related to
>       this response size limit.

... and gives guidance to zone administrators and implementers of DNS  
software? (The former with respect to choosing an appropriate NS set  
for a zone; the latter with respect to the additional section
(Continue reading)

Permalink | Reply | 2 comments |
headers
Joe Abley | 1 Aug 2006 21:49

Re: respsize-04 has landed in the repo


On 1-Aug-2006, at 15:37, Joe Abley wrote:

>>   2.14. An delegation response should prioritize glue records as  
>> follows.
>
> So, this part here seems like guidance to implementers. Perhaps it  
> would be worth isolating the guidance to implementers and that to  
> zone administrators, and to label them accordingly?

Oh, and "A delegation", not "an delegation".

Joe

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
Permalink | Reply | 0 comments |
headers
Robert Story | 2 Aug 2006 00:02

Re: respsize-04 has landed in the repo

On Tue, 1 Aug 2006 15:37:01 -0400 Joe wrote:
JA> >    2.14. An delegation response should prioritize glue records as  
JA> > follows.
JA> 
JA> So, this part here seems like guidance to implementers. Perhaps it  
JA> would be worth isolating the guidance to implementers and that to  
JA> zone administrators, and to label them accordingly?

I had that same thought...

--

-- 
Robert Story
SPARTA
Permalink | Reply | 0 comments |
headers
Geoff Huston | 2 Aug 2006 00:58
Favicon

draft-huston-6to4-reverse-dns-06.txt submitted

As a followup to the DNSOP Last Call on the -05 version of this 
document in March, this -06 version of the document has been revised 
to include comments received from the security directorate review as 
well as review comments received in the last call process

As noted in the DNSOP WG meeting at IETF 66, with the submission of 
this -06 version of the document I believe the document is now ready 
for a PROTO writeup and submission to the IESG as an Informational RFC.

Thanks,

     Geoff

----------------------------------

A New Internet-Draft is available from the on-line Internet-Drafts directories.

         Title           : 6to4 Reverse DNS Delegation Specification
         Author(s)       : G. Huston
         Filename        : draft-huston-6to4-reverse-dns-06.txt
         Pages           : 10
         Date            : 2006-8-1
This memo describes the service mechanism for entering a delegation
of DNS servers which provide reverse lookup of 6to4 IPv6 addresses
into the 6to4 reverse zone file.  The proposed mechanism is based on
a conventional DNS delegation service interface, allowing the service
client to enter the details of a number of DNS servers for the
delegated domain.  In the context of a 6to4 reverse delegation, the
client is primarily authenticated by its source address used in the
delegation request, and is authorised to use the function if its IPv6
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Andrews | 2 Aug 2006 03:31

Re: I-D ACTION:draft-ietf-dnsop-respsize-04.txt


	Section 2.  Delegation Details

	The answer section may contain a optional CNAME/DNAME chain.

	2.2

	TC is set if the answer and authority sections exceed the
	message size less the reserved space for TSIG and / or EDNS 
	responses. 

	2.6.

	The presentation length can be up to 1004 (250*4+4) characters
	as there are minimum of 5 labels in a maximum length domain
	name. This leaves 250 non label start octets which each can
	take 4 presentation character (\DDD), 3 inter-label periods
	and a optional final period to distingish between relative
	and absolute names.

	The network length maximum is 255 not 256.

	The worst case question section is 259 octets.

	2.11

	A NS RR adds at 12 octets (name(2), type, class, ttl, rdlen)
	+ NSDNAME (minimum 2, max 255).  Assuming in zone nameservers
	the that do not match the zone's name you get 16 for [a-z].<zone>.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Pekka Savola | 2 Aug 2006 07:34
Picon

Re: I-D ACTION:draft-ietf-dnsop-respsize-04.txt

On Wed, 2 Aug 2006, Mark Andrews wrote:
> 	2.14
>
> 	First should be all glue which matches the <QNAME,QTYPE>.
> 	TC should be signaled if this can't be added.
>
> 	This allows a resolver to query for missing glue from a
> 	previous referral and get it by forcing a TCP query.

In this context, it might be good to take a reminder look at Appendix 
B of RFC 4472, which discusses additional data, what should be 
included and what not, and what actually happens with implementations 
in some length.

--

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
Permalink | Reply | 1 comment |

Gmane