Re: [DNSOP] kskroll-sentinel responses

[Ray Bellis]

On 02/01/2018 23:37, Paul Hoffman wrote:

> This answer doesn't seem to fully address Robert's and Ray's questions.
> Why use an A/ query if you aren't going to do anything with the
> result? If you are going to use A/, you have to tell resolvers what
> to return in the results. Using a new RRtype would have clearer semantics.

Actually, that wasn't my question at all.

The point I was trying to make (perhaps too obliquely) is that if you
are going to run this experiment from a browser, you'd better make sure
the IP address you return is one that's either under your control or
otherwise "harmless" when the browser subsequently tries to access it.

Using a new RRTYPE would be futile, since browsers don't know how to
access those.

Ray

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

Re: [DNSOP] Please review in terminology-bis: QNAME

[Petr Špaček]

On 18.12.2017 20:05, Paul Vixie wrote:
> Stephane Bortzmeyer wrote:
>> As I mentioned in this errata
>> , I think RFC 2308 was
>> wrong in redefining QNAME. My personal preference would be to change
>> the second paragraph to "RFC 2308 proposed another definition,
>> different from the original one. Since it is actually a different
>> concept, it would be better to find another name for it. Here, QNAME
>> retains the original definition of RFC 1034."
> 
> +1.

+1, yes please.
-- 
Petr Špaček  @  CZ.NIC

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

Re: [DNSOP] kskroll-sentinel responses

[Paul Hoffman]

On 3 Jan 2018, at 1:11, Ray Bellis wrote:


On 02/01/2018 23:37, Paul Hoffman wrote:

This answer doesn't seem to fully address Robert's and Ray's 
questions.

Why use an A/ query if you aren't going to do anything with the
result? If you are going to use A/, you have to tell resolvers 
what
to return in the results. Using a new RRtype would have clearer 
semantics.


Actually, that wasn't my question at all.


Sorry for indicating it was. It was also not (directly) Robert's 
question either. Robert asked "The first is the contents of the A/ 
RRSET returned, and the second is the TTL for the records", and I took 
Geoff's lack of answer to mean that he wasn't going to use the result.


Geoff has now said "At the risk of heading wy down potentially 
spurious ratholes here let me quickly explain what I meant. Within the 
structure of a browser-based scripted test, such as you might find in an 
online ad script, the common operation within the script is to perform a 
GET of a URL." I did not realize that draft-ietf-dnsop-kskroll-sentinel 
was only meant for browser-based tests because there is no indication of 
this in the draft.



The point I was trying to make (perhaps too obliquely) is that if you
are going to run this experiment from a browser, you'd better make 
sure

the IP address you return is one that's either under your control or
otherwise "harmless" when the browser subsequently tries to access it.


Fully agree.


Using a new RRTYPE would be futile, since browsers don't know how to
access those.


That is true for the "browser-based scripted test", definitely. If 
that's the sole motivation for this draft, then we need to stick with A 
/  records which will be specified in a future version of the draft.


--Paul Hoffman

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

Re: [DNSOP] Please review in terminology-bis: QNAME

[Peter van Dijk]

On 11 Dec 2017, at 16:30, Paul Hoffman wrote:


Greetings again.

Some of the new terms added to the terminology-bis draft 
(https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/)since 
RFC 7719 can expose what some (but not all) people perceive as lack of 
clarity in RFC 1034/1035. This week, we hope you will look at the 
definition in the draft for "QNAME".
Please review the lengthy explanation and comment on the list if you 
think the definition should change.


+1 on the lengthy explanation. Nothing shorter could settle this thing.

Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

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

[DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

Title   : C-DNS: A DNS Packet Capture Format
Authors : John Dickinson
  Jim Hague
  Sara Dickinson
  Terry Manderson
  John Bond
Filename: draft-ietf-dnsop-dns-capture-format-04.txt
Pages   : 50
Date: 2018-01-03

Abstract:
   This document describes a data representation for collections of DNS
   messages.  The format is designed for efficient storage and
   transmission of large packet captures of DNS traffic; it attempts to
   minimize the size of such packet capture files but retain the full
   DNS message contents along with the most useful transport metadata.
   It is intended to assist with the development of DNS traffic
   monitoring applications.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-dns-capture-format-04
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-capture-format-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-capture-format-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-04.txt

[Sara Dickinson]

Hi All, 

This is a very minor update (to avoid expiration), a more significant one is in 
the works.

Sara. 


> On 3 Jan 2018, at 17:02, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
>Title   : C-DNS: A DNS Packet Capture Format
>Authors : John Dickinson
>  Jim Hague
>  Sara Dickinson
>  Terry Manderson
>  John Bond
>   Filename: draft-ietf-dnsop-dns-capture-format-04.txt
>   Pages   : 50
>   Date: 2018-01-03
> 
> Abstract:
>   This document describes a data representation for collections of DNS
>   messages.  The format is designed for efficient storage and
>   transmission of large packet captures of DNS traffic; it attempts to
>   minimize the size of such packet capture files but retain the full
>   DNS message contents along with the most useful transport metadata.
>   It is intended to assist with the development of DNS traffic
>   monitoring applications.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-dns-capture-format-04
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-capture-format-04
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-capture-format-04
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 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] 4035 3.1.4.1 erratum? dig ds root-servers.net @X.root-servers.net

[Peter van Dijk]

Output edited for brevity:

$ dig ds root-servers.net @d.root-servers.net

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17643
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;root-servers.net.  IN  DS

;; AUTHORITY SECTION:
root-servers.net.	360	IN	SOA	a.root-servers.net. 
nstld.verisign-grs.com. 2017111600 14400 7200 1209600 360


$ dig ds root-servers.net @e.root-servers.net

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26972
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;root-servers.net.  IN  DS

;; AUTHORITY SECTION:
net.172800  IN  NS  a.gtld-servers.net.
net.172800  IN  NS  b.gtld-servers.net.
.. ..

;; ADDITIONAL SECTION:
a.gtld-servers.net. 172800  IN  A   192.5.6.30
b.gtld-servers.net. 172800  IN  A   192.33.14.30
.. ..



When running the query in the Subject, these are the two possible 
outputs I have observed from various root servers (with some variation 
from the same letter, presumably because of dual vendor strategies).


From 4035 3.1.4.1, the NODATA response should be sent when:

   o  The name server has received a query for the DS RRset at a zone
  cut.

   o  The name server is authoritative for the child zone.

   o  The name server is not authoritative for the parent zone.

   o  The name server does not offer recursion.


Points 1, 2 and 4 are clear. It is point 3 that hurts here. The root 
servers are authoritative for root-servers.net. and for . , but not for 
net - and they know this because they can see the delegation in the root 
zone.


It is my suspicion that 3.1.4.1 was not written with this edge case in 
mind, and I think that while 3.1.4.1 favours the NODATA response, the 
referral is much more useful. As a data point, the PowerDNS validator 
currently gets in trouble with the NODATA response: 
https://github.com/PowerDNS/pdns/issues/6138


I think an erratum to 4035 is in order, clarifying the language such 
that servers would return the referral in this case. I have not figured 
out the exact wording yet (but I will).


What does dnsop think?

Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

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

Re: [DNSOP] 4035 3.1.4.1 erratum? dig ds root-servers.net @X.root-servers.net

[Marek Vavruša]

That's a good point. Personally, I'd favour a referral response since
it saves resolver a round trip (at least for resolvers not doing QNAME
minimisation), it seems in conflict with 3.1.4.1 though as you pointed
here.

Marek

On Wed, Jan 3, 2018 at 10:31 AM, Peter van Dijk
 wrote:
> Output edited for brevity:
>
> $ dig ds root-servers.net @d.root-servers.net
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17643
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;root-servers.net.  IN  DS
>
> ;; AUTHORITY SECTION:
> root-servers.net.   360 IN  SOA a.root-servers.net.
> nstld.verisign-grs.com. 2017111600 14400 7200 1209600 360
>
> $ dig ds root-servers.net @e.root-servers.net
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26972
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;root-servers.net.  IN  DS
>
> ;; AUTHORITY SECTION:
> net.172800  IN  NS  a.gtld-servers.net.
> net.172800  IN  NS  b.gtld-servers.net.
> .. ..
>
> ;; ADDITIONAL SECTION:
> a.gtld-servers.net. 172800  IN  A   192.5.6.30
> b.gtld-servers.net. 172800  IN  A   192.33.14.30
> .. ..
>
>
>
> When running the query in the Subject, these are the two possible outputs I
> have observed from various root servers (with some variation from the same
> letter, presumably because of dual vendor strategies).
>
> From 4035 3.1.4.1, the NODATA response should be sent when:
>
>o  The name server has received a query for the DS RRset at a zone
>   cut.
>
>o  The name server is authoritative for the child zone.
>
>o  The name server is not authoritative for the parent zone.
>
>o  The name server does not offer recursion.
>
>
> Points 1, 2 and 4 are clear. It is point 3 that hurts here. The root servers
> are authoritative for root-servers.net. and for . , but not for net - and
> they know this because they can see the delegation in the root zone.
>
> It is my suspicion that 3.1.4.1 was not written with this edge case in mind,
> and I think that while 3.1.4.1 favours the NODATA response, the referral is
> much more useful. As a data point, the PowerDNS validator currently gets in
> trouble with the NODATA response:
> https://github.com/PowerDNS/pdns/issues/6138
>
> I think an erratum to 4035 is in order, clarifying the language such that
> servers would return the referral in this case. I have not figured out the
> exact wording yet (but I will).
>
> What does dnsop think?
>
> Kind regards,
> --
> Peter van Dijk
> PowerDNS.COM BV - https://www.powerdns.com/
>
> ___
> 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] 4035 3.1.4.1 erratum? dig ds root-servers.net @X.root-servers.net

[Paul Vixie]

Marek Vavruša wrote:

That's a good point. Personally, I'd favour a referral response since
it saves resolver a round trip (at least for resolvers not doing QNAME
minimisation), it seems in conflict with 3.1.4.1 though as you pointed
here.


...


I think an erratum to 4035 is in order, clarifying the language such that
servers would return the referral in this case. I have not figured out the
exact wording yet (but I will).

What does dnsop think?


i think as you and marek do.

--
P Vixie

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

Re: [DNSOP] 4035 3.1.4.1 erratum? dig ds root-servers.net @X.root-servers.net

[Vladimír Čunát]

On 01/03/2018 07:31 PM, Peter van Dijk wrote:
> What does dnsop think? 

I also prefer referral in this case, as it seems to make more sense for
resolvers.  (For public reference, as we've discussed more directly.) 
And thank you for bringing this problem to attention.

How to best formulate a generic rule is a more difficult question.

--Vladimir

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

Re: [DNSOP] 4035 3.1.4.1 erratum? dig ds root-servers.net @X.root-servers.net

[Mark Andrews]

The reply also has to work for STD13 clients which already know about the child 
zone. The NODATA response is the correct one despite it requiring more work for 
a DNSSEC client. 


-- 
Mark Andrews

> On 4 Jan 2018, at 05:31, Peter van Dijk  wrote:
> 
> Output edited for brevity:
> 
> $ dig ds root-servers.net @d.root-servers.net
> 
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17643
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;root-servers.net.INDS
> 
> ;; AUTHORITY SECTION:
> root-servers.net.360INSOAa.root-servers.net. 
> nstld.verisign-grs.com. 2017111600 14400 7200 1209600 360
> 
> $ dig ds root-servers.net @e.root-servers.net
> 
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26972
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27
> ;; WARNING: recursion requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;root-servers.net.INDS
> 
> ;; AUTHORITY SECTION:
> net.172800INNSa.gtld-servers.net.
> net.172800INNSb.gtld-servers.net.
> .. ..
> 
> ;; ADDITIONAL SECTION:
> a.gtld-servers.net.172800INA192.5.6.30
> b.gtld-servers.net.172800INA192.33.14.30
> .. ..
> 
> 
> 
> When running the query in the Subject, these are the two possible outputs I 
> have observed from various root servers (with some variation from the same 
> letter, presumably because of dual vendor strategies).
> 
> From 4035 3.1.4.1, the NODATA response should be sent when:
> 
>   o  The name server has received a query for the DS RRset at a zone
>  cut.
> 
>   o  The name server is authoritative for the child zone.
> 
>   o  The name server is not authoritative for the parent zone.
> 
>   o  The name server does not offer recursion.
> 
> 
> Points 1, 2 and 4 are clear. It is point 3 that hurts here. The root servers 
> are authoritative for root-servers.net. and for . , but not for net - and 
> they know this because they can see the delegation in the root zone.
> 
> It is my suspicion that 3.1.4.1 was not written with this edge case in mind, 
> and I think that while 3.1.4.1 favours the NODATA response, the referral is 
> much more useful. As a data point, the PowerDNS validator currently gets in 
> trouble with the NODATA response: https://github.com/PowerDNS/pdns/issues/6138
> 
> I think an erratum to 4035 is in order, clarifying the language such that 
> servers would return the referral in this case. I have not figured out the 
> exact wording yet (but I will).
> 
> What does dnsop think?
> 
> Kind regards,
> -- 
> Peter van Dijk
> PowerDNS.COM BV - https://www.powerdns.com/
> 
> ___
> 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