In message <20141221102935.ga12...@sources.org>, Stephane Bortzmeyer writes:
> On Fri, Nov 28, 2014 at 07:28:15AM -0800,
> Paul Hoffman <paul.hoff...@vpnc.org> wrote
> a message of 33 lines which said:
>
> > Greetings. Andrew and Kazunori and I have prepared the first draft
> > of what will hopefully be a useful document collecting definitions
> > that useful in the DNS community.
>
> Good, let's bikeshed a lot :-)
>
> Missing items:
>
> It does not seem there is a discussion of the difference between
> "domain name" and "host name". This is one of the least understood
> terminology issues in the DNS, and the basis for many
> misunderstandings (for instance, in the IDN discussions, people
> claiming that the DNS is 7-bits...) Speaking of that, there is not
> even a definition of "domain name" in the draft. Is it because you
> regard the definitions of sections 3.1 (domain name) and section 3.5
> (host name) of RFC 1034 as sufficient? In that case, may be they
> should be quoted, so the future Terminology RFC would be complete.
>
> Also, I do not see a definition of ENT (Empty Non-Terminal), something
> which comes often in DNS discussions.
>
> > 2. DNS Message Format
> > Some common ones [response codes] are:
>
> I agree that NODATA (as a shorthand for NOERROR/ANSWER=0) should be
> mentioned (see Andreas Gustafsson's message on Dec. 1st).
>
> > RRset -- A set of resource records with the same label, class and
> > type,
>
> "same label" is not clear (yes, it is in RFC 2181, I know, but RFC
> 2181 use "label" in a new and undefined way, different from RFC 1034)
> since many nodes in the domain name tree have the same label... Better
> to say "same owner name". Or "same FQDN".
>
> > DNS forwarder -- A system receives a DNS query, possibly changes the
> > query, sends the resulting query to a recursive resolver,
>
> That's not the definition of RFC 2308 ("The forwarder typically either
> has better access to the internet, or maintains a bigger cache which
> may be shared amongst many resolvers."). If you have Alice's machine
> using a SOHO router (whose IP address is announced via DHCP as the DNS
> resolver to use) which forwards every DNS query to Google Public DNS,
> 8.8.8.8 is the forwarder, not the SOHO router (which is a relay). This
> is consistent with BIND's "forwarder" directive, which list the
> recursive resolvers used to resolve the query.
>
> > Authoritative data -- RRsets in a DNS response that has the AA bit in
> > the response header set to 1.
The more describes a authoritative answer (AA) which contains
authoritative data as first RRset in the answer section that matches
the query name along with associated DNSSEC proofs. It also covers
the SOA and NS records in the non-existence cases along with
associated DNSSEC proofs. This is covered in RFC 103[45].
Authoritative data is the data in the zone for the namespace that
hasn't been delegated way or occulted by DNAME records.
> % dig +nodnssec @b.gtld-servers.net NS com
>
> ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +nodnssec @b.gtld-servers.net NS com
> ; (2 servers found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58418
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 16
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;com. IN NS
>
> ;; ANSWER SECTION:
> com. 172800 IN NS m.gtld-servers.net.
> com. 172800 IN NS i.gtld-servers.net.
> com. 172800 IN NS f.gtld-servers.net.
> com. 172800 IN NS c.gtld-servers.net.
> com. 172800 IN NS h.gtld-servers.net.
> com. 172800 IN NS d.gtld-servers.net.
> com. 172800 IN NS j.gtld-servers.net.
> com. 172800 IN NS k.gtld-servers.net.
> com. 172800 IN NS g.gtld-servers.net.
> com. 172800 IN NS l.gtld-servers.net.
> com. 172800 IN NS e.gtld-servers.net.
> com. 172800 IN NS b.gtld-servers.net.
> com. 172800 IN NS a.gtld-servers.net.
>
> ;; ADDITIONAL SECTION:
> m.gtld-servers.net. 172800 IN A 192.55.83.30
> i.gtld-servers.net. 172800 IN A 192.43.172.30
> f.gtld-servers.net. 172800 IN A 192.35.51.30
> c.gtld-servers.net. 172800 IN A 192.26.92.30
> h.gtld-servers.net. 172800 IN A 192.54.112.30
> d.gtld-servers.net. 172800 IN A 192.31.80.30
> j.gtld-servers.net. 172800 IN A 192.48.79.30
> k.gtld-servers.net. 172800 IN A 192.52.178.30
> g.gtld-servers.net. 172800 IN A 192.42.93.30
> l.gtld-servers.net. 172800 IN A 192.41.162.30
> e.gtld-servers.net. 172800 IN A 192.12.94.30
> b.gtld-servers.net. 172800 IN A 192.33.14.30
> b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30
> a.gtld-servers.net. 172800 IN A 192.5.6.30
> a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30
>
> ;; Query time: 47 msec
> ;; SERVER: 2001:503:231d::2:30#53(2001:503:231d::2:30)
> ;; WHEN: Sun Dec 21 11:26:44 2014
> ;; MSG SIZE rcvd: 520
>
> Are the IP addresses in the additional section "authoritative data"?
> This server is not authoritative for gtld-servers.net...
>
>
>
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
