Subject: Re: [dane] Draft for serializing DNSSEC chains

From: "Osterweil, Eric" <[email-masked]>
Date: Wed, 06 Jul 2011 10:43:49 -0400

Have you guys looked at libvdns (specifically the dns_srv.h file)?

    http://vantage-points.org/libvdns.html

Eric

On 6/29/11 9:01 PM, "Phillip Hallam-Baker" <[email-masked]> wrote:

> Yes, but you try calling them from managed code and the results are going to
> be less than pretty.
> 
> All I am saying is that there is probably a reason that very few applications
> seem to be making use of features like SRV and I don't think it is a problem
> with the ideas, its in the deployment.
> 
> 
> 
> 
> On Wed, Jun 29, 2011 at 7:54 PM, Mark Andrews <[email-masked]> wrote:
>> 
>> In message <[email-masked]>, Phillip
>> Hallam-
>> Baker writes:
>>>> 
>>>> The concepts are independent, the code most certainly is not.
>>>> 
>>>> This is why I have spent the past few weeks writing a DNS resolver in C# to
>>>> hopefully render the issue moot.
>>>> 
>>>> 
>>>> While you can call unmanaged code from a managed environment like C#, the
>>>> means of doing so is not at all pretty. And making the result threadsafe is
>>>> a nightmare. It is in fact much easier to recode from scratch than to use
>>>> the existing stuff.
>> 
>> There are already plenty of thread safe resolver libraries.  Which
>> can perform queries in parallel.  They can even be talking to
>> different sets of recursive servers if you want.  libresolv was
>> made thread safe in 1900's and no it was not a giant lock.
>> 
>>>> Calling a math function or a crypto algorithm is one thing, but a DNS
>>>> library is by its very nature asynchronous and it is possible to have
>>>> multiple queries in flight at the same time. I suspect that a lot of the
>>>> objections to using DNS for more sophisticated discovery come from the lack
>>>> of decent DNS library support in modern programming languages.
>>>> 
>>>> It is easy enough to support an API like this with blocking code:
>>>> 
>>>>     EDNS.Client resolver = new EDNS.Client ();
>>>> 
>>>>     EDNS.DNSMessage Response;
>>>>     int result = resolver.Resolve (Domain, EDNS.DNSType.CAA, out Response);
>>>> 
>>>> 
>>>> But most of us would like to have multiple queries in parallel:
>>>> 
>>>>             DNSClient Client = new DNSClient ();
>>>> 
>>>>             // Non blocking request
>>>>             DNSMessage Request = new DNSQueryMessage (Domain,
>>> EDNS.DNSType.A
>>>> );
>>>>             DNSTransaction Transaction1 = Client.Send (Request);
>>>> 
>>>>             DNSMessage Request = new DNSQueryMessage
>>>> (Domain, EDNS.DNSType.CAA);
>>>>             DNSTransaction Transaction2 = Client.Send (Request);
>>>> 
>>>>             // Does other useful stuff like create the message headers
>>>>             // Can poll status of transactions using
>>> DNSTransaction.Complete
>>>> ()
>>>> 
>>>>             Response = Client.Receive (Transaction1);
>>>>             Response = Client.Receive (Transaction2);
>>>> 
>>>> 
>>>> And that is still much less than you would want a .NET library to provide.
>>>> A
>>>> proper .NET library should let the caller loop things into the asynchronous
>>>> caller.
>>>> 
>>>> Ultimately, the goal is to produce a subclass of the TcpClient class such
>>>> that the only difference that the programmer needs to consider is to
>>> replace
>>>> the creation method:
>>>> 
>>>> public TcpClient(string hostname, int port)
>>>> 
>>>> 
>>>> with the creation method:
>>>> 
>>>> public InternetClient(string hostname, string service, int port)
>>>> 
>>>> 
>>>> 
>>>> The difference here is the level of abstraction. TcpClient connects via
>>>> hostname and port and always returns a raw bytestream. InternetClient uses
>>>> the DNS to determine what the best connection that is available for a
>>>> service. If the best connection is raw TCP it will return that, if it can
>>>> form an SSL socket, it will return that.
>>>> 
>>>> [Yes, I know that there is also the question of how to specify 'best', but
>>>> that is something that is more usually something you want to specify at the
>>>> host level or higher and want to avoid embedding in actual applications]
>>>> 
>>>> This actually has a major performance advantage in the right hands because
>>>> the implementation can also be asynchronous. So in the typical calling
>>>> sequence we would have:
>>>> 
>>>> // Create the socket
>>>> // Generate the message headers
>>>> // Check the socket is OK
>>>> // Send the first byte
>>>> 
>>>> In terms of timing what would be going on is:
>>>> 
>>>> // Create the socket
>>>>   [Async socket establishment starts]
>>>> // Generate the message headers
>>>>   [Wait for the socket to be completed]
>>>> // Check the socket is OK
>>>> // Send the first byte
>>>> 
>>>> 
>>>> Now in my preferred programming language, you could just throw up a PAR
>>>> statement and it would work anyway, but very few programmers grok that sort
>>>> of stuff.
>> 
>> And this has gone very far from the original issue of handling unknown types.
>> 
>>>> On Wed, Jun 29, 2011 at 2:21 AM, Mark Andrews <[email-masked]> wrote:
>>>> 
>>>>>> 
>>>>>> In message <[email-masked]
>>>> <mailto:[email-masked]> >, Phillip
>>>>>> Hallam-
>>>>>> Baker writes:
>>>>>>>> I guess that would work for the application programmers who still >>>>
>>>>>>>> code in
>>>>>> C
>>>>>>>> or C++. That is not where the industry has been for a decade now.
>>>>>> 
>>>>>> The concepts are language independent.
>>>>>> 
>>>>>> --
>>>>>> Mark Andrews, ISC
>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>>>>> PHONE: +61 2 9871 4742 <tel:%2B61%202%209871%204742>                 
>>>> INTERNET: [email-masked]
>>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Website: http://hallambaker.com/
>>>> 
>>>> --0016e68debd4b5f20c04a6db8b0b
>>>> Content-Type: text/html; charset=ISO-8859-1
>>>> Content-Transfer-Encoding: quoted-printable
>>>> 
>>>> The concepts are independent, the code most certainly is
>>> not.<div><br></div=
>>>>>> <div>This is why I have spent the past few weeks writing a DNS resolver
>>>>>> >>> in=
>>>>  C# to hopefully render the issue moot.</div><div><br></div><div><br></div>
>>>> <div>While you can call unmanaged code from a managed environment like C#,
>>>> =
>>>> the means of doing so is not at all pretty. And making the result
>>> threadsaf=
>>>> e is a nightmare. It is in fact much easier to recode from scratch than to
>>>> =
>>>> use the existing stuff.</div>
>>>> <div><br></div><div>Calling a math function or a crypto algorithm is one >>
>>>> th=
>>>> ing, but a DNS library is by its very nature asynchronous and it is
>>> possibl=
>>>> e to have multiple queries in flight at the same time. I suspect that a
>>> lot=
>>>>  of the objections to using DNS for more sophisticated discovery come from
>>>> =
>>>> the lack of decent DNS library support in modern programming
>>> languages.</di=
>>>> v>
>>>> <div><br></div><div><br></div><div>It is easy enough to support an API
>>> like=
>>>>  this with blocking code:</div><div><br></div><div><div>=A0 =A0
>>> EDNS.Client=
>>>>  resolver =3D new EDNS.Client ();</div><div><br></div><div>=A0 =A0
>>> EDNS.DNS=
>>>> Message Response;</div>
>>>> <div>=A0 =A0 int result =3D resolver.Resolve (Domain, EDNS.DNSType.CAA,
>>> out=
>>>>  Response);</div><div><br></div></div><div><br></div><div>But most of us >>
>>>> wo=
>>>> uld like to have multiple queries in
>>> parallel:</div><div><br></div><div><di=
>>>> v>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 DNSClient Client =3D new DNSClient
>>> ();</div></div><=
>>>> div><br></div><div>=A0 =A0 =A0 =A0 =A0 =A0 // Non blocking
>>> request</div><di=
>>>> v><div><span class=3D"Apple-style-span">=A0 =A0 =A0 =A0 =A0 =A0 DNSMessage
>>>> =
>>>> Request =3D new DNSQueryMessage (Domain,=A0</span>EDNS.DNSType.A<span
>>> class=
>>>> =3D"Apple-style-span">);</span></div>
>>>> </div><div>=A0 =A0 =A0 =A0 =A0 =A0 DNSTransaction Transaction1 =3D
>>> Client.S=
>>>> end (Request);</div><div><br></div><div><div><div>=A0 =A0 =A0 =A0 =A0 =A0
>>>> >> D=
>>>> NSMessage Request =3D new DNSQueryMessage
>>> (Domain,=A0EDNS.DNSType.CAA);</di=
>>>> v></div><div>=A0 =A0 =A0 =A0 =A0 =A0 DNSTransaction Transaction2 =3D
>>> Client=
>>>> .Send (Request);</div>
>>>> </div><div><br></div><div>=A0 =A0 =A0 =A0 =A0 =A0 // Does other useful
>>> stuf=
>>>> f like create the message headers</div><div>=A0 =A0 =A0 =A0 =A0 =A0 // Can
>>>> =
>>>> poll status of transactions using=A0DNSTransaction.Complete
>>> ()</div><div><b=
>>>> r></div><div><div>=A0 =A0 =A0 =A0 =A0 =A0 Response =3D Client.Receive
>>> (Tran=
>>>> saction1);</div>
>>>> </div><div><div>=A0 =A0 =A0 =A0 =A0 =A0 Response =3D Client.Receive
>>> (Transa=
>>>> ction2);</div></div><div><br></div><div><br></div><div>And that is still >>
>>>> mu=
>>>> ch less than you would want a .NET library to provide. A proper .NET
>>> librar=
>>>> y should let the caller loop things into the asynchronous caller.</div>
>>>> <div><br></div><div>Ultimately, the goal is to produce a subclass of the >>
>>>> Tc=
>>>> pClient class such that the only difference that the programmer needs to >>
>>>> co=
>>>> nsider is to replace the creation method:</div><div><br></div><div><span >>
>>>> cl=
>>>> ass=3D"Apple-style-span" style=3D"font-family: &#39;Segoe UI&#39;,
>>> Verdana,=
>>>>  Arial; font-size: 17px; "><pre style=3D"padding-top: 5px; padding-right:
>>>> >> 5=
>>>> px; padding-bottom: 5px; padding-left: 5px; margin-top: 0px; margin-right:
>>>> =
>>>> 0px; margin-bottom: 0px; margin-left: 0px; font-family: Consolas, Courier,
>>>> =
>>>> monospace; word-break: break-all; word-wrap: break-word; font-style:
>>> normal=
>>>> ; font-weight: normal; overflow-x: auto; overflow-y: auto; ">
>>>> <span style=3D"color: blue; ">public</span> TcpClient(<span
>>> style=3D"color:=
>>>>  blue; ">string</span> hostname, <span style=3D"color: blue; ">int</span>
>>>> >> p=
>>>> ort)</pre></span></div><div><br></div><div>with the creation
>>> method:</div><=
>>>> div>
>>>> <br></div><div><span class=3D"Apple-style-span" style=3D"font-family:
>>> &#39;=
>>>> Segoe UI&#39;, Verdana, Arial; font-size: 17px; "><pre
>>> style=3D"padding-top=
>>>> : 5px; padding-right: 5px; padding-bottom: 5px; padding-left: 5px;
>>> margin-t=
>>>> op: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;
>>> font-fami=
>>>> ly: Consolas, Courier, monospace; word-break: break-all; word-wrap:
>>> break-w=
>>>> ord; font-style: normal; font-weight: normal; overflow-x: auto;
>>> overflow-y:=
>>>>  auto; ">
>>>> <span style=3D"color: blue; ">public</span> InternetClient(<span
>>> style=3D"c=
>>>> olor: blue; ">string</span> hostname, <span style=3D"color: blue;
>>> ">string<=
>>>> /span> service, int
>>> port)</pre></span></div><div><br></div><div><br></div><=
>>>> div>
>>>> The difference here is the level of abstraction. TcpClient connects via
>>> hos=
>>>> tname and port and always returns a raw bytestream. InternetClient uses
>>> the=
>>>>  DNS to determine what the best connection that is available for a
>>> service.=
>>>>  If the best connection is raw TCP it will return that, if it can form an
>>>> >> S=
>>>> SL socket, it will return that.</div>
>>>> <div><br></div><div>[Yes, I know that there is also the question of how to
>>>> =
>>>> specify &#39;best&#39;, but that is something that is more usually
>>> somethin=
>>>> g you want to specify at the host level or higher and want to avoid
>>> embeddi=
>>>> ng in actual applications]</div>
>>>> <div><br></div><div>This actually has a major performance advantage in the
>>>> =
>>>> right hands because the implementation can also be asynchronous. So in the
>>>> =
>>>> typical calling sequence we would have:</div><div><br></div><div>// Create
>>>> =
>>>> the socket</div>
>>>> <div>// Generate the message headers</div><div>// Check the socket is
>>> OK</d=
>>>> iv><div>// Send the first byte</div><div><br></div><div>In terms of timing
>>>> =
>>>> what would be going on is:</div><div><br></div><div><div>// Create the
>>> sock=
>>>> et</div>
>>>> <div>=A0 [Async socket establishment starts]</div><div>// Generate the
>>> mess=
>>>> age headers</div><div>=A0 [Wait for the socket to be
>>> completed]</div><div>/=
>>>> / Check the socket is OK</div><div>// Send the first
>>> byte</div></div><div><=
>>>> br>
>>>> </div><div><br></div><div>Now in my preferred programming language, you
>>> cou=
>>>> ld just throw up a PAR statement and it would work anyway, but very few
>>> pro=
>>>> grammers grok that sort of stuff.</div><div><br></div><div><br><div class=
>>>> =3D"gmail_quote">
>>>> On Wed, Jun 29, 2011 at 2:21 AM, Mark Andrews <span dir=3D"ltr">&lt;<a
>>> href=
>>>> =3D"mailto:[email-masked]">[email-masked]</a>&gt;</span>
>>> wrote:<br><blockquot=
>>>> e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc
>>> sol=
>>>> id;padding-left:1ex;">
>>>> <br>
>>>> In message &lt;<a href=3D"mailto:BANLkTimX2XRgJHSkUq-GAAMDs%2BMb6V2VYw@mail
>>> <mailto:BANLkTimX2XRgJHSkUq-GAAMDs%252BMb6V2VYw@mail> =
>>>> .gmail.com <http://gmail.com>
>>> ">[email-masked]
>>> <mailto:[email-masked]> </a>&gt;, Phi=
>>>> llip Hallam-<br>
>>>> <div class=3D"im">Baker writes:<br>
>>>> &gt; I guess that would work for the application programmers who still
>>> code=
>>>>  in C<br>
>>>> &gt; or C++. That is not where the industry has been for a decade now.<br>
>>>> <br>
>>>> </div>The concepts are language independent.<br>
>>>> <font color=3D"#888888"><br>
>>>> --<br>
>>>> </font><div><div></div><div class=3D"h5">Mark Andrews, ISC<br>
>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
>>>> PHONE: <a href=3D"tel:%2B61%202%209871%204742" value=3D"+61298714742
>>> <tel:%2B61298714742> ">+61 2=
>>>>  9871 4742</a> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: <a
>>> href=3D"mailto:=
>>>> [email-masked]">[email-masked]</a><br>
>>>> </div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: >>
>>>> <a=
>>>>  href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
>>>> </div>
>>>> 
>>>> --0016e68debd4b5f20c04a6db8b0b--
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742 <tel:%2B61%202%209871%204742>                 
>> INTERNET: [email-masked]
> 
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 6 Jul 2011 11:55:35 -0400

It is still a bolt on, not part of the default installation.

If the world was using DNS the way people in the DNS world think they
should, these packages would be part of the Web Services platforms. The fact
that they are not suggests a disconnect.

The developer world lives in a world of C#, Java, Ruby and Python. C++ might
as well be Cobol as far as they are concerned.

On Wed, Jul 6, 2011 at 10:43 AM, Osterweil, Eric <[email-masked]>wrote:

> >>>>>>>> I guess that would work for the application programmers who still
> >>>>
> >>>>>>>> code in
> >>>>>> C
> >>>>  C# to hopefully render the issue
> moot.</div><div><br></div><div><br></div>
> >>>> nsider is to replace the creation
> method:</div><div><br></div><div><span >>
> >>>> cl=
> >>>> In message &lt;<a href=3D"mailto:
> BANLkTimX2XRgJHSkUq-GAAMDs%2BMb6V2VYw@mail

---

From: "Osterweil, Eric" <[email-masked]>
Date: Wed, 06 Jul 2011 13:34:36 -0400

> It is still a bolt on, not part of the default installation.

A dependency?  Sure. ;)

Eric
 
> If the world was using DNS the way people in the DNS world think they should,
> these packages would be part of the Web Services platforms. The fact that they
> are not suggests a disconnect.
> 
>>>>>>>> <mailto:[email-masked]>
>>>>>>>>>> <mailto:[email-masked]
>>>>>> <mailto:[email-masked]> > >,
>>>>>> Phillip
>>>>>>>>>>>> Hallam-
>>>>>>>>>>>> Baker writes:
>>>>>>>> <tel:%2B61%202%209871%204742>                 
>>>>>>>>>> INTERNET: [email-masked]
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> </div><div><br></div><div>=A0 =A0 =A0 =A0 =A0 =A0 // Does other >>>>>
>>>>>>>>>> useful
>>>>>>>> stuf=
>>>>>>>>>> In message &lt;<a
>>>>>> href=3D"mailto:BANLkTimX2XRgJHSkUq-GAAMDs%2BMb6V2VYw@mail
>>>>>> <mailto:BANLkTimX2XRgJHSkUq-GAAMDs%252BMb6V2VYw@mail>
>>>>>>>> <mailto:BANLkTimX2XRgJHSkUq-GAAMDs%252BMb6V2VYw@mail
>>>>> <mailto:BANLkTimX2XRgJHSkUq-GAAMDs%25252BMb6V2VYw@mail> > =
>>>>>>>>>> .gmail.com <http://gmail.com>  <http://gmail.com>
>>>>> <mailto:[email-masked]>
>>>>>>>> <mailto:[email-masked]
>>>>> <mailto:[email-masked]> >
>>>>> </a>&gt;, >>>> Phi=
>>>>>>>>>> llip Hallam-<br>
>>>>>> <tel:%2B61298714742>
>>>> <tel:%2B61%202%209871%204742>                 
>>>>>> INTERNET: [email-masked]
>>>> 
>>>> 
>> 
> 
>