[Fwd: Re: request for info: unbound via https / tls]

[Fwd: Re: request for info: unbound via https / tls]

[Paul Simmons]

[-- Attachment #1: Type: text/plain, Size: 27 bytes --]


Forgot the list cc
:-(.



[-- Attachment #2: attachment.eml --]
[-- Type: message/rfc822, Size: 9564 bytes --]


TWVzc2FnZS1JRDogPDE1MjUxODQ5MjguMzUzMC4xMy5jYW1lbEBnbWFpbC5jb20+ClN1YmplY3Q6
IFJlOiByZXF1ZXN0IGZvciBpbmZvOiB1bmJvdW5kIHZpYSBodHRwcyAvIHRscwpGcm9tOiBQYXVs
IFNpbW1vbnMgPG1iYXRyYW5jaEBnbWFpbC5jb20+ClRvOiBNaWNoYWVsIFRyZW1lciA8bWljaGFl
bC50cmVtZXJAaXBmaXJlLm9yZz4KRGF0ZTogVHVlLCAwMSBNYXkgMjAxOCAwOToyODo0OCAtMDUw
MApJbi1SZXBseS1UbzogPDE1MjUxMTY1NDYuMjQ3OTQ3MS4xODMuY2FtZWxAaXBmaXJlLm9yZz4K
UmVmZXJlbmNlczogPDE1MjI4NjM1MTAuMjExMjYuMTkuY2FtZWxAZ21haWwuY29tPgoJIDwxNTIy
OTIxNDMwLjEwMDkzMTIuNTUuY2FtZWxAaXBmaXJlLm9yZz4KCSA8MTUyMjkzNDkxNS4yMTEyNi40
Mi5jYW1lbEBnbWFpbC5jb20+IDwxNTIyOTM4NzE4LjI3MTcuMTIuY2FtZWxAaXBmaXJlLm9yZz4K
CSA8MTUyNTExNjU0Ni4yNDc5NDcxLjE4My5jYW1lbEBpcGZpcmUub3JnPgpPcmdhbml6YXRpb246
IEZJRk8KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJVVEYtOCIKWC1NYWlsZXI6
IEV2b2x1dGlvbiAzLjI2LjYgKDMuMjYuNi0xLmZjMjcpIApNaW1lLVZlcnNpb246IDEuMApDb250
ZW50LVRyYW5zZmVyLUVuY29kaW5nOiA3Yml0CgpPbiBNb24sIDIwMTgtMDQtMzAgYXQgMjA6Mjkg
KzAxMDAsIE1pY2hhZWwgVHJlbWVyIHdyb3RlOgo+IEFueSBsdWNrIHdpdGggdGVzdGluZz8KPiAK
PiBJIGVuYWJsZWQgRE5TLW92ZXItVExTIG9uIHRoZSBMaWdodG5pbmcgV2lyZSBMYWJzIHNwb25z
b3JlZCByZXNvbHZlcgo+IHRvZGF5IEAKPiA4MS4zLjI3LjU0LiBNYXliZSB5b3UgY2FuIHVzZSB0
aGlzIG9uZSBmb3IgdGVzdGluZy4KPiAKPiBCZXN0LAo+IC1NaWNoYWVsCgpUaGFua3MgZm9yIHRo
ZSBETlMvVExTIHJlc29sdmVyISAgSSd2ZSBiZWVuIHVzaW5nIDkuOS45LjkgYW5kIDEuMC4wLjEK
dG8gdGVzdC4KClRoZSB1bmJvdW5kIGluaXQgYW5kIHRoZSBjZ2kgc2NyaXB0cyB1c2UgZGlnIDku
MTEuMywgd2hpY2ggaGFzIG5vCm5hdGl2ZSBzdXBwb3J0IGZvciBUTFMuICBJJ20gdHJ5aW5nIHRv
IGNvbmZpZ3VyZSBzdHVubmVsIHRvIGFjdCBhcyBNSVRNCnNvIHRoYXQgZGlnIGNhbiBzdWNjZWVk
LiAgSSBob3BlIHRvIHJlc3RyaWN0IHVuYm91bmQgdG8gcG9ydCA4NTMgZm9yCmxpc3RlbiBhbmQg
c2VuZCwgYW5kIHVzZSBzdHVubmVsIHRvIGxpc3RlbiBvbiBwb3J0IDUzIGFuZCBmb3J3YXJkIHRv
Cjg1My4KClN0aWxsIHBva2luZyBpdCwgYnV0IHNvIGZhciBhbGwgaXQgZG9lcyBpcyBzcXVlYWwu
ICBJJ20gbm90IHRoZSBhZG1pbiBJCnVzZWQgdG8gYmUgKHJldGlyZWQpLiAgQmFieSBzdGVwcyEK
ClBhdWwKCj4gCj4gT24gVGh1LCAyMDE4LTA0LTA1IGF0IDE1OjMxICswMTAwLCBNaWNoYWVsIFRy
ZW1lciB3cm90ZToKPiA+IEhpLAo+ID4gCj4gPiBPbiBUaHUsIDIwMTgtMDQtMDUgYXQgMDg6Mjgg
LTA1MDAsIFBhdWwgU2ltbW9ucyB3cm90ZToKPiA+ID4gT24gVGh1LCAyMDE4LTA0LTA1IGF0IDEw
OjQzICswMTAwLCBNaWNoYWVsIFRyZW1lciB3cm90ZToKPiA+ID4gPiBIZWxsbyBQYXVsLAo+ID4g
PiA+IAo+ID4gPiA+IHF1aXRlIGhhcHB5IHRoYXQgd2UgYXJlIG5vdyBoYXZpbmcgYSBjb252ZXJz
YXRpb24gYWJvdXQgdGhpcy4gSQo+ID4gPiA+IGhhdmUKPiA+ID4gPiBiZWVuCj4gPiA+ID4gY29u
c2lkZXJpbmcgd3JpdGluZyBzb21ldGhpbmcgbXlzZWxmLCBidXQgSSBkaWRuJ3Qgd2FudCB0bwo+
ID4gPiA+IGFwcGVhciBzbwo+ID4gPiA+IGdydW1weQo+ID4gPiA+IGFnYWluIDopCj4gPiA+ID4g
Cj4gPiA+ID4gSSBoYXZlIGEgaHVnZSBpc3N1ZSB3aXRoIHRoYXQgZGlzY3Vzc2lvbiBvciBtZWRp
YSBjb3ZlcmFnZSB0aGF0Cj4gPiA+ID4gaXMKPiA+ID4gPiBzdWRkZW5seSBvdXQKPiA+ID4gPiB0
aGVyZSwgZXNwZWNpYWxseSBzaW5jZSAxLjEuMS4xIGlzIGxpdmUuIFBvaW50cyBhcmUgKGluIGJy
aWVmKToKPiA+ID4gPiAKPiA+ID4gPiAqIFRoZXJlIGlzIG5vIGFkdmFudGFnZSB0byBwcml2YWN5
IGFueW9uZSBoYXMgaGVyZS4gSXQgaXMgYQo+ID4gPiA+IGh1Z2UKPiA+ID4gPiBjb3Jwb3JhdGlv
bgo+ID4gPiA+IHRoYXQgaXMgcnVubmluZyB0aGlzIEROUyBzZXJ2aWNlLiBJIGRvIG5vdCBzZWUg
d2h5IEkgc2hvdWxkCj4gPiA+ID4gdHJ1c3QKPiA+ID4gPiB0aGVtIG1vcmUgdGhlbgo+ID4gPiA+
IHRoZSBjb21wZXRpdG9ycyBsaWtlIDguOC44Ljggb3IgOS45LjkuOSBvciB3aGF0IGV2ZXIgaXMg
b3V0Cj4gPiA+ID4gdGhlcmUKPiA+ID4gPiB0aGF0IGRvZXNuJ3QKPiA+ID4gPiBoYXZlIGEgZmFu
Y3kgSVAgYWRkcmVzcy4KPiA+ID4gPiAKPiA+ID4gPiBJIHdvdWxkIGFzc3VtZSB0aGF0IHRoZXkg
YXJlIGFsbCBjb2xsZWN0aW5nIGRhdGEgYWJvdXQgdGhlaXIKPiA+ID4gPiB1c2Vycy4KPiA+ID4g
PiBUaGV5IGFyZSBhbGwKPiA+ID4gPiBidXNpbmVzc2VzIHRoYXQgYXJlIG1ha2luZyBtb25leSBh
bmQgc2luY2UgdGhpcyBzZXJ2aWNlIGlzCj4gPiA+ID4gYmVpbmcKPiA+ID4gPiBvZmZlcmVkIGZv
cgo+ID4gPiA+IGZyZWUsIHRoZSBtb25leSB0aGF0IHBheXMgZm9yIGl0IGhhcyB0byBjb21lIGZy
b20gc29tZXdoZXJlCj4gPiA+ID4gZWxzZS4uLgo+ID4gPiA+IFlvdSBrbm93IHRoZQo+ID4gPiA+
IGRyaWxsLgo+ID4gPiA+IAo+ID4gPiAKPiA+ID4gQWdyZWVkLCBhbHRob3VnaCBDbG91ZGZsYXJl
IGhhdmUgc3RhdGVkIHRoYXQgdGhleSBhcmVuJ3QKPiA+ID4gaW50ZXJlc3RlZCBpbgo+ID4gPiBt
YXJrZXRpbmcgdG8gb3IgdGFyZ2V0aW5nIHVzZXJzLCBhbmQgcmVhbGx5IGhhdmUgbm8gaW50ZXJl
c3QgaW4KPiA+ID4gd2hvIGlzCj4gPiA+IHJlc29sdmluZyB3aGF0Lgo+ID4gCj4gPiBZZXMgdGhl
eSBkaWQsIGJ1dCBhcyBsb25nIGFzIHRoZXJlIGlzIG5vIHRlY2huaWNhbCBndWFyYW50ZWUgZm9y
Cj4gPiB0aGlzLAo+ID4gSSB3b24ndCBiZWxpZXZlIGl0IChRdW90ZSBzaGFtZWxlc3NseSBzdG9s
ZW4gZnJvbSBQZXRlcikuCj4gPiAKPiA+ID4gPiAqIFRoYXQgYmVpbmcgc2FpZCwgRE5TIG92ZXIg
VExTIG9yIEROUyBvdmVyIFggZG9lcyBub3QgaGVscCB0bwo+ID4gPiA+IHByb3RlY3QgdGhhdAo+
ID4gPiA+IHByaXZhY3kgZnJvbSB0aG9zZSBjb3Jwb3JhdGlvbnMuIEl0IGlzIGp1c3QgdHJhbnNw
b3J0Cj4gPiA+ID4gZW5jcnlwdGlvbi4gSQo+ID4gPiA+IGRvIG5vdCBhdAo+ID4gPiA+IGFsbCBz
ZWUgaG93IHBlb3BsZSBjYW4gY29uZnVzZSB0aGlzLgo+ID4gPiA+IAo+ID4gPiA+ICogVGhlbiwg
SSB0aGluayB0aGF0IEROUyBvdmVyIEhUVFBTIGlzIGNvbXBsZXRlIG5vbi1zZW5zZS4KPiA+ID4g
PiBQZW9wbGUKPiA+ID4gPiBoYXZlIGJlZW4KPiA+ID4gPiBjb21wbGFpbmluZyBmb3IgYSB2ZXJ5
IGxvbmcgdGltZSB0aGF0IEROU1NFQyBhZGRzIHRvbyBtdWNoCj4gPiA+ID4gb3ZlcmhlYWQuCj4g
PiA+ID4gSG93IGRvZXMKPiA+ID4gPiBIVFRQUyBmaXQgaW4gaGVyZT8gQW5kIHRvIHRoZSBwZW9w
bGUgd2hvIGFyZSBiZWluZyBhIHByb3h5IHRoYXQKPiA+ID4gPiBkb2Vzbid0IGFsbG93Cj4gPiA+
ID4gYW55dGhpbmcgZWxzZSB0byBwYXNzIHRocm91Z2gsIHlvdSBhcmUgbm90IHVzaW5nIHRoZSBJ
bnRlcm5ldC4KPiA+ID4gPiBZb3UKPiA+ID4gPiBhcmUgdXNpbmcKPiA+ID4gPiBzb21ldGhpbmcg
ZWxzZS4gR2V0IG91dCBvZiB0aGVyZS4KPiA+ID4gPiAKPiA+ID4gPiAqIFNvIGJhc2ljYWxseSB3
ZSBoYXZlIGFub3RoZXIgcGllY2Ugb2YgdGVjaG5vbG9neSB0aGF0IGlzCj4gPiA+ID4gYWN0dWFs
bHkKPiA+ID4gPiBxdWl0ZSB1c2VmdWwKPiA+ID4gPiBoeXBlZCBmb3Igbm8gcmVhc29uLiBQZW9w
bGUgd2lsbCBldmVudHVhbGx5IGZpbmQgb3V0IHRoYXQgaXQKPiA+ID4gPiBkb2Vzbid0Cj4gPiA+
ID4gZG8gd2hhdAo+ID4gPiA+IHRoZXkgd2VyZSBleHBlY3RpbmcgYW5kIGFiYW5kb25pbmcgaXQg
b3Igc29tZXRoaW5nIGVsc2UuIFRoYXQKPiA+ID4gPiBpcwo+ID4gPiA+IGZydXN0cmF0aW5nLgo+
ID4gPiA+IAo+ID4gPiA+ICogQnV0IGFsbCBpbiBhbGwsIEROUyBjb3VsZCBkbyB3aXRoIGEgYml0
IG9mIGFuIHVwZGF0ZS4gSXQKPiA+ID4gPiB3b3JrcyB3ZWxsCj4gPiA+ID4gYXMgYQo+ID4gPiA+
IHByb3RvY29sIGJ1dCBsYWNrcyBzb21lIGZlYXR1cmVzIGxpa2UgdGhlIHByaXZhY3kuIFNvIEkg
c3VwcG9zZQo+ID4gPiA+IHVzaW5nCj4gPiA+ID4gYSBUTFMKPiA+ID4gPiB0dW5uZWwgdG8gY29t
bXVuaWNhdGUgdG8gYSAqdHJ1c3RlZCogcmVzb2x2ZXIgd291bGQgZ2l2ZSB1cwo+ID4gPiA+IHRo
YXQKPiA+ID4gPiBwcml2YWN5IHdoZXJlCj4gPiA+ID4gd2Ugd2FudCBpdC4gQW5kIHdoYXQgZXZl
ciByZXNvbHZlciBwZW9wbGUgYXJlIHVzaW5nIGlzIGVudGlyZWx5Cj4gPiA+ID4gdXAgdG8KPiA+
ID4gPiB0aGVtLgo+ID4gPiA+IAo+ID4gPiA+IE9uIFdlZCwgMjAxOC0wNC0wNCBhdCAxMjozOCAt
MDUwMCwgUGF1bCBTaW1tb25zIHdyb3RlOgo+ID4gPiA+ID4gRm9yIENvcmUxMTksIEknbSBjdXJy
ZW50bHkgdXNpbmcgYSBwYXRjaCB0bwo+ID4gPiA+ID4gL2V0Yy9pbml0LmQvdW5ib3VuZDoKPiA+
ID4gPiA+IAo+ID4gPiA+ID4gIGh0dHBzOi8vZ2l0bGFiLmNvbS9zbmlwcGV0cy8xNzA2ODA0Cj4g
PiA+ID4gPiAKPiA+ID4gPiA+IGJlY2F1c2UgbXkgKG9ubHkgYXZhaWxhYmxlKSBJU1AgbWFuZ2xl
cyBwb3J0IDUzIHRyYWZmaWMsCj4gPiA+ID4gPiBlZmZlY3RpdmVseQo+ID4gPiA+ID4gZGlzYWJs
aW5nIEROUyBvdXRzaWRlIG9mIG15IHByaXZhdGUgZmlyZXdhbGwuCj4gPiA+ID4gPiAKPiA+ID4g
PiA+IEkgd29uZGVyIGlmIGNvbmZpZ3VyaW5nIHVuYm91bmQgc28gdGhhdCBmb3J3YXJkIHJlcXVl
c3RzIHVzZQo+ID4gPiA+ID4gRE5TU0VDCj4gPiA+ID4gPiBvdmVyIEhUVFBTIG9yIFRMUyB3b3Vs
ZCBiZSBhIGJldHRlciAoYW5kIG1vcmUgc2VjdXJlKQo+ID4gPiA+ID4gc29sdXRpb24/Cj4gPiA+
ID4gPiBBbHNvCj4gPiA+ID4gPiBzZWU6Cj4gPiA+ID4gCj4gPiA+ID4gSSB0aGluayB0aGF0IGlz
IHRoZSByaWdodCBwYXRoLiBUaGVyZSBpcyBkZWxpYmVyYXRlbHkgbm8gc3dpdGNoCj4gPiA+ID4g
dG8KPiA+ID4gPiB0dXJuIEROU1NFQwo+ID4gPiA+IG9mZi4gSSB0aGluayB0aGF0IGRvZXNuJ3Qg
bWFrZSBzZW5zZS4gSXQgZmVlbHMgYSBiaXQgbGlrZQo+ID4gPiA+IGxpY2tpbmcgYQo+ID4gPiA+
IHRvaWxldCBzZWF0Lgo+ID4gPiA+IFlvdSB0aGF0IHRoZXJlIGlzIHNvbWUgZGFuZ2VyIHRoZXJl
IGFuZCB0aGVyZWZvcmUgaXQgaXMgYQo+ID4gPiA+IHJlYWxseSBiYWQKPiA+ID4gPiBpZGVhIHRv
IGRvCj4gPiA+ID4gaXQgYWx0aG91Z2ggaW4gdGhlb3J5IHRoYXQgb3B0aW9uIGlzIHRoZXJlLgo+
ID4gPiAKPiA+ID4gSWNrISBUaGFua3MgZm9yIHN0aWNraW5nIHRoYXQgaW1hZ2UgaW4gbXkgYnJh
aW4hIDotKQo+ID4gCj4gPiBJIGFtIHVuZm9ydHVuYXRlbHkgbGFja2luZyBiZXR0ZXIgZXhhbXBs
ZXMgdGhhdCBzaG93IHRoZQo+ID4gc2VyaW91c25lc3Mgb2YKPiA+IHNvbWV0aGluZyB0aGF0IHBl
b3BsZSB3YW50IHRvIGRvIHdyb25nLi4uCj4gPiAKPiA+ID4gSSdtIHByaW1hcmlseSBpbnRlcmVz
dGVkIGluIGNpcmN1bXZlbnRpbmcgdGhlIElTUCBtdW5naW5nIEROU1NFQy4KPiA+ID4gSQo+ID4g
PiBzdXBwb3NlIEknbSByZXByZXNlbnRpbmcgYSBzbWFsbCBjb3JuZXIgY2FzZS4gVGhlcmUgYXJl
IG5vCj4gPiA+IGNvbm5lY3Rpb25zCj4gPiA+IGF2YWlsYWJsZSB0byBtZSBleGNlcHQgSHVnaGVz
TmV0IChIdWdoZXNOMFQgOi0pLiAKPiA+IAo+ID4gWWVzLCB0aGF0IGlzIGEgdmVyeSBnb29kIHJl
YXNvbi4KPiA+IAo+ID4gVGhpcyBpcyBhIGJpdCBvZiBhIGNvcm5lciBjYXNlIGJ1dCB0aGVyZSBp
cyBhIG51bWJlciBvZiB1c2VycyB3aXRoCj4gPiB0aGlzCj4gPiBwcm9ibGVtLiBBbmQgSSB0aGlu
ayB0aGVyZSBhcmUgYSBsb3QgbW9yZSBwZW9wbGUgd2hvIGRvbid0IHRydXN0Cj4gPiB0aGVpcgo+
ID4gSVNQIG9yIGRvIG5vdCBuZWVkIHRvIHRydXN0IHRoZWlyIElTUC4gSG9uZXN0bHksIEkgd291
bGQgcHJlZmVyIHRvCj4gPiB1c2UKPiA+IEROUyBvdmVyIFRMUyBhbGwgdGhlIHRpbWUuCj4gPiAK
PiA+IEEgdGhpbmcgdGhhdCBJIGZvcmdvdCB0byBtZW50aW9uIGluIG15IGZpcnN0IGVtYWlsOiBJ
IHRoaW5rIGl0IGlzCj4gPiB3YXkKPiA+IG1vcmUgbGlrZWx5IHRoYXQgdGhlIEROUyBob3N0ZXIg
aXMgInNweWluZyIgb24geW91IHRoYW4gdGhlIElTUC4gT2YKPiA+IGNvdXJzZSB0aGUgSVNQIGhh
cyB0aGUgY2hhbmNlIHRvIGRvIGl0IGFuZCBpdCBpcyBwcmFjdGljYWwsICBidXQgSQo+ID4gc3Vw
cG9zZSB0aGVyZSBpcyBhIGJpZ2dlciBpbnRlcmVzdCBpbiBoYXJ2ZXN0aW5nIHRoZSBkYXRhIGZv
cgo+ID4gYWR2ZXJ0aXNpbmcgYW5kIHNvIG9uLiBIZW5jZSBteSBjcml0aWNpc20gb2YgR29vZ2xl
LCBDbG91ZGZsYXJlLAo+ID4gZXRjLgo+ID4gCj4gPiA+IAo+ID4gPiA+IAo+ID4gPiA+ID4gaHR0
cHM6Ly9mb3J1bS5pcGZpcmUub3JnL3ZpZXd0b3BpYy5waHA/Zj0yNyZ0PTIwNTc1I3AxMTUzNDIK
PiA+ID4gPiA+IAo+ID4gPiA+ID4gaHR0cHM6Ly9mb3J1bS5pcGZpcmUub3JnL3ZpZXd0b3BpYy5w
aHA/Zj01MCZ0PTIwNTc0Cj4gPiA+ID4gPiAKPiA+ID4gPiA+IENvbW1lbnRzIGFuZCB0ZXN0IGNv
bmZpZ3VyYXRpb25zIGFyZSB3ZWxjb21lIQo+ID4gPiA+IAo+ID4gPiA+IEluIENvcmUgVXBkYXRl
IDEyMCwgdW5ib3VuZCBoYXMgYmVlbiB1cGRhdGVkIHRvIDEuNy4wIGFuZAo+ID4gPiA+IHN1cHBv
cnRzCj4gPiA+ID4gRE5TIG92ZXIgVExTLgo+ID4gPiA+IEZvcmdldCBhYm91dCBETlMgb3ZlciBI
VFRQUy4gSSBjb3VsZG4ndCBmaW5kIHRoZSB0aW1lIHlldCB0bwo+ID4gPiA+IGZ1bGx5Cj4gPiA+
ID4gdXBkYXRlIG91cgo+ID4gPiA+IHJlc29sdmVyIHRoYXQgd2UgaG9zdCB0byBlbmFibGUgRE5T
IG92ZXIgVExTLCB0b28gYnV0IHRoYXQgaXMKPiA+ID4gPiBvbiBteQo+ID4gPiA+IGxpc3QuCj4g
PiA+ID4gCj4gPiA+ID4gU28gd2hhdCBjb3VsZCB0aGlzIGFsbCBsb29rIGxpa2U/IFdlIGJhc2lj
YWxseSB3b3VsZCBuZWVkIGEKPiA+ID4gPiBzd2l0Y2gKPiA+ID4gPiB0aGF0IHRlbGxzCj4gPiA+
ID4gdW5ib3VuZCAqb25seSogdG8gY29udGFjdCB0aGUgcmVzb2x2ZXJzIG92ZXIgVExTLiBJIHRo
aW5rIHRoYXQKPiA+ID4gPiBzaG91bGQKPiA+ID4gPiBzb2x2ZSBpdCwKPiA+ID4gPiBidXQgcGVv
cGxlIG5lZWQgdG8gYmUgYXdhcmUgdGhhdCB0aGV5IHdvbid0IGhhdmUgYW55IEROUwo+ID4gPiA+
IHJlc29sdXRpb24KPiA+ID4gPiB3aGVuIHRoZWlyCj4gPiA+ID4gdXBzdHJlYW0gRE5TIHNlcnZl
cnMgZG9uJ3Qgc3VwcG9ydCBpdCBvciBpbiByZWN1cnNvciBtb2RlLgo+ID4gPiA+IAo+ID4gPiA+
IEFsc28gYWxsIG9mIHRoZSB0ZXN0cyB0aGF0IHdlIGFyZSBydW5uaW5nIGluIHRoZSB1bmJvdW5k
IGluaXQKPiA+ID4gPiBzY3JpcHQKPiA+ID4gPiBwcm9iYWJseQo+ID4gPiA+IHdvbid0IGJlIGFi
bGUgdG8gcnVuIHNpbmNlIGRpZyBkb2Vzbid0IHN1cHBvcnQgRE5TIG92ZXIgVExTLgo+ID4gPiA+
IGJpbmQgYXMKPiA+ID4gPiBhIHdob2xlCj4gPiA+ID4gZG9lcyBub3Qgc3VwcG9ydCBpdCAoeWV0
PykuIFNvIHdlIG5lZWQgYSBzb2x1dGlvbiBmb3IgdGhhdC4KPiA+ID4gCj4gPiA+IEFncmVlZC4g
VGhlIG9ubHkgcmVmZXJlbmNlcyBJJ3ZlIGZvdW5kIHRvIHVzaW5nIGJpbmQgb3ZlciBUTFMKPiA+
ID4gaW52b2x2ZQo+ID4gPiB1c2luZyBhIHByb3h5IC8gdHVubmVsLgo+ID4gCj4gPiB1bmJvdW5k
IGluIENvcmUgMTIwIGRvZXMgaXQuCj4gPiAKPiA+IGh0dHBzOi8vd3d3LnVuYm91bmQubmV0L2Rv
Y3VtZW50YXRpb24vdW5ib3VuZC5jb25mLmh0bWwKPiA+IAo+ID4gQ2hlY2sgZm9yIHRscy11cHN0
cmVhbTogeWVzCj4gPiAKPiA+ID4gCj4gPiA+ID4gCj4gPiA+ID4gV2Ugd291bGQgYWxzbyBuZWVk
IGEgbmV3IENHSSBzY3JpcHQgdGhhdCBnaXZlcyB1c2VycyB0aGUgb3B0aW9uCj4gPiA+ID4gdG8K
PiA+ID4gPiBjb25maWd1cmUKPiA+ID4gPiB0aGlzIG5pY2VseS4gRE5TIGlzIHNjYXR0ZXJlZCBh
bGwgYXJvdW5kLiBTZXJ2ZXJzIGFyZQo+ID4gPiA+IGNvbmZpZ3VyZWQgaW4KPiA+ID4gPiB0aHJl
ZQo+ID4gPiA+IGRpZmZlcmVudCBwbGFjZXMgZm9yIHN0YXRpYywgREhDUCBvciBQUFAgb24gUkVE
IHdoaWNoCj4gPiA+ID4gYWJzb2x1dGVseQo+ID4gPiA+IG1ha2VzIG5vIHNlbnNlLgo+ID4gPiA+
IFdlIGhhdmUgYSBDR0kgZmlsZSB0aGF0IGFsbG93cyB1c2VycyB0byBzZXQgYWx0ZXJuYXRpdmUg
RE5TCj4gPiA+ID4gc2VydmVycwo+ID4gPiA+IGZvciBESENQCj4gPiA+ID4gd2hpY2ggd2UgY291
bGQgcHJvYmFibHkgdXNlIGFuZCBleHRlbmQgYW5kIHRoZW4gZHJvcCBhbGwgdGhlCj4gPiA+ID4g
b3RoZXIKPiA+ID4gPiB0aGluZ3MuCj4gPiA+ID4gCj4gPiA+ID4gQW55b25lIHVwIGZvciBjb250
cmlidXRpbmcgdG8gdGhpcz8gTXkgc2NoZWR1bGUgaXMgYSBiaXQgdGlnaHQKPiA+ID4gPiByaWdo
dAo+ID4gPiA+IG5vdywgYnV0IEkKPiA+ID4gPiB3b3VsZCBjZXJ0YWlubHkgYmUgaW50ZXJlc3Rl
ZCBpbiB0aGlzLgo+ID4gPiA+IAo+ID4gPiA+IEJlc3QsCj4gPiA+ID4gLU1pY2hhZWwKPiA+ID4g
PiAKPiA+ID4gPiA+IAo+ID4gPiA+ID4gUGF1bAo+ID4gPiA+ID4gCj4gPiA+IAo+ID4gPiBJJ20g
YXZhaWxhYmxlIHRvIGV4cGVyaW1lbnQgYW5kIHRlc3QuIEkndmUgc2V0IHVwIGEgc2Vjb25kIEhE
IGZvcgo+ID4gPiBib290aW5nIGFsdGVybmF0aXZlIGNvbmZpZ3VyYXRpb25zLiBJIHdpbGwgYXR0
ZW1wdCBhIG1pbmltYWwKPiA+ID4gdW5ib3VuZAo+ID4gPiBpbml0LmQgdXNpbmcgVExTLgo+ID4g
Cj4gPiBDb29sLiBJIGd1ZXNzIGEgc3dpdGNoIGluIHRoZSBpbml0c2NyaXB0IHdvdWxkIGJlIGEg
Z29vZCBzdGFydCB0bwo+ID4gdHVybgo+ID4gdGhlIHRscy11cHN0cmVhbTogeWVzIG9wdGlvbiBv
bi4gTm90IHN1cmUgaWYgYW55IG1vcmUgYXJlIG5lZWRlZC4KPiA+IAo+ID4gPiBVbmZvcnR1bmF0
ZWx5LCBDR0kgaXNuJ3QgaW4gbXkgc2tpbGwgc2V0LiBEb2VzIGFueW9uZSBlbHNlIG91dAo+ID4g
PiB0aGVyZQo+ID4gPiBoYXZlIGlucHV0Pwo+ID4gCj4gPiBTb21lIG9mIHRoZW0gYXJlIHF1aXRl
IGNvcHkgYW5kIHBhc3RlLiBUaGlzIG9uZSB3aWxsIGp1c3QgZmV0Y2ggYQo+ID4gZmV3Cj4gPiBz
ZXR0aW5ncyBmcm9tIHRoZSB1c2VyIGFuZCB3cml0ZSB0aGVtIHRvIGEgZmlsZS4gTWF5YmUgY2hl
Y2sgdGhlCj4gPiBmaXJld2FsbCBvcHRpb25zIENHSSBmaWxlIGZvciBpbnNwaXJhdGlvbi4KPiA+
IAo+ID4gQmVzdCwKPiA+IC1NaWNoYWVsCj4gPiAKPiA+ID4gCj4gPiA+IFBhdWwKCi0tIApTdWJ1
cmJpYSBpcyB3aGVyZSB0aGUgZGV2ZWxvcGVyIGJ1bGxkb3plcyBvdXQgdGhlIHRyZWVzLCB0aGVu
IG5hbWVzIHRoZQpzdHJlZXRzIGFmdGVyIHRoZW0uIC0tIEJpbGwgVmF1Z2hu

Re: [Fwd: Re: request for info: unbound via https / tls]

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 552 bytes --]

Hello,

> 
> The unbound init and the cgi scripts use dig 9.11.3, which has no
> native support for TLS.  I'm trying to configure stunnel to act as MITM
> so that dig can succeed.  I hope to restrict unbound to port 853 for
> listen and send, and use stunnel to listen on port 53 and forward to
> 853.

as far as I am aware, the knot-utils from CZ.NIC are capable of
DNS over TLS. Maybe we should think about moving to them, or wait
until bind-utils/dig are updated (not sure if we are running the latest
version anyway).

Best regards,
Peter Müller


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Fwd: Re: request for info: unbound via https / tls]

[Paul Simmons]

[-- Attachment #1: Type: text/plain, Size: 1015 bytes --]

On Tue, 2018-05-01 at 16:40 +0200, Peter Müller wrote:
> Hello,
> 
> > 
> > The unbound init and the cgi scripts use dig 9.11.3, which has no
> > native support for TLS.  I'm trying to configure stunnel to act as
> > MITM
> > so that dig can succeed.  I hope to restrict unbound to port 853
> > for
> > listen and send, and use stunnel to listen on port 53 and forward
> > to
> > 853.
> 
> as far as I am aware, the knot-utils from CZ.NIC are capable of
> DNS over TLS. Maybe we should think about moving to them, or wait
> until bind-utils/dig are updated (not sure if we are running the
> latest
> version anyway).
> 
> Best regards,
> Peter Müller
> 

I don't mind continuing with unbound, as it seems to be in active
development and is well documented.

Based on my (failing) testing, I'm abandoning using stunnel, and will
wait for a version of dig with native TLS support.

Until then, I'm using https://gitlab.com/snippets/1706804 to get around
my (only one available) ISP munging DNS.

Best regards,
Paul

Re: [Fwd: Re: request for info: unbound via https / tls]

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 1580 bytes --]

Hey,

well I would actually like to get rid of as much of that shell stuff in that
initscript as we can. This is just a bit too much testing and no matter how much
we tune that will never be where it should be.

I wrote a little blog post about this today:

  https://www.lightningwirelabs.com/2018/05/03/dns-over-tls-now-available-on-our-resolvers

There is more to come...

Best,
-Michael

On Tue, 2018-05-01 at 12:16 -0500, Paul Simmons wrote:
> On Tue, 2018-05-01 at 16:40 +0200, Peter Müller wrote:
> > Hello,
> > 
> > > 
> > > The unbound init and the cgi scripts use dig 9.11.3, which has no
> > > native support for TLS.  I'm trying to configure stunnel to act as
> > > MITM
> > > so that dig can succeed.  I hope to restrict unbound to port 853
> > > for
> > > listen and send, and use stunnel to listen on port 53 and forward
> > > to
> > > 853.
> > 
> > as far as I am aware, the knot-utils from CZ.NIC are capable of
> > DNS over TLS. Maybe we should think about moving to them, or wait
> > until bind-utils/dig are updated (not sure if we are running the
> > latest
> > version anyway).
> > 
> > Best regards,
> > Peter Müller
> > 
> 
> I don't mind continuing with unbound, as it seems to be in active
> development and is well documented.
> 
> Based on my (failing) testing, I'm abandoning using stunnel, and will
> wait for a version of dig with native TLS support.
> 
> Until then, I'm using https://gitlab.com/snippets/1706804 to get around
> my (only one available) ISP munging DNS.
> 
> Best regards,
> Paul

Re: [Fwd: Re: request for info: unbound via https / tls]

[ummeegge]

[-- Attachment #1: Type: text/plain, Size: 2260 bytes --]

Hi all,
have build knot but needed also

  # Begin knot deps
  lfsmake2 libmaxminddb
  lfsmake2 libedit
  lfsmake2 userspace
  lfsmake2 knot
  # End knot

to build kdig properly. By the usage of e.g.

kdig -d @145.100.185.18 +tls-host=dnsovertls3.sinodun.com ipfire.org

i get an

;; DEBUG: Querying for owner(ipfire.org.), class(1), type(1),
server(145.100.185.18), port(853), protocol(TCP)
;; WARNING: TLS, failed to import system certificates
(GNUTLS_E_UNIMPLEMENTED_FEATURE)
;; WARNING: failed to query server 145.100.185.18(a)853(TCP)

. So it seems that 'gnutls_x509_trust_list_add_trust_file{dir}()' is
not able to find the system certificates. May a

--with-default-trust-store-dir=/etc/ssl/certs

in configure of GnuTLS might help there...

As a beside one, some tests causing DoT happens in here -->
https://forum.ipfire.org/viewtopic.php?f=50&t=21954

whereby Dot runs currently without problems but the focus is in there relies
on the initscript of unbound to make DoT usable over on IPFire.

Have compiled meanwhile also ldns whereby drill is also a possibility 
for other views and there is also a DoT patch for ldns -->

https://portal.sinodun.com/stash/projects/TDNS/repos/dns-over-tls_patches/browse/ldns-1.6.17_dns-over-tls.patch

https://tools.ietf.org/html/draft-ietf-dprive-dns-over-tls-09#section-8.2

but the versions are outdated even unbound needs also to be patched.
May NLnet Labs did there already something to support that but i haven´t found it yet.

Some infos from here.

Best,

Erik
 

Am Dienstag, den 01.05.2018, 16:40 +0200 schrieb Peter Müller:
> Hello,
> 
> > 
> > The unbound init and the cgi scripts use dig 9.11.3, which has no
> > native support for TLS.  I'm trying to configure stunnel to act as
> > MITM
> > so that dig can succeed.  I hope to restrict unbound to port 853
> > for
> > listen and send, and use stunnel to listen on port 53 and forward
> > to
> > 853.
> 
> as far as I am aware, the knot-utils from CZ.NIC are capable of
> DNS over TLS. Maybe we should think about moving to them, or wait
> until bind-utils/dig are updated (not sure if we are running the
> latest
> version anyway).
> 
> Best regards,
> Peter Müller
> 

Re: [Fwd: Re: request for info: unbound via https / tls]

[Paul Simmons]

[-- Attachment #1: Type: text/plain, Size: 2814 bytes --]

On Sun, 2018-12-02 at 20:10 +0100, ummeegge wrote:
> Hi all,
> have build knot but needed also
> 
>   # Begin knot deps
>   lfsmake2 libmaxminddb
>   lfsmake2 libedit
>   lfsmake2 userspace
>   lfsmake2 knot
>   # End knot
> 
> to build kdig properly. By the usage of e.g.
> 
> kdig -d @145.100.185.18 +tls-host=dnsovertls3.sinodun.com ipfire.org
> 
> i get an
> 
> ;; DEBUG: Querying for owner(ipfire.org.), class(1), type(1),
> server(145.100.185.18), port(853), protocol(TCP)
> ;; WARNING: TLS, failed to import system certificates
> (GNUTLS_E_UNIMPLEMENTED_FEATURE)
> ;; WARNING: failed to query server 145.100.185.18(a)853(TCP)
> 
> . So it seems that 'gnutls_x509_trust_list_add_trust_file{dir}()' is
> not able to find the system certificates. May a
> 
> --with-default-trust-store-dir=/etc/ssl/certs
> 
> in configure of GnuTLS might help there...
> 
> As a beside one, some tests causing DoT happens in here -->
> https://forum.ipfire.org/viewtopic.php?f=50&t=21954
> 
> whereby Dot runs currently without problems but the focus is in there
> relies
> on the initscript of unbound to make DoT usable over on IPFire.
> 
> Have compiled meanwhile also ldns whereby drill is also a
> possibility 
> for other views and there is also a DoT patch for ldns -->
> 
> 
https://portal.sinodun.com/stash/projects/TDNS/repos/dns-over-tls_patches/browse/ldns-1.6.17_dns-over-tls.patch
> 
> 
https://tools.ietf.org/html/draft-ietf-dprive-dns-over-tls-09#section-8.2
> 
> but the versions are outdated even unbound needs also to be patched.
> May NLnet Labs did there already something to support that but i
> haven´t found it yet.
> 
> Some infos from here.
> 
> Best,
> 
> Erik
>  
> 
> Am Dienstag, den 01.05.2018, 16:40 +0200 schrieb Peter Müller:
> > Hello,
> > 
> > > 
> > > The unbound init and the cgi scripts use dig 9.11.3, which has no
> > > native support for TLS.  I'm trying to configure stunnel to act
> > > as
> > > MITM
> > > so that dig can succeed.  I hope to restrict unbound to port 853
> > > for
> > > listen and send, and use stunnel to listen on port 53 and forward
> > > to
> > > 853.
> > 
> > as far as I am aware, the knot-utils from CZ.NIC are capable of
> > DNS over TLS. Maybe we should think about moving to them, or wait
> > until bind-utils/dig are updated (not sure if we are running the
> > latest
> > version anyway).
> > 
> > Best regards,
> > Peter Müller
> > 
> 
> 

Hello, Erik.  My "admin-foo" has weakened over the years, and my
"developer-foo" is even worse.

Thank you for pursuing DoT on IPFire, as I hope it will circumvent my
ISPs mangling of DNS queries, and allow easier upgrade to current
releases.

Best regards,
Paul
-- 
I would if I could, but I can't so I won't.

Re: [Fwd: Re: request for info: unbound via https / tls]

[ummeegge]

[-- Attachment #1: Type: text/plain, Size: 930 bytes --]

Hi Paul,
and thanks for your positive feedback.
Wrote now all togehter for better overview but also for better overview
of open questions.

You can find in here --> https://gitlab.com/ummeegge/dot-for-ipfire 
the actual state + a simple in- uninstaller helper, i hoped it is 
then may also a little easier for people without "developer|admin-foo" to go 
for some testing rounds ;-).

ldns (which includes drill) can be found in here -->
https://people.ipfire.org/~ummeegge/ldns/ .

Since this topic here is also an older one, i´ am not sure if there is interest anymore in DoT or DoH.

Let´s see.

Best,

Erik

> 
> Hello, Erik.  My "admin-foo" has weakened over the years, and my
> "developer-foo" is even worse.
> 
> Thank you for pursuing DoT on IPFire, as I hope it will circumvent my
> ISPs mangling of DNS queries, and allow easier upgrade to current
> releases.
> 
> Best regards,
> Paul

Re: [Fwd: Re: request for info: unbound via https / tls]

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 1379 bytes --]

Hello Erik,

> Hi Paul,
> and thanks for your positive feedback.
> Wrote now all togehter for better overview but also for better overview
> of open questions.
> 
> You can find in here --> https://gitlab.com/ummeegge/dot-for-ipfire 
> the actual state + a simple in- uninstaller helper, i hoped it is 
> then may also a little easier for people without "developer|admin-foo" to go 
> for some testing rounds ;-).
> 
> ldns (which includes drill) can be found in here -->
> https://people.ipfire.org/~ummeegge/ldns/ .
> 
> Since this topic here is also an older one, i´ am not sure if there is interest anymore in DoT or DoH.
I am pretty sure there is still huge interest in adding DoT support to
IPFire - in my point of view, yesterdays telephone conference showed
this again.

Our problem seems to be a lack of coordination: You are developing
pretty much (OpenSSL 1.1.1 comes to my mind), which is simply great.
I can only speak for myself here, but do not have any overview about
what these are in detail. :-)

Maybe joining a telco might help (nudge, nudge). :-)

Thanks, and best regards,
Peter Müller
> 
> Let´s see.
> 
> Best,
> 
> Erik
> -- 
Microsoft DNS service terminates abnormally when it recieves a response
to a DNS query that was never made.  Fix Information: Run your DNS
service on a different platform.
		-- bugtraq

Re: [Fwd: Re: request for info: unbound via https / tls]

[ummeegge]

[-- Attachment #1: Type: text/plain, Size: 1363 bytes --]

Hello Peter,
and thanks for your response.

Am Dienstag, den 04.12.2018, 17:19 +0100 schrieb Peter Müller:
> I am pretty sure there is still huge interest in adding DoT support
> to
> IPFire - in my point of view, yesterdays telephone conference showed
> this again.
> 
Good to here. Wanted to be part of the last conference but my jobsite
have had other plans.

> Our problem seems to be a lack of coordination: You are developing
> pretty much (OpenSSL 1.1.1 comes to my mind), which is simply great.
I do not really see a lack of coordination here or are somebody else
working on DoT currently ? 
OpenSSL-1.1.1 might be a good/important
addition to DoT --> 

https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-02
--> https://blog.cloudflare.com/encrypted-sni/ which brings also some 
other interesting side affects --> 
https://www.dnsthingy.com/2018/10/encrypted-sni-death-blow-to-transparent-filtering/ 
...

> I can only speak for myself here, but do not have any overview about
> what these are in detail. :-)
> 
Not 100% sure what you mean, are you mean an overview of other projects
which i am currently working one ?


> Maybe joining a telco might help (nudge, nudge). :-)
> 
I hear you :D .
Looking forward for more_action/more_people or in general for more
response/help in this topic.

Best,

Erik

Re: [Fwd: Re: request for info: unbound via https / tls]

[ummeegge]

[-- Attachment #1: Type: text/plain, Size: 133 bytes --]

Hi all,
some news in this topic can be found in here --> 
https://forum.ipfire.org/viewtopic.php?f=50&p=120997#p120997

Best,

Erik

Re: [Fwd: Re: request for info: unbound via https / tls]

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 2312 bytes --]

Hi,

> On 5 Dec 2018, at 07:35, ummeegge <ummeegge(a)ipfire.org> wrote:
> 
> Hello Peter,
> and thanks for your response.
> 
> Am Dienstag, den 04.12.2018, 17:19 +0100 schrieb Peter Müller:
>> I am pretty sure there is still huge interest in adding DoT support
>> to
>> IPFire - in my point of view, yesterdays telephone conference showed
>> this again.
>> 
> Good to here. Wanted to be part of the last conference but my jobsite
> have had other plans.
> 
>> Our problem seems to be a lack of coordination: You are developing
>> pretty much (OpenSSL 1.1.1 comes to my mind), which is simply great.
> I do not really see a lack of coordination here or are somebody else
> working on DoT currently ? 
> OpenSSL-1.1.1 might be a good/important
> addition to DoT --> 
> 
> https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-02
> --> https://blog.cloudflare.com/encrypted-sni/ which brings also some 
> other interesting side affects --> 
> https://www.dnsthingy.com/2018/10/encrypted-sni-death-blow-to-transparent-filtering/ 
> ...
> 
>> I can only speak for myself here, but do not have any overview about
>> what these are in detail. :-)
>> 
> Not 100% sure what you mean, are you mean an overview of other projects
> which i am currently working one ?
> 
> 
>> Maybe joining a telco might help (nudge, nudge). :-)
>> 
> I hear you :D .
> Looking forward for more_action/more_people or in general for more
> response/help in this topic.

I am not sure what you are looking for. But I just wanted to say that I am following this conversation.

So far I think that there are indeed many people interested in DoT. However, I have not received any feedback on what I was mailing before.

I think what is best now is to get this into small patches. What needs to be done to get this UI ready so that people can add those DNS servers? What will the default behaviour be? How will we make sure that the system does not fall back (to unauthenticated DNS)?

I think that we can leave OpenSSL 1.1.1 aside for this for now, because it works perfectly fine with TLS 1.2. We should not mix multiple things together when they have no strict dependency (although I am really looking forward to see TLS 1.3 in IPFire soon).

Best,
-Michael

> Best,
> 
> Erik
> 

Re: [Fwd: Re: request for info: unbound via https / tls]

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 405 bytes --]

I did not understand what the news is here, but please try to keep the conversation on the list when it has started there. I do not regularly read the forums.

-Michael

> On 9 Dec 2018, at 20:08, ummeegge <ummeegge(a)ipfire.org> wrote:
> 
> Hi all,
> some news in this topic can be found in here --> 
> https://forum.ipfire.org/viewtopic.php?f=50&p=120997#p120997
> 
> Best,
> 
> Erik
> 

Re: [Fwd: Re: request for info: unbound via https / tls]

[ummeegge]

[-- Attachment #1: Type: text/plain, Size: 2453 bytes --]

Hi Michael,

Am Montag, den 10.12.2018, 00:21 +0000 schrieb Michael Tremer:
> I did not understand what the news is here,

the main news for me was that i´ ve build knot (kdig) and a deeper look
into the whole DNS-over-TLS subject and a debugging in general of DoT
is now better possible. The next news was that i wrote a script which
checks the configured DoT servers via kdig for a better overview which
servers are reliable.
Since i do not use Quad9 nor Cloudflair which are currently the only
one to my knowledge that are not outlined as not experimental) -->
https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Public+Resolvers
public resolvers i wanted to check what´s going on with all the experimental ones --> 
https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers#DNSPrivacyTestServers-DoTservers
therefor this step was important for me and i decided to share it here with you.

Have update also the DoT configuration file to now 12 DNS test servers which worked now since
~ 2 weeks without problems. Needed also to throw some others out which causes problems
since some certificate where not trustworthy or DNSSEC validation doesn´t worked.

May you ask yourself why on earth 12 DNS servers ? Well, another testing field for me is
not only encryption in that topic but also randomization -->
https://www.monperrus.net/martin/randomization-encryption-dns-requests -->
https://www.ctrl.blog/entry/kresd-random-dns-forwarding
which unbound offers via 'rrset-roundrobin: yes' as a default value on
IPFire but along my testings i could figure out that it only works with DoT not with 
regular DNS, for reference test see here -->
https://forum.ipfire.org/viewtopic.php?f=6&t=21866#p120276

This are currently my main news, but there is more which i wrote in the
forum but also on Gitlab in the README.

>  but please try to keep the conversation on the list when it has
> started there. I do not regularly read the forums.

Yes i know and will do this too but as ever i try to invite the
community also via forum to go for testings/sharing_information which,
also as usual, do not works very well.

Best,

Erik

> 
> -Michael
> 
> > On 9 Dec 2018, at 20:08, ummeegge <ummeegge(a)ipfire.org> wrote:
> > 
> > Hi all,
> > some news in this topic can be found in here --> 
> > https://forum.ipfire.org/viewtopic.php?f=50&p=120997#p120997
> > 
> > Best,
> > 
> > Erik
> > 
> 
> 

Re: [Fwd: Re: request for info: unbound via https / tls]

[ummeegge]

[-- Attachment #1: Type: text/plain, Size: 2702 bytes --]

Hi Michael,

Am Montag, den 10.12.2018, 00:21 +0000 schrieb Michael Tremer:

> I am not sure what you are looking for. 
Mainly for testing people which take also a look over the changes in 
unbound initscript. Since the 'update_forwarders()' function from
unbound init will currently not be used if custom forwarders are in
usage.
'update_forwarders()' includes really a lot of other functions and it
was/is not that easy to check for all possible side affects if this
function will be bypassed and substituded by another one (cue: DNSSEC,
EDNS, ...). All changes causing the unbound initscript can be found in
here -->
https://gitlab.com/ummeegge/dot-for-ipfire/commits/master/unbound
.

Another point i am currently looking for is the question, if unbound is
the best possibility for DoT ? If you take look into the current
implementation status -->
https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Implementation+Status
unbound misses also some other DoT related features.
Am building currently GetDNS and Stubby just to get there also a better 
inside of the differences.

Also, integrating DoT into webuserinterface is, as before mentioned in
here, a point. Should DoT become it´s own one, or is it a complete new
WUI menu point worth ?

In my humble opinion this DoT topic is still pretty much in a testing
phase not only speaking for myself but also looking around and finding
only two (may three) stable DoT providers speaks, i think, also a
little for itself.

> But I just wanted to say that I am following this conversation.

That´s great.

> 
> So far I think that there are indeed many people interested in DoT.
> However, I have not received any feedback on what I was mailing
> before.
> 
I hope some feedback comes around also since i am currently testing it 
for a couple of weeks now and posted the results/code_changes in the
forum and some also in here.

> I think what is best now is to get this into small patches. What
> needs to be done to get this UI ready so that people can add those
> DNS servers? What will the default behaviour be? How will we make
> sure that the system does not fall back (to unauthenticated DNS)?
> 
That´s the fundamental question, please see the above statements.


> I think that we can leave OpenSSL 1.1.1 aside for this for now,
> because it works perfectly fine with TLS 1.2. We should not mix
> multiple things together when they have no strict dependency
> (although I am really looking forward to see TLS 1.3 in IPFire soon).
> 
OpenSSL-1.1.1 and TLS 1.3 fits perfectly into this topic and i hope i
can install today the new OpenSSL and to test it in my productive
environment.


> Best,
> -Michael
> 
> > Best,
> > 
> > Erik
> > 
> 
> 

Re: [Fwd: Re: request for info: unbound via https / tls]

[ummeegge]

[-- Attachment #1: Type: text/plain, Size: 601 bytes --]

A question,
what happens with DoT on Lightningwirelabs -->
https://www.lightningwirelabs.com/2018/05/03/dns-over-tls-now-available-on-our-resolvers ?
I get there an

$ kdig -d @81.3.27.54 +tls-ca=/etc/ssl/certs/ca-bundle.crt +tls-host="ns1.lightningwirelabs.com" google.com;
;; DEBUG: Querying for owner(google.com.), class(1), type(1), server(81.3.27.54), port(853), protocol(TCP)
;; DEBUG: TLS, imported 128 certificates from '/etc/ssl/certs/ca-bundle.crt'
;; WARNING: can't connect to 81.3.27.54(a)853(TCP)
;; WARNING: failed to query server 81.3.27.54(a)853(TCP)

.

Best,

Erik

Re: [Fwd: Re: request for info: unbound via https / tls]

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 946 bytes --]

Hey,

Thanks for reporting.

> On 10 Dec 2018, at 12:32, ummeegge <ummeegge(a)ipfire.org> wrote:
> 
> A question,
> what happens with DoT on Lightningwirelabs -->
> https://www.lightningwirelabs.com/2018/05/03/dns-over-tls-now-available-on-our-resolvers ?
> I get there an
> 
> $ kdig -d @81.3.27.54 +tls-ca=/etc/ssl/certs/ca-bundle.crt +tls-host="ns1.lightningwirelabs.com" google.com;
> ;; DEBUG: Querying for owner(google.com.), class(1), type(1), server(81.3.27.54), port(853), protocol(TCP)
> ;; DEBUG: TLS, imported 128 certificates from '/etc/ssl/certs/ca-bundle.crt'
> ;; WARNING: can't connect to 81.3.27.54(a)853(TCP)
> ;; WARNING: failed to query server 81.3.27.54(a)853(TCP)

I recently made a change which caused that unbound didn’t listen on the TLS port any more.

I fixed that now.

The correct host name for that server is rec1.dns.lightningwirelabs.com.

-Michael

> .
> 
> Best,
> 
> Erik
> 

Re: [Fwd: Re: request for info: unbound via https / tls]

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 4706 bytes --]

Hey,

> On 10 Dec 2018, at 12:14, ummeegge <ummeegge(a)ipfire.org> wrote:
> 
> Hi Michael,
> 
> Am Montag, den 10.12.2018, 00:21 +0000 schrieb Michael Tremer:
> 
>> I am not sure what you are looking for. 
> Mainly for testing people which take also a look over the changes in 
> unbound initscript. Since the 'update_forwarders()' function from
> unbound init will currently not be used if custom forwarders are in
> usage.
> 'update_forwarders()' includes really a lot of other functions and it
> was/is not that easy to check for all possible side affects if this
> function will be bypassed and substituded by another one (cue: DNSSEC,
> EDNS, ...). All changes causing the unbound initscript can be found in
> here -->
> https://gitlab.com/ummeegge/dot-for-ipfire/commits/master/unbound
> .
> 
> Another point i am currently looking for is the question, if unbound is
> the best possibility for DoT ? If you take look into the current
> implementation status -->
> https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Implementation+Status
> unbound misses also some other DoT related features.
> Am building currently GetDNS and Stubby just to get there also a better 
> inside of the differences.

Those are just stub resolvers and no proxies. Out of the proxies unbound might not have the most ticks looking at the TLS features, but I do not see that as a problem. None of them are a must and unbound is under development. I am sure those will come.

> Also, integrating DoT into webuserinterface is, as before mentioned in
> here, a point. Should DoT become it´s own one, or is it a complete new
> WUI menu point worth ?

This is essential.

I do not think that it should add another CGI, because we already have a DNS CGI script that we can use and extend.

> In my humble opinion this DoT topic is still pretty much in a testing
> phase not only speaking for myself but also looking around and finding
> only two (may three) stable DoT providers speaks, i think, also a
> little for itself.

Yes, I agree. It is a new “feature” that was used to market Cloudflare’s DNS. Showing that they “care" about privacy.

However, I think that this is not beta software any more, we can run this on larger scale and it solves a problem that existed before and is a nice solution to it, too.

If IPFire wants to be bleeding-edge that we have to have this feature at some point.

>> But I just wanted to say that I am following this conversation.
> 
> That´s great.
> 
>> 
>> So far I think that there are indeed many people interested in DoT.
>> However, I have not received any feedback on what I was mailing
>> before.
>> 
> I hope some feedback comes around also since i am currently testing it 
> for a couple of weeks now and posted the results/code_changes in the
> forum and some also in here.

Yeah, I am not sure what I should be testing now. There is a bunch of software packages and there is a bunch of changes to scripts. This isn’t really ready for testing yet is it?

I guess we should think about a strategy about which features we want to have in a first alpha stage and then have those agreed, implemented and then sent out in one package for testing. That makes it a lot easier.

So I am thinking about this:

* Make unbound ready for DNS-over-TLS (I believe that that is almost the case)

* Change the scripts that write forwarders.conf. I do not think that we should perform DNSSEC checks on the DNS-over-TLS resolvers.

* Extend the CGI that we can enter the IP addresses and host names

What else do we need?

> 
>> I think what is best now is to get this into small patches. What
>> needs to be done to get this UI ready so that people can add those
>> DNS servers? What will the default behaviour be? How will we make
>> sure that the system does not fall back (to unauthenticated DNS)?
>> 
> That´s the fundamental question, please see the above statements.
> 
> 
>> I think that we can leave OpenSSL 1.1.1 aside for this for now,
>> because it works perfectly fine with TLS 1.2. We should not mix
>> multiple things together when they have no strict dependency
>> (although I am really looking forward to see TLS 1.3 in IPFire soon).
>> 
> OpenSSL-1.1.1 and TLS 1.3 fits perfectly into this topic and i hope i
> can install today the new OpenSSL and to test it in my productive
> environment.

So far we don’t have OpenSSL 1.1.1. I think focussing on one at a time allows to develop this quicker.

I am not even sure if any of the resolvers support TLS 1.3 today.

Best,
-Michael

> 
> 
>> Best,
>> -Michael
>> 
>>> Best,
>>> 
>>> Erik
>>> 
>> 
>> 
> 

Re: [Fwd: Re: request for info: unbound via https / tls]

[ummeegge]

[-- Attachment #1: Type: text/plain, Size: 2125 bytes --]

Great that you looked over it, have tested it again and the kdig report
differs which looks now like this:

;; DEBUG: Querying for owner(google.com.), class(1), type(1),
server(81.3.27.54), port(853), protocol(TCP)
;; DEBUG: TLS, imported 128 certificates from '/etc/ssl/certs/ca-
bundle.crt'
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, CN=rec1.dns.lightningwirelabs.com
;; DEBUG:      SHA-256 PIN:
ZayzRhKLRWLL7v9QC0uEJEMomE572oNUuF4ocAxDQ7E=
;; DEBUG:  #2, C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
;; DEBUG:      SHA-256 PIN:
YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is NOT trusted. The certificate requires
the server to include an OCSP status in its response, but the OCSP
status is missing. 
;; WARNING: TLS, handshake failed (Error in the certificate.)
;; WARNING: failed to query server 81.3.27.54(a)853(TCP)

Exit status: 0

May this is helpful for you.

Best,

Erik

Am Montag, den 10.12.2018, 13:26 +0000 schrieb Michael Tremer:
> Hey,
> 
> Thanks for reporting.
> 
> > On 10 Dec 2018, at 12:32, ummeegge <ummeegge(a)ipfire.org> wrote:
> > 
> > A question,
> > what happens with DoT on Lightningwirelabs -->
> > 
https://www.lightningwirelabs.com/2018/05/03/dns-over-tls-now-available-on-our-resolvers
> >  ?
> > I get there an
> > 
> > $ kdig -d @81.3.27.54 +tls-ca=/etc/ssl/certs/ca-bundle.crt +tls-
> > host="ns1.lightningwirelabs.com" google.com;
> > ;; DEBUG: Querying for owner(google.com.), class(1), type(1),
> > server(81.3.27.54), port(853), protocol(TCP)
> > ;; DEBUG: TLS, imported 128 certificates from '/etc/ssl/certs/ca-
> > bundle.crt'
> > ;; WARNING: can't connect to 81.3.27.54(a)853(TCP)
> > ;; WARNING: failed to query server 81.3.27.54(a)853(TCP)
> 
> I recently made a change which caused that unbound didn’t listen on
> the TLS port any more.
> 
> I fixed that now.
> 
> The correct host name for that server is
> rec1.dns.lightningwirelabs.com.
> 
> -Michael
> 
> > .
> > 
> > Best,
> > 
> > Erik
> > 
> 
> 

Re: [Fwd: Re: request for info: unbound via https / tls]

[Paul Simmons]

[-- Attachment #1: Type: text/plain, Size: 3633 bytes --]

On Mon, 2018-12-10 at 13:14 +0100, ummeegge wrote:
> Hi Michael,
> 
> Am Montag, den 10.12.2018, 00:21 +0000 schrieb Michael Tremer:
> 
> > I am not sure what you are looking for. 
> 
> Mainly for testing people which take also a look over the changes in 
> unbound initscript. Since the 'update_forwarders()' function from
> unbound init will currently not be used if custom forwarders are in
> usage.
> 'update_forwarders()' includes really a lot of other functions and it
> was/is not that easy to check for all possible side affects if this
> function will be bypassed and substituded by another one (cue:
> DNSSEC,
> EDNS, ...). All changes causing the unbound initscript can be found
> in
> here -->
> https://gitlab.com/ummeegge/dot-for-ipfire/commits/master/unbound
> .
> 
> Another point i am currently looking for is the question, if unbound
> is
> the best possibility for DoT ? If you take look into the current
> implementation status -->
> 
https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Implementation+Status
> unbound misses also some other DoT related features.
> Am building currently GetDNS and Stubby just to get there also a
> better 
> inside of the differences.
> 
> Also, integrating DoT into webuserinterface is, as before mentioned
> in
> here, a point. Should DoT become it´s own one, or is it a complete
> new
> WUI menu point worth ?
> 
> In my humble opinion this DoT topic is still pretty much in a testing
> phase not only speaking for myself but also looking around and
> finding
> only two (may three) stable DoT providers speaks, i think, also a
> little for itself.
> 
> > But I just wanted to say that I am following this conversation.
> 
> That´s great.
> 
> > 
> > So far I think that there are indeed many people interested in DoT.
> > However, I have not received any feedback on what I was mailing
> > before.
> > 
> 
> I hope some feedback comes around also since i am currently testing
> it 
> for a couple of weeks now and posted the results/code_changes in the
> forum and some also in here.
> 
> > I think what is best now is to get this into small patches. What
> > needs to be done to get this UI ready so that people can add those
> > DNS servers? What will the default behaviour be? How will we make
> > sure that the system does not fall back (to unauthenticated DNS)?
> > 
> 
> That´s the fundamental question, please see the above statements.
> 
> 
> > I think that we can leave OpenSSL 1.1.1 aside for this for now,
> > because it works perfectly fine with TLS 1.2. We should not mix
> > multiple things together when they have no strict dependency
> > (although I am really looking forward to see TLS 1.3 in IPFire
> > soon).
> > 
> 
> OpenSSL-1.1.1 and TLS 1.3 fits perfectly into this topic and i hope i
> can install today the new OpenSSL and to test it in my productive
> environment.
> 
> 
> > Best,
> > -Michael
> > 
> > > Best,
> > > 
> > > Erik
> > > 
> > 
> > 
> 
> 

Greetings, Erik.

I am VERY pleased that you are pursuing DoT.

I have a test environment prepared, and hope to test your changes on
top of Core125 in the next few days.

I started this thread because my (one and only available) ISP mangles
DNS on port 53, preventing DNSSEC with IPFire.  I want to use my IPFire
machine without applying https://gitlab.com/snippets/1706804 on each
update.

Please continue with your pursuits and development. I will schedule
down time to test.

Thanks, and best regards,
Paul

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Re: [Fwd: Re: request for info: unbound via https / tls]

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 2387 bytes --]

Hey,

Could you try that again? I removed the OCSP must-staple flag from the certificate.

-Michael

> On 10 Dec 2018, at 14:37, ummeegge <ummeegge(a)ipfire.org> wrote:
> 
> Great that you looked over it, have tested it again and the kdig report
> differs which looks now like this:
> 
> ;; DEBUG: Querying for owner(google.com.), class(1), type(1),
> server(81.3.27.54), port(853), protocol(TCP)
> ;; DEBUG: TLS, imported 128 certificates from '/etc/ssl/certs/ca-
> bundle.crt'
> ;; DEBUG: TLS, received certificate hierarchy:
> ;; DEBUG:  #1, CN=rec1.dns.lightningwirelabs.com
> ;; DEBUG:      SHA-256 PIN:
> ZayzRhKLRWLL7v9QC0uEJEMomE572oNUuF4ocAxDQ7E=
> ;; DEBUG:  #2, C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
> ;; DEBUG:      SHA-256 PIN:
> YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
> ;; DEBUG: TLS, skipping certificate PIN check
> ;; DEBUG: TLS, The certificate is NOT trusted. The certificate requires
> the server to include an OCSP status in its response, but the OCSP
> status is missing. 
> ;; WARNING: TLS, handshake failed (Error in the certificate.)
> ;; WARNING: failed to query server 81.3.27.54(a)853(TCP)
> 
> Exit status: 0
> 
> May this is helpful for you.
> 
> Best,
> 
> Erik
> 
> Am Montag, den 10.12.2018, 13:26 +0000 schrieb Michael Tremer:
>> Hey,
>> 
>> Thanks for reporting.
>> 
>>> On 10 Dec 2018, at 12:32, ummeegge <ummeegge(a)ipfire.org> wrote:
>>> 
>>> A question,
>>> what happens with DoT on Lightningwirelabs -->
>>> 
> https://www.lightningwirelabs.com/2018/05/03/dns-over-tls-now-available-on-our-resolvers
>>> ?
>>> I get there an
>>> 
>>> $ kdig -d @81.3.27.54 +tls-ca=/etc/ssl/certs/ca-bundle.crt +tls-
>>> host="ns1.lightningwirelabs.com" google.com;
>>> ;; DEBUG: Querying for owner(google.com.), class(1), type(1),
>>> server(81.3.27.54), port(853), protocol(TCP)
>>> ;; DEBUG: TLS, imported 128 certificates from '/etc/ssl/certs/ca-
>>> bundle.crt'
>>> ;; WARNING: can't connect to 81.3.27.54(a)853(TCP)
>>> ;; WARNING: failed to query server 81.3.27.54(a)853(TCP)
>> 
>> I recently made a change which caused that unbound didn’t listen on
>> the TLS port any more.
>> 
>> I fixed that now.
>> 
>> The correct host name for that server is
>> rec1.dns.lightningwirelabs.com.
>> 
>> -Michael
>> 
>>> .
>>> 
>>> Best,
>>> 
>>> Erik
>>> 
>> 
>> 
> 

Re: [Fwd: Re: request for info: unbound via https / tls]

[ummeegge]

[-- Attachment #1: Type: text/plain, Size: 4540 bytes --]

Hi Michael,
tried that now with this one -->
https://people.ipfire.org/~ummeegge/screenshoots/dns-over-tls_wui.png

... the HTML formatting kills me :D ...

and it looks now good:

$ kdig -d @81.3.27.54 +tls-ca=/etc/ssl/certs/ca-bundle.crt +tls-host=rec1.dns.lightningwirelabs.com google.com
;; DEBUG: Querying for owner(google.com.), class(1), type(1), server(81.3.27.54), port(853), protocol(TCP)
;; DEBUG: TLS, imported 129 certificates from '/etc/ssl/certs/ca-bundle.crt'
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, CN=rec1.dns.lightningwirelabs.com
;; DEBUG:      SHA-256 PIN: pOvVkJSj6rWNPM0vR3hoJr/21kZI6TfImhowIEdcEUQ=
;; DEBUG:  #2, C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
;; DEBUG:      SHA-256 PIN: YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted. 
;; TLS session (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(CHACHA20-POLY1305)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 1349
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 4096 B; ext-rcode: NOERROR

;; QUESTION SECTION:
;; google.com.         		IN	A

;; ANSWER SECTION:
google.com.         	151	IN	A	216.58.208.46

;; Received 55 B
;; Time 2018-12-11 20:30:29 CET
;; From 81.3.27.54(a)853(TCP) in 25.2 ms



Great, will update my dot.conf. 

As a beneath one, try it currently with a seperat CGI to have a better overview. 
Patched now as you suggested the 'write_forward_conf()' function, needed to disable 
nevertheless update_forwarder() function in initscript if forward.conf should be used
... (there is more)

Come back if things are cleaned/cleared up a little more but also better tested.

Best,

Erik



Am Dienstag, den 11.12.2018, 19:22 +0000 schrieb Michael Tremer:
> Hey,
> 
> Could you try that again? I removed the OCSP must-staple flag from
> the certificate.
> 
> -Michael
> 
> > On 10 Dec 2018, at 14:37, ummeegge <ummeegge(a)ipfire.org> wrote:
> > 
> > Great that you looked over it, have tested it again and the kdig
> > report
> > differs which looks now like this:
> > 
> > ;; DEBUG: Querying for owner(google.com.), class(1), type(1),
> > server(81.3.27.54), port(853), protocol(TCP)
> > ;; DEBUG: TLS, imported 128 certificates from '/etc/ssl/certs/ca-
> > bundle.crt'
> > ;; DEBUG: TLS, received certificate hierarchy:
> > ;; DEBUG:  #1, CN=rec1.dns.lightningwirelabs.com
> > ;; DEBUG:      SHA-256 PIN:
> > ZayzRhKLRWLL7v9QC0uEJEMomE572oNUuF4ocAxDQ7E=
> > ;; DEBUG:  #2, C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
> > ;; DEBUG:      SHA-256 PIN:
> > YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
> > ;; DEBUG: TLS, skipping certificate PIN check
> > ;; DEBUG: TLS, The certificate is NOT trusted. The certificate
> > requires
> > the server to include an OCSP status in its response, but the OCSP
> > status is missing. 
> > ;; WARNING: TLS, handshake failed (Error in the certificate.)
> > ;; WARNING: failed to query server 81.3.27.54(a)853(TCP)
> > 
> > Exit status: 0
> > 
> > May this is helpful for you.
> > 
> > Best,
> > 
> > Erik
> > 
> > Am Montag, den 10.12.2018, 13:26 +0000 schrieb Michael Tremer:
> > > Hey,
> > > 
> > > Thanks for reporting.
> > > 
> > > > On 10 Dec 2018, at 12:32, ummeegge <ummeegge(a)ipfire.org> wrote:
> > > > 
> > > > A question,
> > > > what happens with DoT on Lightningwirelabs -->
> > > > 
> > 
> > 
https://www.lightningwirelabs.com/2018/05/03/dns-over-tls-now-available-on-our-resolvers
> > > > ?
> > > > I get there an
> > > > 
> > > > $ kdig -d @81.3.27.54 +tls-ca=/etc/ssl/certs/ca-bundle.crt
> > > > +tls-
> > > > host="ns1.lightningwirelabs.com" google.com;
> > > > ;; DEBUG: Querying for owner(google.com.), class(1), type(1),
> > > > server(81.3.27.54), port(853), protocol(TCP)
> > > > ;; DEBUG: TLS, imported 128 certificates from
> > > > '/etc/ssl/certs/ca-
> > > > bundle.crt'
> > > > ;; WARNING: can't connect to 81.3.27.54(a)853(TCP)
> > > > ;; WARNING: failed to query server 81.3.27.54(a)853(TCP)
> > > 
> > > I recently made a change which caused that unbound didn’t listen
> > > on
> > > the TLS port any more.
> > > 
> > > I fixed that now.
> > > 
> > > The correct host name for that server is
> > > rec1.dns.lightningwirelabs.com.
> > > 
> > > -Michael
> > > 
> > > > .
> > > > 
> > > > Best,
> > > > 
> > > > Erik
> > > > 
> > > 
> > > 
> 
> 

Re: [Fwd: Re: request for info: unbound via https / tls]

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 5555 bytes --]

Hey,

On 11 Dec 2018, at 19:43, ummeegge <ummeegge(a)ipfire.org> wrote:
> 
> Hi Michael,
> tried that now with this one -->
> https://people.ipfire.org/~ummeegge/screenshoots/dns-over-tls_wui.png

This looks good, but under no circumstances should there be *another* place where to configure DNS servers. We already have three. They need to be unified to one.

> 
> ... the HTML formatting kills me :D ...
> 
> and it looks now good:
> 
> $ kdig -d @81.3.27.54 +tls-ca=/etc/ssl/certs/ca-bundle.crt +tls-host=rec1.dns.lightningwirelabs.com google.com
> ;; DEBUG: Querying for owner(google.com.), class(1), type(1), server(81.3.27.54), port(853), protocol(TCP)
> ;; DEBUG: TLS, imported 129 certificates from '/etc/ssl/certs/ca-bundle.crt'
> ;; DEBUG: TLS, received certificate hierarchy:
> ;; DEBUG:  #1, CN=rec1.dns.lightningwirelabs.com
> ;; DEBUG:      SHA-256 PIN: pOvVkJSj6rWNPM0vR3hoJr/21kZI6TfImhowIEdcEUQ=
> ;; DEBUG:  #2, C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
> ;; DEBUG:      SHA-256 PIN: YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
> ;; DEBUG: TLS, skipping certificate PIN check
> ;; DEBUG: TLS, The certificate is trusted. 
> ;; TLS session (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(CHACHA20-POLY1305)
> ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 1349
> ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1
> 
> ;; EDNS PSEUDOSECTION:
> ;; Version: 0; flags: ; UDP size: 4096 B; ext-rcode: NOERROR
> 
> ;; QUESTION SECTION:
> ;; google.com.         		IN	A
> 
> ;; ANSWER SECTION:
> google.com.         	151	IN	A	216.58.208.46
> 
> ;; Received 55 B
> ;; Time 2018-12-11 20:30:29 CET
> ;; From 81.3.27.54(a)853(TCP) in 25.2 ms

25ms is actually quite good!

> 
> Great, will update my dot.conf. 
> 
> As a beneath one, try it currently with a seperat CGI to have a better overview. 
> Patched now as you suggested the 'write_forward_conf()' function, needed to disable 
> nevertheless update_forwarder() function in initscript if forward.conf should be used
> ... (there is more)
> 

As we talked about before, I think that we can skip the DNSSEC tests entirely. They are more damaging than anything else. That means that we should probably be looking at having a switch somewhere that enables DNS-over-TLS first and then all configured name servers are just used without further tests. In the default configuration that cannot be the case because of the problems we are trying to overcome by this script.

But Erik, please let’s find a strategy first because everything is being implemented. I am absolutely happy that you are doing such good work here, but keep in mind that this needs to be integrated into IPFire in a slow and peer-reviewed way.

-Michael

> Come back if things are cleaned/cleared up a little more but also better tested.
> 
> Best,
> 
> Erik
> 
> 
> 
> Am Dienstag, den 11.12.2018, 19:22 +0000 schrieb Michael Tremer:
>> Hey,
>> 
>> Could you try that again? I removed the OCSP must-staple flag from
>> the certificate.
>> 
>> -Michael
>> 
>>> On 10 Dec 2018, at 14:37, ummeegge <ummeegge(a)ipfire.org> wrote:
>>> 
>>> Great that you looked over it, have tested it again and the kdig
>>> report
>>> differs which looks now like this:
>>> 
>>> ;; DEBUG: Querying for owner(google.com.), class(1), type(1),
>>> server(81.3.27.54), port(853), protocol(TCP)
>>> ;; DEBUG: TLS, imported 128 certificates from '/etc/ssl/certs/ca-
>>> bundle.crt'
>>> ;; DEBUG: TLS, received certificate hierarchy:
>>> ;; DEBUG:  #1, CN=rec1.dns.lightningwirelabs.com
>>> ;; DEBUG:      SHA-256 PIN:
>>> ZayzRhKLRWLL7v9QC0uEJEMomE572oNUuF4ocAxDQ7E=
>>> ;; DEBUG:  #2, C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
>>> ;; DEBUG:      SHA-256 PIN:
>>> YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
>>> ;; DEBUG: TLS, skipping certificate PIN check
>>> ;; DEBUG: TLS, The certificate is NOT trusted. The certificate
>>> requires
>>> the server to include an OCSP status in its response, but the OCSP
>>> status is missing. 
>>> ;; WARNING: TLS, handshake failed (Error in the certificate.)
>>> ;; WARNING: failed to query server 81.3.27.54(a)853(TCP)
>>> 
>>> Exit status: 0
>>> 
>>> May this is helpful for you.
>>> 
>>> Best,
>>> 
>>> Erik
>>> 
>>> Am Montag, den 10.12.2018, 13:26 +0000 schrieb Michael Tremer:
>>>> Hey,
>>>> 
>>>> Thanks for reporting.
>>>> 
>>>>> On 10 Dec 2018, at 12:32, ummeegge <ummeegge(a)ipfire.org> wrote:
>>>>> 
>>>>> A question,
>>>>> what happens with DoT on Lightningwirelabs -->
>>>>> 
>>> 
>>> 
> https://www.lightningwirelabs.com/2018/05/03/dns-over-tls-now-available-on-our-resolvers
>>>>> ?
>>>>> I get there an
>>>>> 
>>>>> $ kdig -d @81.3.27.54 +tls-ca=/etc/ssl/certs/ca-bundle.crt
>>>>> +tls-
>>>>> host="ns1.lightningwirelabs.com" google.com;
>>>>> ;; DEBUG: Querying for owner(google.com.), class(1), type(1),
>>>>> server(81.3.27.54), port(853), protocol(TCP)
>>>>> ;; DEBUG: TLS, imported 128 certificates from
>>>>> '/etc/ssl/certs/ca-
>>>>> bundle.crt'
>>>>> ;; WARNING: can't connect to 81.3.27.54(a)853(TCP)
>>>>> ;; WARNING: failed to query server 81.3.27.54(a)853(TCP)
>>>> 
>>>> I recently made a change which caused that unbound didn’t listen
>>>> on
>>>> the TLS port any more.
>>>> 
>>>> I fixed that now.
>>>> 
>>>> The correct host name for that server is
>>>> rec1.dns.lightningwirelabs.com.
>>>> 
>>>> -Michael
>>>> 
>>>>> .
>>>>> 
>>>>> Best,
>>>>> 
>>>>> Erik
>>>>> 
>>>> 
>>>> 
>> 
>> 
> 

Re: [Fwd: Re: request for info: unbound via https / tls]

[ummeegge]

[-- Attachment #1: Type: text/plain, Size: 2274 bytes --]

Hi Paul,

Am Montag, den 10.12.2018, 20:01 -0600 schrieb Paul Simmons:
> 
> Greetings, Erik.
> 
> I am VERY pleased that you are pursuing DoT.
> 
Your welcome, like that feature too.

> I have a test environment prepared, and hope to test your changes on
> top of Core125 in the next few days.
> 
Great. There are meanwhile two branches here.

The first one is the sysconfig "USE_FORWARDER=0" one which is fully
working and in my opinion also easier/faster to test DoT/unbound for,
let´s say, best practice configuration. Current state can be found
under the already linked Gitlab address.

The second one incl. now the WUI (have stolen/missused dnsforward.cgi
for this ;) but also DoT integration in the already existing
/etc/unbound/forward.conf . In there, i patched now the already
existing 'write_forward_conf' function like Michael suggested --> 

@@ -192,6 +195,27 @@
 	(
 		config_header
 
+		# Add DNS-over-TLS forwarder configuration
+
+		if [ -n "/var/ipfire/dnsforward/tlsconfig" ]; then
+			echo "# DNS-over-TLS configuration block"
+			echo "server:"
+			echo "    tls-cert-bundle: /etc/ssl/certs/ca-bundle.crt"
+			echo
+			echo "forward-zone:"
+			echo "    name: \".\""
+			echo "    forward-tls-upstream: yes"
+		fi
+
+		local enabled domain ip port remark
+		while IFS="," read -r enabled domain ip port remark; do
+			# Line must be enabled
+			[ "${enabled}" = "on"  ] || continue
+			echo "    forward-addr: ${ip}@${port}#${domain}"
+		done < /var/ipfire/dnsforward/tlsconfig
+
+		# DNS Forwarding
+
 		local insecure_zones="${INSECURE_ZONES}"
 
 		local enabled zone server remark


as a first one, this one is currently highly experimental but do works
until now and might be a possible way further.?.


> I started this thread because my (one and only available) ISP mangles
> DNS on port 53, preventing DNSSEC with IPFire.  I want to use my
> IPFire
> machine without applying https://gitlab.com/snippets/1706804 on each
> update.
> 
Please check in general if DoT works for your use case.


> Please continue with your pursuits and development. I will schedule
> down time to test.
> 
Let´s see what we can all stick together in here :-) . Great that you
test all that too.


> Thanks, and best regards,
> Paul
> 

Thank you too. 

Best,

Erik

Re: [Fwd: Re: request for info: unbound via https / tls]

[ummeegge]

[-- Attachment #1: Type: text/plain, Size: 5693 bytes --]

Hi Michael,

Am Dienstag, den 11.12.2018, 19:54 +0000 schrieb Michael Tremer:
> Hey,
> 
> On 11 Dec 2018, at 19:43, ummeegge <ummeegge(a)ipfire.org> wrote:
> > 
> > Hi Michael,
> > tried that now with this one -->
> > 
https://people.ipfire.org/~ummeegge/screenshoots/dns-over-tls_wui.png
> 
> This looks good, but under no circumstances should there be *another*
> place where to configure DNS servers.
Sure. I need to check for myself how this can be accomplished so i take
it step-by-step and with a clear CGI it is simply easier for me.


>  We already have three. They need to be unified to one.
You mean dns.cgi and dnsforward.cgi ?

> 
> > 
> > ... the HTML formatting kills me :D ...
> > 
> > and it looks now good:
> > 
> > $ kdig -d @81.3.27.54 +tls-ca=/etc/ssl/certs/ca-bundle.crt +tls-
> > host=rec1.dns.lightningwirelabs.com google.com
> > ;; DEBUG: Querying for owner(google.com.), class(1), type(1),
> > server(81.3.27.54), port(853), protocol(TCP)
> > ;; DEBUG: TLS, imported 129 certificates from '/etc/ssl/certs/ca-
> > bundle.crt'
> > ;; DEBUG: TLS, received certificate hierarchy:
> > ;; DEBUG:  #1, CN=rec1.dns.lightningwirelabs.com
> > ;; DEBUG:      SHA-256 PIN:
> > pOvVkJSj6rWNPM0vR3hoJr/21kZI6TfImhowIEdcEUQ=
> > ;; DEBUG:  #2, C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
> > ;; DEBUG:      SHA-256 PIN:
> > YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
> > ;; DEBUG: TLS, skipping certificate PIN check
> > ;; DEBUG: TLS, The certificate is trusted. 
> > ;; TLS session (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(CHACHA20-POLY1305)
> > ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 1349
> > ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL:
> > 1
> > 
> > ;; EDNS PSEUDOSECTION:
> > ;; Version: 0; flags: ; UDP size: 4096 B; ext-rcode: NOERROR
> > 
> > ;; QUESTION SECTION:
> > ;; google.com.         		IN	A
> > 
> > ;; ANSWER SECTION:
> > google.com.         	151	IN	A	216.58.208.46
> > 
> > ;; Received 55 B
> > ;; Time 2018-12-11 20:30:29 CET
> > ;; From 81.3.27.54(a)853(TCP) in 25.2 ms
> 
> 25ms is actually quite good!
Yes, i think so.

> 
> > 
> > Great, will update my dot.conf. 
> > 
> > As a beneath one, try it currently with a seperat CGI to have a
> > better overview. 
> > Patched now as you suggested the 'write_forward_conf()' function,
> > needed to disable 
> > nevertheless update_forwarder() function in initscript if
> > forward.conf should be used
> > ... (there is more)
> > 
> 
> As we talked about before, I think that we can skip the DNSSEC tests
> entirely. They are more damaging than anything else. 
Yes indeed, i think update_forwarders disables also any forwarder via
unbound-control.

> That means that we should probably be looking at having a switch
> somewhere that enables DNS-over-TLS first and then all configured
> name servers are just used without further tests.
Have tried it now in this way -->
https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/initscripts/system/unbound;h=cc46c33c9425cc85d95b1d7412a9db3e146fea4b;hb=refs/heads/next#l154
. If unbound init finds an 'on' (enabled) in tlsconfig (which will be produced by CGI),
it doesn´t execute update_forwarders. Am currently not sure if we need possibly
the same for dnsforward config. Have tested it with a dummy entry but an
'unbound-control list_forwarders' shows nothing.
If there is no entry or everything is 'off' unbound uses the old 
DNS servers configured via setup.

>  In the default configuration that cannot be the case because of the
> problems we are trying to overcome by this script.
Isn´t forward.conf not a good place for this ?

> 
> But Erik, please let’s find a strategy first because everything is
> being implemented. 
Am happy with this but i really need to know first what´s happen in the
existing stuff, also i need to test for myself which ways may be
possible to overcome side affects. I need there also some new knowledge
causing the whole DNS/unbound thing but also insides how all that has
already been implemented.

In here --> 
https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=90e45d849e5fa185e4dcf83844e85d68474a09f5
a first and also better tested version of DoT can be found whereby i am 
happy if someone comes around for some testings/enhancements.

Merging all DNS CGI´s can be one of the following parts (not sure if i´ am the right one for this)
but i need a working solution to see how the system is in harmony with all that.
Also the dnsforwarding.cgi is in my humble opinion currently not working
or i did there really something wrong.

What strategy would you prefer ?

> I am absolutely happy that you are doing such good work here, but
> keep in mind that this needs to be integrated into IPFire in a slow
> and peer-reviewed way.
Need to think about how we can split things here. Do you have some
ideas ?


Another thing i have in account is the QNAME minimisation -->
https://tools.ietf.org/html/rfc7816
even in unbound.conf 'qname-minimisation: yes' is active it didn´t
worked for me:

$ dig txt qnamemintest.internet.nl +short
a.b.qnamemin-test.internet.nl.
"NO - QNAME minimisation is NOT enabled on your resolver :("

needed to add also

  qname-minimisation-strict: yes
  harden-below-nxdomain: yes

at earlier tests in my local.d conf to get an

a.b.qnamemin-test.internet.nl.
"HOORAY - QNAME minimisation is enabled on your resolver :)!"

. Should we extend unbound.conf or should i add this one in
forward.conf if DoT is active ? Or is this may not wanted ?


Some thoughts/news from here.

Best,

Erik

Re: [Fwd: Re: request for info: unbound via https / tls]

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 7868 bytes --]

Hey,

> On 12 Dec 2018, at 13:42, ummeegge <ummeegge(a)ipfire.org> wrote:
> 
> Hi Michael,
> 
> Am Dienstag, den 11.12.2018, 19:54 +0000 schrieb Michael Tremer:
>> Hey,
>> 
>> On 11 Dec 2018, at 19:43, ummeegge <ummeegge(a)ipfire.org> wrote:
>>> 
>>> Hi Michael,
>>> tried that now with this one -->
>>> 
> https://people.ipfire.org/~ummeegge/screenshoots/dns-over-tls_wui.png
>> 
>> This looks good, but under no circumstances should there be *another*
>> place where to configure DNS servers.
> Sure. I need to check for myself how this can be accomplished so i take
> it step-by-step and with a clear CGI it is simply easier for me.
> 
> 
>> We already have three. They need to be unified to one.
> You mean dns.cgi and dnsforward.cgi ?

No. We have the following places where users can configure their DNS servers:

For RED = STATIC: setup

For RED = DHCP: dns.cgi

For RED = PPP: The PPP profile

It can be argued that it makes sense to have different DNS servers in place for each PPP profile (I do not think that this has any users at all. Either you use your ISP’s DNS or not).

But overall it is confusing and also quite complicated in the code that we are reading the DNS servers from so many different places all the time. This needs to be simplified. There is a ticket for it since 2015:

  https://bugzilla.ipfire.org/show_bug.cgi?id=10886

> 
>> 
>>> 
>>> ... the HTML formatting kills me :D ...
>>> 
>>> and it looks now good:
>>> 
>>> $ kdig -d @81.3.27.54 +tls-ca=/etc/ssl/certs/ca-bundle.crt +tls-
>>> host=rec1.dns.lightningwirelabs.com google.com
>>> ;; DEBUG: Querying for owner(google.com.), class(1), type(1),
>>> server(81.3.27.54), port(853), protocol(TCP)
>>> ;; DEBUG: TLS, imported 129 certificates from '/etc/ssl/certs/ca-
>>> bundle.crt'
>>> ;; DEBUG: TLS, received certificate hierarchy:
>>> ;; DEBUG:  #1, CN=rec1.dns.lightningwirelabs.com
>>> ;; DEBUG:      SHA-256 PIN:
>>> pOvVkJSj6rWNPM0vR3hoJr/21kZI6TfImhowIEdcEUQ=
>>> ;; DEBUG:  #2, C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
>>> ;; DEBUG:      SHA-256 PIN:
>>> YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
>>> ;; DEBUG: TLS, skipping certificate PIN check
>>> ;; DEBUG: TLS, The certificate is trusted. 
>>> ;; TLS session (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(CHACHA20-POLY1305)
>>> ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 1349
>>> ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL:
>>> 1
>>> 
>>> ;; EDNS PSEUDOSECTION:
>>> ;; Version: 0; flags: ; UDP size: 4096 B; ext-rcode: NOERROR
>>> 
>>> ;; QUESTION SECTION:
>>> ;; google.com.         		IN	A
>>> 
>>> ;; ANSWER SECTION:
>>> google.com.         	151	IN	A	216.58.208.46
>>> 
>>> ;; Received 55 B
>>> ;; Time 2018-12-11 20:30:29 CET
>>> ;; From 81.3.27.54(a)853(TCP) in 25.2 ms
>> 
>> 25ms is actually quite good!
> Yes, i think so.
> 
>> 
>>> 
>>> Great, will update my dot.conf. 
>>> 
>>> As a beneath one, try it currently with a seperat CGI to have a
>>> better overview. 
>>> Patched now as you suggested the 'write_forward_conf()' function,
>>> needed to disable 
>>> nevertheless update_forwarder() function in initscript if
>>> forward.conf should be used
>>> ... (there is more)
>>> 
>> 
>> As we talked about before, I think that we can skip the DNSSEC tests
>> entirely. They are more damaging than anything else. 
> Yes indeed, i think update_forwarders disables also any forwarder via
> unbound-control.

Disables them? It is meant to overwrite them with the current DNS servers without restarting unbound.

> 
>> That means that we should probably be looking at having a switch
>> somewhere that enables DNS-over-TLS first and then all configured
>> name servers are just used without further tests.
> Have tried it now in this way -->
> https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/initscripts/system/unbound;h=cc46c33c9425cc85d95b1d7412a9db3e146fea4b;hb=refs/heads/next#l154
> . If unbound init finds an 'on' (enabled) in tlsconfig (which will be produced by CGI),
> it doesn´t execute update_forwarders. Am currently not sure if we need possibly
> the same for dnsforward config. Have tested it with a dummy entry but an
> 'unbound-control list_forwarders' shows nothing.
> If there is no entry or everything is 'off' unbound uses the old 
> DNS servers configured via setup.

In case of “off”, unbound is supposed to run in recursor mode.

>> In the default configuration that cannot be the case because of the
>> problems we are trying to overcome by this script.
> Isn´t forward.conf not a good place for this ?

For what exactly?

>> 
>> But Erik, please let’s find a strategy first because everything is
>> being implemented. 
> Am happy with this but i really need to know first what´s happen in the
> existing stuff, also i need to test for myself which ways may be
> possible to overcome side affects. I need there also some new knowledge
> causing the whole DNS/unbound thing but also insides how all that has
> already been implemented.
> 
> In here --> 
> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=90e45d849e5fa185e4dcf83844e85d68474a09f5
> a first and also better tested version of DoT can be found whereby i am 
> happy if someone comes around for some testings/enhancements.
> 
> Merging all DNS CGI´s can be one of the following parts (not sure if i´ am the right one for this)
> but i need a working solution to see how the system is in harmony with all that.
> Also the dnsforwarding.cgi is in my humble opinion currently not working
> or i did there really something wrong.
> 
> What strategy would you prefer ?

I do not have one yet. I am just saying that there should be one and that it should be discussed before it is being implemented.

I can say that I have a couple of things that are not working for me. That would be that I do not think that an extra CGI is required. We can use the one that we have (although for testing it can be implemented where ever you prefer) and that DNS-over-TLS cannot be enabled by default.

I also have a long list of issues that I would like to see tackled here as well. Those are that the unbound initscript is not behaving as intended. Extending it has to be done very careful to not break it even more or we make it shorter first and boil the problems down first and then add DNS-over-TLS.

>> I am absolutely happy that you are doing such good work here, but
>> keep in mind that this needs to be integrated into IPFire in a slow
>> and peer-reviewed way.
> Need to think about how we can split things here. Do you have some
> ideas ?

What is there to do?

It looks like you have a working version of the initscript and the UI (almost?) done.

> Another thing i have in account is the QNAME minimisation -->
> https://tools.ietf.org/html/rfc7816
> even in unbound.conf 'qname-minimisation: yes' is active it didn´t
> worked for me:
> 
> $ dig txt qnamemintest.internet.nl +short
> a.b.qnamemin-test.internet.nl.
> "NO - QNAME minimisation is NOT enabled on your resolver :("
> 
> needed to add also
> 
>  qname-minimisation-strict: yes
>  harden-below-nxdomain: yes

Please open a ticket for that.

Harden-below-nxdomain is deliberately disabled because it breaks loads of things and I do not consider it a correct solution.

> at earlier tests in my local.d conf to get an
> 
> a.b.qnamemin-test.internet.nl.
> "HOORAY - QNAME minimisation is enabled on your resolver :)!"
> 
> . Should we extend unbound.conf or should i add this one in
> forward.conf if DoT is active ? Or is this may not wanted ?
> 

This has nothing to do with DNS-over-TLS. Therefore this should be handled independently.

> 
> Some thoughts/news from here.
> 
> Best,
> 
> Erik

-Michael

Re: [Fwd: Re: request for info: unbound via https / tls]

[ummeegge]

[-- Attachment #1: Type: text/plain, Size: 11521 bytes --]

Hi Michael,


Am Mittwoch, den 12.12.2018, 15:25 +0000 schrieb Michael Tremer:
> Hey,
> 
> > On 12 Dec 2018, at 13:42, ummeegge <ummeegge(a)ipfire.org> wrote:
> > 
> > Hi Michael,
> > 
> > Am Dienstag, den 11.12.2018, 19:54 +0000 schrieb Michael Tremer:
> > > Hey,
> > > 
> > > On 11 Dec 2018, at 19:43, ummeegge <ummeegge(a)ipfire.org> wrote:
> > > > 
> > > > Hi Michael,
> > > > tried that now with this one -->
> > > > 
> > 
> > 
https://people.ipfire.org/~ummeegge/screenshoots/dns-over-tls_wui.png
> > > 
> > > This looks good, but under no circumstances should there be
> > > *another*
> > > place where to configure DNS servers.
> > 
> > Sure. I need to check for myself how this can be accomplished so i
> > take
> > it step-by-step and with a clear CGI it is simply easier for me.
> > 
> > 
> > > We already have three. They need to be unified to one.
> > 
> > You mean dns.cgi and dnsforward.cgi ?
> 
> No. We have the following places where users can configure their DNS
> servers:
> 
> For RED = STATIC: setup
> 
> For RED = DHCP: dns.cgi
> 
> For RED = PPP: The PPP profile
> 
OK i see. This is also a problem for me here to test or to check
further since RED is here static only.

> It can be argued that it makes sense to have different DNS servers in
> place for each PPP profile (I do not think that this has any users at
> all. Either you use your ISP’s DNS or not).
> 
> But overall it is confusing and also quite complicated in the code
> that we are reading the DNS servers from so many different places all
> the time. This needs to be simplified. There is a ticket for it since
> 2015:
> 
>   https://bugzilla.ipfire.org/show_bug.cgi?id=10886

I think this topic might be a good reason to change this but as
mentioned am not able to do this here.

> 
> > 
> > > 
> > > > 
> > > > ... the HTML formatting kills me :D ...
> > > > 
> > > > and it looks now good:
> > > > 
> > > > $ kdig -d @81.3.27.54 +tls-ca=/etc/ssl/certs/ca-bundle.crt
> > > > +tls-
> > > > host=rec1.dns.lightningwirelabs.com google.com
> > > > ;; DEBUG: Querying for owner(google.com.), class(1), type(1),
> > > > server(81.3.27.54), port(853), protocol(TCP)
> > > > ;; DEBUG: TLS, imported 129 certificates from
> > > > '/etc/ssl/certs/ca-
> > > > bundle.crt'
> > > > ;; DEBUG: TLS, received certificate hierarchy:
> > > > ;; DEBUG:  #1, CN=rec1.dns.lightningwirelabs.com
> > > > ;; DEBUG:      SHA-256 PIN:
> > > > pOvVkJSj6rWNPM0vR3hoJr/21kZI6TfImhowIEdcEUQ=
> > > > ;; DEBUG:  #2, C=US,O=Let's Encrypt,CN=Let's Encrypt Authority
> > > > X3
> > > > ;; DEBUG:      SHA-256 PIN:
> > > > YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
> > > > ;; DEBUG: TLS, skipping certificate PIN check
> > > > ;; DEBUG: TLS, The certificate is trusted. 
> > > > ;; TLS session (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(CHACHA20-
> > > > POLY1305)
> > > > ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 1349
> > > > ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0;
> > > > ADDITIONAL:
> > > > 1
> > > > 
> > > > ;; EDNS PSEUDOSECTION:
> > > > ;; Version: 0; flags: ; UDP size: 4096 B; ext-rcode: NOERROR
> > > > 
> > > > ;; QUESTION SECTION:
> > > > ;; google.com.         		IN	A
> > > > 
> > > > ;; ANSWER SECTION:
> > > > google.com.         	151	IN	A	216.58.208.46
> > > > 
> > > > ;; Received 55 B
> > > > ;; Time 2018-12-11 20:30:29 CET
> > > > ;; From 81.3.27.54(a)853(TCP) in 25.2 ms
> > > 
> > > 25ms is actually quite good!
> > 
> > Yes, i think so.
> > 
> > > 
> > > > 
> > > > Great, will update my dot.conf. 
> > > > 
> > > > As a beneath one, try it currently with a seperat CGI to have a
> > > > better overview. 
> > > > Patched now as you suggested the 'write_forward_conf()'
> > > > function,
> > > > needed to disable 
> > > > nevertheless update_forwarder() function in initscript if
> > > > forward.conf should be used
> > > > ... (there is more)
> > > > 
> > > 
> > > As we talked about before, I think that we can skip the DNSSEC
> > > tests
> > > entirely. They are more damaging than anything else. 
> > 
> > Yes indeed, i think update_forwarders disables also any forwarder
> > via
> > unbound-control.
> 
> Disables them? It is meant to overwrite them with the current DNS
> servers without restarting unbound.
I meant the update_forwarder() function -->
https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/initscripts/system/unbound;h=cc46c33c9425cc85d95b1d7412a9db3e146fea4b;hb=refs/heads/next#l154
as far i understand 'unbound-control -q forward off' .

But also for write_forward_conf() where i integrated DoT needed a restart
of unbound as far as i can see/tested since we need different unbound.conf
directives:

server:
  tls-cert-bundle: /etc/ssl/certs/ca-bundle.crt

forward-zone:
  forward-tls-upstream: yes

unbound needed to read out the config file again. The first version
started DoT via 'unbound-control start' but i couldn´t manage this in
this version?!

> 
> > 
> > > That means that we should probably be looking at having a switch
> > > somewhere that enables DNS-over-TLS first and then all configured
> > > name servers are just used without further tests.
> > 
> > Have tried it now in this way -->
> > 
https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/initscripts/system/unbound;h=cc46c33c9425cc85d95b1d7412a9db3e146fea4b;hb=refs/heads/next#l154
> > . If unbound init finds an 'on' (enabled) in tlsconfig (which will
> > be produced by CGI),
> > it doesn´t execute update_forwarders. Am currently not sure if we
> > need possibly
> > the same for dnsforward config. Have tested it with a dummy entry
> > but an
> > 'unbound-control list_forwarders' shows nothing.
> > If there is no entry or everything is 'off' unbound uses the old 
> > DNS servers configured via setup.
> 
> In case of “off”, unbound is supposed to run in recursor mode.

Haven´t experienced this here. Did You ? unbound switched only back to
the initially configured DNS servers if "off" or not presant.


> 
> > > In the default configuration that cannot be the case because of
> > > the
> > > problems we are trying to overcome by this script.
> > 
> > Isn´t forward.conf not a good place for this ?
> 
> For what exactly?

For extending unbound.conf .

> 
> > > 
> > > But Erik, please let’s find a strategy first because everything
> > > is
> > > being implemented. 
> > 
> > Am happy with this but i really need to know first what´s happen in
> > the
> > existing stuff, also i need to test for myself which ways may be
> > possible to overcome side affects. I need there also some new
> > knowledge
> > causing the whole DNS/unbound thing but also insides how all that
> > has
> > already been implemented.
> > 
> > In here --> 
> > 
https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=90e45d849e5fa185e4dcf83844e85d68474a09f5
> > a first and also better tested version of DoT can be found whereby
> > i am 
> > happy if someone comes around for some testings/enhancements.
> > 
> > Merging all DNS CGI´s can be one of the following parts (not sure
> > if i´ am the right one for this)
> > but i need a working solution to see how the system is in harmony
> > with all that.
> > Also the dnsforwarding.cgi is in my humble opinion currently not
> > working
> > or i did there really something wrong.
> > 
> > What strategy would you prefer ?
> 
> I do not have one yet. I am just saying that there should be one and
> that it should be discussed before it is being implemented.

I see.

> 
> I can say that I have a couple of things that are not working for me.
> That would be that I do not think that an extra CGI is required. We
> can use the one that we have (although for testing it can be
> implemented where ever you prefer) and that DNS-over-TLS cannot be
> enabled by default.

update_forwarders() was the main problem here in both developmant
stages. Anyways, DoT works for me good some testing scenarios and the
resulting informations are available for further development but sadly
i can not test all that but can offer the already working CGI and
sureley some trial and errors if this is needed.

> 
> I also have a long list of issues that I would like to see tackled
> here as well. Those are that the unbound initscript is not behaving
> as intended. Extending it has to be done very careful to not break it
> even more or we make it shorter first and boil the problems down
> first and then add DNS-over-TLS.

That´s plausible. Since i done also some testings in unbound
initscript, i can may try to do also some work in there but as you
already said, this would really need coordination/description of
what/how to do.


> 
> > > I am absolutely happy that you are doing such good work here, but
> > > keep in mind that this needs to be integrated into IPFire in a
> > > slow
> > > and peer-reviewed way.
> > 
> > Need to think about how we can split things here. Do you have some
> > ideas ?
> 
> What is there to do?
Currently not sure how to find here a way of a release structure in a
peer-reviewed way.

> 
> It looks like you have a working version of the initscript and the UI
> (almost?) done.

Yes, this version works for me. Installed it on a fresh installation
(OpenSSL-1.1.1a ;), tried to kill/test it on an old installation but it
worked so far (a little slow since it restart unboundctrl if things are
changing in there).
Haven´t find bugs in the UI since now may someone have some for me ?

> 
> > Another thing i have in account is the QNAME minimisation -->
> > https://tools.ietf.org/html/rfc7816
> > even in unbound.conf 'qname-minimisation: yes' is active it didn´t
> > worked for me:
> > 
> > $ dig txt qnamemintest.internet.nl +short
> > a.b.qnamemin-test.internet.nl.
> > "NO - QNAME minimisation is NOT enabled on your resolver :("
> > 
> > needed to add also
> > 
> >  qname-minimisation-strict: yes
> >  harden-below-nxdomain: yes
> 
> Please open a ticket for that.

OK, will do that.

> 
> Harden-below-nxdomain is deliberately disabled because it breaks
> loads of things and I do not consider it a correct solution.

Great info! 'harden-below-nxdomain: yes' is also not needed for QNAME
minimization.

> 
> > at earlier tests in my local.d conf to get an
> > 
> > a.b.qnamemin-test.internet.nl.
> > "HOORAY - QNAME minimisation is enabled on your resolver :)!"
> > 
> > . Should we extend unbound.conf or should i add this one in
> > forward.conf if DoT is active ? Or is this may not wanted ?
> > 
> 
> This has nothing to do with DNS-over-TLS. Therefore this should be
> handled independently.

Yes, as mentioned will open a ticket for this.

Another thing has come to mind. A kdig check for the configured DoT
servers might be nice. May like it is managed in ddns.cgi with the
syncronisation function.
For example a kdig command can be used to grep for "is trusted" and the
"rd" flag and if true to set a green colored hostname in (currently)
dnsovertls.cgi, if not a red colored one can help the user for better
understanding if/or_which one is not working so possible
missconfiguration can be detected easier since the number of DNS
servers are not limited and open for randomization ?

As a beneath one, Cloudflair offers TLS1.3 support since a couple of
days/weeks now.


Best,

Erik

Re: [Fwd: Re: request for info: unbound via https / tls]

[ummeegge]

[-- Attachment #1: Type: text/plain, Size: 2451 bytes --]

Hi all,
a little update to this comment

Am Mittwoch, den 12.12.2018, 18:44 +0100 schrieb ummeegge:
> 
> As a beneath one, Cloudflair offers TLS1.3 support since a couple of
> days/weeks now.
> 

have tested now a couple of DoT servers and wanted to update some infos
causing encryption but also sorted by speed:

*.quad9.net                                 (TLS1.2)-(ECDHE-SECP256R1)-(ECDSA-SHA512)-(AES-256-GCM)
9.9.9.10        in 12.4 ms

*.quad9.net                                 (TLS1.2)-(ECDHE-SECP256R1)-(ECDSA-SHA512)-(AES-256-GCM)
9.9.9.9         in 18.7 ms

rec1.dns.lightningwirelabs.com              (TLS1.2)-(ECDHE-X25519)-(ECDSA-SHA512)-(CHACHA20-POLY1305)
81.3.27.54      in 24.9 ms

*.tenta.io                                  (TLS1.2)-(ECDHE-SECP521R1)-(ECDSA-SHA256)-(CHACHA20-POLY1305)
99.192.182.200  in 28.7 ms

kaitain.restena.lu                          (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA512)-(AES-256-GCM)
158.64.1.29     in 29.6 ms

dnsovertls2.sinodun.com                     (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
145.100.185.17  in 45.1 ms      

*.cloudflare-dns.com                        (TLS1.3)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
1.0.0.1         in 46.1 ms

*.cloudflare-dns.com                        (TLS1.3)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
1.1.1.1         in 47.8 ms

dot-de.blahdns.com                          (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
159.69.198.101  in 61.1 ms

dns.neutopia.org                            (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
89.234.186.112  in 62.2 ms

securedns.eu                                (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
146.185.167.43, 146.185.167.43
in 72.8 ms      in 75.1 ms

getdnsapi.net                               (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
185.49.141.37   in 88.4 ms

dnsovertls3.sinodun.com                     (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
145.100.185.18  in 91.2 ms

dns.cmrg.net                                (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
199.58.81.218   in 100.8 ms



Lightningwirelabs is really pretty fast (@Michael, did you changed to curve25519 ? seems to be some ms faster) 
but also TLS1.3 seems to become more common as i thought.

Best,

Erik 

Re: [Fwd: Re: request for info: unbound via https / tls]

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 3435 bytes --]

Hi,

> On 13 Dec 2018, at 06:52, ummeegge <ummeegge(a)ipfire.org> wrote:
> 
> Hi all,
> a little update to this comment
> 
> Am Mittwoch, den 12.12.2018, 18:44 +0100 schrieb ummeegge:
>> 
>> As a beneath one, Cloudflair offers TLS1.3 support since a couple of
>> days/weeks now.
>> 
> 
> have tested now a couple of DoT servers and wanted to update some infos
> causing encryption but also sorted by speed:
> 
> *.quad9.net                                 (TLS1.2)-(ECDHE-SECP256R1)-(ECDSA-SHA512)-(AES-256-GCM)
> 9.9.9.10        in 12.4 ms
> 
> *.quad9.net                                 (TLS1.2)-(ECDHE-SECP256R1)-(ECDSA-SHA512)-(AES-256-GCM)
> 9.9.9.9         in 18.7 ms
> 
> rec1.dns.lightningwirelabs.com              (TLS1.2)-(ECDHE-X25519)-(ECDSA-SHA512)-(CHACHA20-POLY1305)
> 81.3.27.54      in 24.9 ms
> 
> *.tenta.io                                  (TLS1.2)-(ECDHE-SECP521R1)-(ECDSA-SHA256)-(CHACHA20-POLY1305)
> 99.192.182.200  in 28.7 ms
> 
> kaitain.restena.lu                          (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA512)-(AES-256-GCM)
> 158.64.1.29     in 29.6 ms
> 
> dnsovertls2.sinodun.com                     (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
> 145.100.185.17  in 45.1 ms      
> 
> *.cloudflare-dns.com                        (TLS1.3)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
> 1.0.0.1         in 46.1 ms
> 
> *.cloudflare-dns.com                        (TLS1.3)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
> 1.1.1.1         in 47.8 ms
> 
> dot-de.blahdns.com                          (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
> 159.69.198.101  in 61.1 ms
> 
> dns.neutopia.org                            (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
> 89.234.186.112  in 62.2 ms
> 
> securedns.eu                                (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
> 146.185.167.43, 146.185.167.43
> in 72.8 ms      in 75.1 ms
> 
> getdnsapi.net                               (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
> 185.49.141.37   in 88.4 ms
> 
> dnsovertls3.sinodun.com                     (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
> 145.100.185.18  in 91.2 ms
> 
> dns.cmrg.net                                (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
> 199.58.81.218   in 100.8 ms
> 
> 
> 
> Lightningwirelabs is really pretty fast (@Michael, did you changed to curve25519 ? seems to be some ms faster) 
> but also TLS1.3 seems to become more common as i thought.

This is the default cipher list of the OpenSSL version that is shipped with IPFire. We kind of prefer Curve25519 but not only for performance reasons. Mainly because it is free of any NSA cryptography.

But cool to see that this is actually quite slow. I suppose that it is crucial to use a permanent connection or TFO might help, too.

We are only fast because we might have the result cached and our hoster has actually really good peering to many locations. So, although you are travelling through half the country, it is not very far away from you on the Internet.

This will probably be super slow from America or somewhere further away because of the long TCP handshake.

Interesting too how we are standing out with our crypto :)

-Michael

> 
> Best,
> 
> Erik 
> 
> 
> 
> 
> 
> 
> 
> 
>