Re: [DNSOP] DNS Camel Viewer

[Olafur Gudmundsson]

> On Mar 26, 2018, at 4:15 AM, Matthijs Mekking  wrote:
> 
> Nice viewer :)
> 
> What immediately catches my eye is that the DNSSEC RFCs 4033-4034-4035 are a 
> Proposed Standard, and RFC 5011 is an Internet Standard. In fact, RFC 5011 is 
> the only DNSSEC Internet Standard. That can't be right, right? :)
> 
> Matthijs
> 
> 

Matthijs, 

It is real sad that this is correct.
Over the many years chairing DNSIND/DNSEXT working group I can tell you the 
most difficult hurdle was to get anyone help push a document up the standards 
track. 
For some reason people can find time to read and write 100+ messages on naming 
of KeyID but spending the same time to advance a document is hard
and then someone  comes out and wants to make changes to text ….. 
overall result Mike StJohns is the only person that had the stamina and think 
skin to succeed 

Olafur

> 
> On 24-03-18 17:51, bert hubert wrote:
>> Hi everyone,
>> [tl;dr, check out https://powerdns.org/dns-camel/ ]
>> As a first step in attempting to not only whine about a glut of DNS
>> standards, I've made an easy to update viewer of all DNS relevant standards.
>> The good news is, if we filter out obsoleted, historical, informational and
>> BCP documents, we are left with a lot less pages. The bad news is, 1403
>> pages remain.
>> I took the set of RFCs from https://www.isc.org/community/rfcs/dns/ and
>> augmented this with the recent RFCs published by DNSOP and DPRIVE.
>> The page is on https://powerdns.org/dns-camel/ - it is a bit slow to load
>> because it sources the 12MB IETF XML file describing all RFCs. It should do
>> this only once and then be fast.
>> The goal is to augment this view with all drafts that are currently active,
>> so we can also see "what is coming".
>> If you know of RFCs that should or should not be on the list, please edit
>> dns-rfcs.js on https://github.com/ahupowerdns/dns-camel/
>> It is my hope that this view will be helpful in determining:
>> 1) What to obsolete
>> 2) The "must read" list for:
>>  a) stub resolvers
>>  b) dns caches / resolvers
>>  c) authoritative servers
>> 3) The "must not read" list - documents not worth it to obsolete, but
>> considered confusing or misguided
>> 4) Perhaps take a good look at the drafts we are currently working on
>>  Bert
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested

[Paul Vixie]

one thing to note is that when the server is authoritative for more than 
one zone, a cname that crosses from one such zone to another is allowed 
by 1035 to be chased. however, the resolver has no reason to accept 
out-of-zone records, since it cannot be sure that a new query in the 
bailiwick of the second zone would be answered the same way (or by the 
same server.) after kashpureff, we ignore the out-of-zone data and 
re-fetch it. this strongly calls for an update to 1035, since akamai and 
other CDN's are sending multi-zone cname chains, and they need to know 
that they should not do that, and also, resolver implementers need to 
know that they should be stripping any answer from the response whose 
owner name is not in-bailiwick with their QNAME.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested

[bert hubert]

On Mon, Apr 16, 2018 at 03:30:36PM +0100, Tony Finch wrote:
> I'm slightly surprised that Evan and Mukund haven't mentioned this, but
> BIND 9.1 to 9.11 had additional-from-cache and additional-from-auth
> options which controlled this behaviour. (I turned them off on my servers
> years ago.) In 9.12 the options have been removed and authoritative
> answers never chase around in search of gossip.

Ok - so it appears staying "in zone" for CNAME and glue is fine, or perhaps
even recommended? A best practice?

> >   None of these resolve when I try them, I wonder if that is because
> >   implementations want CNAMEs to be 'host names', or if this a chain of
> >   bugs.  Not practically very relevant, but still.
> 
> My recursive server gets upset because in noerror/nodata answers, the SOA
> record appears in the answer section not the authority section.

Fixed! 

>   $ ping 'some host.tdns.powerdns.org'
> it does actually ask the recursive server before giving up in disgust.
> Weird.

It is indeed somewhat strange, but I'm not even sure if this is bad or good.

Bert

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested

[Tony Finch]

bert hubert  wrote:
>
> In writing this server and while consulting with some other implementors, I
> for now have decided that in 2018 it makes no sense to:
>
> 1) chase CNAMEs that point to another zone
> 2) look for glue outside of the zone
>
> Given that any resolver will ignore those answers anyhow. But I wonder, is
> this ok, and do we already have words on if chasing CNAMEs outside of zones
> is mandatory or not?

I'm slightly surprised that Evan and Mukund haven't mentioned this, but
BIND 9.1 to 9.11 had additional-from-cache and additional-from-auth
options which controlled this behaviour. (I turned them off on my servers
years ago.) In 9.12 the options have been removed and authoritative
answers never chase around in search of gossip.

The additional-from-auth toggle reminds me of the somewhat painful history
of glue handling in the shared .com / .net registry and DNS servers...

> 2) Try:
>   ping goes-via-embedded-nul.tdns.powerdns.org
>   ping goes-via-embedded-space.tdns.powerdns.org.
>   ping goes-via-embedded-dot.tdns.powerdns.org.
>
>   None of these resolve when I try them, I wonder if that is because
>   implementations want CNAMEs to be 'host names', or if this a chain of
>   bugs.  Not practically very relevant, but still.

My recursive server gets upset because in noerror/nodata answers, the SOA
record appears in the answer section not the authority section.

I guess (without checking) the libc stub resolver is objecting to the
hostname syntax violations. But if I

$ ping 'some host.tdns.powerdns.org'

it does actually ask the recursive server before giving up in disgust.
Weird.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
justice and liberty cannot be confined by national boundaries

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Blog Post: DNS over TLS support in Android P Developer Preview

[Sara Dickinson]

> On 13 Apr 2018, at 20:49, Warren Kumari  wrote:
> 
> Hi all,
> 
> As Erik Kline and Ben Schwartz seem to be too modest to toot their own
> horn, I'll do it for them:
> https://android-developers.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html
>  
> 

Yes - great work by those folks! Ben also gave a talk about this at the DNS 
Privacy workshop in February if you want to watch the video:

https://www.youtube.com/watch?v=9xO6kSgvtOQ=3=PL5i3urU7m33XR1GtR0UZWi4fdX01W2bOZ
 



> 
> Snippet from the above:
> "The Android P Developer Preview includes built-in support for DNS
> over TLS. We added a Private DNS mode to the Network & internet
> settings.
> 
> By default, devices automatically upgrade to DNS over TLS if a
> network's DNS server supports it. But users who don't want to use DNS
> over TLS can turn it off."
> 
> W
> (Also posted to dprive)
> -- 
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>   ---maf
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop