Greetings again. We have posted a very delayed version
draft-ietf-dnsop-rfc7816bis that we believe answers all of the issues brought
up during WG last call. There are a lot of significant changes from the
previous version.
Everyone (but particularly resolver developers): please review the
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.
Title : DNS Query Name Minimisation to Improve Privacy
Authors : Stephane Bortzmeyer
> On 16 Apr 2021, at 04:52, Paul Vixie wrote:
>
> On Thu, Apr 15, 2021 at 05:46:29PM +1000, Mark Andrews wrote:
>>> On 15 Apr 2021, at 17:28, Paul Vixie wrote:
>>> so, freebsd was unfairly maligned in the forescout report on this event;
>>> the bug was in their dhcp client, not their dns or
On Thu, Apr 15, 2021 at 05:46:29PM +1000, Mark Andrews wrote:
> > On 15 Apr 2021, at 17:28, Paul Vixie wrote:
> > so, freebsd was unfairly maligned in the forescout report on this event;
> > the bug was in their dhcp client, not their dns or "tcp/ip stack", and
> > had been fixed 20 years late
On 4/15/2021 5:39 PM, John R Levine wrote:
On Thu, 15 Apr 2021, Christian Huitema wrote:
Adding test vectors would help, especially broken vectors.
+1. That would be a pretty good way for the IETF to help clean the
mess. That, and maybe a DNS site that would serve the test vectors.
In
RFC 1035 says “prior occurance”, which would mean no.
4.1.4. Message compression
In order to reduce the size of messages, the domain system utilizes a
compression scheme which eliminates the repetition of domain names in a
message. In this scheme, an entire domain name or a list of labels at
On Thu, 15 Apr 2021, Christian Huitema wrote:
Adding test vectors would help, especially broken vectors.
+1. That would be a pretty good way for the IETF to help clean the mess.
That, and maybe a DNS site that would serve the test vectors.
In this case I think it's a reasonable idea but I
> On 15 Apr 2021, at 17:28, Paul Vixie wrote:
>
I don't think it's entirely fair to blame the coders who make these
mistakes, because a very large number of excellent programmers have
made a mess of DNS name decompression. ...
>
> i shipped the crap in question as late as 1998,
> > > I don't think it's entirely fair to blame the coders who make these
> > > mistakes, because a very large number of excellent programmers have
> > > made a mess of DNS name decompression. ...
i shipped the crap in question as late as 1998, and excellence wasn't the
problem. in this field at
On 4/14/2021 11:19 PM, Mark Andrews wrote:
On 15 Apr 2021, at 07:17, Tony Finch wrote:
John Levine wrote:
On the other hand, all of the sloppy coding people use to handle
compressed names is embarassing.
I don't think it's entirely fair to blame the coders who make these
mistakes, because
10 matches
Mail list logo
