Re: [dnsext] draft-bellis-dnsext-dnsproxy-00
bert hubert
> > http://tools.ietf.org/html/draft-bellis-dnsext-dnsproxy-00
> >
> > "This document provides guidelines for the implementation of DNS
> proxies,
> > as found in broadband routers and other similar network devices."
>
> Does anyone have any feedback on this draft?
It looks like a fine document to me, and many of the points raised are
actually troublesome in real life.
What I worry about is that this draft basically says "Please adhere to the
DNS RFCs", where it is abundantly clear that proxies so far have not done
so.
It is questionable if people who disregarded the previous 20 RFCs will heed
this one.
Draft-bellis-dnsext-dnsproxy might be something nice and pointed (if not,
pointy) to hit vendors over the head with, and perhaps get them to do the
right thing.
(This was the aim of draft-forgery-resilience, but it did not work in time)
So all in all - I find many good things in this draft, but I worry if it
will achieve any effect.
Bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
--
to unsubscribe send a message to namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
bert hubert
> All of that is true. The point is, I think, that many of the software
> engineers who have developed these proxies are unaware of the wide range
You use the term 'engineer' in the very widest sense of the word. The people
'assembling' these domestic devices will generally only code until they can
browse the web over it using their PC, and then slap a box around the
product and ship it.
> of RFCs that need to be implemented to be fully compatible with modern
> DNS. It's apparent to me, at least, that they've looked up RFC1035, and
> done that, and only that.
They haven't even done that, in my experience.
> My intent is therefore to provide that single "pointer RFC" which provides
> concrete examples of known failings and clear references to where the
> necessary specifications can be found.
That would be good - this also argues for not adding heaps of other stuff to
the RFC - I think everybody would like to have his pet DNS difficulty
included, but overall that would not help achieve greater compliance.
Olafur Gudmundsson
Content-Type: text/plain; charset="us-ascii"; format=flowed
<no-hat>
At 12:46 03/11/2008, bert hubert wrote:
>On Mon, Nov 03, 2008 at 03:51:49PM +0000, Ray.B...@nominet.org.uk wrote:
> > > http://tools.ietf.org/html/draft-bellis-dnsext-dnsproxy-00
> > >
> > > "This document provides guidelines for the implementation of DNS
> > proxies,
> > > as found in broadband routers and other similar network devices."
> >
> > Does anyone have any feedback on this draft?
>
>It looks like a fine document to me, and many of the points raised are
>actually troublesome in real life.
>
>What I worry about is that this draft basically says "Please adhere to the
>DNS RFCs", where it is abundantly clear that proxies so far have not done
>so.
>
>It is questionable if people who disregarded the previous 20 RFCs will heed
>this one.
>
>Draft-bellis-dnsext-dnsproxy might be something nice and pointed (if not,
>pointy) to hit vendors over the head with, and perhaps get them to do the
>right thing.
My biggest hope for this one is that major ISP's will use this document as
an test/purchase guide for equipment. If that happens suddenly the
lazy vendors will fix their act.
>(This was the aim of draft-forgery-resilience, but it did not work in time)
>
>So all in all - I find many good things in this draft, but I worry if it
>will achieve any effect.
This is an attempt to in a small way start getting the effect that some
of us hoped that DNS-Profile document would do.
This is attempt #2, beat the worst offenders into submission.
(Attempt #1 was beat all into compliance)
Olafur (no hat)
--=====================_323862990==.ALT
Content-Type: text/html; charset="us-ascii"
<html>
<body>
<font size=3><no-hat> <br><br>
At 12:46 03/11/2008, bert hubert wrote:<br>
<blockquote type=cite class=cite cite="">On Mon, Nov 03, 2008 at
03:51:49PM +0000, Ray.B...@nominet.org.uk wrote:<br>
> >
<a href="http://tools.ietf.org/html/draft-bellis-dnsext-dnsproxy-00" eudora="autourl">
http://tools.ietf.org/html/draft-bellis-dnsext-dnsproxy-00</a><br>
> > <br>
> > "This document provides guidelines for the implementation
of DNS <br>
> proxies, <br>
> > as found in broadband routers and other similar network
devices."<br>
> <br>
> Does anyone have any feedback on this draft?<br><br>
It looks like a fine document to me, and many of the points raised
are<br>
actually troublesome in real life.<br><br>
What I worry about is that this draft basically says "Please adhere
to the<br>
DNS RFCs", where it is abundantly clear that proxies so far have not
done<br>
so.<br><br>
It is questionable if people who disregarded the previous 20 RFCs will
heed<br>
this one.<br><br>
Draft-bellis-dnsext-dnsproxy might be something nice and pointed (if
not,<br>
pointy) to hit vendors over the head with, and perhaps get them to do
the<br>
right thing.<br>
</font></blockquote><br>
My biggest hope for this one is that major ISP's will use this document
as<br>
an test/purchase guide for equipment. If that happens suddenly the<br>
lazy vendors will fix their act. <br><br>
<br>
<blockquote type=cite class=cite cite=""><font size=3>(This was the aim
of draft-forgery-resilience, but it did not work in time)<br><br>
So all in all - I find many good things in this draft, but I worry if
it<br>
will achieve any effect.</blockquote><br>
This is an attempt to in a small way start getting the effect that
some<br>
of us hoped that DNS-Profile document would do. <br>
This is attempt #2, beat the worst offenders into submission. <br>
(Attempt #1 was beat all into compliance) <br><br>
<x-tab> </x-tab>Olafur (no
hat) <br>
</font></body>
</html>
--=====================_323862990==.ALT--
Edward Lewis
>> Yes.
>
>Has anyone ever looked to find out why this happens?
I know of one case - back when there was the hard limit of 512, one
implementation would truncate at that and not at the end of the last
complete RR. Why? All conjecture, but it is faster than clipping
back to the last useable byte of data.
One thing to keep in mind. When considering the receipt of data from
the network, don't engineer to what makes sense, engineer to what
could possibly come in. As in the robustness principle "liberal in
what you accept." That doesn't mean you have to accept and digest
what's come in, but admit that FORMERRs will happen on the remote end
or at intermediate boxes and write code that won't barf on it.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Never confuse activity with progress. Activity pays more.